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

更新日

投稿日

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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
将来に向かっての強みを設定する要件 普通の組織をイノベーティブにする処方箋 (その47)

        前回はKETICモデルのK(Knowledge)の知識の3つの要素の内、「自社の強み」の中の...

        前回はKETICモデルのK(Knowledge)の知識の3つの要素の内、「自社の強み」の中の...


新商品アイディアは今あるものからしか生まれない 新規事業・新商品を生み出す技術戦略(その54)

        「新商品は今あるものからしか生まれない」    これは分かっているつもりでも、...

        「新商品は今あるものからしか生まれない」    これは分かっているつもりでも、...


ワイガヤとは?イノベーションを生むためのテーマの設定方法や議論の内容について解説

【目次】   1. ワイガヤとは  ホンダの「ワイガヤ」について、ホンダOBは、「イノベーションを加速する仕掛けの一つであ...

【目次】   1. ワイガヤとは  ホンダの「ワイガヤ」について、ホンダOBは、「イノベーションを加速する仕掛けの一つであ...


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

もっと見る
仕組みの見直しに成功する組織1 プロジェクト管理の仕組み (その25)

 この連載では、仕組みの見直しをテーマに様々な考え方や事例を紹介しているわけですが、実際にコンサルタントして仕組みの見直しに取り組んだ組織の中には成功して...

 この連載では、仕組みの見直しをテーマに様々な考え方や事例を紹介しているわけですが、実際にコンサルタントして仕組みの見直しに取り組んだ組織の中には成功して...


システム設計2 プロジェクト管理の仕組み (その34)

 前回でシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなこ...

 前回でシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなこ...


‐操作性改善‐ ‐修理情報活用‐  製品・技術開発力強化策の事例(その1)

1.機械の操作性の改善  自社の機械を購入してくれた顧客を訪問し、操作性について苦情を聞くことを中心に営業活動をしている機械メ-カがあります。多品種...

1.機械の操作性の改善  自社の機械を購入してくれた顧客を訪問し、操作性について苦情を聞くことを中心に営業活動をしている機械メ-カがあります。多品種...