最後は、プロジェクトの入力である開発工数です。これで、基本メトリクスセットすべてについての検討ができたことになりますが、実は、データ収集がもっとも難しいのが、この開発工数です。
開発工数は、通常の開発作業や品質管理などで直接必要になるわけではなく、また、収集を自動化するのは非常に困難で、どうしてもプロジェクトメンバーに意識的に入力してもらうことになります。実際、進捗管理の仕組みが整備できている組織でも、データ収集に一番苦労しているのが開発工数です。
したがって、開発工数については、入力しやすいツール環境の整備、入力することによるメリットの説明、そして、具体的な活用成果の共有などを地道に実施することが大切です。そして、地道だからこそ、やっているところとやっていないところでは大きな差になってあらわれるのです。仕組み改革の推進者の力量が問われるところでもあります。なるべく早く開発工数を入力することの具体的な成果を、入力している技術者に見せると効果的です。
このような地道な努力をして開発工数を収集できるようになった時のために、開発工数を収集する際のポイントをお伝えしておきましょう。それは、開発工数を収集するときに、図42のように、アクティビティ軸とプロジェクト構造（WBS）軸の２つの軸を特定できるようにしておくということです。
図42. 管理のための二つの軸
アクティビティ軸は、取り組む課題、対象（製品）をどのような手順で実現していくかを時間軸で定義したものです。実現するための作業（工程）を特定できるようにしますが、同時に、可視性を高めるため工程の階層化、工程の目的と開始基準、終了基準、その工程で実施する作業、そして責任者なども定義しておく必要があります。このようにして定義された個々の作業をここではアクティビティと呼びます。開発工数を収集するときはアクティビティを特定できるようにしておきます。
プロジェクト構造（WBS）軸は、プロジェクトが達成すべきゴールとして取り組む課題や対象（製品）を階層的に詳細化し、ゴールを達成するために何をすれば良いかを定義したものです。製品の場合はシステム構造図などで表現されたものとほぼ同じと考えても良いと思います。ここではこれを狭義の WBS (Work Breakdown Structure) と呼んでおり、分解された要素を WBS 要素、あるいは、単に WBS と呼びます。開発工数収集の際には、プロジェクト構造上の要素（WBS 要素）を特定できるようにしておきます。
以上のことを例で説明すると、プロジェクトメンバーのAさんが使ったある週の月曜日の2時間は、アクティビティ軸では「回路設計」として特定でき、プロジェクト構造（WBS）軸では「電源ブロック」として特定できるようになっているということです。このようにして、すべてのプロジェクトメンバーのすべての時間に対してアクティビティ軸とプロジェクト構造軸とを関連づけます。
そして、アクティビティ軸とプロジェクト構造（WBS）軸でデータを特定できるようにして...
おくというのは、開発工数に限ったことではなく、基本メトリクスセットすべてについて有効です。それぞれについて収集の際に注意すべきポイントはありますが、最低限、アクティビティ軸とプロジェクト構造（WBS）軸で特定できるようにしておくことを忘れないようにしてください。
次回は、進捗管理の「計画に照らしてプロジェクトを監視する」についての残りのポイントである、わかりやすい見せ方について解説します。収集したデータに対してどのような分析を行えば進捗をわかりやすく伝えることができるかを、いくつかの事例を紹介しながら説明します。