開発持続性（Development Sustainability）という概念を提唱したい~開発者体験だけでは足りない~

はじめに（開発者体験の限界と開発持続性の意義）

近年、ソフトウェア開発では「開発者体験（Developer Experience、DX）」が重要視され、開発生産性に関する書籍の出版や、エンジニアが選ぶ「開発者体験が良い」イメージのある企業も大いに盛り上がっています。開発者が効率的に、そして楽しく仕事ができる環境を整えることで、生産性を向上させるという考え方です。しかし、開発者体験に焦点を当てることは非常に有益ではありますが、当面は継続的な成功を保証するとは限らず、長期的な視点での持続可能性を見落としがちです。この記事では、長期的な視点を持った「開発持続性」の考慮を薦めたいと思います。

開発持続性とは何か？

開発持続性とは、プロジェクトや製品のライフサイクル全体を通して、長期的に持続可能な開発を実現するための総合的なアプローチです。

• 技術上の限界の管理: 技術的な限界を極力抑え、定期的に解消することで、長期プロジェクトの健全性を検討します。トレンド等の変更により技術的限界に直面した場合にはリニューアルを検討します。
• エコシステムとの調和: 使用しているライブラリやツールが時代遅れにならないよう、継続的にアップデートを行い、エコシステムへの追随が必要です。
• 組織拡大への順応: たいていはサービスの成長とともに開発組織も拡大していくので、技術戦略と組織拡大のすり合わせも重要な要素です。

開発持続性が損なわれている例

以下は筆者が実際に見聞きした一例です。

• NoSQLで作成したが、RDBに切り替える
  • 「管理画面」を作る際にNoSQLだと辛くなりがち。
• 最初にRailsなどのフルスタックフレームワークで作成したが、新規機能開発は速度を上げるためにGoのマイクロサービスで開発する。
  • アーキテクチャの歴史を知っているならまだしも、途中参画したメンバーにとってモジュールの境界が意味不明になる。キャッチアップがつらい。
• 初期メンバーが得意な技術(Typescript + Java + Rust等)を持ち寄って作ったが、最初から1つの言語(Typescript)で統一した方がよかった。
  • 組織のメインストリームを外れた技術が見事に属人化する。導入したメンバーが辞めると残ったメンバーが疲弊する。
• 「俺の考える最強の技術選定」と称して、実際には「自分が開発しやすいから」という理由で軽い/薄い技術(フレームワーク等)が導入される。
  • 特に薄いフレームワークは個々人が自由に書けてしまうので、組織拡大とともに書き方が統一されていない、品質が安定しないなどの問題が表面化する。結果、組織の成長とともに品質管理部隊の肥大化と、無駄に長いコーディング規約が誕生する。
• 近い将来、EOLを迎えるとわかっている技術(Vue2等)で新規機能開発を行う。
  • Vue3にしてもReactにしてもリプレイスがさらに大変になる。

とりあえず作ったけど、あとが大変！みたいパターンは多いような気がします。

おまけ：建築業界では技術的限界を超えると"違法"

「2階建てのアパートを建てて空室が無くなったから、住人を維持しながら10階建てのマンションにエンハンスする」ことができるだろうか？
知っているか？当初の予定から勝手に増築して建ぺい率をオーバーすると、違法建築なんだぜ？
https://sawada.co.jp/library/construction/568/

違法建築でも罰則はないらしいです。

そしてかつて世界最大の違法建築だった「九龍城砦」はスラム街なんだぜ？
https://nlab.itmedia.co.jp/nl/articles/2306/12/news120.html

IT分野でも、開発持続性を考えず技術的限界を超えてエンハンスするのは、NGにしたほうがいいのでは？

開発持続性の実現に向けて

• 長期視点での開発体制の構築
• 息の長い技術の採用
• 技術的限界を迎えないためのアーキテクチャ設計

以上のことも今後の開発に最重要項目として考慮した方がいいと思います。

まとめ

「エンジニアが選ぶ"開発持続性"が良いイメージのある企業」をもし開催することになったら、弊社に一票お願いします。