プログラマの思索

日々の新規開発をRedmineのチケットで進捗管理して気づいた点があったのでまとめてみる。

【1】ロードマップを見ると、進捗率が逆に下がる場合がある

下記のロードマップになるようにチケットを登録したと仮定しよう。

◆ロードマップ1：5月1日現在

進捗：0％

#1　機能Aの開発（新規）
#2　機能Bの開発（新規）
#3　テスト（結合テスト）（新規）

すると、普通は、0％→33％→66％→100％　と進捗率が上がって終わるはず。

◆ロードマップ1：5月5日現在

進捗：100％

#1　機能Aの開発（終了）
#2　機能Bの開発（終了）
#3　テスト（結合テスト）（終了）

しかし、テストでバグが上がったり仕様変更が入った時、バグ報告をチケットに登録すると、下記のようになる。

◆ロードマップ1：5月6日現在

進捗：42％　←　終了3件/全7件だから。

#1　機能Aの開発(終了)
#2　機能Bの開発(終了)
#3　テスト（結合テスト）（終了）
#4　バグ1（新規）
#5　バグ2（新規）
#6　バグ3（新規）
#7　仕様変更1（新規）

つまり、進捗率は下がる！

最初にスケジュールを作った時に、バグがいくつ上がるか、とか、仕様変更がいくつ入るとか、予測することはすごく難しい。
実際に作ってみないと分からないのが普通だ。

しかも、バグを修正するたびにモグラ叩きのようにどんどんバグが発生する時もある。
特に、PGの出来が悪い時やあいまいな仕様の場合。

普通は契約上、納期は厳守なので、リリース間際の短い残り期間に残業して休日出勤して、最終的には徹夜してでも全てのバグを修正しなければならない。

だから、プロジェクトリーダーはあらかじめ納期までにバッファを入れて、バグ修正の時間を確保しておく。
でも、このバッファはすぐに浪費して足りなくなるのが普通。

進捗率は増加するだけでなく、減少する時もある現象は、プロジェクトリーダーの感覚ではすごくフィットする。
進捗率が減少する時は、各人のタスクが溢れそうで、納期までに間に合うか、ピリピリしている時だ。
バグ報告がどんどん増えている時、いくら時間があっても、バグ修正が永遠に終わらない感覚になるのが普通だろう。

進捗率が落ちた時は、デスマーチに入るか入らないかの瀬戸際。

ここで、プロジェクトリーダーが取る手段は、下記４つしかない。

1.品質を落とす
2.人を増やす
3.納期を延ばす
4.機能を削る

あなたなら、どれを選ぶか？

【2】プロジェクトリーダーが調整できる作業は、チケットのトリアージしかない

駄目なプロジェクトリーダーは、品質を落としたまま納品して、更に状況を悪化させる。
下手をすれば、契約違反、あるいは昨今なら社会問題にまで発展する。

政治力のあるプロジェクトリーダーは、顧客や上司と調整して、納期を延ばして、人を投入する。
だが、人を増やせば、コミュニケーションロスが発生したりして、逆に開発チームは混乱する時が多い。
たとえ納期を延ばしたとしても、残業や徹夜続きの毎日が更に長引くだけで、開発者も疲労する。

アジャイル開発やXPでは、スコープ管理と称して、機能(スコープ)を調整することでバランスを取ろうとする。

つまり、お客様が業務で使う90％の業務フローの機能とその品質は死守する。
そして、すごく稀な業務フローから生じるバグ、ある機能だけに生じる性能ダウンのバグ、Firefoxでしか再現できない環境依存のバグなど、主要な業務を使う時に無視できるバグ、あるいは別の代替手段がある仕様変更は、間をおいて納品するように後回しにするやり方。

下記の例になるだろう。

◆ロードマップ1：5月8日現在

進捗：100％

#1　機能Aの開発(終了)
#2　機能Bの開発(終了)
#3　テスト（結合テスト）（終了）
#4　バグ1（終了）
#5　バグ2（終了）
#6　バグ3（終了）

◆ロードマップ2：5月8日現在

進捗：10％

#7　仕様変更1（担当）

MIXIやGoogleが編み出すWebアプリは、「永遠のベータ版」と言われる。
この手法は、頻繁な間隔でリリースする手法を使うことによって、たくさんのバグ報告や仕様変更を「どのタイミングでリリースするか」という問題に置き換える。

この手法では、トリアージという概念を理解しきっていることが大事だ。
機能やバグ報告に優先順位とリリース日をアサインして管理することだ。

つまり、チケットの優先順位を付けて、チケットを取捨選択すること。
捨てるべきチケットもある。
限られた時間、限られたメンバーという制約がある限り、全てのチケットを実現するのは難しいから。

プロジェクトリーダーは、チケットの優先順位付けとチケットの対策立案が本来の仕事であるべきだ。

RedmineのようなBTSでチケット管理すると、プロジェクトリーダーはガントチャートを作るのが彼の作業ではなく、ロードマップ等の色んな集計結果から、実現すべきチケットと後回しにするチケットへ取捨選択するのが彼の仕事であることが良く分かる。

【3】CCPM(クリティカルチェーン・プロジェクトマネジメント)が提唱する工数見積からバッファを分散せず集中させる利点

上記のリスクがある限り、プロジェクトリーダーは、工数見積で2倍以上のバッファを入れたりする。
しかし、そのバッファを各タスクに分散させると、開発者も人間なので、学生症候群ですぐにバッファを使いきってしまう。

CCPMでは、TOCの発想を使って、クリティカルパス上のタスクが必ずボトルネックにならないようにバッファを入れるタイミングに注意する。
つまり、二つのタスクが合流するときは、合流バッファを入れて調整できるようにする。
他のタスクは、バッファを入れず、ギリギリの工数に設定し、一番最後に置かれたバッファで調整できるようにする。

チケット駆動開発でも、この発想は使える。
新規開発している場合は、開発担当のチケットはバッファを入れない。
テストでバッファを入れる。

結合テストや運用保守では、優先順位の高いチケットがクリティカルチェーンにある。
これらのチケットの依存関係から、バッファを入れるチケットを指定する。

Redmineのチケット管理は、チケットの状態をロードマップ・ガントチャート・レポートなど複数の観点から見れるので、プロジェクトのどこに問題があるのか分かりやすい。

プロジェクトリーダーの本来の仕事は、リスク管理であるべきだ。

チケット管理こそがBTSの肝。