コンウェイの法則
組織のコミュニケーション構造がシステムの設計に反映されるという経験則
組織アーキテクチャ
コンウェイの法則とは
コンウェイの法則は、1967 年に Melvin Conway が提唱した経験則で、「システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計を生み出す」とする。
具体例
| 組織構造 | 生まれるシステム |
|---|---|
| フロント + バックエンド + DB チーム | 3 層アーキテクチャ |
| 機能横断チーム (注文、決済、配送) | マイクロサービス |
| 1 つの大きなチーム | モノリス |
❌ 意図しないコンウェイの法則:
フロントチーム → バックエンドチーム → DB チーム
→ API の境界がチーム境界に一致
→ チーム間の調整がボトルネック
✅ 逆コンウェイ戦略:
望ましいアーキテクチャに合わせてチームを設計
注文チーム (フルスタック) → 注文サービス
決済チーム (フルスタック) → 決済サービス
逆コンウェイ戦略
1. 望ましいアーキテクチャを設計
2. アーキテクチャに合わせてチームを編成
3. チームがサービスを所有 (You build it, you run it)
チームトポロジーとの関係
| チーム型 | コンウェイの法則での役割 |
|---|---|
| Stream-aligned | ビジネスドメインに対応するサービスを所有 |
| Platform | 共通基盤を提供 (チーム間の依存を減らす) |
| Enabling | チームの能力を向上 |
コンウェイの法則の活用
逆コンウェイ戦略を実践するには、まず望ましいアーキテクチャを描き、それに合わせてチームを編成する。チーム境界がそのまま API 境界になるため、チーム設計とシステム設計は表裏一体だ。リポジトリもチーム単位で分離すると、所有権が明確になり、チーム間の不要な依存を防げる。
コンウェイの法則については関連書籍でも詳しく扱われている。