プログラマの思索

WBSの作り方は組織構造に依存するという記事がとても参考になったのでメモ。

【参考】
ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

ＷＢＳはコスト見積の基準を規定する : タイム・コンサルタントの日誌から

【1】ガントチャート初心者からよく聞かれる質問は、「WBSは工程単位に作った方がいいですか？それとも機能単位に作った方がいいですか？」だ。

話を聞くと、工程単位にチケットを作ってみると、実際の開発フローに合っていない感触があり、途中で、機能単位にチケットを作り直す時が多いらしい。
WBSの作成方法は、工程単位と機能単位のどちらが正しいのだろうか？

(引用開始)
さて、３つの機能モジュール×３段階の作業プロセスだから、合計９個のアクティビティからなるプロジェクトである。
これをＷＢＳに構成するとき、二種類の表現が考えられる（ＩＴ系の仕事になじみのない人は、「システム設計」「プログラミング」「テスト」をそれぞれ、「コンセプト開発」「製品設計」「量産準備」だとか、「機械設計」「資材調達」「製造」とか、自分に理解しやすい業務におきかえてみてほしい）。

ＷＢＳ・案１
1　モジュールＡ
1.1　モジュールＡを設計する
1.2　モジュールＡをプログラミングする
1.3　モジュールＡをテストする
2　モジュールＢ
2.1　モジュールＢを設計する
2.2　モジュールＢをプログラミングする
2.3　モジュールＢをテストする
3　モジュールＣ
3.1　モジュールＣを設計する
3.2　モジュールＣをプログラミングする
3.3　モジュールＣをテストする

ＷＢＳ・案２
1　設計
1.1　モジュールＡを設計する
1.2　モジュールＢを設計する
1.3　モジュールＣを設計する
2　プログラミング
2.1　モジュールＡをプログラミングする
2.2　モジュールＢをプログラミングする
2.3　モジュールＣをプログラミングする
3　テスト
3.1　モジュールＡをテストする
3.2　モジュールＢをテストする
3.3　モジュールＣをテストする

さて、上記二つの案のうち、どちらをとるべきだろうか？　あるいは、両者は互換的(convertible)で、内容的に差はない、と考えるべきだろうか。
(中略)
ところが、両者は実務的には大違いなのだ。プロジェクトの生みだす成果物の品質や納期だって、大きな差が出るだろう。なぜだろうか？
(引用終了)

僕は今まで、案件の状況に合わせて切り替えたら、と答えていたが、上記の記事では、この質問の本質をズバリ言い当てていた。

(引用開始)
そして、プロマネであるあなたは、自分のプロジェクトをどのようにマネージしたいかによって、どちらのＷＢＳをとるか判断するべきなのである。
たとえば、モジュール間の関連性が強くて、全体が密結合のシステムを作る場合は、プロセス中心型で進めたいだろう。
逆に、たとえばすでにあるシステムに、新規機能をいくつか追加していくようなプロジェクトならば、モジュールができた順にリリースしたいから、成果物中心型を選ぶだろう。
もしもこれが逆だったら、いかに仕事がやりにくいか、想像に難くない。
(引用終了)

【2】すなわち、工程単位・機能単位のWBSをPERT図に書いてみると、PERT図の構造は全く違う。

工程単位なら、工程ごとに合流して派生するから、工程に属する全てのタスクは全て同じ終了日までに確実に終わらなければならない。
つまり、工程内部では並行開発になるので、それぞれのタスクの同期が非常に重要になる。

普通は、SEチームが設計、開発チームが開発・単体テスト、SEと開発者の両チームが結合・総合・受入テストを行うようなチーム編成になるだろう。
すると、各工程ごとに開発要員の変動が大きく起きるので、チームを去っていく作業者の引き継ぎ作業が重要になってくる。

また、工程内でクリティカルパス上のタスクが一つでも遅れると、開発案件の全体の納期がすぐに遅延してしまう。
だから、残業や休日出勤で、その遅延をリカバリーせざるを得なくなる。

