前回のプロジェクトの問題を見極める1に続いて解説します。
図58はアクティビティ軸からシステム設計だけを抽出し、サブグループごとの工数推移のグラフにしたものです。このグラフを見ると、システム設計に工数を割いているのは無線サブグループ（RF）であることがわかります。
図58. システム設計のプロジェクト構造軸工数推移
システムサブグループの代わりに無線サブグループが製品全体のシステム設計を実施しているのであれば問題ないかもしれないのですが、現実は、無線ブロックは独立したブロックであり無線の範囲だけで方式設計をやっているのがここでのシステム設計の中身でした。製品全体のシステム設計はシステムサブグループの仕事であり、他の誰もやることはできないのです。
このように詳細に開発工数メトリクスのグラフを見てみると、本当にまずい状況であることわかってきました。しかし、システムサブグループや無線サブグループなどの個々のサブグループは、自分たちの目に前にある問題を解決することに一生懸命なわけですから、大きな遅れはないと判断することもありますし、大きな問題ととらえていないので進捗報告にもとりあげていないこともあります。個別には一生懸命であってもプロジェクト全体で見たときには問題をはらんでいる状況は珍しくはありません。そしてこれは、プロジェクト責任者が把握し対応を指示しなければ解決できない問題です。この例の場合、システムサブグループが本来やるべきシステム設計に工数を割けるように規格認定試験の対応方法を見直すことと、対外的な業務の担当や進め方を見直すことが急務です。
プロジェクト責任者は常にメンバーとのコミュニケーションを密にして、サブグループやそのメンバーの状況を把握しておくことでこのような状況を把握することはできますが、そのために進捗会議や報告の時間が長くなってしまうのでは開発効率が下がってしまい本末転倒です。また、様々な意見や報告があったときに客観的な基準がなければ、どの声が正しいのかという判断を誤ってしまうこともなりかねません。基本メトリクスセットの各メトリクスはこのような状況を避けるための道具なのです。
システムサブグループでは問題だとは認識していないことは、実は別のグラフでも知ることができます。図59はシステムサブグループの 2009 年以降の週ごとの工数を表示したグラフです。このグラフでは3種類のデータを表示しています。一番左がスケジュールでその週で計画されている作業を実施するのに必要となる工数（計画工数）、中央がその週に予定している作業の成果（アウトプット）を工数換算したもの（成果進捗工数）、一番右がその週に実際に使った工数（実績工数）です。
図59. システムサブチームの週ごとの工数推移
図59を見ると、システムサブグループはスケジュール上では２月から大幅に作業が増える計画になっているのですが、2/9 週までは計画工数と成果進捗工数はほぼ同じ値になっていることから、スケジュール上は計画通りに作業が進んでいることがわかります。しかし、２月以降の実績工数はほとんど増えておらず、計画工数の 1/3 程度しか工数を使っていないのです。つまり、システムサブグループは計画通りに作業は進んでいると認識（報告）しているのですが、実際に使っている時間は計画通りに増やせていないわけです。これは、システムサブグループが作業成果（アウトプット）に対して甘い評価をしている、もしくは...
、かなり余裕を持たせた計画になっており実際はもっと少ない工数の計画で良かった、のどちらかです。いずれにしても、計画もしくはその進捗把握に問題があるということです。メトリクスによってこのようなことも把握することが可能です。
以上、開発工数メトリクスを使うだけでもかなりつっこんだプロジェクト進捗分析ができることがわかっていただけたと思います。また、タスク、作業成果物、不具合・課題という各々のメトリクスを使ってもかなり詳細な進捗分析が可能なことはこれまで解説したとおりですし、これら基本メトリクスセットのメトリクスを組み合わせることで、プロジェクトの進捗を多面的、総合的に判断できます。