今回はコンウェイの法則について、できるだけわかりやすく例を交えて解説していきます。大規模開発になるほど影響を受けやすいこの法則…あなたの開発現場も無関係ではないはずです。
コンウェイの法則とは
「システム設計する組織は、組織のコミュニケーション構造をコピーした構造の設計を生み出す」
なぜこのような法則が述べられたのか、その理由を紐解いてみましょう。
コミュニケーション境界とソフトウェア境界は相関する
理由を端的に述べると、各コンポーネントを開発するチーム間のコミュニケーションのあり方とコンポーネント間のインターフェースのあり方は相関性があるためです。(この記事ではソフトウェアを構成する部品をコンポーネントと呼ぶこととします。)
例
もう少しかみ砕いて、例えば以下のような状況を考えてみましょう。
あるプロジェクトに関わっている3つのチーム(A,B,C)を例にとって考えてみましょう。チームA,Bは終日同じ拠点で開発を行っており、昼食もガヤガヤと一緒に取るような関係です。一方、チームCは別拠点の所属で、A･Bとは週1回の定例ミーティングをするようにしています。
このような前提で開発を開始すると、自然と次のような状態になります。
- チームA･BとチームCとのコミュニケーションの機会は必然的に少なくなる
- チームA･B間のコミュニケーションの機会は、多くなる
すると、コミュニケーションの状態によって、コンポーネント間の構造に次のような影響を及ぼします。
コミュニケーションをとる機会の多いチームA･Bが開発するコンポーネント間のインターフェースの本数は自然と多くなり、かつ複雑な情報をやり取りしやすくなります。A･Bはいつでも相談しやすいので当然といえば当然です。
一方で、コミュニケーションの機会が少なく、開発に関する情報のやり取りが少なくなりがちなチームCの作るコンポーネントとのインターフェースは相対的に少なくなり、依存の度合いは疎になります。チームCとの情報のやり取りを面倒くさがっている風にも見えますが、定例ミーティングに加えて、必要に応じ追加ミーティングを実施するという前提でもこのような状況は発生し得ます。
この例では、コミュニケーション境界を「拠点」と紐づけていますが、それ自体が問題であることを述べるための例ではありません。実はチームCのリーダーが嫌われ者だとか、口数が少ないとかでも構いません。重要なのは組織のコミュニケーション境界であり、それがソフトウェアの構造に反映されるということです。上記の例のように、コンウェイの法則で述べられた製品は日夜生み出され続けています。こういったことを体感しているエンジニアも多いのではないでしょうか。
名前の由来
この法則はメルヴィン・コンウェイ氏の格言に対して、コンウェイ氏の名前が付いたものです。例にもれず、先人のお名前が法則名の由来でした。そしてこの法則も1970年には明文化されていたとか…恐れ入ります。
参考書籍
コメント