コーンウェイの法則![Conway]()
「コーンウェイの法則」というのを知ってますか？Jim Conplien の組織プロセスパターンにも登場しますが、”組織の構造がソフトウェアの構造に反映する“あるいはその逆、“ソフトウェアの構造が組織の構造に反映する”というものです。Wikipedia によると、
Conway’s law is an adage named after computer programmer Melvin Conway, …
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”
— M. Conway
分かりやすくたとえが、「４つのチームでコンパイラを作成すると、4 pass コンパイラになる」
という言い方で知られています。
逆コーンウェイ戦略
少し前の ThoughtWorks のテクノロジーレーダーに、逆コーンウェイ（“Inverse Conway Maneuver” ）というのがあり、気になっていましたのでちょっと調べてみました。
コーンウェイの法則が、「観察結果」に対しての「こうなっちゃいます」というパターンとして言語化されているのに対して、逆コーンウェイは、「積極的に組織とコミュニケーションを設計しよう」というのです。観察でなく、積極的に。Maneuver、すなわち設計戦略なのだと。
“The ‘Inverse Conway Maneuver‘ recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture.”
– Technology Lader (ThoughtWorks)
拙訳：逆コーンウェイ戦略は、自分たちのアーキテクチャ設計を促進するようにチームと組織を進化させることを推奨する。理想的には「技術的アーキテクチャ」が「ビジネスアーキテクチャ」の同形写像になるように。
現代流に言えば、
- DevOps をやるなら、Dev と Ops を同じ組織にせよ。
- Agile やるならワンチームで。
- 複数の Agile チーム構成にするとき、でビジネスに分かりやすい機能（フィーチャ）を重視するなら、コンポーネントチーム（ソフトウェアの部品に着目したチーム構成）でなく、フィーチャーチーム（機能縦割りのチーム構成）で。
- Microservices アーキテクチャを採用するなら、ちいさいAgileチームをたくさん。
ということになると思います。要するに、「人間間のコミュニケーション流」というものがソフトウェア開発には決定的なインパクトを与える、ということをまず認め、それを積極的に活用するように、ということです。
「ソフトウェアは会話でできてる」(Software is made of conversations) という、このブログのテーマそのものだったので、ちょっと嬉しかったのです。
以下、参照文献。
- Technology Lader (ThoughtWorks)
https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver - DevOps Insight’s into Conway’s Law
http://intellyx.com/2015/06/22/devops-insights-into-conways-law/