コンウェイの法則

コンウェイの法則とは

コンウェイの法則は、1967 年に Melvin Conway が提唱した経験則で、「システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計を生み出す」とする。

具体例

具体例を以下に示す。

組織構造	生まれるシステム
フロント + バックエンド + DB チーム	3 層アーキテクチャ
機能横断チーム (注文、決済、配送)	マイクロサービス
1 つの大きなチーム	モノリス

❌ 意図しないコンウェイの法則:
  フロントチーム → バックエンドチーム → DB チーム
  → API の境界がチーム境界に一致
  → チーム間の調整がボトルネック

✅ 逆コンウェイ戦略:
  望ましいアーキテクチャに合わせてチームを設計
  注文チーム (フルスタック) → 注文サービス
  決済チーム (フルスタック) → 決済サービス

逆コンウェイ戦略

逆コンウェイ戦略を図で示す。

1. 望ましいアーキテクチャを設計
2. アーキテクチャに合わせてチームを編成
3. チームがサービスを所有 (You build it, you run it)

チームトポロジーとの関係

チームトポロジーとの関係を以下に整理する。

チーム型	コンウェイの法則での役割
Stream-aligned	ビジネスドメインに対応するサービスを所有
Platform	共通基盤を提供 (チーム間の依存を減らす)
Enabling	チームの能力を向上

コンウェイの法則の活用

逆コンウェイ戦略を実践するには、まず望ましいアーキテクチャを描き、それに合わせてチームを編成する。チーム境界がそのまま API 境界になるため、チーム設計とシステム設計は表裏一体だ。リポジトリもチーム単位で分離すると、所有権が明確になり、チーム間の不要な依存を防げる。

コンウェイの法則については関連書籍でも詳しく扱われている。