変更が難しいものは、深く設計して、ゆっくりと実装する / 「ソフトウェアアーキテクトのための意思決定術」

はじめに「Done is better than nothingは正しいのか？」

「Done is better than nothing」というネットミームがあります。

このミームはマークザッカーバーグの画像と共に用いられることが多く、日本語では「まず完成させろ」「しょぼくてもいいから完成させろ」みたいな意訳がされることが多いです。

このミームに関してX上で「めちゃくちゃ共感した！」というジュニアエンジニアの方がいたのですが、そうではない部分もあるのではないかと思っています。

というのも、ソフトウェアについては一度リリースしてしまうと変更が難しい類のものがあります。

顧客に直接公開されるAPI

共有範囲の広いサービスAPI

データベーススキーマ（顧客環境内のデータベースを使用するプロダクトをデプロイする場合）

共有データ、オブジェクト、メッセージ形式

技術フレームワーク

ソフトウェアアーキテクトのための意思決定術 p33

例えば、顧客に公開されるAPIのインターフェースをサービスリリース後に変更しようと思うと、「顧客調整した上で、インターフェースをv1、v2に分けて徐々にv1を廃止する」といった対応が必要になります。

この例の場合、変更が完了するタイミングはv1インターフェースが廃止されるタイミングになると思うので、APIインターフェースの変更にかなりの時間がかかることがわかると思います。

また、顧客の環境にデプロイされるDBのスキーマについても変更が難しいことは容易にわかると思います。

これも顧客調整が必要であることが理由ですね

また「DBのライフサイクルはアプリケーションコードよりも長い」と言われたりするように、一度顧客のデータが作成されたDBを変更することはかなりリスキーなので変更のハードルが高いです。

他には「技術フレームワーク」もなかなか変更が難しいです。

例えばRuby on RailsなどのWebフレームワークを利用している中で、性能がでなくなったのでRustで書き換えたいとなった場合、丁寧にやろうと思うと以下のような手順を踏む必要があり、かなりの時間がかかります。

[UTの作成] 性能が出ない箇所にUTを追加する
[モジュール化] 性能が出ない箇所をリファクタリングして粗結合なモジュールにする
[E2Eテストの作成] E2Eテストを整備してリアーキテクチャ時の品質を担保する
[マイクロサービスの実装] Rustでマイクロサービスを作成する
[呼び出し元の修正] Ruby on RailsからRustのマイクロサービスを呼び出すように修正する（適宜フィーチャーフラグで呼び出し先をモジュール<->マイクロサービスで切り替えられるようにする
適宜リグレッションテストを実施する
[リリース] Rustのマイクロサービスをリリースする
[モジュールの削除] 後に安定したら、Ruby on Railsの対象モジュールを消す

このように後から変更が難しいと思われるものは、「深く設計して、ゆっくりと実装する」のが良いと「ソフトウェアアーキテクトのための意思決定術」で紹介されています。

設計では、APIやデータベーススキーマのような箇所の設計に多大なエネルギーを費やす必要がある。こうした箇所の設計は、顧客に提供する前に、多くのレビューやイテレーションを経なければならない。

ソフトウェアアーキテクトのための意思決定術 p33

具体的には、変更が難しいものは

「要件定義時にスコープを限定する」

「性能要件を丁寧に定義する」

「ドメインエキスパートにユースケースについてヒアリングする」

「後から修正しやすいようにビジネスロジックに対して粗結合に設計する」

「ユーザのリアクションをもらいつつ少しずつ実装することでドメイン理解を深めつつ精度高く開発を進める」

などの工夫を惜しまないのが大事ですね。

反対に後から変更しやすいものは、とっとと実装して、実装のFBをもとに必要な要件を確定させていき、それに合わせて設計を固めるほうがコスパが良いかもしれないなと思いました。

たとえば、テストコード・プロトタイプなどは変更が容易だと思うので、さっと実装してユーザのFBを迅速に得て設計を改善することで、スピード感を持ちつつ精度高く設計をすることが可能になると思われます。

「ソフトウェアアーキテクトのための意思決定術」, https://amzn.to/4hJTV5S (アマゾンのアフィリエイトリンクを利用しています。)