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

15分 で読める | 2026.04.10

公式ドキュメント
チーム開発設計

コンウェイの法則は、systemの構造が、それを作る組織のcommunication構造を反映しやすいという観察です。

これは「必ず同じ形になる」という自然法則ではありません。設計時に見落としやすい傾向を説明する考え方です。

コンウェイの法則とは

Melvin Conwayは1968年の論文で、systemを設計する組織は、そのcommunication構造を写した設計を生み出すと述べました。

上段で別boxのTeam AとTeam Bを横接続し、下段で別boxのComponent AとComponent Bを横接続し、上段全体から下段全体への一本の矢印で組織構造がsystem設計へ反映されやすい傾向を示す図

重要なのは、組織図そのものより、日常的に誰と誰が相談し、誰が変更を承認し、どこで情報が止まるかです。

同じ部署でも頻繁に協力する人たちは、一つのmoduleを共同で改善しやすくなります。会話が少ないteam間では、明示的なAPIや依頼手続きが生まれやすくなります。

二つのteamで考える

online shopを二つのteamで開発するとします。

team主な責任
注文teamcart、注文確定、注文履歴
決済team支払方法、決済実行、返金

注文確定には決済が必要です。二teamは次を相談します。

  • どの情報を渡すか
  • 成功と失敗をどう表すか
  • retryや二重決済をどう防ぐか
  • 仕様変更をどう知らせるか

communicationが定例会議とticketだけで、実装の相談が少ないなら、境界には明示的なAPIが作られやすくなります。

注文module
  -> Payment API
  -> 決済module

反対に、両teamが毎日同じcodeを共同編集するなら、注文と決済の境界はcode上で曖昧になるかもしれません。

どちらが必ず良いという話ではありません。必要な変更を安全に進められる境界かを見ることが大切です。

communicationがinterfaceになる

team間の会話で合意した内容は、systemではinterfaceとして現れます。

たとえば注文teamから決済teamへ次を渡します。

type PaymentRequest = {
  orderId: string;
  amount: number;
  idempotencyKey: string;
};

返り値も合意が必要です。

type PaymentResult =
  | { ok: true; paymentId: string }
  | {
      ok: false;
      reason: "declined" | "temporary_error";
    };

この型だけでは十分ではありません。

  • timeout時に再送してよいか
  • 同じkeyを何回受け取れるか
  • amountの単位は何か
  • errorを利用者へどう見せるか
  • interface変更をいつ適用するか

team間で決めていないことは、codeでも曖昧になりやすくなります。

変更の流れを見る

「割引後の金額を決済する」という変更を考えます。

注文teamだけで完了できるなら、注文module内の変更で済みます。

決済requestのfield追加が必要なら、二teamの調整が発生します。

企画
  -> 注文teamが仕様確認
  -> 決済teamとinterface確認
  -> 両側を実装
  -> 結合確認

毎回この調整が必要なのに、二teamが話す機会を持たない場合、変更は遅くなり、temporary fieldや重複logicが増えます。

system図だけでなく、変更requestがどのteamを通過するかを描くと、組織とarchitectureの不一致を見つけやすくなります。

法則を「傾向」として読む

コンウェイの法則について、次の断定は避けます。

  • team数とservice数は必ず一致する
  • microservicesなら自律teamになる
  • 組織図を変えればarchitectureも自動で良くなる
  • communicationを減らすほど疎結合になる

実際には技術的制約、歴史、規制、利用者要求も設計へ影響します。

この法則は、問題の原因を組織だけに決めつける道具ではなく、communicationとinterfaceを一緒に観察する視点です。

たとえばAPIが複雑だからといって、必ずteam構造が原因とは限りません。過去の互換性、法的な制約、性能要件によって複雑さが必要な場合もあります。反対に、system図が整っていても、変更のたびに非公式な相談や特定の一人への確認が必要なら、図に現れないcommunication構造があります。設計資料と実際の変更履歴を両方見て、傾向として確かめます。

一つの事例だけで結論を出さず、複数の変更や障害対応で同じ傾向が繰り返し続くかも慎重に観察し、仮説として扱います。

逆コンウェイ戦略

作りたいsystem境界に合わせ、意図的にteamの責任とcommunicationを設計する考え方をInverse Conway Maneuver、逆コンウェイ戦略と呼びます。

注文と決済を明確に分けたいなら、次のように進めます。

  1. それぞれの責任とdata ownershipを決める
  2. teamごとの変更可能範囲を決める
  3. 境界のinterfaceを共同で設計する
  4. 継続的に互換性を確認する
  5. 問題時に直接相談できる経路を作る

単に「serviceごとにteamを作る」だけでは不十分です。必要なskill、権限、運用責任がteam内に揃っていなければ、別teamへの待ち時間が残ります。

境界を先に細かくしすぎない

逆コンウェイ戦略を聞くと、すぐmicroservicesへ分割したくなるかもしれません。

