コンウェイの法則

私が敬愛するソフトウェアアーキテクチャの専門家たちは、この分野のあらゆる一般法則に対して懐疑的です。 優れたソフトウェアアーキテクチャはコンテキストに固有であり、さまざまな環境下で異なる解決をしなければならないトレードオフを分析するものだからです。 とはいえ、彼ら全員が同意するものがひとつだけあります。 それは、コンウェイの法則の重要性とパワーです。 私がこれまでに経験したすべてのシステムに影響を与えるほど重要であり、抗えないほどのパワーがあります。

この法則を説明するには、作者の言葉がいちばんでしょう¹。

システム（広義に定義）を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。
―メルヴィン・コンウェイ

コンウェイの法則とは、ソフトウェアシステムのアーキテクチャは開発チームの組織とよく似る、というものです。 元々は、1つのチームでコンパイラーを作るとワンパスのコンパイラーになり、2つのチームでコンパイラーを作るとツーパスのコンパイラーになる、というものでした。 通常はソフトウェアに関するものですが、システム全般に広く適用されます²。

設計者のコミュニケーションのやり方が...
...システムの設計に制約を与える

同僚のChris Fordが私に言ったように「ソフトウェアの結合は人間のコミュニケーションによって可能になり、強化されるものであることをコンウェイは理解していました」。 コードの作成者と簡単に話をすることができれば、私はそのコードを深く理解できます。 私のコードはそのコードとやり取りしやすくなり、両者は結合していくでしょう。 結合とは明示的な関数呼び出しのことだけではありません。 暗黙的な共有理解や問題領域に対する考え方なども含まれます。

この法則に注意を払っていないと、システムアーキテクチャにねじれが生じます。 アーキテクチャが開発組織の構造と違った形で設計されていると、ソフトウェアの構造に緊張が生まれます。 素直に設計されたモジュールのやり取りが複雑になっていきます。 それらを担当するチームがうまく連携できないからです。 開発グループ同士が話し合わないので、有益な設計の代替案も考慮されません。

10〜20人程度であれば、非公式に深くコミュニケーションできます。 コンウェイの法則に従えば、彼らはモノリスを生み出すことになるでしょう。 特に問題はありません。 小規模のチームであれば、コンウェイの法則が考え方に影響を与えることはありません。 コンウェイの法則が意思決定に影響を与えるのは、人間が組織化を必要とするときです。

コンウェイの法則に対応する最初のステップは、抗わないことです。 ある優秀なテクニカルリーダーのことを今でも覚えています。 そのリーダーは、世界中の都市にいる6つのチームで構成された、大規模な新規プロジェクトのアーキテクトに任命されたばかりでした。 彼は私にこう言いました。 「最初のアーキテクチャを決めました。6つの主要なサブシステムにする予定です。それぞれ何になるかはわかりませんが、数は6つになると思います」

この例では、場所が人間のコミュニケーションに大きな影響を与えることが認識されています。 同じ建物であってもチームを別々のフロアに配置するだけで、コミュニケーションが大幅に減少します。 異なる都市や別々のタイムゾーンにチームを配置すると、日常的な会話がさらに妨げられます。 このアーキテクトはそのことを認識しており、技術的な設計では最初から考慮しておかなければならないことを理解していました。 異なるタイムゾーンで開発されたコンポーネントは、相互のやり取りを厳密に定義して制限する必要がありました。 作成者同士が簡単に話せなかったからです³。

コンウェイの法則のよくあるミスマッチは、アクティビティ指向のチーム組織がさまざまな目的で機能開発をしている場合です。 ソフトウェアレイヤー（フロントエンド、バックエンド、データベースなど）で組織化されたチームは、プレゼンテーションドメインデータレイヤリングの構造になります。 これには問題があります。 機能ごとにすべてのレイヤーでコラボレーションが必要になるからです。 同様に、ライフサイクルのアクティビティ（分析、設計、実装、テスト）で組織を分割すると、機能をアイデアから実装するまでに何度も受け渡しが必要になってしまいます。

コンウェイの法則を受け入れることは無視するよりも優れていますが、この10年間で3番目の方法が見られるようになりました。 開発チームの組織構造を変更して、望ましいソフトウェアアーキテクチャを目指すというものです。 これは逆コンウェイ作戦と呼ばれるアプローチです⁴。 このアプローチは、マイクロサービスの世界でよく話題に上ります。 マイクロサービスの支持者たちは、顧客価値を提供するためのすべてのスキルを持つ、小規模で寿命の長いビジネスケイパビリティ中心のチームを作ることを推奨しています。 このような自律的なチームを編成し、コンウェイの法則を利用することで、チームと同様の自律的なサービスを促進するのです。各サービスは独立して改良およびデプロイできます。 私が「マイクロサービスは開発組織の構造を作るためのツールである」と説明するのはそのためです。

逆コンウェイ作戦は便利なツールですが、万能ではありません。 既存のシステムのアーキテクチャに柔軟性がない場合、それを変更しようとして開発組織を変更しても即効性はありません。 むしろ開発者とコードにミスマッチが生まれ、変更に摩擦が生じる可能性が高くなります。 このような既存のシステムでは、コンウェイの法則の存在を考慮しながら、組織とコードベースの両方を変更する必要があります。 いつものように、フィードバックに気を配りながら小さなステップで進めることをお勧めします。

ドメイン駆動設計（DDD）はコンウェイの法則において重要な役割を果たします。 DDDで重要となるのは境界づけられたコンテキストを特定することなので、組織構造の定義を支援します。 境界づけられたコンテキストの特徴は、独自のユビキタス言語を持ち、そのコンテキストで働く人たちが言語を定義および理解できることです。 そのようなコンテキストが、価値の流れに沿ったテーマの周囲に人々を集める方法になります。

コンウェイの法則で覚えておきべきことは、システムのモジュール分解と開発組織の分割は同時に行わなければならない、ということです。 これは最初だけではありません。 アーキテクチャの進化と人間組織の再編成は、企業が存続する限り密接に連携させなければなりません。

さらに詳しく知るために

コンウェイの法則の重要性を認識するというのは、これからのソフトウェアアーキテクトはIT組織の設計について考えなければならないことを意味します。 このトピックに関する価値ある2冊は、Narayanの『Agile IT Organization Design』とSkeltonとPaisの『Team Topologies』です。

Birgitta Böckeler、Mike Mason、James Lewisと私は、ThoughtWorks Technology Podcastでコンウェイの法則の経験を話し合っています。

謝辞

Bill Codding、Birgitta Boeckeler、Camilla Crispim、Chris Ford、Gabriel Sadaka、Matteo Vaccari、Michael Chaffee、Unmesh Joshiは、この記事の草稿をレビューして、改善点を提案してくれました。

更新履歴

2022-10-24: 逆コンウェイ作戦と柔軟性のないアーキテクチャに関する段落を追加しました。また、リモートファーストの働き方に関する脚注も追加しました。

脚注