【メトリクス管理 連載目次】
- 1. メトリクスとは
- 2. 基本メトリクスセット
- 3. 進捗管理とメトリクス分析
- 4. 工数メトリクス
- 5. ソフトウェアメトリクス
- 6. プロジェクト管理ツール＆システムの成長モデル
- 7. プロジェクト管理ツール＆システム構築の戦略
- 8. Metrics for Project Management
- 9. メトリクスの実例
- 10. Products of Metrics for PM
1. プロジェクト管理の仕組みに必要な2つの基本思想
このようなムダやムリになるとわかっているその場限りの対応が真の問題だととらえて、それを極力なくすための思想を仕組みに組み入れることが必要です。そのための基本思想は次の2つです。
- 現場に合ったミニマル運用
- プロジェクト管理の資産化
プロジェクト管理の資産化とは、やってことがムダにならないということです。一つひとつのプロジェクトでやったことが活用できる形で記録され、そのプロジェクト記録はプロジェクトが終わるたびに積み上がっていく。一つひとつが活用できる形になっているため、積み上がれば積み上がるほど、その利用価値は高くなっていく。このようにしてプロジェクトをやった結果が資産となっていきます。
そして、現場に合ったミニマル運用とは、やることにムダがないということです。たとえば、MS Project は多機能でいろいろな要求に答えることができますが、現場により暗黙的な決まりごとは数多くあり、その暗黙的な決まりごとに対応することで、必要最小限のシンプルな運用にすることが大切です。
それぞれについて、もう少し詳しく取り上げたいと思います。
2. 現場に合ったミニマル運用
暗黙的な決まりごとの1つに納期最優先というものがあります。日本でのほとんどのプロジェクトは完了日、または、リリース日は動かすことができません。結果的に延期になることはあっても、計画の段階でプロジェクトの終了日が変更されることは稀です。
納期厳守が暗黙的な決まりごとだと、MS Project の単位数固定におけるシミュレーション機能はほとんど意味がありません。進捗によってプロジェクト終了日が変わるのは（遅れるのは）迷惑なだけです。
また、計画は「できないことはわかっている」という状態からはじめるのが普通で、誰をプロジェクトに参加させればできるようになるのか、何人追加すればできるのかなどを問われます。つまり、スケジューリングとはメンバーやメンバーの負荷を分析することであり、調整することです。メンバーの負荷分析が重要だということです。
もうひとつ、ミニマル運用で考えておく必要があるポイントを紹介しておきたいと思います。進捗管理にはさまざまな視点の必要性です。多様な視点が複眼思考や多面的思考を促し、プロジェクトの状態をより正確に把握することにつながります。
上図のような、ある組織を考えたときでも、組織の中にはいくつかのプロジェクトが存在すると同時に、これとは別に電子制御部、機構部、ソフト部などのように機能グループ（部）が存在します。プロジェクトはさらに電源ブロック、制御ブロックなどのようにブロックに分かれ、ブロックごとに個人がアサインされます。機能グループ（部）はさらにチーム（課）に分かれ、チームごとに個人がアサインされます。たとえば、ソフト部の下が設計1課、設計2課、設計3課に分かれていて、それぞれに技術者が配属されます。
進捗はこの構造のどこにおいても見たいという要望が出てきます。プロジェクトごと、ブロックごと、グループ（部）ごと、個人ごとのどの単位でも進捗を見たいのです。
3. メトリクスによるプロジェクト管理の資産化
個人的に見積もりをしたりスケジュールを書いたりするだけでは、どんなに MS Project などのツールを使ったとしても、そのノウハウを他の人たちへと水平展開するのは難しいものです。実際、他人が作ったプロジェクトのガントチャートを見ても、どこをどう活用できるかはわかりません。参考にはなるところはあるかもしれませんが、その場合でも、見る側の個人的なスキルやセンスで決まります。
このような状況を越えて、プロジェクトの結果を次々と蓄積でき、蓄積したものがいつでも使える状態になる、それが資産化です。資産化の仕組みができていれば、あるプロジェクトでやったことを他のプロジェクトに水平展開することができます。過去の経験を流用することも可能です。
この資産化の仕組みを支えるのがメトリクス。メトリクスとは、数値化して定量的な管理を可能にすることです。資産化の仕組みを作るために、メトリクスを使った、可視化、パターン化、モデル化という3つのステップ（手法）が必要となります。以下、それぞれのステップについて説明したいと思います。
4. 可視化（見える化）
プロジェクトで計画している作業や進捗度合いなどを適切に把握し、関係者で共有するためには、プロジェクトの活動そのものを可視化（見える化）することが最も効果的です。「自分のことは自分でわかっているから可視化は必要ない」という主張を聞くことがありますが、重要なのは、関係者全員がプロジェクトの状況に対して共通認識を持つことです。そのための手段が可視化なのです。
MS Project で見ることができるガントチャートなども可視化のひとつですが、それだけでは不十分です。プロジェクト活動を包括的に把握するためには、少なくとも基本メトリクスセットとよぶ4つの要素を可視化する必要です。これが、プロジェクトを可視化するための必要最小限のメトリクスです。
可視化は、標準の MS Project では弱い部分ですが、出力を工夫することにより、基本メトリクスセットの工数（時間）と作業（作業要素）を可視化することが可能です（詳細は後述）。作業成果物と不具合・課題については MS Project とは別の仕組みが必要になります。基本的に、作業成果物は成果物管理の仕組み、不具合・課題は不具合管理や課題管理の仕組みと関連づけて可視化します。
5. パターン化
上図の左のグラフは、時間軸で見て、開発工程ごとにプロジェクトがどのような工数（時間）のかけ方をしたのかをグラフ化したものです。プロジェクトの開発工程ごとの工数（時間）パターンということができます。その右のグラフは、別のプロジェクトの工数（時間）パターンです。これを見ると、この2つのプロジェクトはかかった工数（時間）と期間はほぼ同じですが、工数（時間）のかけ方はまったく別だということがわかります。
このように、パターン化とは相違点や類似点を明らかにするための「型（パターン）」を作るということです。次に、それぞれのパターンに成功と失敗というプロジェクトの結果を関連づけます。このグラフでは、左側はほぼ計画通りにリリースして、リリースした後も品質問題などが起きなかったプロジェクトです。右側のプロジェクトは日程も工数（時間）も計画を超過しただけでなく、リリース後も品質問題に悩まされたプロジェクトです。つまり、左は成功したプロジェクトで、右は失敗プロジェクトということです。
このように、結果とリンクしたパターン化ができれば、進行中のプロジェクトを同じ工数（時間）パターンであらわしたとき、左のパターンと同じであれば成功する可能性が高いということになりますし、右のパターンと同じであれ...
