進捗の見える化:第2回 プロジェクト管理の仕組み (その11)

更新日

投稿日

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

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
思考の構成要素 普通の組織をイノベーティブにする処方箋 (その59)

   前回まではKETICモデルの2つ目、経験(Experience)の解説をし、また前回は経験(Experience)と他の要素、すなわ...

   前回まではKETICモデルの2つ目、経験(Experience)の解説をし、また前回は経験(Experience)と他の要素、すなわ...


リスクマネジメント 新規事業・新商品を生み出す技術戦略(その81)

  ◆ 共創におけるリスクマネジメント  今回は「共創におけるリスクマネジメント」というタイトルで解説します。  昨今オープンイノベー...

  ◆ 共創におけるリスクマネジメント  今回は「共創におけるリスクマネジメント」というタイトルで解説します。  昨今オープンイノベー...


イノベーションの創出 普通の組織をイノベーティブにする処方箋 (その125)

  今回も前回と同様「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にもとづき、日々の活動の中でどう...

  今回も前回と同様「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にもとづき、日々の活動の中でどう...


「技術マネジメント総合」の活用事例

もっと見る
設計部門の課題と原因分析(その2)

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...


技術人材が目指す第3のキャリアとは

1.R&Dの現場に存在する2つのラダー    私は、イノベーションを「価値の創造と具現化」として定義していますが、もう少し突っ込んで...

1.R&Dの現場に存在する2つのラダー    私は、イノベーションを「価値の創造と具現化」として定義していますが、もう少し突っ込んで...


作業要素の進捗分析2 プロジェクト管理の仕組み (その19)

  前回のその18:作業要素の進捗分析1に続いて解説します。    図50は製品構造の観点から管理単位にブレークダウンした例です。製品がどの...

  前回のその18:作業要素の進捗分析1に続いて解説します。    図50は製品構造の観点から管理単位にブレークダウンした例です。製品がどの...