Redmineプロジェクトの構造とConwayの法則
Redmineの複数プロジェクト構造と組織構造の関係を示唆したTwitterで気付いたことがあったのでメモ。
ラフなメモ書き。
Twitter / @cointoss: Conwayの法則的には、Redmineはチームに従い、チームはRedmineに従う。といったところか。結果として チームとRedmineが整合すると良い。
鈍重な開発チームは鈍重なシステムを作る? - @IT情報マネジメント
Conwayの法則~アーキテクチャは組織にしたがう: プログラマの思索
「保守しやすいこと」が、良いプロセス~開発における、「設計」と「プロセス」の双対関係~:An Agile Way:ITmedia オルタナティブ・ブログ
【1】Conwayの法則は下記で紹介されている。
すなわち、ソフトウェアの構造はそれを作った組織を反映しているという法則。
パターン14:Conwayの法則
別名:
アーキテクチャは組織にしたがう
(中略)
解決策:
組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。
(中略)
論理的根拠:
このパターンは歴史的なものである。
Gerard Meszaros (BNR)は、人々はアーキテクチャが安定してから組織をアーキテクチャに合わせようとしたがる、といっている。もし、早すぎる時機に組織をアーキテクチャに合わせると、アーキテクチャの変化の流れは個々人の統制の範囲の間での干渉を引き起こす。
コンウェイの法則(Conway's Law) - Plan9日記
(引用開始)
要はソフトウェアの構造はそれを作った組織を反映しているという法則。3機関が協業した複雑なMulticsに対して少数精鋭の研究者がシンプルに作ったUNIX。巨大化する商用UNIXと、原点回帰したPlan9。Microsoftの発展と、MS-DOSからWindowsへの流れ。オープンソース革命とLinux。なるほど、いろいろ思いあたるところがある。
この法則、最初にどこで読んだのか忘れてたけど、Fred Brooks Jr.の「人月の神話」だったのか。
(引用終了)
【2】「Redmineのプロジェクトはどんな単位にすべきか?」という質問はよく出る。
僕は下記に書いたように、「開発チームの単位」「ブランチの単位」と考えていた。
だが、上記のTwitterで、Redmineプロジェクトは「製品単位」に作るべきではないか、という事実に気づいた。
「製品」とは、ビルドモジュールの単位だし、ITプロジェクトの最終的な成果物であり、SCMブランチ(trunk)でもある。
製品単位にRedmineプロジェクトを作った場合、メンバーはどのRedmineプロジェクトにアサインされて、タスクはどのRedmineプロジェクトへ配置されるのか?
解答は、メンバーのアサインやタスクの配置の観点は、まさにConwayの法則通りに従えばいい。
所属チーム単位ではなく、フィーチャ(サブシステム)単位に管理する。
メンバー主導ではなくアーキテクチャ主導。
つまり、Redmineプロジェクトは、SIの組織構造にマッピングするのではなく、製品のアーキテクチャにマッピングすればいい。
組織主導よりもアーキテクチャ主導の方が良いシステムが作れる。
Redmineプロジェクトはチーム単位よりも、派生された製品単位に作る。
メンバーは複数プロジェクトに所属して、要員の流動化を図る方がよい。
下記のBlogでも似たような発言がある。
なぜRedmine導入は失敗したか?あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド
(引用開始)
僕の所属していたプロジェクトはいわゆるソリューション開発というやつで、リリースするお客さんごとに
微妙にカスタマイズするのが常である。
SCMについてはメインラインモデルを利用した管理で十分だったが、ITS側でもカスタマイズごとに
プロジェクトを分けて管理した方が、視覚的にも整理されたのではないかと感じる。
TracでもTraMで複数プロジェクトが管理できるが、Redmineの「プロジェクトの親子関係」の方が
直感的で分り易く、やりたいことがすぐに実現できたのではないか。
事実、Redmineを導入したプロジェクトもソリューション開発であるが、早期からプロジェクトの親子関係を
使って顧客ごとにプロジェクトを分割したため、要件の整理に大変役立った。
(引用終了)
一つの製品(プロダクト)があり、その製品を複数の顧客へカスタマイズして開発している場合、例えば、親プロジェクトは共通の「製品」プロジェクト、子プロジェクトに顧客ごとにカスタマイズした時に発生するタスクの単位にすればいいだろう。
つまり、オリジナルの製品に対して派生された製品群は、Redmineのサブプロジェクトへ配置すればいい。
そして、メンバーは、複数プロジェクトにアサインされる。
すなわち、ソフトウェア組織は基本的にはPMBOKの言うマトリクス型組織になるだろう。
ラインとプロジェクトの2つの指揮命令系統がある組織構造にならざるを得ない。
縦割りの組織ならば、リーダー同士で調整しないと、メンバーは混乱する。
複雑な組織構造を作ると、アーキテクチャが組織構造に依存して、コミュニケーションの疎遠さがシステムをバラバラにしてしまう。
例えば、サブシステムと開発チームを密に関連付けてしまうと、チーム同士のインターフェイスがシステムのインターフェイスの溝になってしまうだろう。
大規模システムの開発案件ほど、それぞれの開発チームがタコツボのようになってしまい、チーム同士のコミュニケーションの疎遠さがそのまま開発のやりにくさに比例してしまうのは、そういう構造があるからだろう。
アジャイルな開発組織ならば、Scrumの言う自己組織化されたチームの集合体になっているだろうから、メンバーが複数のプロジェクトにアサインされていても、うまく調整出来るだろう。
Redmineプロジェクトの構造と組織構造、アーキテクチャが密接に関係するという事実、そして、特に製品ファミリー開発や派生開発でRedmineの複数プロジェクト機能が有効である事実は、ソフトウェアプロダクトラインの話を連想させる。
ソフトウェアプロダクトラインの話では、いつも組織構造の話が出てきて、何故そんな話が必要なのか、ピンとこなかったけれど、Conwayの法則の観点から考えれば、ごく自然な発想なのだろう。
この観点をもっと考えてみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Redmine」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「チケット駆動開発」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
「Agile」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
コメント