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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
関係性の種類、対立とは 普通の組織をイノベーティブにする処方箋(その97)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回は下記(6)の対立についてお話します。 ◆関連解...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回は下記(6)の対立についてお話します。 ◆関連解...


顧客の声を聴くとは 新規事業・新商品を生み出す技術戦略(その49)

        今回は一部に賛否両輪がささやかれる「顧客の声を聴く」がテーマです。    売れ...

        今回は一部に賛否両輪がささやかれる「顧客の声を聴く」がテーマです。    売れ...


開発効率向上、活動計画 1 開発効率を上げるには(その4)

  【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 開発効率向上、活動計画 1...

  【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 開発効率向上、活動計画 1...


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

もっと見る
進捗の見える化:第1回 プロジェクト管理の仕組み (その10)

 この数回はプロジェクト管理の仕組みについて解説していますが、表面的な仕組みではなく、本質的な課題に対応したより進化・深化した仕組みにするための考え方を解...

 この数回はプロジェクト管理の仕組みについて解説していますが、表面的な仕組みではなく、本質的な課題に対応したより進化・深化した仕組みにするための考え方を解...


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

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

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


システム設計7 プロジェクト管理の仕組み (その39)

 前回のシステム設計6に続いて解説します。    検証作業の基本は、考えたサブシステム構成に対してシステム要件の一つひとつに対してどのような...

 前回のシステム設計6に続いて解説します。    検証作業の基本は、考えたサブシステム構成に対してシステム要件の一つひとつに対してどのような...