基準モデルはどこにも必ずある成功パターン(実践的メトリクス管理その7)

更新日

投稿日

 

【必要最小限の手間で行う開発の見える化 連載目次】

 

 前回のその6に続いて、解説します。実践的メトリクス管理の最後のテーマは「基準モデル」です。基準モデルとは、開発を適切に進めることができたときの成功パターンを数値化したもので、見積もりの基準として使ったり、進捗の判断基準に使ったりします。どんな組織にも自分たちの成功パターンが存在するはずで、それを基準モデルとして数値化することが、見積り精度を高め、進捗判断をより適切にする仕組みにつながります。
 

1. 基準モデル

 
 基準モデルは、開発を行っている組織の実績から作成するということが特徴となっています。開発プロジェクトの中には成功したものもあれば失敗したものもあると思いますが、これまでに解説してきた基本メトリクスを使って分析してみると興味深いことに気づくはずです。成功したプロジェクと失敗したプロジェクトとそれぞれに、共通のパターンがあるのです。たとえば、連載第1回でも紹介した工程別工数比率(図1)は、通信設備を開発している組織の実例ですが、成功プロジェクトはだいたい左の棒グラフ(基準モデル=成功パターン)のような工数比率になり、失敗プロジェクトは右の棒グラフ(失敗モデル=失敗パターン)のようになりました。
 
                  me71
図1 工程別工数比率の成功パターンと失敗パターン
 
 成功と失敗のそれぞれに共通パターンがあるのには理由があります。たとえば図1において、構想・システム設計と機器設計の工数比率は、成功プロジェクトでは 1:3 となるのに対して、失敗プロジェクトでは 1:5 となっています。これは、失敗プロジェクトでは構造・システム設計を十分に行わずに機器設計をスタートしてしまい、そのために後工程で多くの不具合が出てしまい、不具合対応に多くの工数がかかっていると考えられます。また、付帯業務が成功プロジェクトの場合は全体の 10% 未満で、失敗プロジェクトでは 20% になっていることも特徴的ですが、これは、開発がはじまる前に管理の仕組みや環境の整備を疎かにしたため、開発とは直接関係のない作業が増えてオーバーヘッドが増えていると考えられます。
 

2. ムダの多い分析的アプローチ

 
 このように、うまく行った、うまく行かなった、というのには原因があり、その結果、それぞれに共通のパターンがあらわれるわけです。これを数値化、可視化したものが基準モデルであり、その組織における成功の経験をモデルにして使える形にしたものということができます。基準モデルは見積り式ということができます。この見積もり式を作成するときによくあるのが、プロジェクト規模や期間、複雑度、困難度、さらには、メンバーの経験年数やスキルなど、関係があると考えられる要因をできるだけ数多く洗い出して、その一つひとつを数値化して重みづけをするという分析的アプローチです。
 
 開発プロジェクトを詳細に分析するために、分析的アプローチは高い精度の見積もり式ができると考えがちですが、必要となるデータを収集するのが大変で、しかも、計算式が複雑になり計算にも手間がかかることなり、やがて運用できなくなるケースがほとんです。しかも、手間がかかるわりには見積もり精度は高くならないのです。回路や機構のようなものには分析的アプローチは有効ですが、開発の主役である人間系の場合には有効ではありません。見積り式を作るには、分析的アプローチではなく、基準モデルという経験的アプローチが適しています。
 

3. 経験にもとづく実践的アプローチ

 
 ほとんどの開発組織は、仕様や機能、採用している技術などは違うものの、開発しているものは同じラインナップといえます。また、所属している管理者や技術者も、多少の増減や移動はあるものの大きくは変わりません。つまり、開発している製品ごとにいろいろと違いはあるものの、同じ組織の中ではほぼ一定の枠組みの中での開発なのです。
 
                        me72
図2 プロジェクト別の工程別工数比率
 
 図2は、ある製造装置を開発している部署で2年間で行った開発の内、開発中止や大幅な遅延などの失敗と考えられるものを除いた7つのプロジェクトの工程別工数比率です。それぞれのプロジェクトの関係者に話を聞くと、製品グレードが違う、価格が違う、機能が違う、規模が違う、新技術を使っているなど、他のプロジェクトとは違うことを強調するのですが、開発が上手く進んだこれらの7つのプロジェクトは、どれも同じような工数比率になっていることがわかると思います。実際、この部署ではこれらの平均をとって基準モデルを作ることで、見積り精度を高くすることができました。
 
 以上、成功した開発実績からその組織における成功パターンを見つけることが可能で、その成功パターンを数値化したものが基準モデルだということを解説しました(図3)。基準モデルを作成するためには、個々の開発を基本メトリクスセットを使って記録しておく必要があります。
 
                                                                                                                                           me73
図3 基準モデルの作成フロー
 
 実践的メトリクス管理の第7回は、工程別工数比率を使って基準モデルを解説しましたが、次回からは別の基準モデルの例を紹介したいと思います。
 
 
...

 

【必要最小限の手間で行う開発の見える化 連載目次】

 

 前回のその6に続いて、解説します。実践的メトリクス管理の最後のテーマは「基準モデル」です。基準モデルとは、開発を適切に進めることができたときの成功パターンを数値化したもので、見積もりの基準として使ったり、進捗の判断基準に使ったりします。どんな組織にも自分たちの成功パターンが存在するはずで、それを基準モデルとして数値化することが、見積り精度を高め、進捗判断をより適切にする仕組みにつながります。
 

