組織構造に固執する上司が知らない『コンウェイの法則』

詳しく解説！雑学のコーナー

コンウェイの法則は、1967年にプログラマーのメルヴィン・コンウェイが提唱した組織論とシステム設計に関する法則です。「システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計を生み出す」という内容で、ソフトウェア開発における組織とアーキテクチャの密接な関係を指摘しました。 コンウェイ自身は、国際的なコンピュータメーカーで働く中で、この法則を発見しました。当初、彼の論文は「証明がない」という理由で学術誌に掲載を拒否されましたが、その後、数多くの実証研究によってその正しさが証明されました。ハーバード・ビジネス・スクールの研究では、数百のソフトウェアプロジェクトを分析した結果、組織構造とシステムアーキテクチャの相関係数が0.85という驚異的な数値を示しました。 有名な実例として、マイクロソフトのInternet Explorerの開発があります。開発チームが機能別に分かれていたため、ブラウザ自体も機能ごとにモジュール化され、結果として動作が重くなりました。一方、Firefoxは少数精鋭のチームで開発されたため、統合的で軽快なアーキテクチャを実現できたのです。 アマゾンの「Two-Pizza Team」ルールも、コンウェイの法則を意識した組織設計です。小さなチームがマイクロサービスを担当することで、サービス間の結合度を低く保っています。NetflixやSpotifyも同様に、自律的な小チームによる開発体制を採用し、それぞれがマイクロサービスアーキテクチャを成功させています。 逆コンウェイ戦略という考え方も生まれました。これは、望ましいシステムアーキテクチャから逆算して組織構造を設計する手法です。ThoughtWorksは、この戦略を用いて、クライアント企業の組織改革とシステム刷新を同時に行うコンサルティングを提供しています。 日本企業では、この法則の理解不足が深刻な問題を引き起こしています。縦割り組織のまま統合システムを作ろうとして失敗した例は枚挙にいとまがありません。ある大手銀行では、部門ごとに異なるベンダーに発注した結果、システム間の連携に追加で数百億円かかった事例もあります。みずほ銀行のシステム統合の困難さも、三つの銀行の組織文化が統合されないまま、システムだけを統合しようとしたことが一因とされています。 最新のDevOps文化も、コンウェイの法則への対応策の一つです。開発と運用を分離した組織では、デプロイが困難なシステムができあがります。DevOpsは、開発と運用を一体化することで、継続的デリバリーが可能なシステムを生み出すのです。 マイクロサービスアーキテクチャの流行も、コンウェイの法則と無関係ではありません。モノリシックなシステムを維持するには、全体を把握する巨大なチームが必要ですが、マイクロサービスなら小さなチームで管理できます。しかし、組織がサイロ化したままマイクロサービス化すると、「分散モノリス」という最悪の結果を招きます。 興味深いことに、オープンソースプロジェクトもコンウェイの法則に従います。Linuxカーネルの構造は、その開発コミュニティの階層構造を反映しています。一方、分散型で開発されているGitは、分散型のアーキテクチャを持っています。組織構造がソフトウェアの思想にまで影響を与えるのです。