アーキテクチャと実装を分離したときに、実装不可能な仕様やコストを度外視した機能をアーキテクトがアーキテクチャに盛り込むのを防ぐ方法として以下のものがある。
- アーキテクトと実装担当者の間で、徹底的に、注意深く、そして、思いやりを持ってコミュニケーションを行う。
- コストの見積もりを良くする方法として、開発初期から継続してアーキテクトと実装担当者がコミュニケーションを持つことがある。
- コストの折り合いがつかないときには、アーキテクトが実装を提案したり、実装担当者がアーキテクチャに対する変更を提案したりしても良い。しかし、アーキテクチャと実装の分離を念頭に置き、相手の領分に対して提案しているのだということや、感情的にならないことに気をつけて行うこと。（これらの注意事項の詳細は、第5章の「Interactive Discipline for the Architect」の項を参照のこと。）
続いて以下は、後述の「The Second-System Effect」を念頭に置いた対策である。
- アーキテクトは、設計のしすぎ、つまり、無駄だったり価値の低かったりする機能や仕様を作っていないかについて、自身にとって2つめとなるシステムを設計するときは特に気をつける。
- システムの基本的前提や目的が変化していないかに注意する。時代遅れになっている技術の改良にコストを注ぎ込んでしまい、新たに必要になっている技術への取り組みが不足することになっていないかに注意をする。
- それぞれの小さな機能に対して、その機能に見合う代償を割り当てておく。例えば、メモリ使用量などの具体的なリソース使用上限を割り当てておく。この割り当ては、実装作業中にもガイドや警報装置として役に立つ。
以下は、プロジェクトマネージャーの立場からの対策である。
- 既に2つ以上のシステムを設計したことがある人をシニアアーキテクトにする。
- 無駄な物を作ることに駆り立てる要因を念頭に置いて、設計の詳細がシステムのコンセプトと目的に合致しているかを確認するための質問を考え、投げかける。
The Second-System Effect（セカンドシステム症候群）
2つめのシステム設計は、設計しすぎになりやすく、最も危険である。著者はこれを「The Second-System Effect」と名付けた。
その理由は以下の通りである。
- 初めてのシステムを設計するときは、注意深く自重しながら設計するものである。そして、初めてのシステムでは見送って、次回、つまり2つめのシステムに取って置かれた事項が溜まるものである。
- 3つめ以降のシステムを設計するときには、2つ以上のシステムの設計経験があるため、その経験の中からシステムに共通する一般的な性質や各システムで異なる特徴を確認することが出来る。
他の章はこちらから：
「人月の神話」の要点
人月の神話の要点・ポイントをまとめています。原著に基づき、人月の神話の要点・ポイントを主に箇条書き形式でご紹介しています。
picolab.dev
2022.04.18
