【あなたの組織構造が、すでにあなたのソフトウェアの運命を決定している】コンウェイの法則——56年間見過ごされてきた経営学の鉄則 AI時代のソフトウェア工学の変革——ゆっくり学ぶAI171
前書き
- あなたのソフトウェアアーキテクチャは、技術チームが「設計」したものではなく、あなたの組織構造が「自然に生み出した」ものである。1968年に提唱されたこの法則は、AI時代において繰り返し検証されている。
- ハーバード・ビジネス・スクールの実証研究は、コードの複雑さよりも「組織的距離」の方がソフトウェアの欠陥率をより正確に予測できることを示している。あなたが「技術的負債」と呼んでいるものは、本質的には「組織的負債」である可能性が高い。
- Amazonのマイクロサービス帝国、Spotifyのスモールチームモデル、AppleのSiriの苦境——三社とも兆ドル級の企業だが、それぞれ異なる運命をたどり、同じ法則を示している。
- AIエージェントが組織図に登場し始めた。チーム内の「ノード」がすべて人間でなくなったとき、コンウェイの法則は、あなたが想像もしない形で再定義される。
1968年、名の知れないプログラマーが一篇の論文を執筆した。『ハーバード・ビジネス・レビュー』は「論点が証明されていない」として拒否した。56年後、その論文の核心的主張は、ソフトウェア業界全体で広く受け入れられた法則となった——そして、AIがすべてを再構築する2026年、その重要性はかつてないほど高まっている。
1. 拒絶された論文が、ソフトウェア工学の「万有引力の法則」になった理由
HBRに門前払いされた預言者
1968年4月、メルヴィン・コーンウェイは『Datamation』誌に、地味なタイトルの論文『How Do Committees Invent?』（委員会はどのように発明するのか？）を発表した。
この論文の核心的な主張はたった一文だが、その一文はあらゆるCTOを夜も眠れなくする：
「システムを設計する組織の構造は、その組織のコミュニケーション構造と等しい。」
言い換えれば：あなたの会社の組織図は、そのままあなたのソフトウェアアーキテクチャ図のコピーだ。
コーンウェイは論文の中で、精緻な事例を提示した。ある企業が8人を2つのチームに分け、2つのコンパイラを開発させた：5人チームと3人チーム。結果はどうだったか？5人チームは5段階のコンパイラを、3人チームは3段階のコンパイラを生み出した。これは技術的に段階をそのように分割する必要があったからではない。なぜなら——それぞれのメンバーは、自分自身の「作業単位」を「所有」したかったからだ。
コーンウェイはこの関係を数学的な言語で「準同型写像」（homomorphism）と表現した。組織構造とシステム設計の間には、構造を保つ写像関係が存在する。これは偶然でも偶然の積み重ねでもなく、ほぼ数学的必然の法則である。
皮肉なことに、コンウェイは当初、この論文を『ハーバード・ビジネス・レビュー』に投稿したが、編集者に「論点が証明されていない」として却下された。7年後、フレッド・ブルックスは古典的著作『人月の神話』でこの見解を正式に引用し、「コンウェイの法則」（Conway’s Law）という名称を付けた。
以来、トップ級の商業ジャーナルに拒絶されたこの観察は、ソフトウェア工学分野で最も広く引用される法則の一つとなった。 ## マーティン・フーラーの「蓋棺定論」
コンウェイが仮説を提唱したコペルニクスだとすれば、過去20年の実証研究はその望遠鏡である。
2022年、ThoughtWorksのチーフサイエンティストであるマーティン・フーラーは、業界で広く広まった評価を残した：「ソフトウェアアーキテクチャの分野で、すべての実践者が合意する法則が一つだけあるとすれば、それはコンウェイの法則だ。それは十分に重要で、私が見てきたすべてのシステムに影響を与えた。また、十分に強力で、これに逆らおうとする者は必ず失敗する。」
これは学者が象牙の塔で行う理論的推論ではない。フーラーは、世界中の数百社の企業でコンサルティングを重ねる中で、常に同じ現象を目撃してきた。つまり、組織図は、経営陣がそれに気づいていようがいまいが、ソフトウェアの設計図の影にすぎない。
ここには、多くの人が見落とす微妙だが重要な意味がある：Fowler が言っているのは、「それを利用しようとする誰もが」ではなく、「それを対抗しようとする誰もが」必ず失敗する、ということだ。この違いとは何か？コンウェイの法則に対抗するとは、組織構造を変えずにアーキテクチャの変革を無理に推し進めるということである。一方、それを活用するとは、まず組織を調整し、アーキテクチャが「自然に成長」するようにすることである。
この違いが、デジタルトランスフォーメーションプロジェクトの成功と失敗を分ける。後続の第2編で Team Topologies を議論する際、「逆康威操作」（Inverse Conway Maneuver）という重要な戦略を詳しく解説する——これは、この法則に対抗するのではなく、活用することそのものである。
二、ラボから戦場へ：三项研究がこの法則を裏付けた
ハーバード・ビジネス・スクールの「ミラーリング仮説」
2012年、ハーバード・ビジネス・スクールの MacCormack らは、学術界で「ミラーリング仮説」（Mirroring Hypothesis）と呼ばれる重要な研究を発表した。
研究手法は非常に巧みだった：彼らは、同じ機能を実装した商用ソフトウェアとオープンソースソフトウェアを比較した。商用ソフトウェアは階層的な企業チームによって開発され、オープンソースソフトウェアは分散したコミュニティによって開発された。
結果はコンウェイの法則が予言した通りだった：疎結合の組織が開発した製品は、はるかにモジュール化されている。密結合の企業チームは、たとえ意図的にモジュール設計を追求しても、最終的に得られるシステムは、その組織構造と一致する密結合の特徴を示す。
組織構造は「重力場」のようなものだ——一時的にそれと対抗することは可能だが、時間が経つと、システムアーキテクチャは必ず組織構造と同型の形へと引き戻される。
この研究が企業の意思決定者に与える真の示唆とは何か？ あなたの技術チームが繰り返し「リファクタリングが必要だ」と言っているとき、本当に「リファクタリング」が必要なのはコードではなく、組織かもしれない。では、それは「技術的負債」か「組織的負債」か、どう判断すればいいのか？ これには体系的な診断手法が必要だ——その完全な評価モデルを、第12篇『企業AI開発ツール採用決定フレームワーク』で提供する。
マイクロソフト研究室の「Windows Vista実験」
2008年、マイクロソフト研究室のNagappanらは、Windows Vistaプロジェクトを対象とした大規模な定量的研究を実施した。彼らは、ソフトウェア内の欠陥（バグ）を最もよく予測する要因は何かという重要な問いに答えることを目指した。
候補として挙がったのは：コードの複雑度、コード行数、コード変更頻度、開発者の経験……そして、「技術」とは無関係に見える変数——組織的距離（つまり、関連モジュールを開発するチーム間の組織構造上の距離）。
研究結果は、多くのテクノクラートに不安をもたらした：組織の距離が、コードの複雑さよりもソフトウェアの欠陥率をより正確に予測する。 つまり、組織図上で「離れている」2つのチームが共同で開発したモジュールは、極めて複雑だが密接に協力するチームが保守するモジュールよりも、バグが発生しやすい。コードが拙劣だからバグが起きていると信じていたかもしれないが、実際は組織設計が悪かった可能性が高い。
この発見の企業レベルでの含意は、表面的に見える以上に深遠である。それは——QA戦略はコードの複雑さではなく、組織構造に従うべきだということを意味する。たとえコード自体が単純に見えても、複数チームが協力して開発するモジュールには、より厳格なテストカバレッジとレビュープロセスが必要だ。AIが生成するコード量が急増する今日（Copilotはユーザーが書くコードの46%を生成している）、この原則はさらに重要になっている。この点については、第8篇で「生産性のパラドックス」を議論する際に、Coinbaseの事例を詳しく取り上げる。
DORA研究の「加速」と「懸念」
Google傘下のDevOps Research and Assessment（DORA）チームは、Nicole Forsgren、Jez Humble、Gene Kimが率い、これまでで最大規模のソフトウェア配信効率に関する研究を発表した。
核心発見はコンウェイの法則と非常に一致している：「我々が疎結合で良好にカプセル化されたアーキテクチャを実装し、それに見合った組織構造を併せ持てば、デリバリーのスピードと安定性を向上させるとともに、エンジニアリングチームが大幅に拡大しても、線形、あるいはそれ以上の生産性の成長を維持できる。」 しかし、DORAの2022年レポートでは、興味深い副作用も明らかになった：疎結合アーキテクチャはデリバリー効率を高める一方で、チームの燃え尽き感を増加させる可能性がある。その理由は、チームが高度に自律的かつ相互に分断されると、メンバーが全体の意義を失い、「自分はただの歯車に過ぎない」という孤立感を抱くからだ。
これは重要な注意喚起だ——アーキテクチャと組織の整合性は万能薬ではない。効率の問題は解決するが、文化の問題を生み出す可能性がある。
深く考えるべき推論がある：疎結合アーキテクチャ＋疎結合組織が人間開発者を孤立させているなら、チームにAIエージェントが加わったらどうなるのか？AIは「孤立を感じない」が、人間はさらに孤立する。この側面はほとんど議論されていないが、我々が調査した資料の中には、BCGの2025年レポートが「中間管理職の編成課題」を提起している——これは、我々の第11記事の核心テーマでもある。
三、三社の兆円級企業の「コンウェイの法則の瞬間」
Amazon：すべてを変えるCEOのメール
2002年頃、ジェフ・ベゾスはAmazon内部で有名な「API命令」を発信した——すべてのチームはサービスインターフェース（API）を通じて通信しなければならず、他のチームのデータストレージに直接アクセスすることは厳禁とされた。
このメールの最後には、次のように書かれていたとされる：「上記の規定に従わない者は解雇される。」
多くの人はAmazonのマイクロサービスアーキテクチャを技術的決定と見なすが、コンウェイの法則の観点から見れば、ベゾスが行ったのは組織構造の決定だった：彼はまず管理手段でチーム間の「近道的なコミュニケーション」を強制的に遮断し、その結果、ソフトウェアアーキテクチャは自然と相互に分離されたサービスモジュールへと進化した。
これが後にベゾスが提唱した「ピザ2枚チーム」（Two-Pizza Team）——各チームの規模は2枚のピザで満腹になる人数（通常5～8人）を超えないようにし、各チームは自らのサービスを所有し、独立してデプロイし、APIを通じて外部とやり取りする。
Amazonのマイクロサービス帝国はアーキテクトが設計したものではなく、組織構造が「自然に成長」したものである。これはコンウェイの法則の最も古典的な成功事例である。
しかし、多くの記事では言及されないもう一つの層がある：アマゾンの成功は、ベゾスがコンウェイの法則を理解しただけでなく、同時に「インセンティブの整合性」の問題も解決したからである。 各「ピザ2つ分のチーム」は独自のP&L（損益計算書）を抱えており、技術的自律性に加えて、ビジネス的自律性も持っている。つまり、チームにはサービスの境界を明確に保つ内在的動機がある——境界が曖昧になると責任が曖昧になり、責任が曖昧になると評価も曖昧になるからである。 組織構造＋インセンティブ構造＋技術アーキテクチャの三角整合こそ、アマゾンモデルの真の姿である。 組織構造だけを真似て、インセンティブ設計を学ばない企業は、形は真似ても本質を掴めていないのが大半だ。
Spotify：理想モデルが現実の「エントロピー増加」に直面する
Spotifyの「Squadモデル」は一時期、シリコンバレーで組織設計の聖書と崇められた：5～8人の自律的小チーム（Squad）、複数のSquadが集まってトライブ（Tribe）を形成し、トライブを超えて技術専門家がチャプター（Chapter）を、興味に基づくコミュニティがギルド（Guild）を構成する。
このモデルの設計思想は、コンウェイの法則と高い整合性を保っている——小さな自律的なチーム構造を通じて、小さな自律的なソフトウェアサービスを生み出すように仕組まれている。
しかし、Spotify自身も後に、現実はモデルよりもはるかに複雑であると認めた。ビジネスが一定規模に達すると、チーム間の依存関係は避けられず、純粋な自律性は調整コストを生み始める。
これは、コンウェイの法則のしばしば見落とされる帰結を明らかにする：組織構造は一度設計すれば永久に固定されるものではなく、ソフトウェアと同じく「エントロピー増加」の傾向を持つ。ビジネスの複雑さが増すにつれ、組織の境界は徐々に曖昧になり、コミュニケーションのパスは長くなり、システムアーキテクチャも劣化していく。
優れた技術組織は「良いアーキテクチャを設計した」のではなく、組織とアーキテクチャの整合性を継続的に調整する能力を築いた。この能力については、第2篇でTeam Topologiesについて議論する際に詳しく展開する——それはSpotifyモデルよりも体系的で、より実行可能なフレームワークを提供する。
Apple：SiriがChatGPTに「大敗」した理由
2024–2025年、AppleのSiri AIアップグレード計画は、コンウェイの法則の「反面教師」となった。
問題の本質は技術にはない。Apple は世界最高レベルの AI 研究人材と豊富な資金を有している。しかし、Siri の開発は、組織構造上、構造的亀裂を抱える二つのチーム——AI 研究チーム（John Giannandrea が率いる）と製品開発チーム（Craig Federighi が率いる）——の間で行われている。
両チームは、優先順位も、進行スピードも、成功の基準も異なる。AI 研究チームはモデル能力の最先端突破を追求し、製品チームはユーザー体験の安定した提供を重視する。この二つの組織「ノード」間のコミュニケーション構造が断絶している限り、生み出されるシステムも必然的に断絶したままになる。
ユーザーが最終的に得る Siri とは何か？「機能の寄せ集めに過ぎない平凡なアシスタント」——各モジュールは個別にはそれなりに見えるが、統合された全体としては一貫した知的体験が欠如している。これはコンウェイの法則が予言した結果そのものだ：システムの亀裂は、組織の亀裂を反映する。
Apple の事例は、中国企業の意思決定者にとって特に注目に値する。多くの企業が、まったく同じ困境に直面している——AI チームとビジネスチームが異なる VP の下に分かれ、AI の実装プロジェクトは「一つの製品の協同的提供」ではなく、「二つの部門間の政治的駆け引き」になっている。
あなたの企業がAIの実装を推進しているなら、組織図を振り返ってみてください：AI能力は独立した部門として存在していますか、それともビジネスチームに組み込まれていますか？この問いの答えは、どのAIモデルを選択するかよりも、プロジェクトの成功・失敗をより大きく左右する可能性があります。
四、AI時代：コンウェイの法則は再定義されている
「組織ノード」がすべて人間でなくなったとき
2026年、コンウェイの法則は1968年以来最も深い挑戦に直面している。コンウェイがこの法則を提唱した際、その前提には「組織内のすべてのノードは人間である」という暗黙の仮定があった。コミュニケーション構造とは、人間と人間の間のやり取りだった。
しかし今日、AIエージェントが組織図に登場している。Claude Codeは複数ステップの開発タスクを自律的に完了し、StripeのMinionsシステムは週に1000個以上のマージPRを生成している。CursorはNVIDIAの全エンジニアの働き方を変革した。Gartnerは2025年、企業におけるマルチエージェントAIオーケストレーションに関するコンサルティング需要が1445%急増したと報告している。
組織の一部のノードが人間でなくなったとき、コンウェイの法則はどのように変化するのか？
この問題の展開は、本シリーズの後半全体にわたって貫かれます——第10篇の「一人ユニコーン」現象、第11篇の「コンウェイの法則とAIエージェント」、第14篇の「エージェントエンジニアリング」——しかし、ここではまず3つの初期判断を提示し、思考の枠組みを構築します：
第一に、コミュニケーション構造は戦略構造に変わる。 人間同士のコミュニケーションは文化、默契、非公式なやり取りに依存する。しかし、人間とAIエージェントの間には「默契」は存在しない——インタラクションの境界は、明確な戦略、ルール、権限によって定義しなければならない。治理能力は、組織設計における核心的変数として、コミュニケーション能力に取って代わる。
第二に、組織図は権限図に変わる。 伝統的な組織図は、報告関係と職務分担を記述する。AI時代の「組織図」はむしろ有向非巡回グラフ（DAG）に似ており、能力と制約を定義する——どのエージェントがどのデータにアクセスでき、どの操作を実行でき、どの条件下で人間の承認が必要かを示す。
第三に、制度的知識は人間から戦略へ移行する。 過去、「ベテランが去れば知識も失われる」は、あらゆる企業の痛手だった。未来では、重要な知識はAIエージェントの戦略とコンテキストにコード化される——これは機会である（知識の流失が防げる）、同時にリスクでもある（戦略の誤りがシステム全体で拡大する可能性がある）。
各判断の背後には、多数の業界実践とデータが支えています。たとえば、「制度的知識の移転」に関する3番目の項目では、Klarnaの事例が劇的な正反面の教訓を提供しています——彼らは40%の従業員を削減した後、AIシステムが解雇された従業員が持ち去った暗黙的知識を担いきれないことに気づき、再雇用を余儀なくされました。この事例は、第9篇『Klarnaの教訓』で完全に展開します。
第一条と第二条の判断は、私たちだけがそう見ているわけではない。2026年7月、a16zのポッドキャスト『Software in the Age of Agents』で、a16z企業チームのパートナーであるSeema Ambleと元Microsoft Windows社長のSteven Sinofskyは、第一線での投資観察から、極めて一致した結論を導き出した。Stevenは、判断一の核心を一言で言い当てた——「エンタープライズソフトウェアにおける最大のネットワーク効果は、企業間ではなく、企業内部にある」（The biggest network effect in enterprise software is inside of a company）：人間関係、プロセス、システムが織りなす組織内部のネットワークこそが、真の粘着性の源泉である。agentは「默契」によってこのネットワークに接続できるわけではない。明確な戦略と権限を通じてのみ可能だ——これが「コミュニケーション構造が戦略構造へと変わる」現実の推進力である。一方、Seemaはagentがエンタープライズシステムにアクセスする視点から判断二を裏付けた：agentが「実行」する（システムの記録を書き込む、会計を変更する）際、即座に身分認証、認証情報、課金枠、承認権限という一連の課題に直面する——組織図は、まさに「誰が何にアクセスでき、誰が何を承認するか」を定義する権限図へと書き換えられている。この二つの判断は予測ではなく、第一線のベンチャーキャピタリストが実際に投資しているプロジェクトで既に起きている現実である。（登場人物はa16zパートナー／元Microsoft幹部、VCの立場。）
五、自己チェック：あなたの組織はどの「コンウェイの誤り」を犯しているか？
ここまで読んで、「これらの道理はすべて理解している」と思っているなら、次の練習をしてみてください。
以下は、コンウェイの法則およびその拡張研究に基づいてまとめた5つの一般的な「組織-アーキテクチャの不一致」パターンです。自社と照らし合わせ、いくつ当てはまるか確認してください：
- ❶ 表面的なマイクロサービス： コードは分割したが、50人がまだ1つのチャットグループで喧嘩している。
- ❷ 中台の幻覚： 中台がすべての事業ラインのコミュニケーションのボトルネックになっている。
- ❸ AIの孤島： AIチームが開発したモデルは、組織的に「道が違う」ため、ビジネスに組み込めない。
- ❹ リモート協力の劣化： 物理的な隔離が、不要なシステムの分断を引き起こしている。
- ❺ 子会社の消化不良： 組織文化の不適合により、技術統合が失敗した。
次に進む
これは「AI時代のソフトウェア工学の変革」シリーズ15本のうちの第1篇です。私たちはコンウェイの法則から出発し、基本的な認識を確立しました：組織構造がシステム構造を決定する——これは比喩ではなく、実証的に検証された因果関係である。
しかし、この法則を知ることは始まりに過ぎません。真の問いはこれです：私たちはこれを逆に活用できるのか？
理想的なシステムアーキテクチャを誘導するために、意図的に組織構造を設計する——これが「逆コンウェイ・マニューバ」（Inverse Conway Maneuver）の核心思想です。
次回の記事『Team Topologies——アジャイル後の組織設計方法論』では、Matthew Skelton と Manuel Pais がこの思想を、4つの基本的なチームタイプ、3つの相互作用パターン、そして過小評価されすぎている「認知負荷」という概念を含む、完全かつ実践可能な方法論へと発展させた過程を深掘りします。Netflix、Adidas、Accenture などの事例を通じて、逆コンウェイ・マニューバがどのような条件下で有効であり、どのような条件下で失敗するかを具体的に示します。
シリーズ说明：本シリーズでは、AIプログラミングツール、組織構造、ソフトウェア工学のパラダイムの最新の進化を追跡します。2026年におけるAIエージェント時代のコンウェイの法則の変化、最新ツールエコシステムの成熟度なども含みます。本シリーズをフォローして、継続的な洞察をお届けします。
このシリーズについて
「AI時代のソフトウェアエンジニアリングの変革」は、企業の技術意思決定者を対象とした深度ある研究シリーズで、全15編から構成されています。200篇以上の学術論文と業界レポートを体系的に分析した結果をもとに、証拠レベルが明示された意思決定の指針をご提供します。更多精彩コンテンツをお楽しみに。
参考文献：
- Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31.
- Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
- MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
- Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
- Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
- Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
- a16z (2026). Software in the Age of Agents. The a16z Podcast.（Steven の名言「エンタープライズソフトウェアにおける最大のネットワーク効果は、企業の内部にある」、および Seema Amble がエージェントが企業システムにアクセスする際に権限・認証・ライセンス枠に突き当たるという観察——これらは第4節の判断一、二を裏付ける。一次情報源：ポッドキャスト原音。立場注記：a16z パートナー／元マイクロソフト幹部、VC 立場。ゲスト確認済み：a16z エンタープライズチームパートナー Seema Amble、元マイクロソフト Windows 社長 Steven Sinofsky（ボードパートナー）、a16z 記者 Elena Burger；2026年7月放送。）
buymeacoffee
