【こんうぇいのほうそく】
コンウェイの法則 とは？
最終更新:
💡 人の間のやり取りが、システムの境界にも表れやすい
システムを設計する組織のコミュニケーション構造が、そのシステムの構造にも反映されやすいという考え方。組織図との違い、チーム数と部品数が必ず一致しない理由、逆コンウェイ戦略を解説します。
📌 このページのポイント
- 組織のコミュニケーション構造と、設計するシステムの構造を関連付ける
- 組織図だけでなく、実際の相談や調整の仕方を見る
- チーム数とモジュール数が必ず1対1で一致する法則ではない
- 望む設計に合わせた連携と、既存コードの変更を一緒に考える
ひよこ コンウェイの法則は、どんな話？
ペンギン先生 システムを設計する人たちが、どう情報を交換するかが、作るシステムの構造にも表れやすいという考え方だよ。独立して仕事をする集団の間では、システムの境界や接続方法も調整が必要になる。
ひよこ 組織図と同じ形のシステムになる？
ペンギン先生 正式な組織図だけではなく、実際のコミュニケーションを見るんだ。よく相談する相手、別の集団との調整の難しさ、誰が全体を把握するかなどが関係する。部署名を並べるだけでは設計への影響を説明しきれないよ。
ひよこ 3チームなら、部品も3つになる？
ペンギン先生 そういう必然的な数の一致ではないよ。元の論文も、1つの集団が複数の部分を設計する場合を扱っている。チームと部品の対応は説明の例にはなるけれど、いつも1対1という意味にはしないようにしよう。
ひよこ 設計を変えるなら、チームも変える？
ペンギン先生 目指す境界に合わせて担当と連携を整える考え方がある。逆コンウェイ戦略と呼ばれるよ。たとえば独立して変更したい機能を同じ担当が継続して扱えるようにする。ただし機能ごとに必ず1チーム、という決まりではないんだ。
ひよこ 組織を変えれば、すぐ独立したシステムになる？
ペンギン先生 既存のコードやデータの結び付きは残るので、すぐには変わらないよ。望む設計、必要な相談の仕組み、コードの変更を一緒に考えよう。Fowlerも、組織を変えるだけの即効策ではなく、小さな変更を重ねることを説明している。
もっと詳しく知りたい人へ
コンウェイの法則を使うと設計の正解が分かる？
特定の設計が正しいと証明するものではありません。なぜその境界や結び付きが生まれたかを考える視点になります。利用者の要求、運用、データの整合性なども合わせて設計を判断します。
チームの間でやり取りを減らせばよい？
単に減らせばよいわけではありません。独立性が必要な部分と、共有の方針や接続を調整する部分を分けます。必要な相談までなくすと、全体の目的に合わない設計になるおそれがあります。
まとめ：ざっくりこれだけ覚えればOK！
「コンウェイの法則」って出てきたら「人の間のコミュニケーションがシステムの構造にも影響するという考え方」と思えばだいたいOK！
📖 おまけ：英語の意味
「Conway’s Law」 ＝ メルヴィン・コンウェイの名に由来する法則
💬 コンウェイは1967年に論文を投稿し、1968年4月のDatamationに「How Do Committees Invent?」を発表しました。1967年の投稿と1968年の掲載を区別します。