Summary
「コンウェイの法則」は、組織・人事・チームの設計が、そのまま仕組み（特にソフトウェア／業務プロセス／MarTechスタック）の形に写るという観察則です。
一言で言うと、「組織図が、そのままシステム図になる。だから組織を変えない限り、プロダクトの形は変わりにくい」
いつ使うか： 部門間サイロで施策が遅い／顧客体験が分断される／AIマーケ（データ活用）が“PoC止まり”のときに、組織設計とアーキテクチャのズレを診断します。
秀逸ポイント
“失敗の原因”を技術ではなく組織の通信構造にまで掘り下げられるのが最大の強みです。機能別（広告・CRM・Web・データ等）で分断されたまま統合基盤を作ろうとしても、実装は結局「会話が成立する範囲」で割れ、インターフェース（引き継ぎ・API・会議体）が増殖します。
さらに重要なのは、コンウェイの法則が“運命論”ではなく、設計レバー（逆コンウェイ／チームトポロジー）に変換できる点です。コミュニケーション構造を意図的に変えれば、望ましいアーキテクチャが出やすくなる（＝逆コンウェイ）という実務的な処方箋につながります。
マーケ領域では、MA／CRM／CDP／広告配信／アクセス解析などのマーケティングツール群（いわゆるMarTechスタック）やデータ基盤は「ITの話」に見えがちです。ですが実態は、“誰が誰と、どの頻度で、どの粒度で合意できるか”という組織のコミュニケーション設計の問題です。AIマーケ（AI/ML活用）も同様で、学習・配信・改善が回るかは、ツールの高機能さより価値流（Value Stream）とチーム境界に左右されます。
提唱者・発表時期
提唱者は、計算機科学者の Melvin Conway（メルヴィン・コンウェイ）です。1968年4月に雑誌 Datamation に掲載された論文「How Do Committees Invent?」で、「システムを設計する組織は、そのコミュニケーション構造の写しである設計を生み出す」という趣旨を述べました。
同論文では、同一組織がCOBOLコンパイラとALGOLコンパイラを別チーム構成で作った結果、成果物の“段（フェーズ）構造”がチーム分割に対応して現れた、という観察が紹介されます。
詳細説明
1) コンウェイの法則は「因果」ではなく「対応（ミラーリング）」が主語
コンウェイの主張は本質的に、組織の通信構造と成果物の構造が対応するという観察です。厳密には「通信が原因で設計が決まる」と断定するというより、“そうなりやすい制約”として語られます。
このニュアンスを取り違えると、後述の「誤用」（たとえば“だからマイクロサービスが正解”）につながります。
2) なぜ起きるのか：設計は「分割」と「調整」のゲームだから
システム設計は、(a) 問題を部品に分け、(b) 部品同士の整合を取って全体を成立させる行為です。
このとき、調整（コミュニケーション）が濃い境界＝同一チーム内は密結合の設計がしやすく、調整が薄い境界＝チーム間はインターフェースで切る（＝疎結合／引き継ぎ）方向に寄ります。結果として「組織図の線＝設計の線」になりがちです。
3) マーケティングに翻訳すると「MarTech／データ／業務フローの分断」に出る
マーケ組織で典型的なのは、機能別組織（広告、CRM、Web、コンテンツ、データ、情シス…）です。ここで起こる“写り込み”はソフトウェアだけでなく、KPI設計・データ定義・顧客体験（CX）にも出ます。
| 組織の分け方（通信の線） | 出やすい“システムの形” | 症状（マーケ現場） | 逆コンウェイ的な対処 |
|---|---|---|---|
| チャネル別（広告/メール/SEO） | チャネル別ツール最適・データ定義がバラバラ | 同一顧客でも接触履歴が繋がらない／属性が一致しない | 「顧客ジャーニー単位」の合意点を作る（共通ID/イベント設計） |
| 企画→制作→運用の工程別 | 引き継ぎ前提の承認フロー／待ち行列 | 施策リードタイムが伸びる／学習が回らない | 小さな単位で“企画〜運用”を閉じるチームを作る |
| データ分析が別部門 | “分析レポート”が成果物化 | AI/MLがPoC止まり／現場実装が進まない | プロダクト/施策側へ分析者を埋め込む＋共通基盤は別チームへ |
ポイントは、「組織が悪い」ではなく「通信コストの設計」が成果物に転写されるという理解です。機能別の専門性は必要ですが、端点同士が会話できないまま統合だけを求めると、摩擦は設計と運用に出ます。
4) 関連用語との違い（チームトポロジー／逆コンウェイ／ブルックスの法則）
逆コンウェイ（Inverse/Reverse Conway Maneuver）
ThoughtWorks の ThoughtWorks Technology Radar では、望ましいアーキテクチャを得るためにチームや組織構造を進化させる手法として整理されています。
Martin Fowler も同趣旨で、無視・受容・逆コンウェイといった反応をまとめています。
チームトポロジー（Team Topologies）
Team Topologies は、チーム設計を“型”として扱い、4つのチームタイプと3つの相互作用パターンで、価値流を速く保つための設計論を提供します。
AI/MLのような新技術導入でも、価値流を崩さずに進める文脈が明示されています。
（マーケで言うなら、施策側の“ストリーム”と、共通基盤（計測・ID・配信・ガバナンス）を分けて設計する発想が近いです。）
ブルックスの法則（Brooks’s Law）
Fred Brooks が The Mythical Man-Month で述べた「遅れたプロジェクトに人を足すと、かえって遅れる」という観察は、原因の一つをコミュニケーションコストに置きます。
コンウェイが“構造が写る”なら、ブルックスは“人数増が通信を悪化させ、遅延を増やす”で、どちらも“通信が設計・生産性の制約”という点で補完関係です。
具体例／活用案
事例1：原典にある「チーム分割が成果物の段構造に写る」
コンウェイ自身が、COBOLとALGOLのコンパイラ開発を異なる人数配分で行った結果、成果物がそれぞれ“5段”“3段”の構造になった観察を紹介しています。
ここで重要なのは、設計意図より先に“組織の分け方”が設計制約になっている点です。
事例2：逆コンウェイの「組織からアーキテクチャを作りに行く」— Netflixの講演例
Netflix について、InfoQの講演記録で「inverted Conway’s Law（逆コンウェイ）を使った」旨が語られています。
※ここでの教訓は「マイクロサービスが正しい」ではなく、望ましい境界（責任範囲）を先に定義し、それに合わせて“グループ（通信の線）”を整えるという設計順序です。
（※）”Netflix：エンジニアのJuan Ignacio Vimbergが自身のブログで、ObservabilityチームでInverse Conway Maneuverを実践した経緯を詳述（2023）。
事例3：小さな自律チーム（Two-Pizza Team）— Amazonの“チーム境界”の作法
Amazon の「Two-Pizza Team」は、チームを小さく保ち自律性と説明責任を高める考え方として紹介されています。
マーケに翻訳すると、“小さく自律した施策チーム”が、計測→学習→改善までを閉じられる状態（＝実験の回転数が上がる）を作りやすいです。
事例4：MarTechのBuild vs Buyにも出る（Chiefmartec）
MarTechの文脈でも、組織が持つワークフロー／顧客体験の“理想形”にツールを合わせに行く、という逆コンウェイ的な論点が整理されています。
「ツール導入で運用を矯正する」のではなく、運用（通信の線）を定義してからツールを選ぶ、のほうが分断が起きにくい、という示唆です。
事例5：AIマーケは「データサイロ→共有コンテキスト」へ圧力をかける
AI活用が、データサイロを解体し“共有された顧客コンテキスト”を必要とする、という論旨が紹介されています。
生成AI／レコメンド／予測（LTV・解約・CV）などは、入力（イベント・属性・接触履歴）の整合が生命線なので、組織境界のままデータ定義が割れると精度以前に運用が破綻します。
事例6：データ分析組織で起きる“コンウェイの法則”──中央集約 vs 事業埋め込み
データ分析組織でも、コンウェイの法則は分かりやすく現れます。分析人材を「データ分析部門」として集約し、各事業部門を横断支援する形にすると、メンバー同士で最新手法や分析パターンを共有しやすく、標準化や再利用が進みます。一方で、事業部門との距離が広がり、現場の制約（業務オペレーション、KPIの本当の意味、意思決定のクセ、例外処理）を織り込んだ“事業に根差した分析”がやりにくくなりがちです。
逆に、分析担当者が事業部門に所属していると、課題設定や仮説は事業にフィットし、施策や運用へつなげやすくなります。しかし、横串のコミュニティが弱い環境では、分析手法・実装パターン・品質基準の共有が難しく、スキルや型の進化が頭打ちになりやすい、という副作用が出ます。
この現象は、ソフトウェアに限らず「意思決定の仕組み（データ定義、KPI設計、分析プロセス）」にも当てはまります。つまり、誰と誰が日常的に会話し、どの粒度で合意できるか（組織の境界線）が、分析アウトプットの構造と粒度を決めてしまうのです。ここで重要なのが逆コンウェイの発想で、「どちらが正しいか」ではなく、狙う成果物（価値流）に合わせて組織配置とインターフェースを設計することが解になります。
使い分けの整理
中央集約が向くケース：全社で指標や定義がバラバラ／計測やデータ品質を揃えたい／共通基盤（ID・イベント・データモデル）を作りたい
事業埋め込みが向くケース：施策の回転を上げたい／意思決定までつなげたい／AI/MLをPoCで終わらせず運用に乗せたい
逆コンウェイの“小さな実装”案（AIマーケ寄り）
実務では「中央集約 or 埋め込み」の二択にせず、二層構造にすると副作用が減ります。たとえば、中央側が共通基盤（計測設計・データ定義・ガードレール・教育）を担い、事業側は価値流（獲得→オンボーディング→リピート等）に沿って分析〜施策実装〜改善までを閉じる。こうすると、AIマーケで重要な「学習→配信→検証→改善」のループが回りやすくなります。
近年の学術研究
近年の学術研究では、Harvard Business SchoolのColferとBaldwin（2016）が142の実証研究をレビューし、従来型組織の70%でコンウェイの法則が観察される一方、オープンソースプロジェクトでは異なるパターンも見られることを報告している。”
すぐに使える「活用手順」（マーケ組織 × アーキテクチャ）
顧客ジャーニー（価値流）を1本選ぶ：例）「獲得→オンボーディング→リピート」。
“詰まり”を可視化：引き継ぎ、承認、データ依頼、ツール改修待ち。
望ましいアーキテクチャを文章で定義：例）「共通ID・共通イベント・共通実験基盤」。
逆コンウェイでチーム境界を引き直す：ジャーニー単位の小隊（施策責任＋MarOps＋データ/AI）を作り、共通部品は“プラットフォーム的チーム”に寄せる（チームトポロジーの発想）。
通信の“契約”を作る：データ定義（data contract）、API、SLA、意思決定の場。
たとえば、6〜8週間で評価：リードタイム、再作業率、学習回数（実験数）、品質（計測欠損）で見ます。
よくある誤用（注意）
「コンウェイの法則＝マイクロサービス推奨」：法則は“写る”と言っているだけで、アーキテクチャの正解を指定しません。
「サイロは悪だから全部壊す」：専門性の塊まで壊すと、逆に品質が落ちます。大事なのは“サイロ間の通信設計”です。
「組織図のせいだ」と責任転嫁する：観察則を免罪符にすると改善が止まります。逆コンウェイのように“設計レバー”として使うのが実務的です。
よくある質問（FAQ）
Q1: コンウェイの法則は「法則」なのに例外はないのですか？
A: 学術的には「観察則」であり、絶対法則ではありません。Harvard Business School（2016）の研究では、オープンソースプロジェクトの56%で従来型のミラーリングが見られず、デジタルツールによる新しい調整モードが機能していることが報告されています。
Q2: 「逆コンウェイ手法」とは具体的に何をすればいいのですか？
A: 以下の3ステップです： 1. 理想のシステムアーキテクチャを先に設計 2. そのアーキテクチャに合わせて組織構造を変更 3. チーム間のコミュニケーション経路を明確化 （例：マイクロサービス化したいなら、まず小規模自律チームを作る）
Q3: マイクロサービスにすれば自動的に良くなりますか？
A: いいえ。コンウェイの法則は「マイクロサービス推奨」を意味しません。組織とアーキテクチャの「対応（ミラーリング）」が主語です。組織構造を変えずにマイクロサービス化すると、かえって混乱を招きます。
Q4: 小規模チーム（5-10人）にも適用されますか？
A: Martin Fowlerによれば、「10数人程度のチームなら非公式な密なコミュニケーションが可能なため、コンウェイの法則の影響は小さい」とされています。組織が大きくなり、チーム分割が必要になった時点で法則が顕在化します。
Q5: 「Two-Pizza Team」の「2枚のピザ」は日本だと何人分ですか？
A: アメリカサイズのピザを想定しているため、一般的に5-10人程度とされています。日本のLサイズピザで考えると誤解を招く可能性があるので、「10人以下の小規模自律チーム」と理解するのが適切です。
すぐ使える問い（Killer Question)
「顧客体験（ジャーニー）の分断点は、組織の境界線と一致していないか？」
一致しているなら、分断はツールではなく“通信設計”の問題で、改善余地が大きいからです。「AI施策のボトルネックは、モデル精度ではなく“データ定義の合意”にないか？」
AI/MLは共有コンテキストが前提です。合意が割れていると、精度改善以前に運用が崩れます。「望むアーキテクチャ（共通ID・共通イベント・共通基盤）に合わせて、チーム境界を“意図的に”引き直したか？」
逆コンウェイは“自然発生を待たずに”構造を作りに行く発想で、手戻りコストを下げやすいからです。
参考文献リスト
カテゴリA：原典・基礎文献
Conway, M. E. (1968, April). How do committees invent? Datamation, 14(5), 28-31. https://www.melconway.com/Home/pdf/committees.pdf
Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
カテゴリB：学術研究・実証分析
Colfer, L. J., & Baldwin, C. Y. (2016). The mirroring hypothesis: Theory, evidence, and exceptions. Industrial and Corporate Change, 25(5), 709-738. https://doi.org/10.1093/icc/dtw027
MacCormack, A., Baldwin, C., & Rusnak, J. (2012). Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis. Research Policy, 41(8), 1309-1324.
カテゴリC：実務書・フレームワーク
Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
Narayan, S. (2015). Agile IT Organization Design: For Digital Transformation and Continuous Delivery. Addison-Wesley Professional.
カテゴリD：業界専門家による解説
Fowler, M. (n.d.). Conway’s Law. martinfowler.com. Retrieved February 1, 2026, from https://martinfowler.com/bliki/ConwaysLaw.html
LeRoy, J., & Simons, M. (2010, December). Dealing with creaky legacy platforms. Cutter IT Journal, 23(12). http://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy-platforms/
カテゴリE：企業実践事例
Vimberg, J. I. (2023, September 4). Pulling an Inverse Conway Maneuver at Netflix. Coding Forest. http://jivimberg.github.io/blog/2023/09/04/the-inverse-conway-maneuver
Amazon Web Services. (n.d.). Amazon’s two-pizza teams. AWS Executive Insights. Retrieved February 1, 2026, from https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/
Brinker, S. (2023, August 21). Conway’s Law vs. Inverse Conway’s Law and the future of build vs. buy in martech. chiefmartec. https://chiefmartec.com/2023/08/conways-law-vs-inverse-conways-law-and-the-future-of-build-vs-buy-in-martech/
カテゴリF：業界メディア・技術レーダー
ThoughtWorks. (2014, July). Inverse Conway Maneuver. ThoughtWorks Technology Radar. https://www.thoughtworks.com/en-us/radar/techniques/inverse-conway-maneuver
Böckeler, B., Mason, M., Lewis, J., & Fowler, M. (2022). Reckoning with the force of Conway’s Law [Audio podcast]. ThoughtWorks Technology Podcast. https://www.thoughtworks.com/en-us/insights/podcasts/technology-podcasts/reckoning-with-the-force-conways-law
カテゴリG：オンライン百科事典・リファレンス
Conway’s law. (2024, December 15). In Wikipedia. https://en.wikipedia.org/wiki/Conway’s_law
Team Topologies. (n.d.). Key concepts. teamtopologies.com. Retrieved February 1, 2026, from https://teamtopologies.com/key-concepts
コメント