9．基準モデル
基準モデルについては、開発工程別の工数比率が製品カテゴリーによって共通のパターンになることを解説しました。共通パターンを抽出できれば、見積もりの際に参照でき、経験と勘による属人的な見積もりの仕組みを組織的なものへと変えられます。
個々のプロジェクトには、メンバーの経験年数やスキルなど固有の事情、特徴がありますが、マクロ的に見れば、開発グループのスキルや開発スタイルなどは大きく変わりません。現実の開発現場では、開発する製品も開発者も短期間に大幅に変わることはないからです。従って、基準モデルを作るには、組織の中で成功したプロジェクトを選別し、そのデータを分析して共通パターンを見つければよいのです。
成功したプロジェクトのパターンを作ることで、その組織における成功パターンを定量化したことになります。個々のプロジェクトはそれを参考に計画を作成して、また、それを基準にプロジェクト進ちょくを比較すればプロジェクトの悪さも分かりやすいのです。
図4.基準モデルの活用例
図4は不具合について、検査などで発見した日から修正される日までの期間を調べ、その期間ごとの不具合件数分布を表したものです。開発工程を適切に管理できているプロジェクトでは、基準モデルに示す分布となります。この基準モデルとの差異を生じている部分についてその原因を推測することが可能であり、プロジェクトの進め方にフィードバックできます。
図5.開発工数と不具合件数
図5は開発工数に対する不具合件数です。これは複数の組織でのプロジェクトをまとめてプロットしたものですが、これから、開発工数と不具合件数とは正の相関があることが分かります。楕円で囲んでいる部分は同一組織におけるプロジェクトです。開発工数を見積もることで、不具合時間を見積もることができるのが分かります。
10．予実差管理
進ちょく管理の基本は予定と実績との乖離を見ることで、予実差管理をすることです。これまでに述べたメトリクスを、予定と実績の乖離が分かるようにして可視化するということです。
図6.進ちょく率の比較
図6は基本メトリクスセットの一つひとつに対して予実差をグラフ化したものです。一つのメトリクスだけを見るよりも、プロジェクトの振る舞いがより把握できます。プロジェクトに対する複眼的な視点が持てます。
次回のその7から、スコープを少し広げて、メンバー管理など進ちょく管理以外でのメトリクスの活用につい...
