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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
自分の望むものを得る環境に身を置く 普通の組織をイノベーティブにする処方箋 (その78)

 今回は「多様な思考パターンを実現」するための方策としての「課題を持つ環境に自らを置く」ための1つ「Gain:自分の望むものを得る環境に身を置く」の方...

 今回は「多様な思考パターンを実現」するための方策としての「課題を持つ環境に自らを置く」ための1つ「Gain:自分の望むものを得る環境に身を置く」の方...


技術文書の品質管理(その6)技術文書の最小単位、文の品質管理

  今回は、技術文書の最小単位である文と、その品質管理について解説します。文の品質管理は技術文書の品質管理に含まれます。しかし、文の品質管...

  今回は、技術文書の最小単位である文と、その品質管理について解説します。文の品質管理は技術文書の品質管理に含まれます。しかし、文の品質管...


研究開発と新規テーマ~技術企業の高収益化:実践的な技術戦略の立て方(その13)

    ◆『業務が忙しくて新しいことができない』に対処する方法  新規事業に限らず、会社でなにか新しいことを始める時に問題になる...

    ◆『業務が忙しくて新しいことができない』に対処する方法  新規事業に限らず、会社でなにか新しいことを始める時に問題になる...


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

もっと見る
設計部門と組織政治の影響(その3)

 前回のその2に続いて解説します。   ◆政治的要因の検討で決まるスケジュールの確度・精度    日程を決めるときには、仕組み...

 前回のその2に続いて解説します。   ◆政治的要因の検討で決まるスケジュールの確度・精度    日程を決めるときには、仕組み...


製品開発部へのカンバン導入記(その3)

        前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...

        前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...


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

 前回は進捗管理の基本的な考え方を紹介しました。今回は、この考え方にしたがってどのような方法で実際に進捗を把握できるのかを紹介したいと思います。具体的な話...

 前回は進捗管理の基本的な考え方を紹介しました。今回は、この考え方にしたがってどのような方法で実際に進捗を把握できるのかを紹介したいと思います。具体的な話...