一方、機能単位なら、最初と最後だけ派生・合流し、途中の進捗は各機能でばらばらになる。
実際のチーム構造は、機能単位のチームになるので、チームは自分たちだけの機能の進捗を管理すればいい。
但し、他のチームと同期が取りにくいので、CCBやスクラムオブスクラムのようなリーダー会議を設けるなどして、機能間のI/Fや共通ライブラリの開発を調整したり、共同作業する場をもうける必要があるだろう。

つまり、WBSの構造は、チーム内のメンバーの役割と開発体制に影響させるし、その影響から離れられないのだ。

【3】上記の話をRedmineに当てはめてみるとどうなるのか？

工程単位にチケット管理したい場合も、機能単位にチケット管理したい場合も、チケットに書く作業は同じ。
チケットの先行・後続の関係を付ける場合、工程単位と機能単位ではPERT図の構造が異なるので、その内容が反映されるだろう。

また、工程や機能という概念をチケットのどの属性に当てはめるか、という運用も重要だろう。
たぶん2つある。
一つは、対象バージョン、もう一つは、親子チケット。

工程をバージョンに紐付けるのは直観的で分かりやすい。
工程の終了日までに、工程内のタスクを全て終わらせないといけないから、その制約条件と対象バージョンの意味合いは合致しやすい。
しかし、レビュー漏れ、仕様変更などで手戻り作業が何度も発生すると、設計工程がリオープンされてしまい、いつまで経っても設計工程が終了できない、という状況はよくある。
工程単位のWBSはとてもきれいな構造であるが、変化の激しい開発には合わないと思う。

そのせいか、MSProjectに慣れた人ほど、親子チケットでWBSを表現しようとする人が多い。
Redmineの最新バージョンでは、WBS100％ルールの設定ON/OFFができるようになったので、故意に子チケットを親チケットへロールアップする設定を外すこともできるので、柔軟な運用は可能になった。
親子チケットで階層化すれば、ガントチャート画面の見栄えは良くなる。
但し、チケットの階層が深くなるほど、メンバー全員で運用するのは難しくなるのでトレードオフになる。

一方、機能を対象バージョンに割り当てる方法は、FDDの言うパーキングロットチャートの機能と同じだ。
過去に@daipresentsさんが試されている。
機能の粒度が小さければ、パーキングロットチャートで表現すると分かりやすい利点はあるだろう。

Redmineプラグイン開発 ? パーキングロットチャートプラグインリリース

Redmineにプラグインを入れる - ソフトウェアエンジニアリング - Torutk

同様に、機能ごとに親子チケットでWBSを表現することも可能だ。
この場合、WBS100％ルールを使って、親チケットは子チケットの進捗情報をロールアップするように設定した方が進捗が分かりやすくなる。

但し、複数の機能に関する障害とか、仕様変更が発生した場合の作業は、チケットでどのように表現すべきか？という課題は残る。
実際は、それぞれの障害や仕様変更の単位でチケットをその都度作成する運用になるから、機能単位にWBSを作るのも、そんなに綺麗なやり方にはならないだろう。

個人的には、作業ごとにチケットを起票し、リリース日ごとにチケットをグループ化して小刻みにリリースしていくアジャイルな開発スタイルがチケット管理に最も向いていると思う。
WBSを綺麗にチケットに表現して管理していこうとすると、予期しないトラブルや仕様変更に耐え切れない。

【4】「機能単位・工程単位のWBSがプロジェクトの組織構造を規定する」法則をRedmineチケット管理に当てはめると、どちらでも運用できるし、WF型でもアジャイル型でも運用できる柔軟性はある。

つまり、WBSが組織構造を決めるという流れではなく、自分たちの開発体制にRedmineを合わせるという流れに持ち込みやすい。
換言すれば、Redmineは運用を非常にカスタマイズしやすいことを示唆していると思う。

Redmineの機能と組織構造、開発体制の依存関係については、他の観点でも色々考えてみる。