プロジェクト管理サーバーのメトリクスは教科書みたいだ

プロジェクトが一段落したから、メトリクスを出力してみた。
その時に気付いたことをメモ。

【元ネタ】
プログラマの思索: プロジェクト管理サーバーとは
プログラマの思索: アジャイル開発の弱点をプロジェクト管理サーバーが助ける

【各種ツール】
BitNami :: Trac
All In One TestLink JP
TestLinkCnvMacro
StatCVS - Repository Statistics
StatSVN - Repository Statistics

Tracから、カテゴリ、マイルストーン、解決方法、種類などの観点のチケット集計結果。

TestLinkにあるテスト実績からTestLinkCnvMacroを使って、テストケースの成功・失敗・ブロックの累積グラフ、曜日別・時間別・ピーク時間別のテスト実績、そしてテスター毎の生産性グラフ。

SVNリポジトリやCVSリポジトリから、StatSVNやStatCVSを使って、システム全体・サブシステム毎のLOCの累積グラフ、プログラマ毎の生産性グラフ。

これらのメトリクスは、上記ツールですぐに出力できる。
そのメトリクスを印刷して、メンバーにメトリクスの意味を説明したら、「まるで教科書みたい！」と言われた。

理由は、基本・応用・高度情報処理試験でSW工学や信頼度成長モデルの問題が出てくるが、実際の現場では今まで使ったことがなかったから、とのこと。

メンバーのその言葉を聞いて、SW工学の座学だけ知っていても、実際の現場で使えなければ無意味なんだな、と思った。
普通の現場にいるSEやPGは、基本・応用・高度情報処理試験の知識をどれだけ現場で使いこなせているのだろうか？
実際は、それらの知識は殆ど役立っていないのではないか？

普通の現場リーダーは、コストと納期に追われて、従来と変わらないKKDのプロジェクト管理しか知らない。
だから、現場で得られたメトリクスとSW工学の知識を組み合わせて、事実に基づいた意思決定を行うというマネジメントの基本スキルを普通の現場リーダーは知らない。

チケット駆動開発は、メトリクス出力を背後で自動集計する機構があるから、このメトリクスを正しく分析することで、効果的な意思決定を行うことができる。

更には、僕が考えるプロジェクト管理サーバーのインフラがあれば、プロジェクトマネージャにとって必要なマネジメント情報はいつでもすぐに得られるし、そこから良質の意思決定ができるようになるだろう。