コンウェイの法則入門 - 組織構造とシステムアーキテクチャの相関

コンウェイの法則（Conway’s Law）は、1968年にMelvin Conwayが論文「How Do Committees Invent?」で提唱した、組織論とソフトウェア設計の橋渡しとなる洞察です。「システムを設計する組織は、その組織のコミュニケーション構造を反映した設計を生み出す」という、一見単純ながら現代のアーキテクチャ設計に深い影響を与える法則です。本記事では、コンウェイの法則の本質から、逆コンウェイ戦略、Team Topologies までを体系的に解説します。

概要

コンウェイの法則とは

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. — Melvin Conway, 1968

組織のコミュニケーション構造が、そのままソフトウェアのモジュール境界として現れるという観察です。4つのチームでコンパイラを作ると4パスのコンパイラになる、という有名な例があります。

flowchart TB
    subgraph Org["組織構造"]
        T1["Team A"]
        T2["Team B"]
        T3["Team C"]
        T1 <--> T2
        T2 <--> T3
    end

    subgraph System["システム構造"]
        M1["Module A"]
        M2["Module B"]
        M3["Module C"]
        M1 <--> M2
        M2 <--> M3
    end

    Org -. 反映 .-> System

なぜ起こるのか

• コミュニケーションコスト: チーム間の会話は社内で最も高コスト
• 所有権の明確化: モジュール境界 = チーム境界で責任が明確になる
• 局所最適化: 各チームは自分の担当範囲を最適化する
• API = 契約: チーム間インターフェースがそのままAPIになる

原則・定義

コンウェイの法則の系

1. ホモモルフィズム: システム構造 ≅ 組織構造
2. コミュニケーションパスの反映: 会話しないチームのモジュールは統合されない
3. 非可逆性: 一度できたシステム構造は組織構造を変えても簡単には変わらない
4. マネジメントの制約: マネジメント階層が設計を制約する
5. 組織変更=設計変更: 組織再編はアーキテクチャ再編と等価

Inverse Conway Maneuver（逆コンウェイ戦略）

flowchart LR
    subgraph Traditional["従来型"]
        O1["組織"] --> A1["アーキテクチャ"]
    end

    subgraph Inverse["逆コンウェイ戦略"]
        A2["理想の<br/>アーキテクチャ"] --> O2["組織設計"]
        O2 --> Result["期待通りの<br/>アーキテクチャ"]
    end

構成要素

Team Topologies の 4 つのチーム型

Matthew Skelton と Manuel Pais が提唱した、コンウェイの法則を活用するチーム編成モデルです。

flowchart TB
    Stream["Stream-aligned Team<br/>(価値提供チーム)"]
    Platform["Platform Team<br/>(基盤提供チーム)"]
    Enabling["Enabling Team<br/>(能力支援チーム)"]
    Complicated["Complicated Subsystem Team<br/>(専門領域チーム)"]

    Enabling -. 支援 .-> Stream
    Platform -. サービス .-> Stream
    Complicated -. 部品 .-> Stream

3 つのインタラクションモード

1. Collaboration（協業）: 期間を区切って密に協力
2. X-as-a-Service（サービス提供）: セルフサービスで利用
3. Facilitating（ファシリテート）: 学習や改善の支援

実装例

1. モノリスからマイクロサービスへの移行

flowchart TB
    subgraph Before["移行前: 機能別組織"]
        FE["Frontend Team"]
        BE["Backend Team"]
        DBA["DBA Team"]
        QA["QA Team"]
        Mono["単一モノリス"]
        FE --> Mono
        BE --> Mono
        DBA --> Mono
        QA --> Mono
    end

    subgraph After["移行後: ドメイン別組織"]
        UserTeam["User Team<br/>(FE+BE+DBA+QA)"]
        OrderTeam["Order Team<br/>(FE+BE+DBA+QA)"]
        PayTeam["Payment Team<br/>(FE+BE+DBA+QA)"]
        UserSvc["User Service"]
        OrderSvc["Order Service"]
        PaySvc["Payment Service"]
        UserTeam --> UserSvc
        OrderTeam --> OrderSvc
        PayTeam --> PaySvc
    end

機能別（FE/BE/DBA）の組織のままマイクロサービスに移行すると、各サービスに複数チームが関与し、調整コストが爆発します。ドメイン別のクロスファンクショナル組織に再編することが前提です。

2. コードオーナーシップと組織の対応

# .github/CODEOWNERS
# ドメイン別オーナーシップ

