Metrics for PM of メトリクス管理


Metrics for Project Management

Metrics for Project Management の思想

前述(システム構築の戦略LinkIcon)のプロジェクト管理システムの基本戦略であるミニマル運用と資産化をシステムとして実現したものが、Metrics for Project Management(以下、Metrics for PM)である。Metrics という単語が入っていることからもわかるように、メトリクスを徹底的に活用している。

中小規模MSP運用の課題.pngシステム構築の戦略LinkIconで述べたように、レベル3の Project エンタープライズ導入は費用や手間の観点から負担が大き過ぎるが、レベル2のスタンダード導入では組織レベルでの管理が難しいため拡張性や柔軟性に欠けるという問題がある。レベル2とレベル3の間の差は大きく、とくに中規模、小規模の組織では適切なシステム環境を構築しづらい原因になっている。実際、中小規模の組織では Project の導入・運用に関して右図に示すような問題を抱えているところが多い。

このようなことから、スタンダードの導入であっても、複数プロジェクトの管理やリソース管理を組織レベルで可能とする レベル2.5 とよべるシステム環境として機能するシステム環境が Metrics for PM である。

中小規模MSP運用の課題.pngMetrics for PM を利用することにより、Microsoft Project(以下、MS Project)で作成し進捗を記録したファイル(プロジェクトファイル)を、メトリクスが活用できるフォーマットに変換し、さらにクラウドのデータベースに登録することにより、複数プロジェクトの進捗管理やプロジェクトを横断したリソース管理などが可能となる。つまり、MS Project スタンダードであっても組織全体でプロジェクト横断的な進捗管理を可能にし、メトリクスによる蓄積や分析を標準機能として提供する。

まとめると、Metrics for PM は左図に示すような特徴を持つ。Metrics for PM のデータベース機能や各種の分析機能はクラウドサービスとして提供するため、プロジェクトの増減、規模のバラツキ、利用者の変化などに柔軟に対応することが可能である。1人1ヶ月単位で利用契約を結ぶことができる。さらに、MS Project そのものもクラウドサービスを利用することで、運用環境の変化に容易に対応することが可能である。

Metrics for PM の全体像

システム全体像.jpgMSP のアドイン (Metrics Add-in) を使って、MSP ファイルからメトリクスによる見える化、パターン化、モデル化ができるフォーマットにした分析用データを出力する。資産化できるデータ・フォーマットに変換するわけである。この分析用データを Excel などに取り込むことでも、見える化、パターン化、モデル化という一連の作業を行うことも可能である。

ただ、資産として蓄積して過去から現在まで、組織レベルの複数プロジェクトで見たり、分析したりするには、この分析用データをデータベースに蓄積していく必要がある。

これを Metrics for PM ではクラウドサービスとして提供している (Cloud-Based Metrics PM) 。
データベースに蓄積されたデータは、各種ブラウザ上で様々な進捗分析レポートやリソース分析レポートとして見ることができる。当然、過去プロジェクトを見ることや、現在走っている複数プロジェクトを比較すること、特定プロジェクトの中を詳しく見ることなど、様々な視点での分析結果を見ることができる。

Metrics for PM での進捗管理やリソース管理は、次のような手順の繰り返しとなる。

  1. MSP で計画を作成し、進捗の入力・更新を行う
  2. 進捗を更新した後、Metrics Add-in を使って分析用データを作成する
  3. 出力した分析用データを Cloud-Based Metrics PM にアップロードする
  4. ウェブブラウザを使って進捗やリソースの分析を行う

なお、Metrics Add-in から出力される分析用データは、Excel のピボットを使って様々な表やグラフにすることも可能である。この場合、クラウドサービスを利用せずに進捗やリソースを分析することができる。

メトリクスの実例

それでは、実際の開発現場で使われたメトリクスの実例を紹介したい。グラフなどはすべて Cloud-Based Metrics PM を使ってウェブブラウザで表示させたものである。一部、Metrics Add-in の出力を使って Excel で表示させたものもある。

工数推移

工数推移.png時間軸で見た工数の予定(青色)と実績(赤色)のグラフ。プロジェクト全体や、プロジェクト中のブロックなど、必要なスコープ(範囲)で表示させることができる。単純に計画と実績の乖離を確認することができる。実績は進捗率を工数(時間)に変換したものである。

タスク推移

タスク推移.png時間軸でみたタスク数の推移グラフ。タスク数とは時間の分解能(日,週,月)に合わせて、その分解能であらわした期間のタスクをカウントしたものである。作業の負荷を知ることができる。プロジェクト全体や、プロジェクト中のブロックなど、必要なスコープ(範囲)で表示が可能。
また、色分けは「タスクの状態」を使った「遅れている」「完了」「今後のタスク」などの分類である。タスク数で見たときの遅れ度合いや、遅れているタスクがいつからはじまっているのか、その遅れはいつまで影響するのか、などを知ることができる。

