進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造（WBS）軸とアクティビティ軸のそれぞれの視点で開発工数メトリクスをグラフ化した例を紹介しました。少しおさらいをしておきましょう。
図54. プロジェクト構造軸 工数推移
図54のプロジェクト構造軸ごとの工数推移では、プロジェクトを構成しているサブグループ（ブロック）の工数の動きを把握することができ、機構サブグループ（ME）が最も早くから開発着手していたことや、開発初期段階である現時点では全体アーキテクチャ設計を担当しているシステムサブグループ（System）が開発作業の中心となっていることがわかりました。
図55. アクティビティ軸 工数推移
図55のアクティビティごとの工数推移では、開発工程ごとの時間の使い方を見ることによって開発が適切に進んでいるかどうかを見ることができました。プロジェクト構造軸のグラフでは、システム設計である全体アーキテクチャを担当しているシステムサブグループがもっとも多くの工数（40 %程度）を使っていたのですが、アクティビティでみるとどの週もシステム設計は多くても 20 % 程度であり、基本設計や詳細設計にも同じくらいの割合で工数を使っていることがわかりました。システム設計が完了する前から基本設計や詳細設計に着手しており、システム設計の手戻りになる危険が高いと考えることができました。従って、もし、あなたがプロジェクトの責任者であれば、基本アーキテクチャを設計すべきシステムサブグループについての詳細と、基本アーキテクチャ設計が含まれるシステム設計についての詳細を確認するだろうと思います。そこで今回は、プロジェクト構造軸におけるシステムサブグループとアクティビティ軸におけるシステム設計を中心に開発工数メトリクスを使って、より詳細な状況分析をしてみましょう。
図57. システムサブグループのアクティビティ軸工数推移
図57はプロジェクト構造軸からシステムサブグループだけを選択して、アクティビティ（開発工程）ごとの工数推移をグラフにしたものです。図55はプロジェクト全体のアクティビティごとの工数推移でしたが、プロジェクト構造軸を適切に設定しておくことでこのように特定のサブグループについて同様のグラフを作ることができるのです。さて、前述したようにシステムサブグループは基本アーキテクチャ設計、すなわち、システム設計に工数を割くべきなのですが、図57を見ると、システム設計をやっていないことがわかります。ほとんどゼロです。その代わりに工数を割いているのはプロジェクト管理とシステムテストであることがわかります。グラフに示している期間はプロジェクトの前半段階であり、システムサブグループが本来やるべき作業は構想やシステム設計のはずですから、プロジェクトの責任者としては放ってはおけない状況だと言えるでしょう。
実際に事情を確かめたところ、プロジェクトリーダーは対外的な交渉や調整で忙しく、製品全体を見ているシステムサブグループがメンバーを10人程度抱えているプロジェクト内の管理作業をやらざるを得ない状況になっていることがわかりました。アーキテクチャという技術的なことだけでなく、プロジェクト管理面でもメンバーから頼られているためにプロジェクト管理の工数が多くなっているのです。そして、...
システムテストが多いのは、規格認定試験を行う時期が迫っており、そのための環境整備や動作確認などに工数をとられているということでした。予定しているリリース時期から逆算するとこの時期に規格認定試験を受けることになるのはわかっていたのですが、その準備や対応に予想以上に工数がかかっているというわけです。システムサブグループはこのような事情を抱えているのですが、結果的にシステムサブグループは本来業務である構想やシステム設計に工数を割くことができず、目の前の、半ば場当たり的な作業に追われている状況になっていることは間違いありません。
次回は、プロジェクトの問題を見極める2を解説します。