前回のプロジェクト管理の仕組み (その20)に続いて解説します。
進捗管理のための基本メトリクスセットについての解説を続けています。基本メトリクスセットの目的は、プロジェクトに対するインプットとアウトプットを計測することによりプロジェクトの状況（進捗）を把握することで、それをできるだけ少ないメトリクスで実現しています。前回まではプロジェクトのアウトプットであるメトリクスについてでしたが、今回はインプットである開発工数メトリクスについて解説します。
製品開発プロジェクトのインプット（リソースという言い方もできます）にはいろいろなものがありますが、その中でも、ヒト、すなわち、プロジェクトメンバーが最も重要なインプット（リソース）であることは間違いないと思います。開発工数メトリクスとは、この最重要リソースであるプロジェクトメンバーがどのようなことに時間を使っているのかを計測することにより、メンバーの振る舞いを「見える化」するためのものです。
開発工数メトリクスも、基本メトリクスセットの他のメトリクス同様、プロジェクト構造（WBS）軸とアクティビティ軸の２軸で値を特定できるように収集します。を付加すること就業時間管理のために何らかの工数収集をやっているところも多いと思いますが、この既存の仕組みにプロジェクト構造軸とアクティビティ軸の情報ができれば、比較的簡単に工数収集の仕組みを整えることができます。
また、Excel を使って工数収集する仕組みを運用している組織もよく見かけます。専用ツールを開発して運用しているところも少なくありません。このように、何らかの形で工数収集ツールを運用しているところは多いのですが、ほとんどの組織で共通の課題を抱えています。それは、入力が継続しないことや、入力率が上がらないという課題です。これは、ツールの使い勝手が悪いことが原因であることも多いのですが、入力したデータを活用できていないためにメンバーが入力する意味を感じなくなるということも主な原因となっています。今回は、このような課題を避けるためにも、工数メトリクスでどのようなことがわかるのかを実例を使いながら解説したいと思います。最初に、プロジェクト構造軸とアクティビティ軸とで開発工数の時間推移をグラフにした例を紹介しましょう。図54がプロジェクト構造別の工数推移、図55がアクティビティ別の工数推移です。
図54. プロジェクト構造軸 工数推移
図55. アクティビティ軸 工数推移
このプロジェクトは、大きくベースバンド（BB）、ネットワーク（Network）、プラットフォーム（Platform）、無線（RF）、ソフトウェア（SW）、機構（ME）、システム（System）という７つのブロックに分かれて開発を進めており、図54を見ると、機構（ME）ブロックが最も早く開発に着手していることがわかります。また、システム (System) というアーキテクチャ設計など製品全体を担当しているブロックが継続的に全体の3～4割の大きな工数割合になっていることがわかります。このことから、この製品開発は機構面の新規開発要素を持ち、全体のアーキテクチャ設計が重要であると分析できます。そして、この分析が実際は違うということになれば、プロジェクトの進め方に問題がある可能性が高いことになります。
また、図55を見ると、開発の最初から基本設計に入ってしまいシステム設計が後回しになっていることがわかります。先ほどの図54と合わせて考えると、機構ブロックがシステム設計を待たずに基本設計を行っていると想像できますが、機構ブロックのアクティビティ別工数推移グラフを見ればそれが正しいことが確認できます（グラフは掲載しませんが実際そうでした）。したがって、システム設計の...
結果次第では手戻りになる可能性が高く、機構ブロックの仕事に進め方には問題があると判断できます。さらに、グラフからは、基本設計や詳細設計、そして、システムテストまでもがシステム設計と並行して実施されていることがわかります。設計重視とは反対の、作ってみて動作確認するという開発スタイルになっていると考えられます。
単純に基本メトリクスセットの基本である２軸で開発工数メトリクスを見るだけでも、プロジェクトの状況を客観的に把握できることがわかっていただけたと思います。開発工数メトリクスはプロジェクトメンバーの振る舞い、すなわち、メンバーが何をやっているのかを知ることができる指標であり、それを積み上げたものがプロジェクトの振る舞いをあらわしているのです。