こんにちは、阿久梨絵です。
今回は、開発の現場で知らず知らずのうちにソフトウェアの構造を決めているともいえる「 コンウェイの法則 」について深掘りしていきます。
コンウェイの法則とは？
「ソフトウェアの構造は、それを作った組織の構造を反映する」
（Melvin Conway, 1968）
開発チームが持つコミュニケーションのパターンや組織の分断状態が、そのままソフトウェア設計に現れるという法則です。
例えば——
・チームが3つに分かれていれば、自然と3つのモジュールに分かれたアーキテクチャになる
・部門間の連携が弱いと、設計にもその”断絶”が現れ、非効率な結合になることも
つまり、組織のあり方がそのまま技術的負債にも生まれ変わってしまう可能性があるということ。
なぜ組織が設計に影響するのか？
1. コミュニケーション経路が制限を生む
情報の流れが分断されていれば、チーム間で統一された設計思想を保つのは困難になります。
2. 責任の範囲＝モジュールの分割単位になりやすい
担当者のスコープによって、自然と「ここまでがうちの役割」→「ここで設計を区切ろう」となりがちです。
3. 合意形成コストの回避
複雑な調整を避けるため、システム設計が現実の組織の制約に”合わせて”作られてしまう。
コンウェイの法則の活用法：設計を変えたいなら、組織を変えよ
チームの並列性とアーキテクチャを一致させる（逆コンウェイ戦略）
→ 「この機能領域はこのチームが責任を持つ」ように整えることで、疎結合で保守性の高いシステムへ。
機能横断チーム（クロスファンクショナル）を導入
→ 一部門に閉じず、UX・フロント・バックエンドが横断的に関与することで、縦割り構造を解消できる。
重要なドメインを組織構造の中心に置く
→ ドメイン駆動設計（DDD）と組み合わせることで、技術と業務の整合性がとれる設計へと導ける。
事例で見る：ありがちな「組織の制約による設計崩れ」
・営業部門と技術部門の目的のズレ → 顧客志向のプロセスが断裂、機能優先型のUI設計に
・フロントとバックエンドで完全分離 → データ整合性やUXのギャップが後々発覚
・外注先との役割境界が曖昧 → 境界づけされた責任範囲がコード上に滲み出てしまう
まとめ
ソフトウェアアーキテクチャは、単なる技術的成果ではなく、チームの文化や構造の写し鏡です。
だからこそ、テックリードやマネジメントに求められるのは「コードの設計力」だけでなく、「組織のデザイン力」でもあるのです。
阿久梨絵でした！
