コンウェイの法則

ソフトウェアアーキテクチャの実践者のほとんどが、この分野における一般的な法則には非常に懐疑的です。優れたソフトウェアアーキテクチャはコンテキストに大きく依存し、幅広い環境で異なる解決策となるトレードオフを分析します。しかし、彼らが皆同意するものが一つあるとすれば、それはコンウェイの法則の重要性と力です。それは私が遭遇したすべてのシステムに影響を与えるほど重要であり、それに立ち向かおうとすれば失敗する運命にあるほど強力です。

この法則は、おそらくその著者によって次のように述べられるのが最良でしょう：[1]

システム（広義で定義）を設計する組織は、組織のコミュニケーション構造を模倣した構造の設計を生み出す。

-- メルビン・コンウェイ

コンウェイの法則は、基本的にソフトウェアシステムのアーキテクチャが、それを構築した開発チームの組織と驚くほど似ているという観察です。最初に私に説明されたのは、単一のチームがコンパイラを作成すると、それは1パスコンパイラになるが、チームが2つに分割されると、それは2パスコンパイラになるというものでした。通常はソフトウェアに関して議論しますが、この観察は一般的にシステムに広く適用されます。[2]

私の同僚であるクリス・フォードが私に言ったように、「コンウェイは、ソフトウェアの結合は人間のコミュニケーションによって可能になり、促進されることを理解していました」。もし私がコードの作者と簡単に話せるなら、そのコードについての深い理解を深めることが容易になります。これにより、私のコードがそのコードと相互作用し、したがって結合することが容易になります。明示的な関数呼び出しだけでなく、暗黙的な共有された前提や問題領域についての考え方においても同様です。

私たちは、この法則への不注意がシステムのアーキテクチャをどのように歪めるかを見ることがよくあります。もしアーキテクチャが開発組織の構造と矛盾するように設計されていると、ソフトウェア構造に緊張が現れます。本来は簡単であるはずのモジュール間の相互作用が複雑になるのは、それらの担当チームがうまく連携していないからです。必要な開発グループがお互いに話をしていないため、有益な設計の代替案は考慮すらされません。

10人から20人程度の人は、深く非公式なコミュニケーションをとることができるので、コンウェイの法則は彼らがモノリスを作成することを示唆しています。それは問題ありません。したがって、小規模なチームではコンウェイの法則は私たちの考えに影響を与えません。人間を組織する必要が出てきたときに、コンウェイの法則が意思決定に影響を与えるべきです。

コンウェイの法則に対処する最初のステップは、それに立ち向かわないことを知ることです。私は、世界中の異なる都市に6つのチームがある大規模な新規プロジェクトのアーキテクトに任命されたばかりの、ある優れた技術リーダーのことを今でも覚えています。「最初のアーキテクチャ上の決定を下しました」と彼は私に言いました。「6つの主要なサブシステムが存在することになるでしょう。それが何になるかは見当もつきませんが、6つになるでしょう。」

この例は、場所が人間のコミュニケーションに大きな影響を与えることを認識していました。同じ建物の別の階にチームを配置するだけでも、コミュニケーションを大幅に減らすのに十分です。別の都市やタイムゾーンにチームを配置すると、定期的な会話がさらに妨げられます。アーキテクトはこれを認識し、技術的な設計で最初からこれを考慮に入れる必要があることを理解しました。異なるタイムゾーンで開発されたコンポーネントは、その作成者が容易に話すことができないため、明確に定義された限定的な相互作用を持つ必要がありました。[3]

コンウェイの法則との一般的な不一致は、アクティビティ指向のチーム組織が、機能開発と対立して働く場合です。ソフトウェアレイヤー（フロントエンド、バックエンド、データベースなど）で編成されたチームは、主要なPresentationDomainDataLayering構造につながり、各機能はレイヤー間の密接な連携を必要とするため、問題があります。同様に、ライフサイクル活動（分析、設計、コーディング、テスト）に沿って人々を分割することは、機能のアイデアから生産までを達成するために多くの引き継ぎが必要であることを意味します。

コンウェイの法則を受け入れることは、それを無視するよりも優れており、この10年間で、この法則に対応する3番目の方法を目にしました。ここでは、意図的に開発チームの組織構造を変更して、望ましいソフトウェアアーキテクチャを促進します。これは、逆コンウェイ作戦と呼ばれるアプローチです[4]。このアプローチは、マイクロサービスの世界でよく話題になり、そこで提唱者は、顧客価値を提供するために必要なすべてのスキルを含む、小規模で長期的なビジネスケイパビリティ中心のチームを構築することを推奨しています。このように自律的なチームを組織することで、コンウェイの法則を利用して、互いに独立して拡張および展開できる同様に自律的なサービスを促進します。これがまさに、私がマイクロサービスを主に開発組織を構造化するためのツールとして説明する理由です。

逆コンウェイ作戦は便利なツールですが、万能ではありません。変更したい硬直したアーキテクチャを持つ既存のシステムがある場合、開発組織を変更してもすぐに修正されるわけではありません。代わりに、開発者とコードの間に不一致が生じ、さらなる機能強化に摩擦が生じる可能性が高くなります。このような既存のシステムでは、コンウェイの法則の要点は、組織とコードベースの両方を変更する際に、その存在を考慮に入れる必要があるということです。そしていつものように、フィードバックに注意しながら小さなステップを踏むことをお勧めします。

ドメイン駆動設計は、DDDの重要な部分が境界づけられたコンテキストを特定することであるため、組織構造を定義するのに役立つコンウェイの法則の役割を果たします。境界づけられたコンテキストの重要な特徴は、そのコンテキストで作業する人々のグループによって定義および理解される、独自のユビキタス言語を持つことです。このようなコンテキストは、価値の流れに沿って配置できる主題を中心に人々をグループ化する方法を形成します。

コンウェイの法則について覚えておくべき重要なことは、システムのモジュール分解と開発組織の分解を一緒に行う必要があるということです。これは最初だけではなく、アーキテクチャの進化と人間組織の再編成は、エンタープライズのライフサイクル全体を通して密接に行われる必要があります。