見かけ上の進捗

【1】進捗報告のスタイルは色々あるだろうが、最も簡単な進捗報告は、完了ステータスと未完了ステータスの数値を先週・今週・来週で集計すること。

普通は、機能とステータスのクロス集計で、先週・今週・来週の数値を表示しているだろう。
この場合、「未着手→作成中→テスト中→レビュー中→完了」のワークフローにあるステータス毎に集計する。

前者と後者の違いは、実質の進捗と見かけ上の進捗の違い。
前者は、完了ステータスの数値＝実質の進捗。
後者は、未完了ステータスが「作成中」「作成中」「テスト中」「レビュー中」の4種類に更に分けて、見かけ上の進捗を集計している。

何故、後者のような見かけ上の進捗が必要なのか？
理由は、実質の進捗が芳しくない場合、開発チームが今どのような状態であるのか、を追跡したいからだ。

すると、部長クラスの人は、見かけ上の進捗の報告書を見て、ステータスごとの数値の差から、今チームがどんな状況なのか、を探るのが非常に巧みだ。
いわゆる計数管理が部長クラスの人は得意。

よくある例は、数少ないレビュー担当者とレビュースケジュールを調整できず、機能を実装してテストまで進むが、レビュー中で滞留してしまっている時がある。
この場合のボトルネックは、レビューの停滞だから、部長クラスの人は、レビュースケジュールを調整する対策を採ろうとする。

【2】Redmineのロードマップ画面では、バージョン毎の進捗バーが緑色と黄緑色の2色で表示される。
これは、緑色は実質の進捗、黄緑色は見かけ上の進捗を表す。

つまり、緑色は、ステータス＝終了のチケット累積数から実質の進捗を計算している。
逆に、黄緑色は、全チケットの進捗率から見かけ上の進捗を計算している。

だから、Redmineのロードマップを見れば、緑色が短く黄緑色が長ければ、完了間近の仕掛かり中の作業が多いのだろうと推測できる。

Tracのロードマップでは、実質の進捗しか表示しないため、開発チームの本当の進捗が分かりにくい弱点があると思う。

【3】同様にテスト工程でも、テストケース数が数千～数万以上の桁になるほど、実質の進捗と見かけ上の進捗による管理が重要になってくる。

TestLinkのテスト結果画面で「全ビルドステータス」画面では、「成功」「失敗」「ブロック」「未実行」のステータスごとにテストケースの進捗率を表示する。

テスト工程では、実質の進捗は、「成功」ステータスのテストケース数になる。
但し、「成功」テストケースは、1回目のテストで成功した場合だけでなく、1回以上失敗してバグ修正した後に成功になった場合も含まれる。

では、テスト工程の見かけ上の進捗とは何か？

テストの場合、テストケースの失敗が頻発した場合、いくらテストケースをこなしても、実質の進捗は進まない。
だから、テスト工程の進捗の本当の状態を知るには、「実施済み」のテストケース数を集計することが重要になる。

「全般的なテスト計画のメトリクス 」画面にある「完了率」は、実施済みのテストケース数の割合を表示していて、これが見かけ上のテスト進捗になる。
だから、実施済みのテストケース数が多くても、成功率が低ければ、バグが多いと予測できる。

【4】チケット駆動開発やTestLinkの利点は、見かけ上の進捗や実質の進捗を自動集計する機能があることだ。
RedmineやTestLinkでチケット管理やテスト管理の運用を徹底できれば、見かけ上の進捗や実質の進捗をリアルタイムにモニタリングできる。

進捗報告やテスト結果の数値から開発チームの状況や傾向を読み取る能力は、特に経営者に近い管理者は非常に得意だ。
チケット駆動開発やTestLinkの運用は、下流工程の構成管理だけでなく、プロジェクト管理全般の生産性向上にも非常に役立つはずだ。