進捗管理の精度を上げる:第2回 プロジェクト管理の仕組み (その14)

更新日

投稿日

 実際の進捗管理方法について、基本メトリクスセットの中の「作業成果物」から紹介します。作業成果物とは開発作業を進める中で出力されるもののことです。ハードウェアであれば回路図や部品表など、ソフトウェアであればプログラムなどがあります。また、ハード、ソフトに関係なく各種の設計文書も作業成果物です。作業成果物は開発という作業アウトプットですから、この量(規模)を測定することで開発作業の進捗を把握することができるわけです。では、実際の作業成果物メトリクスを見ていきましょう。
 
 回路図や実装図(アートワーク)の場合には、部品や端子数などをカウントすることになります。先ほど、進捗管理するためには見積もり(計画)を作成すること、見積もりを作成するためには基準モデルを作っておく必要があることを説明しましたが、ここで、基準モデルがどのようなものになるのかを紹介しましょう。
 
 図44は通信関連のある製品について、基板ごとに開発工数と端子数(ピン数)とを調べ、横軸に開発工数、縦軸に端子数を開発工数で割った値(単位時間あたりの端子数)をとったグラフです。このグラフを見ると、バラツキはあるものの、基板ごとの端子数/開発工数は開発工数とは関係ないこと、端子数/開発工数はデジタル基板(青色)とアナログ基板(緑色)とで傾向が分かれることがわかります。したがって、デジタル基板、アナログ基板に分けてそれぞれの基準値を作成することができます。特異点を除くと図44 に示しているところがベストプラクティスと考えられるでしょう。これで、デジタル基板とアナログ基板について、単位開発時間あたりの端子数という基準モデルを作成することができました。
 
R&D
図44. 基準モデルの例
 
 単位開発時間あたりの端子数という基準モデルがあれば、基板ごとに手当てできる開発工数(担当メンバーと開発期間が決まれば決まる)から端子数が求まり、その基板で実現できる部品数から基板サイズを見積もったり、実現できる機能(の量)を見積もったりすることができます。基板ごとの機能やサイズから必要な開発工数を見積もることも可能です。
 
 基準値をそのまま見積もりとして採用することもできますが、技術の新規性や再利用の程度などにより多少の調整を行い見積もり値...
 実際の進捗管理方法について、基本メトリクスセットの中の「作業成果物」から紹介します。作業成果物とは開発作業を進める中で出力されるもののことです。ハードウェアであれば回路図や部品表など、ソフトウェアであればプログラムなどがあります。また、ハード、ソフトに関係なく各種の設計文書も作業成果物です。作業成果物は開発という作業アウトプットですから、この量(規模)を測定することで開発作業の進捗を把握することができるわけです。では、実際の作業成果物メトリクスを見ていきましょう。
 
 回路図や実装図(アートワーク)の場合には、部品や端子数などをカウントすることになります。先ほど、進捗管理するためには見積もり(計画)を作成すること、見積もりを作成するためには基準モデルを作っておく必要があることを説明しましたが、ここで、基準モデルがどのようなものになるのかを紹介しましょう。
 
 図44は通信関連のある製品について、基板ごとに開発工数と端子数(ピン数)とを調べ、横軸に開発工数、縦軸に端子数を開発工数で割った値(単位時間あたりの端子数)をとったグラフです。このグラフを見ると、バラツキはあるものの、基板ごとの端子数/開発工数は開発工数とは関係ないこと、端子数/開発工数はデジタル基板(青色)とアナログ基板(緑色)とで傾向が分かれることがわかります。したがって、デジタル基板、アナログ基板に分けてそれぞれの基準値を作成することができます。特異点を除くと図44 に示しているところがベストプラクティスと考えられるでしょう。これで、デジタル基板とアナログ基板について、単位開発時間あたりの端子数という基準モデルを作成することができました。
 
R&D
図44. 基準モデルの例
 
 単位開発時間あたりの端子数という基準モデルがあれば、基板ごとに手当てできる開発工数(担当メンバーと開発期間が決まれば決まる)から端子数が求まり、その基板で実現できる部品数から基板サイズを見積もったり、実現できる機能(の量)を見積もったりすることができます。基板ごとの機能やサイズから必要な開発工数を見積もることも可能です。
 
 基準値をそのまま見積もりとして採用することもできますが、技術の新規性や再利用の程度などにより多少の調整を行い見積もり値とすることもできます。このような調整を行う場合でも基準が明確なので議論が発散しないようになります。
 
 ここでは単位時間あたりの端子数を例にとりましたが、基本メトリクスセットの各メトリクスについても同様です。実際のデータを収集・分析すれば一定の傾向が発見できます。
 
 次回は、基板を例にとっていくつかの進捗管理のためのグラフを解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
機能の分類 設計機能(その3)

   製品開発やサービス設計において、目に見える「顕在的な機能」だけで要件を満たした気になっていませんか?実は、見落としがちな「潜在的な機能」...

   製品開発やサービス設計において、目に見える「顕在的な機能」だけで要件を満たした気になっていませんか?実は、見落としがちな「潜在的な機能」...


知識・経験を物理量で整理する 普通の組織をイノベーティブにする処方箋 (その67)

 前回までは、知識や経験を時系列で整理するという話をしてきましたが、当然時系列以外の物理量という軸があります。今回からは「知識・経験を物理量で整理する...

 前回までは、知識や経験を時系列で整理するという話をしてきましたが、当然時系列以外の物理量という軸があります。今回からは「知識・経験を物理量で整理する...


恐れずに目標設定をするための仕組みとは 新規事業・新商品を生み出す技術戦略(その60)

◆ 不明確な状況であってもゴールを設定する 1. 不明確はデフォルト  先日コンサルティング現場で次のような事例を目にすることがありました。  ...

◆ 不明確な状況であってもゴールを設定する 1. 不明確はデフォルト  先日コンサルティング現場で次のような事例を目にすることがありました。  ...


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

もっと見る
進捗管理可能なソフト開発計画 プロジェクト管理の仕組み (その6)

 前回のその5:ソフト開発計画の作成方法に続いて解説します。    製品機能に対するソフトウェアの各モジュールが実装すべき処理(内部機能)が...

 前回のその5:ソフト開発計画の作成方法に続いて解説します。    製品機能に対するソフトウェアの各モジュールが実装すべき処理(内部機能)が...


ソフトウェア開発スケジュールと結合テスト プロジェクト管理の仕組み (その7)

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。    ソフトウェア開発スケジュールでは次のような問題を抱えています。 &...

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。    ソフトウェア開発スケジュールでは次のような問題を抱えています。 &...


設計部門の仕組み構築(その3)

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...