組織がどのようにコミュニケーションを取り、どのようにチーム編成をしているかは、そのままプロダクトやサービスの構造に現れる。たとえば、部門ごとに独立して作業を進めている組織は、分断されたシステムを作りやすい。一方、部門を横断して協力し合う組織は、統合的なシステムを生み出しやすい傾向がある。

組織内のチーム編成や意思疎通の流れが、そのままプロダクトやサービスの構造に現れるという法則がコンウェイの法則である。

この法則は、1968年にアメリカのコンピュータ科学者、Melvin Conwayメルヴィン・コンウェイによって提唱された。コンウェイ氏は論文「How Do Committees Invent?」の中で、「4つのグループがコンパイラを作れば、4つのパーツからなるコンパイラができる」と述べている。

組織とシステムは鏡写しになる

組織が4つの独立したチームを持てば、システムも4つの独立したモジュールに分かれやすい。

コンウェイの法則がもたらす影響

ポジティブな側面

組織設計とシステム設計がうまく連動すれば、効率的なモジュール化が進み、開発効率や保守性が向上する。チームごとに役割や責任が明確であれば、担当範囲も明確になり、問題発生時の対応も迅速になる。品質管理や責任の所在もはっきりする。

ネガティブな側面

チーム間のコミュニケーションが不十分だと、システム全体の統一感が失われ、バラバラな設計になりやすい。既存の組織構造に縛られることで、新しいアイデアや技術の導入が難しくなり、部門を越えた連携や新規事業の立ち上げが阻害されることもある。

みずほ銀行の事例：コンウェイの法則が招いたシステム障害

みずほ銀行は、第一勧業銀行、富士銀行、日本興業銀行の三行が合併して誕生した。しかし、合併直後に大規模なシステム障害が発生した。全国のATMが停止し、顧客が現金を引き出せなくなる、給与振込や公共料金の引き落としで二重処理が発生する、大量の振込処理が滞るなど、顧客からの信頼を大きく損なう事態となった。

この障害の根本的な原因は、三行がそれぞれ異なるベンダーが開発したシステムを持ち、それを一体化せずに運用したことで、複雑な連携や重複管理が発生した点にある。銀行統合の際、三行間での覇権争いがあった上、システムを開発したベンダー各社にとって三行が大口顧客であったこともあり、簡単にシステムを統合できなかった。その結果、システム統合には約10年という膨大な時間と数千億円規模のコストがかかった。

プロダクトやコンテンツデザインでの活用場面と事例

プロダクトやコンテンツデザインの現場では、コンウェイの法則を意識することが重要である。

具体的な事例

サービスのナビゲーション設計において、部署ごとに「検索」「お気に入り」「マイページ」などの画面を別々に担当した結果、体験として統一感のないUIが生まれた。

コンテンツチームと開発チームの間に十分な連携がないまま進めたプロジェクトでは、ユーザーにとって冗長な情報階層が残った。

対応策

目的ベースで横断チームを構成する（例：検索体験チーム、初回オンボーディングチームなど）。

チーム間のコミュニケーション構造を可視化し、意識的に「ユーザー中心の構造」に再設計する。

コンウェイの法則を理解し、活用しよう

コンウェイの法則は「組織とシステムは鏡写しになる」という本質を持っている。この法則を理解し、組織設計とプロダクト設計の両面から意識的に活用することで、ポジティブな影響を最大化し、ネガティブな影響を最小限に抑えることができる。デザインやプロダクト開発の現場では、組織構造やチーム編成を意識することで、より良い成果物を生み出すことにつながる。

参考サイト

http://www.melconway.com/Home/pdf/committees.pdf