コンウェイの法則の反転現象
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.
システムを設計するあらゆる組織は、組織の通信構造と同じ構造の設計を必然的に作成する
To the extent that organizational protocol restricts communication along lines of command, the communication structure of an organization will resemble its administrative structure. This is one reason why militarystyle organizations design systems which look like their organization charts.
組織のプロトコルが指揮系統に沿って通信を制限する範囲内で、組織の通信構造はその管理の構造に似たものになる。これが、ミリタリースタイルの組織が組織図のようなシステムを設計する理由の 1 つです。
コンウェイの法則は設計しか語っていない
この法則がソフトウェア開発においても普遍的なものだと言い伝えられてきたこの数十年の時代背景を考える
多くの企業にとって、ソフトウェアはシステム開発会社や、開発部署へ発注するものだった
「どのようなシステムが必要か」を考える主体と、それをシステム仕様に落とし込み開発する主体は別であった
コンウェイの法則でいう「設計」とは、前者のことだろう
つまり、「組織」や「業務プロセス」などの「われわれ」の構造が、発注するシステムへの要求にそっくりそのまま表れ、その要求に最適化した形にシステムが実装される
ソフトウェア開発のレベルでの「設計」は顧客の要求に応えるものにすぎず、その根本原因は発注者側の要求である
その意味で、コンウェイの法則がソフトウェア開発において成立してきた背景には、システムを「設計=要求する主体」と「実装する主体」が異なっていたこと、さらに「実装する主体」が「設計=要求する主体」に逆らえない関係（一方的に要求する関係）であったことが前提にあるのではないか
「実装する主体」が「設計=要求する主体」に逆らえない関係
クライアントとベンダー
営業部門と開発部門
設計=要求したとおりに実装されることを前提としている
だが現在、その前提の普遍性が薄れていく中で、コンウェイの法則が反転したような現象が起きているのではないか
コンウェイの法則の反転現象
内製化の進行による構造の変化
内製化とは「設計=要求する主体」と「実装する主体」がひとつになるということ
「設計=要求する主体」が「実装する主体」でもあるという構造は、意思決定に新しい力学をもたらす
すなわち、実装の困難さ
これまでは、「われわれの組織」を基準にそれに最適化したシステムを設計=要求すれば、そのように実装されたシステムが手に入った
しかし内製化によって「われわれの組織」と「われわれのシステム」がどちらもコントロール可能なものとして手元にやってくる。そうすると、「どちらに手を入れようか」という選択の余地が生まれる
この意思決定は他の多くの場合と同じく、簡単で楽な方が選択される
どちらに手を入れるのが簡単で楽か、つまり、どちらの変更容易性が高いかという問い
変更容易性は、それが現状を維持しようとする力と、それを変化させられる力のバランスによって決まる
組織にもシステムにも、現状を維持しようとする力がある
日々の小さな意思決定は現状に最適化した形で次々に積み重ねられ、現状を変えにくくし続ける
変化させられる力
組織においては、人を巻き込んで動かしていく力であり
システムにおいては、アーキテクチャを把握して適切に変更を加えていく力である
これらのことから、次の反転現象が説明できる
システムの構造を変更するほうが組織の構造を変更するよりも困難である場合、組織の構造はむしろシステムの構造から優越的に影響を受ける
つまり、システムの構造と組織の構造がミスマッチしたときに組織のほうが適応してしまうという、コンウェイの法則とは逆の現象
システム開発能力の養成が不十分なまま内製化を進める組織においては、この反転現象が起こりやすい
システムの構造を変更することが楽ではないため
また、ソフトウェア開発現場のアジャイル化はこの現象をさらに促進するだろう
アジャイルな組織とは変更容易性の高い組織であるため、システム開発能力が追いつかなければ必然的に組織側が適応しつづけることになる
たとえば次のようなケースが想像できる
システムの構造を改善するために、逆コンウェイ戦略を狙って職能横断的なフィーチャーチームを作ったとする チームの責任範囲と現状のシステムの節理面が違っているミスマッチがある
それを狙って正そうとする逆コンウェイ戦略である
だが、システムの構造を変化させる力が弱ければ、フィーチャーチームに合わせて横断的に動きやすいシステムに変えていくよりも、チームの構造をシステムに合わせるほうが楽になる
また、新しいチームは現状を維持しようとする力も弱いため、組織の方の変更容易性が高い
結果として、フィーチャーチームの中で特定のレポジトリやシステムごとに専任のサブチームが作られたりする本末転倒なことが起きる
翻って、逆コンウェイ戦略を機能させる条件として、新しく作られる組織が瓦解することなくシステムの構造を変更できるような力のバランスが必要である 組織の芯、軸がどれだけ強固であるか（Whyを見失わない）
システムを適応させていく設計力・実装力