メトリクスの威力

チケット駆動開発を上層部へアピールするのに最も効果的なことは、現場の数字を提示することだ。

社長や取締役、管理職は、数字が非常に好きな人達。
彼らは、いつも売上の数字とにらめっこしている。
彼らは月次売上のために、請け負ったプロジェクトの進捗や品質をすごく気にしている。

チケット駆動開発を実践すると、チケットに日々の作業状態がリアルタイムに入力されるため、進捗をリアルタイムに見ることができる。

RedmineやTracでは、生成されたガントチャートから、赤色のタスクが遅延しているのが分かる。
カレンダーを見ると、月別のタスクの一覧が表示され、取消線のないタスクは作業中であることが分かる。
ロードマップから、バージョン単位の進捗が出るので、マイルストーンまでの残日数と比較して間に合うのかどうか考えることができる。
チケット集計結果であるサマリから、バージョンやコンポーネント単位の残チケット数が即座に分かる。
Redmineのレポート機能から、バージョンと月別の工数のクロス集計が表示されるため、月別でどれだけのコストがかかったのか、即座に把握できる。

RedmineやTracは、プロジェクトの進捗のメトリクスを色んな観点で出力してくれる。

更に、TestLinkを使えば、全テストケース数、ケース消化率、NGテストケース数、要件カバレッジなど、テスト工程の進捗を表すメトリクスを出力してくれる。

statSVNは、曜日別の開発者毎のコミット回数、システムのLOCグラフなど、開発者の貢献度合い、システムの規模を表すメトリクスを出力してくれる。

以上のメトリクスを定期的に上層部へ見せれば、現場の状態をリアルタイムに完全把握できる資料として非常に喜ぶだろう。

しかし、メトリクスは現場リーダーや開発者にとって諸刃の剣。
プロジェクトの進捗が良ければ上層部へアピールできるが、遅れていれば何故問題を放置しているのか、と問い詰められるだろう。

だから、ずる賢い人達は、これらのメトリクスを操作して、遅延しているのにあたかもプロジェクトがスムーズに進んでいるかのように、品質が確保されているかのように改ざんするだろう。

そうなると、メトリクスはもはや現場の状態を素直に反映したものでなくなる。
これが「メトリクスを過信しない」という意味の一つ。

チケット駆動開発でソフトウェア開発の諸問題が全て解決されるのではない。
チケット駆動開発は、現場の問題を強力に見える化するだけ。
溢れたタスクをRedmineが解決するわけではない。

結局、現場リーダーや開発者の技術力、マネジメント力という問題解決能力のレベルが試されるだけなのだ。