進捗の見える化ですが、前回のその10に続いて解説します。今回考えるべきポイントは、可視化・見える化の方法です。図40 に示しているように、進捗管理では予定と実績との乖離を把握する必要があり、そのためは、計画も実績も見える化し、両者の乖離を把握しやすくすることが大切です。見える化とは、対象を数値化して定量的な把握や分析を可能にすることなのです。
図40.計画作成と進捗管理
対象を数値化して定量的な把握をするときに重要になるのは、どのようにしてデータを収集するのか（測定をするのか）、そして、収集したデータに対してどのような分析をおこなうのかということです。プロジェクト活動の中で実際に測定できる仕組みになっていないと、いくら進捗管理に役立つデータであっても収集するのは困難です。また、せっかく収集したデータでも、巨大な数表にして見せられるだけでは、そこから重要な情報を見抜くのは困難です。現実的なデータ収集方法と、効果的なデータの見せ方（分析方法）を工夫することが大切なのです。
それでは、先ほどの基本メトリクスセットの収集方法を考えてみましょう。まず、アウトプットの３つについてです。どれも製品開発をやる上ではいずれにしても収集しなくてはいけないものばかりです。タスクは、どのようなプロジェクトでも開発スケジュールとして必ず記述し、タスクごとに進捗を確認しているはずですから、測定可能なデータとしては必ず存在します。ただ、収集・分析できる形になっているかどうかというと、そうではない場合が多く、Excel などを使って単に図表（絵）として作成しているだけというところは少なくありません。適切な進捗管理を実施するためには、何かしらの進捗管理ツールを使って、データとして利用できる環境を整える必要があります。
作業成果物は、設計を行った後に、基板なり、半導体なり、プログラムなりを作るのであれば、何かしら設計文書や設計データを作成しているはずですし、評価やテストに関しても同様です。したがって、データとしては存在しているでしょう。しかし、収集・分析できる形になっているには、電子化されていることと、外部から取り出せるようになっている必要がありますが、そうなっていない場合もしばしば見かけます。このような場合は、進捗管理の仕組み作りと並行して、作業成果物を電子化した上で、成果物管理、構成管理の仕組みも整備するのが良いと思います。これらは、広義のプロジェクト管理や品質管理の観点から必要不可欠な仕組みです。そして、回路図からピン数やネット数をカウントするとか、プログラムのステップ数をカウントするといった、電子化された作業成果物を計測する仕組みを組み込みます。
このような仕組みを整備することが難しい場合は、開発工程移行の際に実施するレビュー（公式レビュー）の際のチェック項目として作業成果物のカウントを含めるのが良いでしょう。作業成果物の量（規模）をレビューのチェック項目にすることで、ブロック間での比較や以前の製品開発との比較、そして、まさに計画との比較など、単純に作業成果物があるかないかだけではないレビューが可能になります。これだけでも作業成果物をカウントする価値はあるのではないでしょうか。
そして、不具合・課題は、製品開発である以上、これらを把握せずに出荷することは考えられませんから、必ず何らかの形で管理しているはずです。ただ、ここでも、収集・分析できる形になっていない場合は結構見かけますし、その場合は、やはり電子化し、必要なときに必要なデー...
タを取り出すことができるように一元管理しておく必要があります。
以上をまとめると、プロジェクトのアウトプットである、タスク、作業成果物、不具合・課題については、電子化してデータとして処理できるようにしておくことと、それを一元管理しておく必要があるということです。それができなければ、人手をかけてデータ収集するという選択もありますが、製品開発のグローバル化や拡大化の流れを止めることはできませんから、このような仕組みがない場合には電子化し、必要なときに必要なデータを取り出すことができるように、一元管理する仕組みを整備することが肝要です。
次回は、進捗の見える化：第3回を解説します。