システム開発における設計の法則、「コンウェイの法則」を5分でわかるようにご紹介します。
コンウェイの法則
「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」 1967年にアメリカのコンピュータープログラマーのメルヴィン・コンウェイ（Melvin Edward Conway）が提唱した原則です。 提唱されてからすでに半世紀が経過しており、当時のシステム開発を取り巻く環境は、現在の環境とは異なる部分が多いですが、 今なお多くの文脈で引用されている法則になります。
コンウェイの法則に当てはまるコンウェイ型の例として、バックエンド、フロントエンド、インフラなどの「職能型」のチーム構成があります。 こうしたチーム分割を行うと、各チーム内で完結するシステム変更は問題なく対応できますが、 チーム内で完結しない変更が発生した場合、チーム間のコミュニケーションが多く発生し、コスト増の要因となってしまいます。 チーム内でのコミュニケーションコストよりも、チームをまたがったコミュニケーションコストが大幅に高いことで、チーム内は密結合に、チーム間は疎結合になっていきます。
逆コンウェイの法則
この法則を逆手にとったのが、昨今提唱されている逆コンウェイの法則になります。 アーキテクチャが組織構造に依存する法則にのっとり、最初からアーキテクチャに合わせた組織構造を作るのが、逆コンウェイの法則になります。 職能型の組織構造ではなく、サービス単位の組織構造をとることで、チーム間のコミュニケーションコストの削減や、システムの変更コストの削減が見込めます。
まとめ
どのようなプロジェクトであるか、また、各チームメンバーのスキルによって、どちらの法則が適切かどうかは変わってきます。 逆コンウェイ型の組織の場合、ある程度のスキルがあり、個人で一定の成果を出せる前提で組織体制を検討しないといけません。 例えば、新入社員を組み込むとなると、その役割が全うできない期間は少し厳しい可能性があります。 また、サービス単位での分割が可能であることも、逆コンウェイ型の組織の前提となります。