第1章 設計とアークテクチャ
著者見解
設計もアーキテクチャも、本質的には同じことを指します。一般には「アーキテクチャ」は上位レベルの構造、「設計」はその下位の詳細を指すことが多いですが、実際には上位と下位は連続していて、両方ともシステム全体の設計の一部です。どちらが欠けても良いシステムは作れません。
では、設計／アーキテクチャの目的は何でしょうか。端的に言えば「必要な人手を最小限にして、求められるシステムを継続的に作り続けられる状態にすること」です。設計やコードが雑だと、リリースを重ねるごとに修正や調査にかかるコストが増え、同じ人数でも新機能をほとんど追加できなくなります。たとえば初期は数百万ドルで済んでいた開発が、何度も手戻りを繰り返すと何千万ドルもかかるようになる、というのはよくある話です。
多くのチームは「まずは市場に出すために雑に作り、あとできれいにする」と考えがちですが、これが誤りであることも示されています。短期的には速く見えても、結局は後で手戻りが増えて長期的に遅くなります。実証的な例として、TDD（テスト駆動開発）を使った場合の方が、使わなかった場合よりも全体的に早く完了する、という実験結果もあります。つまり「速く進めたければ、きちんと進めること」が最短の道なのです。
まとめると：
- アーキテクチャと設計は連続した同じ仕事であり、両方を適切に行うことが必要
- 目的は「最小の人員で長期にわたり開発・保守できる状態をつくること」
- コードを後回しにすると短期的には見かけ上速くても、結局は大きな遅延とコスト増を招く
- テストやリファクタリングなど「きれいに作る投資」は、長期的な速度と品質を支える
筆者所感
人の記憶には限界があり、数ヶ月前の自分のコードを思い出せないことはよくあります。スパゲッティコードだと内容が一目で分からず、結局また一から追い直す必要が出てきます。きれいなコードはドメインの意図をそのまま伝えてくれるので、後で読む人（自分も含め）の負担を大幅に減らします。「あとでリファクタすればいい」はたいてい実行されず、結果として遅延とコスト増を招くため、最初から読みやすく設計・実装することが結局いちばんの近道です。
第2章 2つの価値のお話
著者見解
ソフトウェアがステークホルダーに提供する価値は大きく分けて二つあります。一つは「振る舞い」（要求される機能を実現すること）、もう一つは「構造」（変更しやすさや再利用しやすさなどソフトウェア自体の性質）です。ところが多くの現場では、目に見える「振る舞い」に注力するあまり、「構造」を軽視してしまいがちです。マシンが要件どおり動けばよい、バグが出たら直せばいい——そう考えると短期的には成果が出ますが、長期的には問題が膨らみます。
「構造」の価値が重要なのは、ソフトウェアを“ソフト（柔軟）”に保つためです。ステークホルダーが機能の変更を望んだときに、簡単に対応できることが求められます。本来、変更の難しさは「変更する範囲（スコープ）」に比例すべきであって、ソフトウェアの形（アーキテクチャ）が合っていないために同じスコープの変更でも大掛かりな作業になるべきではありません。ところが設計やアーキテクチャが特定の「形」を選んでしまうと、新しい機能がその形に合わず、次第に修正が難しくなっていきます。まるで「四角い杭」を「丸い穴」に無理やり打ち込むような状況です。
価値の優先度を考えるために、極端な例を比べてみましょう。完璧に動くがまったく変更できないプログラムと、動作は不完全でも修正が容易なプログラム。前者は要件が変われば使い物にならなくなりますが、後者は将来も役に立ち続けられます。現実には極端なケースは稀ですが、変更コストが高すぎて事実上変更不能になっているシステムは存在します。
ここでアイゼンハワーの「重要度と緊急度のマトリックス」を当てはめてみると分かりやすくなります。ソフトウェアの「振る舞い」は目に見えるため緊急であることが多い一方、必ずしも重要とは限りません。一方「構造」は重要ですが必ずしも緊急ではありません。多くのビジネス側やマネージャーは「今すぐ動くこと」を優先しがちで、アーキテクチャの重要性を見落とします。そのため開発チームは、短期的なプレッシャーに屈せず、構造（アーキテクチャ）の重要性を説得し、必要な時間や投資を確保する責任があります。
この責任は時に対立を伴いますが、放置すれば開発コストは雪だるま式に増え、やがてシステムの一部または全部が変更不能になってしまいます。だからこそ、チームはステークホルダーと対話し、設計上の選択とその将来的な影響を説明し、リファクタリングや設計改善のための工数を確保する必要があるのです。
筆者所感
私は現在、自社SaaSの現場にいて、継続的なリファクタリングができる環境にあります。プロダクトが成熟していて短期的なビジネス要求も落ち着いているため、「構造」に投資しやすい状況です。対照的に、以前の受託案件では納品で終了することが多く、次の保守や二次開発の確約がないため、構造を重視するインセンティブが働きません。現実には、プロダクトや組織の事情でリファクタリングできない場面は多く、だからこそルール化が重要になります。たとえばアジャイルならスプリント内の工数の何割かをリファクタリングに割り当てる、ウォーターフォールや外注案件なら契約・設計段階で保守時間を確保する、といった制度的な仕組みを作る必要があります。日常的には厳格なコードレビューに加えて、CI/CD上での構造チェック（静的解析、テストカバレッジやアーキテクチャルルールの自動検査など）を導入することで、品質維持を現場の手間に頼らず持続可能にできます。