Redmineプロジェクトの構造とConwayの法則

Redmineの複数プロジェクト構造と組織構造の関係を示唆したTwitterで気付いたことがあったのでメモ。
ラフなメモ書き。

【元ネタ】
Twitter / @cointoss: Redmineがプロジェクトを頂点をする階層構造になっているおかげで情報が自然と整理される。製品開発を一つのプロジェクトとした場合、所属グループ（複数プロジェクトにまたがっていたと仮定）単位で実施していた進捗会議をプロジェクト単位に整理しようという動きが生まれてくる。

Twitter / @akipii:@cointoss1973 @sakaba37 ソフトウェアプロダクトラインやConwayの法則を連想させます。所属チーム単位ではなくフィーチャ単位で、チーム主導よりもアーキテクチャ主導でプロジェクト管理していこうという発想でうね。面白いです。#redmine

Twitter / @cointoss: Conwayの法則的には、Redmineはチームに従い、チームはRedmineに従う。といったところか。結果として チームとRedmineが整合すると良い。

鈍重な開発チームは鈍重なシステムを作る？ － ＠IT情報マネジメント

Conwayの法則～アーキテクチャは組織にしたがう: プログラマの思索

コンウェイの法則 - Strategic Choice

「保守しやすいこと」が、良いプロセス～開発における、「設計」と「プロセス」の双対関係～：An Agile Way：ITmedia オルタナティブ・ブログ

【1】Conwayの法則は下記で紹介されている。
すなわち、ソフトウェアの構造はそれを作った組織を反映しているという法則。

Conway's Law

パターン１４：Conwayの法則
別名：
アーキテクチャは組織にしたがう
(中略)
解決策：
組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。
(中略)
論理的根拠：
このパターンは歴史的なものである。
Gerard Meszaros (BNR)は、人々はアーキテクチャが安定してから組織をアーキテクチャに合わせようとしたがる、といっている。もし、早すぎる時機に組織をアーキテクチャに合わせると、アーキテクチャの変化の流れは個々人の統制の範囲の間での干渉を引き起こす。

コンウェイの法則（Conway's Law） - Plan9日記

(引用開始)
要はソフトウェアの構造はそれを作った組織を反映しているという法則。3機関が協業した複雑なMulticsに対して少数精鋭の研究者がシンプルに作ったUNIX。巨大化する商用UNIXと、原点回帰したPlan9。Microsoftの発展と、MS-DOSからWindowsへの流れ。オープンソース革命とLinux。なるほど、いろいろ思いあたるところがある。
この法則、最初にどこで読んだのか忘れてたけど、Fred Brooks Jr.の「人月の神話」だったのか。
(引用終了)

【2】「Redmineのプロジェクトはどんな単位にすべきか？」という質問はよく出る。
僕は下記に書いたように、「開発チームの単位」「ブランチの単位」と考えていた。

RedmineとTracの機能比較: プログラマの思索

だが、上記のTwitterで、Redmineプロジェクトは「製品単位」に作るべきではないか、という事実に気づいた。
「製品」とは、ビルドモジュールの単位だし、ITプロジェクトの最終的な成果物であり、SCMブランチ(trunk)でもある。

製品単位にRedmineプロジェクトを作った場合、メンバーはどのRedmineプロジェクトにアサインされて、タスクはどのRedmineプロジェクトへ配置されるのか？
解答は、メンバーのアサインやタスクの配置の観点は、まさにConwayの法則通りに従えばいい。
所属チーム単位ではなく、フィーチャ(サブシステム)単位に管理する。
メンバー主導ではなくアーキテクチャ主導。
つまり、Redmineプロジェクトは、SIの組織構造にマッピングするのではなく、製品のアーキテクチャにマッピングすればいい。

組織主導よりもアーキテクチャ主導の方が良いシステムが作れる。
Redmineプロジェクトはチーム単位よりも、派生された製品単位に作る。
メンバーは複数プロジェクトに所属して、要員の流動化を図る方がよい。

下記のBlogでも似たような発言がある。

なぜRedmine導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド

(引用開始)
僕の所属していたプロジェクトはいわゆるソリューション開発というやつで、リリースするお客さんごとに
微妙にカスタマイズするのが常である。
SCMについてはメインラインモデルを利用した管理で十分だったが、ITS側でもカスタマイズごとに
プロジェクトを分けて管理した方が、視覚的にも整理されたのではないかと感じる。
TracでもTraMで複数プロジェクトが管理できるが、Redmineの「プロジェクトの親子関係」の方が
直感的で分り易く、やりたいことがすぐに実現できたのではないか。
事実、Redmineを導入したプロジェクトもソリューション開発であるが、早期からプロジェクトの親子関係を
使って顧客ごとにプロジェクトを分割したため、要件の整理に大変役立った。
(引用終了)

一つの製品(プロダクト)があり、その製品を複数の顧客へカスタマイズして開発している場合、例えば、親プロジェクトは共通の「製品」プロジェクト、子プロジェクトに顧客ごとにカスタマイズした時に発生するタスクの単位にすればいいだろう。
つまり、オリジナルの製品に対して派生された製品群は、Redmineのサブプロジェクトへ配置すればいい。
そして、メンバーは、複数プロジェクトにアサインされる。

すなわち、ソフトウェア組織は基本的にはPMBOKの言うマトリクス型組織になるだろう。
ラインとプロジェクトの2つの指揮命令系統がある組織構造にならざるを得ない。
縦割りの組織ならば、リーダー同士で調整しないと、メンバーは混乱する。

マトリクス組織 － ＠IT情報マネジメント用語事典

複雑な組織構造を作ると、アーキテクチャが組織構造に依存して、コミュニケーションの疎遠さがシステムをバラバラにしてしまう。
例えば、サブシステムと開発チームを密に関連付けてしまうと、チーム同士のインターフェイスがシステムのインターフェイスの溝になってしまうだろう。
大規模システムの開発案件ほど、それぞれの開発チームがタコツボのようになってしまい、チーム同士のコミュニケーションの疎遠さがそのまま開発のやりにくさに比例してしまうのは、そういう構造があるからだろう。

アジャイルな開発組織ならば、Scrumの言う自己組織化されたチームの集合体になっているだろうから、メンバーが複数のプロジェクトにアサインされていても、うまく調整出来るだろう。

Redmineプロジェクトの構造と組織構造、アーキテクチャが密接に関係するという事実、そして、特に製品ファミリー開発や派生開発でRedmineの複数プロジェクト機能が有効である事実は、ソフトウェアプロダクトラインの話を連想させる。
ソフトウェアプロダクトラインの話では、いつも組織構造の話が出てきて、何故そんな話が必要なのか、ピンとこなかったけれど、Conwayの法則の観点から考えれば、ごく自然な発想なのだろう。

この観点をもっと考えてみる。