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の法則の観点から考えれば、ごく自然な発想なのだろう。
この観点をもっと考えてみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント