開発生産性とは プロジェクト管理の仕組み (その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プロジェクトをプロットしたものです。縦軸の開発生産性は、そのプロジェクトで新規に作成したプログラム・ステップと修正したプログラム・ステップを加算したものを、リリースまでの開発工数で除算したものです。複数会社の複数プロジェクトをプロットしたものですから、かなりバラツキがあるのは当然ですが、高い値を示しているところに注目すると、流用率が高くなるにつれて開発生産性も高くなっていることがわかります(橙色の線)
 
 流用率を上げることが推奨されることは多いものですが、確かに流用率を上げることは開発効率を上げることにつながることがわかります。ただし、流用率が高くなるほど開発生産性のバラツキが大きくなっていることに注意が必要です。単純に流用率を上げるだけでは開発生産性を上げることにはつながらないことを示しています。「流用率を上げろ」というかけ声だけではダメだということです。
 
 さて、今回はソフトウェア開発における作業成果物メトリクスについて解説しました。プログラム・ステップ数など、作業成果物メトリクスを収集しているところは多いものの、その妥当性を検証することなく複雑化していることや、特定の開発工程にしか使えないメトリクスだけで済ませていることなどがあるので、改めてそのメトリクスが活用できているかどうかを確かめてみても良いかも知れません。また、作業成果物メトリクス間の関係式を作ることで、段階的に見積もり精度を上げる仕組みを構築することができることも、ぜひトライしてみて下さい。
 
 次回は、作業成果物メトリクス以外のメトリクスについての解説です。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


関連する他の活用事例

もっと見る
「あったらいいな」を技術シーズ起点に発想する~製薬会社の新しいアイデア創出に向けた取り組み

♦新製品開発のアイデア創出に“新たな風”吹き込む  小林製薬(大阪府)社は「“あったらいいな&rdq...

♦新製品開発のアイデア創出に“新たな風”吹き込む  小林製薬(大阪府)社は「“あったらいいな&rdq...


追求するのは擦り合わせ能力を活かすマネジメント(その2)

 前回のその1に続いて解説します。それでは、まず「調整」の仕組みについて考えたいと思います。最初に質問です。調整の仕組みが欠如した製品開発はどのような状態...

 前回のその1に続いて解説します。それでは、まず「調整」の仕組みについて考えたいと思います。最初に質問です。調整の仕組みが欠如した製品開発はどのような状態...


開発部門の管理職が学ぶべきこととは

   今回は、新任の開発課長が学ぶべきこと、課長就任前に3週間で準備をすべきこと、さらには課長就任後に取り組むべきことについて解説します。 ...

   今回は、新任の開発課長が学ぶべきこと、課長就任前に3週間で準備をすべきこと、さらには課長就任後に取り組むべきことについて解説します。 ...