Category: 法則
Type: 組織理論
Origin: プログラミング、1957年、メルヴィン・コンウェイ
Also known as: コンウェイの相関定理
Type: 組織理論
Origin: プログラミング、1957年、メルヴィン・コンウェイ
Also known as: コンウェイの相関定理
先に答えると —
コンウェイの法則は、システムを設計する組織は、その組織のコミュニケーション構造のコピーである設計を生み出さざるを得ないと述べています。1957年にメルヴィン・コンウェイによって定式化されたこの原則は、なぜソフトウェアアーキテクチャがチーム構造を反映するのか、なぜサイロ化した組織がサイロ化したシステムを作り出すのか、そしてなぜクロスファンクショナルチームがより統合されたソリューションを生み出せるのかを説明します。
コンウェイの法則（Conway’s Law）とは
コンウェイの法則は、ソフトウェアエンジニアリングと組織設計における根本的な原則であり、組織のコミュニケーション構造とそれが生み出すシステムの関係を記述します。この法則は、あらゆるシステムはそれを構築した組織のコミュニケーションパターンを反映せざるを得ないと述べています。「システムを設計する組織は、これらの組織のコミュニケーション構造のコピーである設計を生み出すように制約される。」——メルヴィン・コンウェイ直感的に言えば、人々はコミュニケーションできることしか構築できません。エンジニアリングチームが最小限のコミュニケーションしかないフロントエンドグループとバックエンドグループに分かれて組織化されている場合、システムもおそらく対応する分離を持つことになります——2つの間に定義されたAPI境界線ができます。チームがビジネス機能を中心に組織化されている場合、システムもその構造を反映する傾向があります。 この法則は、組織の設計方法、システムのアーキテクチャ、組織変化の考え方について深遠な含意を持ちます。
コンウェイの法則を3つの深さで理解する
- 初心者: チームの境界はしばしばシステムの境界になることを認識しましょう。異なるシステムの境界が欲しいなら、異なるチーム構造が必要です。
- 実践者: コンウェイの法則を意図的に活用しましょう——望ましいシステムアーキテクチャに合ったチーム構造を作りましょう。これはときに「逆コンウェイ作戦」と呼ばれます。
- 上級者: コンウェイの法則は複数のスケールで機能することを理解しましょう——部門、チーム、個々の開発者でさえ、コードに表れる個人の「アーキテクチャ」を持っています。
起源
メルヴィン・コンウェイ（1934年生まれ）は、1957年に「委員会はどのように発明するか（How Do Committees Invent?）」という論文でこの概念を紹介したアメリカの計算機科学者かつプログラマーです。この論文は後に短縮され、1967年に「コンウェイの法則」として再発表されました。 コンウェイの洞察は、委員会や組織がどのようにシステムを設計するかを観察することから生まれました。彼は、結果として得られるシステムの構造が、それを生み出したグループの構造を必然的に反映することに気づきました。この観察は、それ以来、業界や数十年にわたって無数に検証されてきました。 「コンウェイの法則」というフレーズは、1968年の出版物で著者ノーマン・F・ネイマンによって造語されましたが、原則自体は完全にコンウェイのものです。要点
コミュニケーションのボトルネックがシステムのボトルネックになる
2つのチームがめったにコミュニケーションしない場合、それらのシステムコンポーネント間のインターフェースは設計が不十分で、文書化されておらず、変更が困難になります。
クロスファンクショナルチームは統合されたソリューションを可能にする
多様な専門知識（デザイン、バックエンド、フロントエンド、運用）を含むチームは、サイロ化したグループよりも包括的なシステムを生み出すことができます。
応用場面
組織設計
新しいシステムを設計したり再構築したりする際、チームの境界を望ましいシステムの境界に合わせましょう。これが「逆コンウェイ作戦」です。
アーキテクチャ計画
システムアーキテクチャを設計する前に、組織のアーキテクチャを検討しましょう。どのようなチームが存在するか？それらはどのようにコミュニケーションするか？これが実際に達成可能なアーキテクチャを明らかにします。
M&A統合
合併や買収後、システムを統合するにはまず組織を統合する必要があることを認識しましょう。古いチーム構造は新しいシステムアーキテクチャに抵抗します。
DevOps変革
DevOpsとプラットフォームエンジニアリングのイニシアチブは、コンウェイの法則を無視すると失敗することがよくあります。OpsとDevが別々の報告ラインにある場合、DevOpsカルチャーを持つことはできません。
事例
MIMEプロトコル
1974年、メルヴィン・コンウェイは有名なメモ（後に「コンウェイの相関定理」と呼ばれた）を書き、提案された連邦データ共有標準がどうなるかを予測しました。彼は次のように書いています。「連邦機関のデータ処理プロジェクトが十分に重要である場合、結果として得られるシステムは連邦機関のような構造を持つでしょう。」 この予測は、IETFがMIME電子メール標準を開発したときに有名な検証を受けました。技術標準であったにもかかわらず、MIMEはそれを作成した企業の組織構造を反映していました。各企業の電子メールシステムにはそれぞれの特徴があり、標準は基本的にこれらの組織の違いを技術プロトコルにエンコードしたものでした。 教訓：複数の組織がシステムで協力するとき、最終的な設計はそれらのすべてのコミュニケーション構造を反映します——それは多くの場合、レガシーパターンの寄せ集めです。限界と失敗パターン
この法則が適用されない場合:- 強力なアーキテクチャリーダーシップ: 非常に影響力のあるアーキテクトやCTOは、一時的であれ、組織構造とは異なるシステム構造を課せることがあります。
- 外部の制約: 規制要件、顧客の命令、レガシーシステム統合は、アーキテクチャに対する組織の影響を上書きすることがあります。
- 小規模チーム: 非常に小さなチーム（5〜8人未満）は、硬直的な構造上の制約を課さないインフォーマルなコミュニケーションを維持できます。
- コンウェイの法則を言い訳にする: チーム構造のせいで特定のアーキテクチャを「作れない」と主張するチームは、構造を変えようとしません。
- 再編成時に無視する: 組織は既存システムへの影響を考慮せずに再編成することが多く、アーキテクチャとチームの不一致につながります。
- 法則を過度に適用する: すべてのコードモジュールが特定の人を反映しているわけではありません。一部のコードは本当にジェネリックです。
よくある誤解
コンウェイの法則はソフトウェアにのみ適用される
コンウェイの法則はソフトウェアにのみ適用される
違います。
この法則は、グループによって設計されたあらゆるシステム——建物、プロセス、ポリシー、さらには社会構造——に適用される根本的な組織現象を記述しています。
この法則は組織の階層がシステムの階層に等しいことを意味する
この法則は組織の階層がシステムの階層に等しいことを意味する
違います。
報告ラインではなくコミュニケーションパターンに関するものです。同じマネージャーに報告しても互いに話さない2つのチームは、やはりサイロ化したシステムを作り出します。
コンウェイの法則は常に悪いものである
コンウェイの法則は常に悪いものである
違います。
この法則は記述的であって規範的ではありません。適切なチーム構造があれば、コンウェイの法則は一貫したシステムを作成するのに役立ちます。鍵は組織とシステムの両方を意図的に設計することです。
関連概念
コンウェイの法則は、ソフトウェアアーキテクチャ、組織設計、チームダイナミクスにおけるより広範なテーマとつながっています。マイクロサービス（Microservices）
システムを小さく独立したサービスに分解するアーキテクチャスタイル——多くの場合、小さく独立したチームを反映しています。
チームトポロジー（Team Topologies）
コンウェイの法則を意図的に活用し、システムアーキテクチャを中心にチームを編成するフレームワーク。
クロスファンクショナルチーム（Cross-Functional Teams）
価値を提供するために必要なすべてのスキルを含むチーム——受け渡しを減らし、統合されたソリューションを可能にします。
API設計（API Design）
システムコンポーネント間のインターフェースは、多くの場合チーム間のコミュニケーション境界を反映します。
境界付けられたコンテキスト（Bounded Context）
ドメイン駆動設計において、ドメインモデルを分離する境界——多くの場合チームの所有権に合わせて配置されます。
アーキテクチャガバナンス（Architecture Governance）
システムアーキテクチャが組織の目標と技術標準に一致することを保証するメカニズム。