開発生産性とは プロジェクト管理の仕組み (その17)

更新日

投稿日

 前回のその16に続いて解説します。作業成果物メトリクスは、作業成果物を測定することにより作業量から見た進捗を把握するためのものですが、その活用方法について紹介しておきたいことがあります。もう一度、図48をご覧ください。図に開発工程の作業成果物メトリクス間の関係式を記載しています。この関係式は、基準モデルと同じように、自組織でのプロジェクトの実績値を分析して作ったもので、図に記載している関係式はある組織でのものです。
 
研究開発
図48.開発工程ごとの作業成果物メトリックス例
 
 このような関係式を作ると、作業成果物メトリクスを使って進捗管理をするだけでなく、その進捗情報を使って作業見積もりをすることが可能となります。たとえば基本設計工程では、計画していた総プロセス数に対して、実際に設計ができたプロセス数をカウントすることで作業進捗を判断するわけですが、この関係式を使えば、設計ができたプロセス数から詳細設計工程におけるファンクション数を見積もることができます。同様に、見積もったファンクション数からコーディング工程におけるプログラム・ステップ数を見積もり、さらにはテスト工程におけるテスト項目数も見積もることができます。
 
 図48で説明すると、設計できたプロセス数が10であればファンクション数は、53と見積もることができ、さらに、プログラム・ステップ数の見積もりは、1855となり、テスト項目数の見積もりは、222となります。図48には書いていませんが、それぞれの作業成果物メトリクスと工数との関係式も明確になっているはずですから、各工程での工数も見積もることができます。
 
 このように、作業成果物メトリクス間の関係式を使えば、開発工程における作業が進むにつれ、そして、開発工程が進むにつれ、それ以降の作業量や必要工数の見積もり精度を上げることができます。開発初期に見積もったプログラム・ステップ数や工数を最終ゴールとし、その変わらないゴールと実績と比較することで進捗とするのではなく、継続的に見積もりを見直すことにより段階的にその精度を上げることができるのです。
 
 この関係式を作ればそれが基準モデルになっているのですが、作業成果物メトリクスについても基準モデルを作ることを忘れないでください。プログラム・ステップ数であれば、コーディング工程の作業成果物メトリクスですから、単位時間当たりのプログラム行数というコーディングのパフォーマンスとなる基準モデルをつくることができるはずです。ただ、繰り返しになりますが、単位工数あたりのプログラム・ステップ数というのは他社データが手に入れやすいこともあり、そのまま自分のところの基準としてしまうことがありがちですが、あくまでも自分の組織でのベストプラクティス(成功事例)を基準とすることを忘れないようにしてください。自分たちの現状の延長上にあるゴール(基準)であることが大切なのです。ここで、プログラム・ステップ数に関して興味深いデータをひとつ紹介しましょう。
 
研究開発
図49.流用率と開発生産性の関係
 
 図49は横軸に流用率、縦軸に単位時間当たりのプログラム・ステップ数(開発生産性)をとり、10 社程度のエレクトロニクス・メーカーの約50プロジェクトをプロットしたものです。縦軸の開発生産性は、そのプロジェクトで新規に作成したプログラム・ステップと修正したプログラム・ステップを加算したものを、リリースまでの開発工数で除算したものです。複数会社の複数プロジェクトをプロットしたものですから、かなりバラツキがあるのは当然ですが、高い値を示しているところに注目すると、流用率が高くなるにつれて開発生産性も高くなっていることがわかります(橙色の線)
 
 流用率を上げることが推奨されることは多いものですが、確かに流用率を上げることは開発効率を上げることにつながることがわかります。ただし、流用率が高くなるほど開発生産性のバラツキが大きくなっていることに注意が必要です。単純に流用率を上げるだけでは開発生産性を上げる...
 前回のその16に続いて解説します。作業成果物メトリクスは、作業成果物を測定することにより作業量から見た進捗を把握するためのものですが、その活用方法について紹介しておきたいことがあります。もう一度、図48をご覧ください。図に開発工程の作業成果物メトリクス間の関係式を記載しています。この関係式は、基準モデルと同じように、自組織でのプロジェクトの実績値を分析して作ったもので、図に記載している関係式はある組織でのものです。
 
