Conway's Law：組織構造がアーキテクチャを決める

定義

1968 年、Melvin Conway はこう述べた。

「システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計を生成する」 (Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.)

アーキテクチャはチームの自然な産物だということだ。

なぜ組織構造がアーキテクチャに影響するのか

チームは自分たちが管理できる範囲でシステムを分割する。別チームとの調整コストが高ければ、境界を曖昧にしたまま放置する。

【例: フロントエンドチームとバックエンドチームが分かれている組織】

  フロントエンドチーム  ←── API 境界 ──→  バックエンドチーム
        ↓                                       ↓
   SPAアプリ                              モノリスAPI

  → チームの境界 = システムの境界になる

【例: 機能チームが独立している組織（注文・在庫・決済）】

  注文チーム   在庫チーム   決済チーム
      ↓            ↓           ↓
  注文サービス  在庫サービス  決済サービス

  → チームの境界 = マイクロサービスの境界になる

実例：Amazon の 2 ピザチームとマイクロサービス

Jeff Bezos は「2 枚のピザを食べきれる人数（6〜10人）がチームの上限」というルールを導入した。チームが小さければ、担当システムも小さく・独立した境界を持つようになる。

これが Amazon の大規模マイクロサービスアーキテクチャの土台になったと言われている。組織が先、アーキテクチャが後だ。

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

Conway’s Law は「組織がアーキテクチャを決める」という観察だ。これを逆用する戦略が 逆コンウェイ戦略だ。

「理想のアーキテクチャに合わせてチームを再編する」

【従来の流れ】
  現在の組織構造 → 自然にそれをコピーしたアーキテクチャが生まれる

【逆コンウェイ戦略】
  理想のアーキテクチャを先に描く
        ↓
  そのアーキテクチャを作れるようにチームを再編する
        ↓
  チームの境界 = システムの境界が一致するようになる

マイクロサービスへの移行で「技術的に分割したのに組織が変わっていない」と失敗する例は多い。アーキテクチャと組織を同時に進化させる必要がある。

Team Topology との接続

Matthew Skelton と Manuel Pais は Team Topologies（2019）で、進化的アーキテクチャを支えるチームの 4 形態を提唱した。

チームタイプ	役割	アーキテクチャ上の対応
Stream-aligned Team	ビジネス機能の流れに沿って動くチーム	マイクロサービス・プロダクト単位
Platform Team	他チームのデリバリーを支援する基盤を提供	共有インフラ・CI/CD・可観測性
Enabling Team	一時的に他チームの能力向上を支援	新技術の導入・研修
Complicated Subsystem Team	専門知識が必要な複雑なコンポーネントを担当	機械学習・暗号処理・決済

  Stream-aligned Team A ←── Platform Team（CI/CD・DB・監視）
  Stream-aligned Team B ←──      ↑
  Stream-aligned Team C ←──  インフラをセルフサービスで使える

  Complicated Subsystem Team（決済エンジン）← 専門性が必要なコアを担当
  Enabling Team（観測性導入支援）← 一時的にチームに入り込んでスキル移転

チーム構造とアーキテクチャへの影響

チーム構造	生まれやすいアーキテクチャ	進化耐性
機能別（フロント / バック / DB）	レイヤードな大きなモノリス	低い（全チームが同じリリースに縛られる）
プロダクト別（注文 / 在庫 / 決済）	マイクロサービス・独立デプロイ	高い（各チームが独自に進化できる）
完全に自律したフルスタックチーム	サービスメッシュ・独立したデータストア	最も高い（Conway’s Law を最大限活用）

進化的アーキテクチャとの接続

進化的アーキテクチャは「システムが変化に耐えること」を目指す。しかし、どんなに良い設計も、チームの境界がシステムの境界とずれていると機能しない。

Fitness Function を誰が管理するか？ チームの責任範囲と一致していないと放置される
段階的変更を誰が実施するか？ 複数チームにまたがる変更は調整コストで遅延する
Architecture Quantum はチームの自律性と対応する

「アーキテクチャを進化させる」とは、同時に「組織を進化させる」ことでもある。Conway’s Law はその根拠だ。

出典・参考文献

Melvin E. Conway, “How Do Committees Invent?” Datamation (1968) — melconway.com
Matthew Skelton, Manuel Pais, Team Topologies (2019) — teamtopologies.com
Neal Ford et al., Building Evolutionary Architectures (2022) Chapter 6 “Building Evolvable Architectures”

定義