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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
リーンスタートアップとは 新規事業・新商品を生み出す技術戦略(その86)

   今回は、研究開発においてリーンスタートアップを適用する際は、徹底的に仮説検証サイクルを短く設定することがポイントであることについて解...

   今回は、研究開発においてリーンスタートアップを適用する際は、徹底的に仮説検証サイクルを短く設定することがポイントであることについて解...


改革をやりきる秘訣とは~技術企業の高収益化:実践的な技術戦略の立て方(その15)

【目次】 ◆ 両利きの経営に成功する最初で最後の一手 今回は、両利きの経営に成功する最初で最後の一手とはを解説します。 &nbs...

【目次】 ◆ 両利きの経営に成功する最初で最後の一手 今回は、両利きの経営に成功する最初で最後の一手とはを解説します。 &nbs...


マクロ環境分析 普通の組織をイノベーティブにする処方箋 (その36)

        前回から市場の知識を得る方法として、マクロ環境分析の解説をしています。今回も前回に引き続き、...

        前回から市場の知識を得る方法として、マクロ環境分析の解説をしています。今回も前回に引き続き、...


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

もっと見る
ソフトウェア開発スケジュールと結合テスト プロジェクト管理の仕組み (その7)

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。    ソフトウェア開発スケジュールでは次のような問題を抱えています。 &...

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。    ソフトウェア開発スケジュールでは次のような問題を抱えています。 &...


R&Dの価値創造力を高めるシンプルツール、iMapとは、

 技術経営とは、「企業の経営資源である技術を経営戦略の中核に位置づけ、顧客価値の創造へ向けて、その獲得・強化・活用を戦略的に行うことにより、継続的な企業の...

 技術経営とは、「企業の経営資源である技術を経営戦略の中核に位置づけ、顧客価値の創造へ向けて、その獲得・強化・活用を戦略的に行うことにより、継続的な企業の...


トレーサビリティの保証 プロジェクト管理の仕組み (その43)

 前回までシステム設計について、その基本の考え方や実施方法について解説してきました。多くの組織で、システム設計は、できる人だけの作業になっており、設計の最...

 前回までシステム設計について、その基本の考え方や実施方法について解説してきました。多くの組織で、システム設計は、できる人だけの作業になっており、設計の最...