しかし、小さなproductや少人数teamでは、network境界が増えることで次の負担が増えます。

  • deployと監視
  • 認証と認可
  • data整合性
  • retryとtimeout
  • local開発
  • 障害調査

組織がまだ小さいなら、modular monolithから始める選択があります。

modular monolithという選択

modular monolithは、一つのapplicationとしてdeployしながら、code内部のmodule境界を明確にする構成です。

app
├── orders
│   ├── application
│   ├── domain
│   └── public-api
└── payments
    ├── application
    ├── domain
    └── public-api

注文moduleは決済moduleの内部fileを直接importせず、公開されたinterfaceだけを使います。

これにより、二teamが同じrepositoryで作業しても責任境界を試せます。

将来、独立deployが必要になった時に、実際の変更頻度や運用負担を見てservice分割を判断できます。

modular monolithはmicroservicesへの途中段階に限りません。一体deployの方がproductに合うなら、そのまま有効なarchitectureです。

境界が機能しているかはfolder名だけで判断しません。注文moduleの変更が決済moduleの内部修正を毎回必要としないか、公開interfaceだけでtestできるか、障害時の責任を説明できるかを確認します。code上の境界とteamの作業範囲を一緒に観察します。

architectureとteam境界がずれる例

注文teamが決済moduleの変更を頻繁に必要とするのに、決済teamしかmergeできない場合を考えます。

次の症状が出るかもしれません。

  • 小変更でも複数teamの承認待ちになる
  • 同じ規則を注文側へcopyする
  • temporary workaroundが残る
  • 誰が障害対応するか曖昧になる
  • interface変更が事後連絡になる

この時、すぐteamを統合するとは限りません。

  • 注文teamへ必要な権限を移す
  • 決済APIをself-service化する
  • 共同設計の時間を作る
  • module ownershipを見直す
  • 境界そのものを移動する

どの対応が適切かは、変更の頻度と責任の所在で判断します。

communicationは多ければよいのか

会議を増やすだけでは解決しません。

同じ内容を毎回口頭で確認しているなら、interfaceやdecision recordへ残した方がよい場合があります。

反対に、曖昧な新機能を文書だけで渡すと、前提の違いへ気づけません。初期は直接協力し、安定した後にAPIと文書へ移す方法があります。

目的はcommunicationを最大化することではなく、必要な情報が必要な相手へ届くことです。

観察する質問

自分のprojectで次を確認してください。

変更の開始

  • 要望を最初に受け取るteamはどこか
  • 仕様を決められる人は誰か
  • 利用者のfeedbackは誰へ届くか

codeの所有

  • 変更できるrepositoryやmoduleはどこか
  • 小変更に何teamの承認が必要か
  • ownershipと障害対応者は一致しているか

interface

  • team境界にAPI、event、shared tableのどれがあるか
  • 互換性を誰が確認するか
  • errorやtimeoutの責任はどちらか

日常のcommunication

  • 仕様変更をいつ共有するか
  • 問題時に直接相談できるか
  • 同じ確認を毎回繰り返していないか

回答をsystem図のmoduleと線へ重ねると、法則を抽象論で終わらせずに使えます。

観察から改善する手順

1. 一つの変更を選ぶ

最近遅れた機能や障害対応を一つ選びます。

2. team間の移動を書く

依頼、承認、実装、test、deployがどこを移動したかを時系列で書きます。

3. code境界と比べる

teamが変わる場所と、module/API境界が同じかを見ます。

4. 待ち時間の原因を探す

責任不足、情報不足、権限不足、interface不足を分けます。

5. 小さく試す

共同review時間、ownership変更、公開interface追加など、戻せる改善を一つ試します。

大規模な組織再編を最初の答えにしません。

よくある誤解

組織図だけ見れば分かる

実際の相談、承認、共同作業の経路を見る必要があります。

microservicesが正解

独立deployが必要でないなら、modular monolithの方が単純な場合があります。

team間の会話は結合である

新しいinterfaceを設計する時は協力が必要です。安定後に契約と自動testで調整負担を減らします。

法則を人の責任追及に使う

設計は個人の失敗ではなく、情報と権限の流れから生まれます。改善可能な仕組みを探します。

二team例のまとめ

注文teamと決済teamの例では、次が対応しています。

組織側system側
teamの責任moduleの責任
team間の合意APIや型
変更の連絡versioning
障害時の協力error処理と運用
ownershipdataとcodeの変更権限

表の左右が一致しないこと自体が悪いのではありません。不一致により、頻繁な待ち時間や責任の空白が生まれているかを確認します。

まとめ

  • Conway’s Lawはcommunication構造がsystemへ反映されやすいという傾向
  • team間の合意はAPIやmodule interfaceへ現れやすい
  • 逆コンウェイ戦略は望む境界に合わせteam責任を設計する試み
  • team数に合わせてserviceを増やすことが目的ではない
  • 小規模ならmodular monolithで境界を試せる
  • 実際の変更がteam間をどう移動するか観察する

参考リソース

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR