【メトリクス管理 連載目次】
- 1. メトリクスとは
- 2. 基本メトリクスセット
- 3. 進捗管理とメトリクス分析
- 4. 工数メトリクス
- 5. ソフトウェアメトリクス
- 6. プロジェクト管理ツール＆システムの成長モデル
- 7. プロジェクト管理ツール＆システム構築の戦略
- 8. Metrics for Project Management
- 9. メトリクスの実例
- 10. Products of Metrics for PM
1. 管理できる指標に加工する
基本メトリクスセットの工数メトリクスについて、その詳細を紹介したいと思います。
メトリクスで大切なのが、プロジェクトの関係者、とくに、管理する責任を持った人にわかりやすい形に加工するということでした。これについて例を使って考えてみたいと思います。
工数（時間）をデータとして収集したものは右図のような形になります。これは、ある製品開発プロジェクトのデータで、誰が、どのプロジェクトの、どのユニットの、どういう開発工程に、いつ、どれだけの工数（時間）をかけたのかというデータです。
これは、単なる「データ」です。プロジェクトの状況はわかりません。
これを、開発工程ごとに集計して、その時間の推移がわかるように加工するとどうでしょうか。しっかり見ると、プロジェクトの状況がわかるようになりました。たとえば、システム設計は早い時期の終わらせなくてはいけないのに、その後工程である基本設計よりも後でやっていることなどが読み取れます。さらに、これを次のようなグラフにすれば、状況を理解することは格段に簡単になります。
このように理解できる形になったものがメトリクスです。理解できる形になっていなければ進捗管理など、プロジェクトのコントロールに使うことは無理だということがわかります。もう一つ、大切なことがあります。
データではなくメトリクスにするためには、プロジェクトをどのようにしてコントロールするのかを明確にしておく必要があるということです。ここが明確になっていなければ、手間暇かけてやみくもにデータを収集し、そのデータの中でおぼれてしまって有効な情報を取り出せないということになってしまいます。プロジェクトに対してどのようなコントロールをするのか、そのためにはどんなメトリクスが必要なのか、そして、そのメトリクスのためにはどういうデータを収集しなければならないのかが決まります。
2. 工数メトリクスで振る舞いを把握する
では、工数メトリクスを使ったプロジェクト管理の例をいくつか紹介しましょう。
まず、先ほどの開発工程別工数（時間）のグラフについてもう少し解説します。製品開発の場合、うまくコントロールするために守らなければならない作業の流れ（工程）があります。理想的には、このグラフの凡例に示している工程を下から順々にやっていくのがいいのですが、開発現場ではいろいろなことが起こりますから、そう単純にはいきません。それでも、たとえば次のことを守るのは大切です。
- ルール1：最初に「構想」にじっくりと時間をかける
- ルール2：「システム設計」は「基本設計」の前に実施しておく
- ルール3：「単体テスト」は「システムテスト」の前に実施しておく
工数メトリクスを使うとこれらのルールが守られているかどうかを把握できます。実際、次のようにルールが守られていません。
- 「構想」を開発がはじまってしばらくしてから実施している
- 「システム設計」は開発が終わるまでずっとやっている
- 「単体テスト」は「システムテスト」と並行してやっている
先ほどのルールは守るべき最低限のレベルなので、ルール通りにできていないのは、プロジェクトがうまく管理できていないということになります。予期せぬトラブルや遅れにつながる可能性が非常に高くなります。後の祭りにならないように、プロジェクトの責任者は工数メトリクスを見ながら、早め早めに対策を打つことが大切です。グラフでは開発の最後までの工数（時間）を表示していますが、開発の途中でも先ほどのことは確認は可能ですよね。
では、同じプロジェクトですが、ユニット別工数（時間）推移を見てみましょう。
工数（時間）の合計値はもちろん同じです。ただ、凡例に示しているようにユニット別になっているところが先ほどのグラフとは違うところです。このプロジェクトは、ベースバンド（BB）、ネットワーク（Network）、プラットフォーム（Platform）、無線（RF）、ソフトウェア（SW）、機構（ME）、システム（System）という７つのユニットに分かれて開発を進めています。どんな製品なのか、それぞれのユニットはどういうものなのかを想像できる人もいるかと思いますが、そうでなくても気にしないでください。
このプロジェクトで進捗管理の上で大切なのは、次のことでした。
- 機構（ME）が新しい仕組みなので早期に実現性検証をやる
- 全体を担当しているシステム（System）チームは開発前半で作業を完了させる
グラフを見ると、機構（ME）は確かに、他のユニットよりも早く前倒しで工数（時間）が発生しているので、うまく作業が進んでいるようです。しかし、システム（System）は開発後半になっても工数（時間）が収束していません。遅くても 11月には工数（時...
間）が収束しない原因を明らかにして対策を打っておくべきだったといえるでしょう。
この2つの例から気がつくことはありませんか？ 気づいた人は「メトリクス管理の手法」をしっかり読んでいただいた方ですね。そうです、この2つはアクティビティとプロダクトの２軸管理の実例になっています。
アクティビティ軸というのは作業工程という視点で見ること、プロダクト軸というのは製品の構造のようにできあがるものの構造という視点で見ることでした。この2軸を使ってプロジェクトの進捗を見る（コントロールする）とプロジェクトの状態を把握しやすいことがわかっていただけたのではないでしょうか。
このように、工数メトリクスはプロジェクトのメンバーや、ユニットを担当しているチームが、どのような作業をやっているのか、その振る舞いを把握するための有力な手段です。ぜひ、工数メトリクスを使うことを検討してください。
次回は、ソフトウェアメトリクスの解説です。