工数メトリクスで進捗遅れの原因を知る（実践的メトリクス管理その3）

【必要最小限の手間で行う開発の見える化 連載目次】

• 1、必要最小限の手間で行う開発の見える化
• 2、工数メトリクスでわかるプロジェクトの振る舞い
• 3、工数メトリクスで進捗遅れの原因を知る
• 4、遅れのはじまりと今後の影響がわかるタスク・メトリクス
• 5、作業の進捗や品質がわかる作業成果物メトリクス
• 6、不具合メトリクスによる進捗管理や根本原因分析
• 7、基準モデルはどこにも必ずある成功パターン

1. 工数メトリクス

　前回のその2に続いて、解説します。基本メトリクスセットの中のひとつであり、メンバーがどのような振る舞いをしているのかを分析することでプロジェクトを可視化する工数メトリクスの事例の中で、今回は「リソースマップ」と「進捗ポートフォリオ」を紹介します。

2. リソースマップ

　リソースマップは、プロジェクトのチーム（ユニット）ごとに、誰がどのくらいの時間を投入することになっているかという予定に対して、実際はどうなのかを知るためのツールです。以下の図1で説明しましょう。このグラフは、入力ユニット、処理ユニット、画像処理ユニット、出力ユニットという4つのチームからなるプロジェクトのリソースマップで、チームごとの予定工数と現時点での実績を並べて表示しています。

 図1．リソースマップ

　各チーム（ユニット）の計画工数と実績工数とを比較すると、出力ユニットが計画通りの工数を最も投入できていないことがわかります。出力ユニットは開発が大幅に遅れているということです。 

　色分けで担当がわかりますから詳しく見てみると、予定では駒場さん（赤色）がメインで作業することになっているのに、実績工数を見るとほとんど工数を投入できていないことがわかります。つまり、駒場さんが出力ユニットの開発に参加できていないことが遅れの原因です。 

　さらに、駒場さん（赤色）に注目して全体を見てみると、画像処理エンジンの計画に入っていないにもかかわらず、実績工数の多くが駒場さんとなっていることがわかります。確認してみると、計画では画像処理エンジンはそのまま流用できるのでほとんど工数がかからないと考えていたのですが、実際にはかなりの修正が必要になり、駒場さんがその修正作業をやっていることがわかりました。画像処理エンジンも含めて計画を見直す必要があります。
　　 

3. 進捗ポートフォリオ

　次に紹介するのは、アーンドバリュー・マネジメント (EVM) を応用した、進捗ポートフォリオとよんでいるものです。計画価値（PV）にあたる計画工数、出来高（EV）にあたる進捗工数、そして、実コスト（AC）にあたる実績工数の3つの工数指標を使い、プロジェクトのチーム（ユニット）ごとに計画の遅延と実績の遅延とを分析します。 

図2．進捗ポートフォリオ

　図2の横軸は、計画工数と進捗工数を使って計画に対する作業の進捗度合いを示したスケジュール指標、縦軸は、計画工数と実績工数を使って計画に対する投入工数の進捗度合いを示したパフォーマンス指標となっています。それぞれ 100% を示す 1.00 と表示されているところがオンスケジュールで、数値が小さいほど大きく遅れていることを意味します。 

　○ や △ などでプロットしている点は、各ユニットを担当しているチームを表しており、どのチーム（ユニット）が遅れているのか、そして、その遅れの原因が計画にあるのか、それとも、工数を投入できない実施にあるのかを判断することができます。このグラフを使って説明したいと思います。 

　画像処理エンジンは、予定よりも作業が遅れており（スケジュール指標）、さらに工数も予定よりかかっている（パフォーマンス指標）ことがわかります。製品の中核となるユニットであり、プロジェクトとして大きなリスクになっています。計画を見直すと同時に、アサインが適切かどうか含めて担当メンバーも見直す必要があるでしょう。 

　処理ユニットは、計画よりも進捗しているのですが、計画以上に工数を投入しています。過度な残業になっているメンバーがいないかを確認する必要がありますが、大きな問題はないでしょう。

　入力ユニットと出力ユニットは、どちらも計画よりも工数をかけているにもかかわらず、作業（成果）は遅れています。メンバーの能力に見合った計画になっていないと考えられ、急いで計画を見直す必要があります。

　このように進捗ポートフォリオは、工数だけを使っていて EVM とは違うものの、進捗を簡単に把握することができる上に、計画に問題があるのか、メンバーの投入に問題があるのかまで判断することができます。