研究開発
図48.開発工程ごとの作業成果物メトリックス例
 
 このような関係式を作ると、作業成果物メトリクスを使って進捗管理をするだけでなく、その進捗情報を使って作業見積もりをすることが可能となります。たとえば基本設計工程では、計画していた総プロセス数に対して、実際に設計ができたプロセス数をカウントすることで作業進捗を判断するわけですが、この関係式を使えば、設計ができたプロセス数から詳細設計工程におけるファンクション数を見積もることができます。同様に、見積もったファンクション数からコーディング工程におけるプログラム・ステップ数を見積もり、さらにはテスト工程におけるテスト項目数も見積もることができます。
 
 図48で説明すると、設計できたプロセス数が10であればファンクション数は、53と見積もることができ、さらに、プログラム・ステップ数の見積もりは、1855となり、テスト項目数の見積もりは、222となります。図48には書いていませんが、それぞれの作業成果物メトリクスと工数との関係式も明確になっているはずですから、各工程での工数も見積もることができます。
 
 このように、作業成果物メトリクス間の関係式を使えば、開発工程における作業が進むにつれ、そして、開発工程が進むにつれ、それ以降の作業量や必要工数の見積もり精度を上げることができます。開発初期に見積もったプログラム・ステップ数や工数を最終ゴールとし、その変わらないゴールと実績と比較することで進捗とするのではなく、継続的に見積もりを見直すことにより段階的にその精度を上げることができるのです。
 
 この関係式を作ればそれが基準モデルになっているのですが、作業成果物メトリクスについても基準モデルを作ることを忘れないでください。プログラム・ステップ数であれば、コーディング工程の作業成果物メトリクスですから、単位時間当たりのプログラム行数というコーディングのパフォーマンスとなる基準モデルをつくることができるはずです。ただ、繰り返しになりますが、単位工数あたりのプログラム・ステップ数というのは他社データが手に入れやすいこともあり、そのまま自分のところの基準としてしまうことがありがちですが、あくまでも自分の組織でのベストプラクティス(成功事例)を基準とすることを忘れないようにしてください。自分たちの現状の延長上にあるゴール(基準)であることが大切なのです。ここで、プログラム・ステップ数に関して興味深いデータをひとつ紹介しましょう。
 
研究開発
図49.流用率と開発生産性の関係
 
 図49は横軸に流用率、縦軸に単位時間当たりのプログラム・ステップ数(開発生産性)をとり、10 社程度のエレクトロニクス・メーカーの約50プロジェクトをプロットしたものです。縦軸の開発生産性は、そのプロジェクトで新規に作成したプログラム・ステップと修正したプログラム・ステップを加算したものを、リリースまでの開発工数で除算したものです。複数会社の複数プロジェクトをプロットしたものですから、かなりバラツキがあるのは当然ですが、高い値を示しているところに注目すると、流用率が高くなるにつれて開発生産性も高くなっていることがわかります(橙色の線)
 
 流用率を上げることが推奨されることは多いものですが、確かに流用率を上げることは開発効率を上げることにつながることがわかります。ただし、流用率が高くなるほど開発生産性のバラツキが大きくなっていることに注意が必要です。単純に流用率を上げるだけでは開発生産性を上げることにはつながらないことを示しています。「流用率を上げろ」というかけ声だけではダメだということです。
 
 さて、今回はソフトウェア開発における作業成果物メトリクスについて解説しました。プログラム・ステップ数など、作業成果物メトリクスを収集しているところは多いものの、その妥当性を検証することなく複雑化していることや、特定の開発工程にしか使えないメトリクスだけで済ませていることなどがあるので、改めてそのメトリクスが活用できているかどうかを確かめてみても良いかも知れません。また、作業成果物メトリクス間の関係式を作ることで、段階的に見積もり精度を上げる仕組みを構築することができることも、ぜひトライしてみて下さい。
 
 次回は、作業成果物メトリクス以外のメトリクスについての解説です。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
知識・経験を時系列で整理 普通の組織をイノベーティブにする処方箋 (その65)

 今回も、前回同様、「思い付く」ための「知識・経験を整理するフレームワーク」の中の、知識・経験を時系列で整理する「期」ついて議論をします。 1. 守...

 今回も、前回同様、「思い付く」ための「知識・経験を整理するフレームワーク」の中の、知識・経験を時系列で整理する「期」ついて議論をします。 1. 守...


市場トラブルを解決に導く調査の進め方~海外製テレビの誤動作と電池焼損の事例に学ぶ~

【目次】 市場で発生する製品トラブルは、単なる故障から環境要因、設計上の不具合まで多岐にわたります。特に海外製品の場合、初期対応や原...

【目次】 市場で発生する製品トラブルは、単なる故障から環境要因、設計上の不具合まで多岐にわたります。特に海外製品の場合、初期対応や原...


普通の組織をイノベーティブにする処方箋 (その188) 妄想を続けることで頭が良くなることを実感し妄想を好きになる

・見出しの番号は、前回からの連番です。 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 妄想はネガティブに捉えられがちですが...

・見出しの番号は、前回からの連番です。 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 妄想はネガティブに捉えられがちですが...


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

もっと見る
技術高度化の5戦略

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...


先行技術テーマを企画段階で評価するには

1.先行技術開発    イノベーション、すなわち価値創造がものづくり企業におけるR&Dのミッションとして期待される中で、それを実現す...

1.先行技術開発    イノベーション、すなわち価値創造がものづくり企業におけるR&Dのミッションとして期待される中で、それを実現す...


羽のない扇風機が創られた時の目標設定、横並び競争と何が違うのか?

【目次】 1. 福原流QFDは技術者の創造性を引き出す技法 私も含めて我々技術者の思考は知らず知らずにうちに技術手段のHOWを考え...

【目次】 1. 福原流QFDは技術者の創造性を引き出す技法 私も含めて我々技術者の思考は知らず知らずにうちに技術手段のHOWを考え...