マイケル・ハーマーアーキテクチャーを設計するときには、その導きの糸として、原理原則に明確に従うようにすべきです。すれば、単に自分の経験、意見、趣味でシステムを作ったときよりもメリットが得られます。アーキテクチャーのドキュメントが簡単になります。どのような原則に従ったかを書くところからスタートできます。あなたの意見や経験を説明するよりもずっと楽です。原理原則は、アーキテクチャーを理解し、実装するデベロッパーたちに、手がかりを与えることもできます。あなたのアーキテクチャーを引き継ぐアーキテクトがあまり経験をつんでいなくても、原理原則がはっきりしていれば何かと便利です。明確な原則を持つアーキテクチャーは、何から何まで面倒を見ることからアーキテクトを解放します。レバレッジや影響が大きくなるのです。全能のワーカホリックとしてチームメンバーの次のような仕事をいちいち監督する必要はなくなります。境界条件の細かいチェック見解や趣味の違いは、権威のある方が勝つ政治的な議論を引き起こします。基本原則が明確になっているところで意見が違う場合には、個人の人格をかけた争いにはならず、理性的に議論を進めることができます。アーキテクトが立ち会わなくても、意見の相違を解決できます。原理原則に従えば、実装全体を通じて、また時間を越えて一貫性の取れたアーキテクチャーが得られます。複数のテクノロジーを使い、何年も使われる大規模なシステムでは、特に一貫性がよく問題になります。明確な原則に従ってアーキテクチャーを設計すれば、特定のテクノロジーやコンポーネントをよく知らない人々でも、その知らない部分を早く理解できます。ソフトウェアアーキテクトが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。