---

コンウェイの法則

1967年にプログラマーのメルヴィン・コンウェイが提唱した定義がすべての出発点になる

システムを設計する組織はその組織のコミュニケーション構造のコピー複製であるような設計を生み出す制約を受ける

メカニズムの解説

システムでモジュールAとモジュールBを連携させるには、Aを作る人間とBを作る人間が事前にすり合わせを行う必要がある

組織上の摩擦が大きいと、その摩擦が設計に写る

• 2つのチームが別部署で権限が分かれている
• 社内政治で対立している
• 外注先が異なり契約や窓口が分断されている

結果として、モジュール間には次のような不自然さが入りやすい

• 使いにくいAPI
• 手動バッチ連携
• 手間のかかる物理的な作業分断

ソフトウェアのアーキテクチャは、その組織の壁の投影になりやすい

社会の渡り方ルールブック：3つの実践的教義

Rule 1: 「見えない内部構造」は「見えるプロダクト」から逆算せよ

企業の内情や組織の透明性・経営陣のITへの理解度・セクショナリズムの有無は決算書やIR資料・採用パンフレットには表れない しかしコンウェイの法則を使えば提供されるシステムのUXやAPIから内部構造を見抜ける

• 判定基準（サイロ化の検知）
  • サービスの分断
    • 例 複数の関連サービス間でIDが統一されておらず、資金や情報の移動に余計な手間や期間が必要
    • 内部構造の推測 部門間が縦割りで権限や予算、システム基盤が分断され、ユーザー体験より内部都合の境界線を優先している
  • 一貫性のないUI/UX 同じグループのアプリでも画面ごとにデザインや操作体系が全く異なる場合
    • 内部構造の推測 開発を複数の外注先に任せきりで、全体統括や品質管理を担う責任者がいない

行動原則

• プロダクトの境界線で摩擦やユーザーへの操作負担の転嫁を感じた場合、その企業は顧客志向ではなく内部の論理で動いている可能性が高い
• 投資対象やメインのプラットフォームの候補から外す

Rule 2: 逆コンウェイの法則（Inverse Conway Maneuver）を実行できない組織からは去る

現代のモダンなテック企業はこの法則を逆手にとり理想とするアーキテクチャに合わせて先に組織構造を設計し分割・独立させるアプローチを重視している

• 判定基準（組織のモダニティ）
  • システムをモダナイズすると公言しつつも組織図は従来型の領域別サイロのままの場合
    • 内部構造の推測 経営陣にコンウェイの法則の理解がなく、組織構造の改革なしにシステム刷新だけで解決できると錯覚している
    • 帰結 プロジェクトは失敗し、技術的負債だけが積み上がる

行動原則

• データサイエンティストやコンサルタントとして組織に関わる際「基盤を統合したい」という要望には「評価軸や権限など、組織構造も統合・再編する覚悟があるか」を確認する
• Noなら深く関わらない

Rule 3: 密結合のシステムは、技術的負債ではなく「組織的負債」である

バッチ処理が特定の時間に全体をロックするような現象は、システム全体が密結合の巨大なモノリスであることに起因する これをマイクロサービスのような疎結合かつ変更容易な構成にするには、各機能ごとに設計・開発・運用・データ管理まで自己完結できる独立した小さなチームが必要になる

行動原則

• 流動性の低い密結合組織では、システムだけを疎結合かつ流動性の高い構造にすることは難しい
• システム障害や利用時の摩擦を体験した場合、単なるITの遅れとして片付けず、硬直した組織構造の兆候として扱う
• 流動性の高いアーキテクチャとモダンな組織構造を持つ他社へリソースをシフトする