組織プロセスパターンにも登場しますが、”組織の構造がソフトウェアの構造に反映する“あるいはその逆、“ソフトウェアの構造が組織の構造に反映する”というものです。コンパイラになる」という言い方で知られています。)というのがあり、気になっていましたのでちょっと調べてみました。コーンウェイの法則が、「観察結果」に対しての「こうなっちゃいます」というパターンとして言語化されているのに対して、逆コーンウェイは、「積極的に組織とコミュニケーションを設計しよう」というのです。観察でなく、積極的に。Maneuver、すなわち設計戦略なのだと。行く、という意味合いがあります。(ThoughtWorks)拙訳:逆コーンウェイ戦略は、自分たちの望ましいアーキテクチャ設計を促進するように、チームと組織側を機動的に進化させることを推奨する。理想的には「技術的アーキテクチャ」が「ビジネスアーキテクチャ」の同形写像になるように。やるならワンチームで。チーム構成にするとき、でビジネスに分かりやすい機能(フィーチャ)を重視するなら、コンポーネントチーム(ソフトウェアの部品に着目したチーム構成)でなく、フィーチャーチーム(機能縦割りのチーム構成)で。アーキテクチャを採用するなら、小さなAgileチームをたくさん。いうことになると思います。要するに、「人間や組織間のコミュニケーション(情報流)」というものがソフトウェア開発には決定的なインパクトを与える、ということをまず認め、それを積極的に活用するように、ということです。