逆コンウェイ戦略のメモ～望ましいアーキテクチャを促進するためにチームと組織構造を進化させる

平鍋さんの記事で「逆コンウェイ戦略」という概念を初めて知ったのでメモ。
まだ消化不良なので、ラフなメモ書き。

【参考】
逆コーンウェイ戦略とDevOps, Microservices, Agile | an Agile Way

ThoughtWorks Technology Radar 2014年7月版

Inverse Conway Maneuver | Technology Radar | ThoughtWorks

James Lewis/Martin Fowlerの"Microservices"日本語訳 - 自由課題

分散スクラム

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク: プログラマの思索

第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

Redmineチケット一覧のフィルタ「対象バージョン」のリストが大量表示されて使いにくい問題点: プログラマの思索

【1】(引用開始)
(8) Inverse Conway Maneuver (Trial) (逆コンウェイ戦略)
「望ましいアーキテクチャを促進するためにチームと組織構造を進化させること」、理想的にはテクノロジとビジネスのアーキテクチャが同じ形になることを提案する。
(引用終了)

(引用開始)
拙訳：
逆コーンウェイ戦略は、自分たちの望ましいアーキテクチャ設計を促進するように、チームと組織側を機動的に進化させることを推奨する。理想的には「技術的アーキテクチャ」が「ビジネスアーキテクチャ」の同形写像になるように。

現代流に言えば、
DevOps をやるなら、Dev と Ops を同じ組織にせよ。
Agile やるならワンチームで。
複数の Agile チーム構成にするとき、でビジネスに分かりやすい機能（フィーチャ）を重視するなら、コンポーネントチーム（ソフトウェアの部品に着目したチーム構成）でなく、フィーチャーチーム（機能縦割りのチーム構成）で。
Microservices アーキテクチャを採用するなら、小さなAgileチームをたくさん。
ということになると思います。

要するに、「人間や組織間のコミュニケーション（情報流）」というものがソフトウェア開発には決定的なインパクトを与える、ということをまず認め、それを積極的に活用するように、ということです。
「ソフトウェアは会話でできてる」(Software is made of conversations) という、このブログのテーマそのものだったので、ちょっと嬉しかったのです。
(引用終了)

【2】最近、Redmineの運用が大規模になっていくと、会社の既存の組織の枠組みが組織慣性となってしまい、軽量プロセスとして思うように運用できない場面に遭遇する時がある。
5人だけの1チームでチケット駆動でやっていても、ユーザ100人で50個以上のプロジェクトが運用されていれば、メンバー同士やチーム間だけでなく、会社としての開発業務がどのように運用されるべきか、という問題まで発展する。

そもそも、Redmineでは、Redmineプロジェクト＝ソース管理の1リポジトリ＝1システムという設計思想で作られている。
僕は、その思想を受け継いで、Redmineプロジェクトを階層化していけば何とかなると思っていた。

しかし、ソフトウェア開発のタスク管理以外に、ソフトウェア保守やサポートデスク、事務処理ワークフローまでRedmine運用を拡大すると、どうしてもRedmineの機能に不満が出てくる時もある。
そもそも会社としてどのような運用ルールが必要なのか分かっていないことが根本問題になってくる。
たぶん、RedmineやJira、Tracなどのチケット管理ツールだけの問題ではなくなってくるのだ。

つまり、組織構造に見合った運用フローをRedmineに適合させようとして、上手く適合できていない症状が現れていると思う。
その根本原因は、大規模運用に見合ったRedmineの機能不足もあるだろうが、むしろ、組織構造に見合った運用フローが組織内で明確化されてメンバー全員に共有されていない事の方にあると思う。

【3】Conwayの法則は「4チームでコンパイラを作れば4パスコンパイラとして無駄に複雑に作ってしまう」という経験則。
この経験則は、身近なソフトウェア開発組織でもよく見られる。
「鈍重な組織構造は鈍重で複雑なソフトウェアシステムを作る」とも言い換えられる。

(引用開始)
チーム メンバーが物理的に近接していない場所で作業している場合は、チーム内のコミュニケーションは確実により複雑になり、チームが作成するソフトウェアにも同じことが当てはまります。
1968 年に、Melvin Conway (メルビン コンウェイ) 氏は次のように説明しました。
システムを設計する組織には、その組織のコミュニケーション構造を反映した設計を作り出すという制約が課されます。

Conway の法則は、ただの格言ではなく、より実証的な説明です。
ソフトウェア開発チーム内では、測定可能な動的要因になる可能性もあります。
ある研究では、チーム分散という事実がシステム アーキテクチャに及ぼす影響を測定して、Conway の法則が実際に影響力を持つことが実証されました。
チーム メンバーが分散している場合は、ソフトウェア開発者が互いを分離しようとして、コード内でより多くの抽象化レイヤーを作成する傾向に陥りがちです。
(引用終了)

一方、逆コンウェイ戦略は、この経験則を逆手に取って、アーキテクチャに見合った組織構造になるように戦略的に組織構造を作り直すべきだ、と考えられる。
アジャイル開発をやりたい、マイクロサービスで開発したい、と思うならば、そのアーキテクチャに適合する組織になるように、戦略的に意図してチーム構成を考えるべきだ、とも言い換えられる。
面白い発想だと思う。

【4】この発想をRedmineによるチケット駆動開発に適用すると、どのような思想になるだろうか？

Redmineのプロジェクト、バージョン、チケット、トラッカー、ロール、カテゴリは、逆コンウェイの法則に即した組織構造とどのようにマッピングされるのか？

チケット駆動開発に逆コンウェイの法則を適用した場合、アジリティを活かした組織構造はどのようにあるべきか？

数多くの機動的なチーム(例：スクラムチーム)で運用する場合、数多くのチームがバラバラにならないように見通しが良くなるように統制する方法をRedmineの機能で提供できるのか？