工数一覧・タスク一覧

工数一覧.png
組織全体やある特定の部署で存在している複数のプロジェクトについて、タスク数や工数を表示したグラフ。色分けは前述のグラフと同じで、工数の場合は「計画」(図では作業時間)と「実績」(図では実績作業時間)。タスクの場合は「遅れている」「完了」「今後のタスク」といった進捗状況の分類である。タスク数や工数を比較・一覧できるほか、その進捗状況を比較・一覧することができる。
タスク一覧.png進捗率などの遅れている割合(比率)の把握も重要だが、規模が大きいほど進捗の影響が大きくなるので、作業量と遅れている割合の両方を一覧できることは効果的である。

進捗履歴

進捗履歴.png過去どのようにプロジェクトの進捗率が推移してきたかを表示したもの。過去その時々の工数やタスク数で見たときの進捗率の履歴である。遅れが拡大傾向にあるのか収束傾向にあるのかわかる。
下図では2つのプロジェクトについて、 約1ヶ月ごとに、そのときの上段は遅延時間(日)、下段は遅延タスクの割合(%)を表示している。遅延時間は、その時点で計画(作業時間)に較べて実績(実績作業時間)がどれだけ遅れているか、遅延タスク割合は、その時点のタスク数に対して「遅れている」タスクがどのくらいの割合なのかを示している。

リソースマップ

リソースマップ.pngプロジェクトのブロックごとに計画と実績の工数を表示し、それぞれを担当しているメンバーで分類したグラフ。メンバーがどのブロックの作業にどのくらいの時間を投入する予定になっており、実際にどのくらいの時間を投入したのかを一覧することができる。

プロジェクト横断のメンバー負荷分析

メンバー負荷分析.jpg組織が、電子制御,機構,ソフトなどの技術要素で別れており、プロジェクト・メンバーがそれらの組織からの横断的なメンバーで成り立つような場合、実質、組織のマネジャーがプロジェクトへのメンバーアサインやメンバーの進捗や負荷の管理を任されているケースが多い。
この場合、組織のマネジャーにとって、自分の組織に所属しているメンバーの工数管理は非常に重要になるが、今後の詳細な予定工数を知りたい場合は、メンバーが関係しているプロジェクトそれぞれの詳細な計画を入手して、メンバーが関係している部分だけを抜き出して足し合わせるという手間のかかる作業となる。Metrics for PM を使えば、プロジェクトごとのデータを結合して分析することが可能である。
図の左側のグラフは、ある部署に所属しているメンバーの毎月の計画工数であり、右側のグラフは、あるメンバーについて毎月の計画工数で担当するプロジェクトごとに色分けしたものである。このグラフにより、プロジェクトの兼任状況や、移行状況などを確認することができる。

工数を使ったアーンドバリュー・マネジメント

EVMS.jpgMetrics for PM では、個別にインタフェースを作成する必要があるが、 MS Project ファイルとは別に実績工数をデータベースに登録することができ、実績工数を使うと、工数でのアーンドバリュー・マネジメントを表示することが可能である。最新の計画と別に当初(企画時)の計画の差異を比較することもできる。

進捗ポートフォリオ

進捗ポートフォリオ.jpg前述のアーンドバリュー・マネジメントの計画工数、進捗工数、実績工数を使って、プロジェクトのブロックごとに計画の遅延と実績の遅延とを算出し、ポートフォリオ表示したグラフ。横軸が計画遅延で、縦軸が実績遅延を示す。それぞれ 100% がオンスケジュールで、100% 未満が遅れている状態である。プロット(点)は、プロジェクトを構成するブロックであり、このグラフにより、どのブロックが遅れているのか、計画を修正すべき遅れなのか、メンバーを増やす必要がある工数投入遅れなのかを知ることができる。

運用の規模や形態に合わせた仕組み化

MSP利用形態.pngシステム成長モデルLinkIconで説明したように、レベル1,レベル2,レベル3というプロジェクト管理の運用形態をツールやシステム環境の違いをもとに説明したが、MSP は利用形態にバラツキがあることも考慮しておく必要がある。典型的には右図のように整理することができる。

プロジェクトの現場では、規模や MSP の利用形態が、プロジェクトによって違っていたり、組織によって変化したりすることは珍しくない。そもそも、プロジェクトとはこのような多様性を持つものであるため、プロジェクト管理の仕組みも柔軟性を持ったものになっている必要がある。さもなければ、結局は無駄な投資や時間を生むことになる。