/services/user/**           @org/user-team
/services/order/**          @org/order-team
/services/payment/**        @org/payment-team
/services/notification/**   @org/notification-team

# プラットフォームチーム
/platform/**                @org/platform-team
/infra/**                   @org/platform-team

# 共有ライブラリ（Enabling）
/libs/design-system/**      @org/enabling-ui
/libs/auth-sdk/**           @org/enabling-security

3. モジュール境界の設計例（TypeScript Monorepo）

// apps/user-service/src/index.ts
// User Team が所有。Order Team は import できない
export { UserService } from "./user.service";
export type { User, UserId } from "./user.types";

// apps/order-service/src/index.ts
// Order Team が所有。User の詳細型には依存しない
import type { UserId } from "@company/user-contracts"; // 契約のみ

export class OrderService {
  async createOrder(userId: UserId, items: Item[]): Promise<Order> {
    // UserId を使うが、User 実装の内部には触れない
    return this.repo.create({ userId, items });
  }
}

4. プラットフォームチームによるセルフサービス

// Platform Team が提供する内部プラットフォーム SDK
// Stream-aligned Team はこれを使って自律的にデプロイできる

interface PlatformSDK {
  // Stream チームは YAML 1つで新サービスをデプロイできる
  deployService(spec: ServiceSpec): Promise<DeploymentResult>;
  provisionDatabase(spec: DbSpec): Promise<DbCredentials>;
  createObservabilityDashboard(serviceName: string): Promise<DashboardUrl>;
}

interface ServiceSpec {
  name: string;
  image: string;
  replicas: number;
  resources: { cpu: string; memory: string };
  env: Record<string, string>;
}

プラットフォームチームが良いAPIを提供すれば、他チームとの会話を最小化でき、コンウェイの法則の「密結合」を防げます。

メリット・デメリット

法則を活用するメリット

1. 意図した設計の実現: 逆コンウェイで狙ったアーキテクチャに
2. 高い自律性: チーム境界=モジュール境界で独立して動ける
3. 低コミュニケーションコスト: 調整会議の削減
4. 高速な意思決定: チーム内で完結
5. 明確な責任: 誰が何を所有するか曖昧にならない

法則を無視するデメリット

1. アーキテクチャの歪み: 組織の不整合がそのままコードの不整合に
2. 密結合の蔓延: チーム間の非公式な依存が増える
3. 調整の肥大化: 何をするにも会議が必要
4. 責任の押し付け合い: バグの所有者が不明確
5. リリースサイクルの硬直化: 全チーム同時リリースが必須に

ユースケース

コンウェイの法則を意識すべき場面

• マイクロサービス移行プロジェクト
• 大規模チームのスケーリング（Spotify Model など）
• モジュラーモノリスの設計
• 組織再編に伴うシステム再構築
• M&A による複数組織の統合

注意が必要な場面

• 小規模チーム（法則の影響が小さい）
• 研究開発フェーズ（構造がまだ流動的）
• 単発プロジェクト（長期最適化の必要が薄い）

落とし穴

1. 組織��変���ずにアーキテクチャだけ変��る

「マイクロサービスにすれば生産性が上がる」と思い、機能別組織のままサービス分割すると、1サービスに4-5チームが関与する地獄が待っています。組織変更とアーキテクチャ変更はセットです。

2. 過度な自律性の追求

全チームが完全独立を目指すと、共通基盤が崩壊します。Platform Team と Enabling Team による「意図的な共有」が必要です。

3. チームサイズの不適切さ

Amazon の「2ピザルール」（チームは2枚のピザで賄える人数）は、認知負荷の観点から妥当です。大きすぎると内部でさらに分裂し、小さすぎると専門性を維持できません。

4. 認知負荷の見落とし

1チームが扱うサービス数・技術数が多すぎると、認知負荷が限界を超えます。Team Topologies では認知負荷をチーム設計の最重要指標と位置づけます。

5. 組織変更の頻度

組織変更はアーキテクチャに直接影響するため、頻繁な再編はシステムの安定性を損ないます。最低でも1-2年は同じ構造を維持するのが望ましいとされます。

6. マトリクス組織の罠

機能横断型のマトリクス組織は、1人が複数の指揮系統に属するため、コンウェイの法則的には「境界が曖昧なシステム」を生みます。明確なオーナーシップが損なわれがちです。

比較表

組織モデルの比較

Stream-aligned vs Platform Team

ベストプラクティス

1. アーキテクチャ先行: 欲しい構造を決めてから組織を設計
2. 認知負荷を制約条件に: チームが扱える範囲を明示
3. APIファースト: チーム間は必ず明示的なAPIで通信
4. 自律チーム: 1チームで価値提供を完結できる構成
5. プラットフォーム投資: 共通基盤を専任チームで育てる
6. Enabling Team: 横断的な学習支援を制度化
7. 定期的な見直し: 半年～1年で組織設計をレビュー
8. ドキュメント化: チームAPIとオーナーシップを明文化

まとめ

コンウェイの法則は、単なる観察を超えて、現代のソフトウェア設計に組織論を組み込む強力なツールです。

• 本質: 組織構造 ≅ システム構造
• 活用: 逆コンウェイ戦略で意図した設計を実現
• 枠組み: Team Topologies の4種のチーム型
• 指標: 認知負荷を制約条件とする
• 現実: 技術だけでは良いアーキテクチャは作れない

「良い組織なくして良いアーキテクチャなし」という視点を持つと、技術的決定の多くが別の景色に見えてきます。

応用トピック

Spotify Model の再評価

Spotify が2012年頃に公開した「Squad / Tribe / Chapter / Guild」モデルは世界中で模倣されましたが、Spotify 自身が2016年以降「これは理想像ではなく特定時点のスナップショット」と明言しています。盲目的な模倣ではなく、自組織に合わせた適用が重要です。

認知負荷の3タイプ

Team Topologies では認知負荷を3つに分類します。

1. Intrinsic（内在的）: タスク自体の本質的難易度
2. Extraneous（外在的）: ツール・プロセスによる不要な負荷
3. Germane（学習関連）: スキル向上に役立つ負荷

外在的負荷をプラットフォームチームが吸収することで、Stream-alignedチームはIntrinsic/Germane負荷だけに集中できます。

ドメイン駆動設計との接続

Bounded Context とチーム境界を一致させることで、コンウェイの法則を設計に活かせます。

flowchart LR
    subgraph DDD["DDD: Bounded Contexts"]
        BC1["User Context"]
        BC2["Order Context"]
        BC3["Payment Context"]
    end

    subgraph Teams["Teams"]
        T1["User Team"]
        T2["Order Team"]
        T3["Payment Team"]
    end

    BC1 <-.-> T1
    BC2 <-.-> T2
    BC3 <-.-> T3

リモートワーク時代のコンウェイの法則

物理的な距離ではなく「コミュニケーション頻度」が構造を決めます。非同期コミュニケーション（Slack、GitHub Discussion、ドキュメント）が中心のリモート組織では、より明確なAPI契約と文書化が必要になります。

組織再編の実例

Amazon の 2ピザチーム: Jeff Bezos が提唱。「全員を2枚のピザで賄えない規模のチームは大きすぎる」。この原則がAWSマイクロサービスアーキテクチャの基礎となりました。

Netflix の Freedom & Responsibility: 少人数チームに最大限の自律性を与え、Chaos Engineering など独自の文化を生みました。

GitHub の Open by default: リポジトリオープン化によりチーム間の情報非対称を削減し、境界を柔軟に保ちました。

組織と技術的負債の関係

技術的負債の多くは、過去の組織構造の「化石」です。機能別組織時代に作られたモノリスを、ドメイン別組織に再編後も使い続けると、組織とコードのミスマッチが負債として蓄積します。逆に言えば、組織を変えずにコードだけリファクタリングしても、同じ構造が再生成されます（これをコンウェイの逆襲と呼ぶ人もいます）。

チームAPIの文書化

各チームは自分たちの「API」を文書化すべきです。

# User Team API

## 提供するサービス
- User Service (REST/gRPC)
- User Events (Kafka topic: user.events)

## 所有するドメイン
- ユーザー登録・認証・プロフィール管理

## 所有しないもの
- 注文履歴 (Order Team)
- 決済情報 (Payment Team)

## 連絡方法
- Slack: #team-user
- On-call: PagerDuty "user-team"
- Office Hours: 火曜 14:00-15:00

## SLO
- API可用性: 99.95%
- p99 レイテンシ: < 200ms

Fracture Plane（破断面）

Team Topologies では、チーム境界を引くべき「自然な破断面」として以下が挙げられています。

1. ビジネスドメイン境界: DDDのBounded Context
2. 規制要件: PCI-DSS、GDPR等の対象範囲
3. 変更頻度: 高頻度変更と低頻度変更の分離
4. パフォーマンス特性: レイテンシ重視 vs スループット重視
5. 技術スタック: モバイル vs Web vs データ分析
6. リスクプロファイル: ミッションクリティカル vs 実験的

これらの破断面に沿ってチームを編成すると、コンウェイの法則が味方になります。

アンチパターン: 一つのPRに複数チームがレビュー必須

1つの変更に対して複数チームの承認が必要な状況は、コンウェイの法則の観点では「境界が壊れている」サインです。オーナーシップを見直し、1つのPRは1チームで完結できる設計にします。

測定可能な指標

コンウェイの法則の活用度を計測するために、以下の指標を追跡できます。

Modular Monolith への示唆

マイクロサービスに移行せずとも、コンウェイの法則の知見は Modular Monolith にも適用できます。同一リポジトリ内でもモジュール境界を明確にし、モジュールごとにオーナーを決め、モジュール間の依存をCIで検査することで、組織構造とコード構造の一致を保てます。DDDの文脈では「Bounded Context per Module」が自然な単位です。

// モジュール依存ルールの例 (dependency-cruiser)
{
  forbidden: [
    {
      name: "no-cross-module-internals",
      from: { path: "^src/modules/([^/]+)/" },
      to: {
        path: "^src/modules/(?!$1)([^/]+)/internal/",
      },
    },
  ],
}

ソフトウェア考古学としての組織分析

既存コードを調べると、過去の組織構造が読み取れます。特定ディレクトリのコミット履歴を分析すれば、かつてそこに責任を持っていたチームが見えてきます。リファクタリングや再編の計画時、このようなソフトウェア考古学的アプローチで「なぜこうなっているか」を理解することが、効果的な変更の前提になります。

参考リソース

• Melvin Conway - How Do Committees Invent?
• Martin Fowler - Conway’s Law
• Team Topologies (Skelton & Pais)
• Thoughtworks - Inverse Conway Maneuver
• Martin Fowler - MicroservicePremium
• Accelerate - Forsgren, Humble, Kim
• Platform Engineering on Kubernetes (Manning)