1. 基準モデル

 
 基準モデルは、開発を行っている組織の実績から作成するということが特徴となっています。開発プロジェクトの中には成功したものもあれば失敗したものもあると思いますが、これまでに解説してきた基本メトリクスを使って分析してみると興味深いことに気づくはずです。成功したプロジェクと失敗したプロジェクトとそれぞれに、共通のパターンがあるのです。たとえば、連載第1回でも紹介した工程別工数比率(図1)は、通信設備を開発している組織の実例ですが、成功プロジェクトはだいたい左の棒グラフ(基準モデル=成功パターン)のような工数比率になり、失敗プロジェクトは右の棒グラフ(失敗モデル=失敗パターン)のようになりました。
 
                  me71
図1 工程別工数比率の成功パターンと失敗パターン
 
 成功と失敗のそれぞれに共通パターンがあるのには理由があります。たとえば図1において、構想・システム設計と機器設計の工数比率は、成功プロジェクトでは 1:3 となるのに対して、失敗プロジェクトでは 1:5 となっています。これは、失敗プロジェクトでは構造・システム設計を十分に行わずに機器設計をスタートしてしまい、そのために後工程で多くの不具合が出てしまい、不具合対応に多くの工数がかかっていると考えられます。また、付帯業務が成功プロジェクトの場合は全体の 10% 未満で、失敗プロジェクトでは 20% になっていることも特徴的ですが、これは、開発がはじまる前に管理の仕組みや環境の整備を疎かにしたため、開発とは直接関係のない作業が増えてオーバーヘッドが増えていると考えられます。
 

2. ムダの多い分析的アプローチ

 
 このように、うまく行った、うまく行かなった、というのには原因があり、その結果、それぞれに共通のパターンがあらわれるわけです。これを数値化、可視化したものが基準モデルであり、その組織における成功の経験をモデルにして使える形にしたものということができます。基準モデルは見積り式ということができます。この見積もり式を作成するときによくあるのが、プロジェクト規模や期間、複雑度、困難度、さらには、メンバーの経験年数やスキルなど、関係があると考えられる要因をできるだけ数多く洗い出して、その一つひとつを数値化して重みづけをするという分析的アプローチです。
 
 開発プロジェクトを詳細に分析するために、分析的アプローチは高い精度の見積もり式ができると考えがちですが、必要となるデータを収集するのが大変で、しかも、計算式が複雑になり計算にも手間がかかることなり、やがて運用できなくなるケースがほとんです。しかも、手間がかかるわりには見積もり精度は高くならないのです。回路や機構のようなものには分析的アプローチは有効ですが、開発の主役である人間系の場合には有効ではありません。見積り式を作るには、分析的アプローチではなく、基準モデルという経験的アプローチが適しています。
 

3. 経験にもとづく実践的アプローチ

 
 ほとんどの開発組織は、仕様や機能、採用している技術などは違うものの、開発しているものは同じラインナップといえます。また、所属している管理者や技術者も、多少の増減や移動はあるものの大きくは変わりません。つまり、開発している製品ごとにいろいろと違いはあるものの、同じ組織の中ではほぼ一定の枠組みの中での開発なのです。
 
                        me72
図2 プロジェクト別の工程別工数比率
 
 図2は、ある製造装置を開発している部署で2年間で行った開発の内、開発中止や大幅な遅延などの失敗と考えられるものを除いた7つのプロジェクトの工程別工数比率です。それぞれのプロジェクトの関係者に話を聞くと、製品グレードが違う、価格が違う、機能が違う、規模が違う、新技術を使っているなど、他のプロジェクトとは違うことを強調するのですが、開発が上手く進んだこれらの7つのプロジェクトは、どれも同じような工数比率になっていることがわかると思います。実際、この部署ではこれらの平均をとって基準モデルを作ることで、見積り精度を高くすることができました。
 
 以上、成功した開発実績からその組織における成功パターンを見つけることが可能で、その成功パターンを数値化したものが基準モデルだということを解説しました(図3)。基準モデルを作成するためには、個々の開発を基本メトリクスセットを使って記録しておく必要があります。
 
                                                                                                                                           me73
図3 基準モデルの作成フロー
 
 実践的メトリクス管理の第7回は、工程別工数比率を使って基準モデルを解説しましたが、次回からは別の基準モデルの例を紹介したいと思います。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


「プロジェクトマネジメント一般」の他のキーワード解説記事

もっと見る
学んだ教訓をまとめるレッスンズ・ラーンドの進め方【連載記事紹介】

  学んだ教訓をまとめるレッスンズ・ラーンドの進め方が無料でお読みいただけます!   ◆学んだ教訓をまとめるレッスンズ・ラー...

  学んだ教訓をまとめるレッスンズ・ラーンドの進め方が無料でお読みいただけます!   ◆学んだ教訓をまとめるレッスンズ・ラー...


工数メトリクスでわかるプロジェクトの振る舞い(実践的メトリクス管理その2)

  【必要最小限の手間で行う開発の見える化 連載目次】 1、必要最小限の手間で行う開発の見える化 2、工数メトリクスでわかるプロジェク...

  【必要最小限の手間で行う開発の見える化 連載目次】 1、必要最小限の手間で行う開発の見える化 2、工数メトリクスでわかるプロジェク...


作業の進捗や品質がわかる作業成果物メトリクス(実践的メトリクスその5)

  【必要最小限の手間で行う開発の見える化 連載目次】 1、必要最小限の手間で行う開発の見える化 2、工数メトリクスでわかるプロジェク...

  【必要最小限の手間で行う開発の見える化 連載目次】 1、必要最小限の手間で行う開発の見える化 2、工数メトリクスでわかるプロジェク...


「プロジェクトマネジメント一般」の活用事例

もっと見る
中小規模組織でのプロジェクト管理システムの課題(その1)

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...


中小規模組織でのプロジェクト管理システムの課題(その3)

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...


中小規模組織でのプロジェクト管理システムの課題(その2)

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...