開発チームの作り方、それで大丈夫？ーー「コンウェイの法則」とは
ソフトウェア開発では、そのチームの作り方が成功の鍵を握ります。
つまり、誰をどの役割に配置するかによって、プロジェクトの成否が左右されるのです。
ここで注目したいのが「コンウェイの法則」という考え方です。
コンウェイの法則：組織の構造がシステムを形作る
コンウェイの法則とは、システムを設計する組織は、自らのコミュニケーション構造を真似た設計を生み出すという制約を受けるという考え方です*1。この考え方は、米国のプログラマーであるメルヴィン・コンウェイ（Melvin E. Conway）氏が発表した論文に記されたものです。
例えば、ある一つのシステム開発に携わる3つのチーム（A、B、C）があったとしましょう。
チームAとBは同じオフィスで働いており、昼食も一緒に取るなど、頻繁にコミュニケーションを取っています。一方、チームCは別のオフィスにあり、週に一度の定例ミーティングでしか顔を合わせません。
こうした状況では、どんなことが起き得るのか。
それは、そのシステム設計がおのずとその組織構造を反映されたものになるということです。
具体的には、チームAとBが開発するコンポーネント間のインターフェースは多く、複雑な情報をやり取りできるのに対して、チームCのコンポーネントとのインターフェースは少なく、依存度も低くなります。
このように、コンウェイの法則ではシステムと組織の構造が一致することが指摘されているのです。
コンウェイの法則と逆コンウェイの法則
このように、コンウェイの法則はシステムの設計が組織の構造を反映するという考え方です。
しかし、この法則は単なる理論にとどまらず、我々の身近なシステム開発の現場でも起こっており、様々な問題を引き起こしています。
例えば、システム刷新に関わるプロジェクトはわかりやすい例のひとつだと考えられます。
新しく要件定義された機能別にプロジェクトチームが分かれていると、チーム間のコミュニケーションが円滑に行われにくくなります。しばしば見かけるのは、ユーザー部門とIT部門との分断でしょう。要件定義や予算決定などがうまくやり取りできず、プロジェクトが停滞することは皆さんの経験したことがあるのではないでしょうか。
さらにIT部門側が外部委託をしている場合、さらにその組織構造がシステム設計にも影響してしまい、非常に複雑で、変更が困難なものになりがちです。
近年はこうした課題感を踏まえ、GoogleやAmazonなどが「逆コンウェイの法則」と呼ばれるアプローチを試みています*2。つまり、アーキテクチャが組織構造に依存する法則にのっとり、最初からアーキテクチャに合わせた組織構造を作るというものです。
このアプローチもまた課題はいくつか存在しますが、改めて肝に銘じておきたいのは、システムと組織の間に密接な関係があることです。したがって、プロジェクト成功のためにも、どのような組織やチームで取り組むべきかをしっかり検討することが、ビジネスの成功に貢献することができると考えられます。
（参考情報）
*1 Conway, Melvin E. (April 1968). "How do Committees Invent?". Datamation. 14 (5): 28–31.
*2 *2 日経XTECH「変われない組織が目指すべき、GAFAMに浸透する「逆コンウェイの法則」とは」https://xtech.nikkei.com/atcl/nxt/column/18/02470/061200005/（2024年8月18日アクセス）
★関連投稿はこちら★
【開発チームの作り方、それで大丈夫？ーー「コンウェイの法則」とは】
— 太田昂志｜ゆめみCHRO (@oh1ta) August 18, 2024
ソフトウェア開発では、そのチームの作り方が成功の鍵を握ります。
つまり、誰をどの役割に配置するかによって、プロジェクトの成否が左右されるのです。
ここで注目したいのが「コンウェイの法則」という考え方です。…