開発工数メトリクス1 プロジェクト管理の仕組み (その21)

更新日

投稿日

 前回のプロジェクト管理の仕組み (その20)に続いて解説します。
 
 進捗管理のための基本メトリクスセットについての解説を続けています。基本メトリクスセットの目的は、プロジェクトに対するインプットとアウトプットを計測することによりプロジェクトの状況(進捗)を把握することで、それをできるだけ少ないメトリクスで実現しています。前回まではプロジェクトのアウトプットであるメトリクスについてでしたが、今回はインプットである開発工数メトリクスについて解説します。
 
 製品開発プロジェクトのインプット(リソースという言い方もできます)にはいろいろなものがありますが、その中でも、ヒト、すなわち、プロジェクトメンバーが最も重要なインプット(リソース)であることは間違いないと思います。開発工数メトリクスとは、この最重要リソースであるプロジェクトメンバーがどのようなことに時間を使っているのかを計測することにより、メンバーの振る舞いを「見える化」するためのものです。
 
 開発工数メトリクスも、基本メトリクスセットの他のメトリクス同様、プロジェクト構造(WBS)軸とアクティビティ軸の2軸で値を特定できるように収集します。を付加すること就業時間管理のために何らかの工数収集をやっているところも多いと思いますが、この既存の仕組みにプロジェクト構造軸とアクティビティ軸の情報ができれば、比較的簡単に工数収集の仕組みを整えることができます。
 
 また、Excel を使って工数収集する仕組みを運用している組織もよく見かけます。専用ツールを開発して運用しているところも少なくありません。このように、何らかの形で工数収集ツールを運用しているところは多いのですが、ほとんどの組織で共通の課題を抱えています。それは、入力が継続しないことや、入力率が上がらないという課題です。これは、ツールの使い勝手が悪いことが原因であることも多いのですが、入力したデータを活用できていないためにメンバーが入力する意味を感じなくなるということも主な原因となっています。今回は、このような課題を避けるためにも、工数メトリクスでどのようなことがわかるのかを実例を使いながら解説したいと思います。最初に、プロジェクト構造軸とアクティビティ軸とで開発工数の時間推移をグラフにした例を紹介しましょう。図54がプロジェクト構造別の工数推移、図55がアクティビティ別の工数推移です。
 
開発工数
図54. プロジェクト構造軸 工数推移
 
開発工数
図55. アクティビティ軸 工数推移
 
 このプロジェクトは、大きくベースバンド(BB)、ネットワーク(Network)、プラットフォーム(Platform)、無線(RF)、ソフトウェア(SW)、機構(ME)、システム(System)という7つのブロックに分かれて開発を進めており、図54を見ると、機構(ME)ブロックが最も早く開発に着手していることがわかります。また、システム (System) というアーキテクチャ設計など製品全体を担当しているブロックが継続的に全体の3~4割の大きな工数割合になっていることがわかります。このことから、この製品開発は機構面の新規開発要素を持ち、全体のアーキテクチャ設計が重要であると分析できます。そして、この分析が実際は違うということになれば、プロジェクトの進め方に問題がある可能性が高いことになります。
 
 また、図55を見ると、開発の最初から基本設計に入ってしまいシステム設計が後回しになっていることがわかります。先ほどの図54と合わせて考えると、機構ブロックがシステム設計を待たずに基本設計を行っていると想像できますが、機構ブロックのアクティビティ別工数推移グラフを見ればそれが正しいことが確認できます(グラフは掲載しませんが実際そうでした)。したがって、システム設計の...
 前回のプロジェクト管理の仕組み (その20)に続いて解説します。
 
 進捗管理のための基本メトリクスセットについての解説を続けています。基本メトリクスセットの目的は、プロジェクトに対するインプットとアウトプットを計測することによりプロジェクトの状況(進捗)を把握することで、それをできるだけ少ないメトリクスで実現しています。前回まではプロジェクトのアウトプットであるメトリクスについてでしたが、今回はインプットである開発工数メトリクスについて解説します。
 
 製品開発プロジェクトのインプット(リソースという言い方もできます)にはいろいろなものがありますが、その中でも、ヒト、すなわち、プロジェクトメンバーが最も重要なインプット(リソース)であることは間違いないと思います。開発工数メトリクスとは、この最重要リソースであるプロジェクトメンバーがどのようなことに時間を使っているのかを計測することにより、メンバーの振る舞いを「見える化」するためのものです。
 
 開発工数メトリクスも、基本メトリクスセットの他のメトリクス同様、プロジェクト構造(WBS)軸とアクティビティ軸の2軸で値を特定できるように収集します。を付加すること就業時間管理のために何らかの工数収集をやっているところも多いと思いますが、この既存の仕組みにプロジェクト構造軸とアクティビティ軸の情報ができれば、比較的簡単に工数収集の仕組みを整えることができます。
 
 また、Excel を使って工数収集する仕組みを運用している組織もよく見かけます。専用ツールを開発して運用しているところも少なくありません。このように、何らかの形で工数収集ツールを運用しているところは多いのですが、ほとんどの組織で共通の課題を抱えています。それは、入力が継続しないことや、入力率が上がらないという課題です。これは、ツールの使い勝手が悪いことが原因であることも多いのですが、入力したデータを活用できていないためにメンバーが入力する意味を感じなくなるということも主な原因となっています。今回は、このような課題を避けるためにも、工数メトリクスでどのようなことがわかるのかを実例を使いながら解説したいと思います。最初に、プロジェクト構造軸とアクティビティ軸とで開発工数の時間推移をグラフにした例を紹介しましょう。図54がプロジェクト構造別の工数推移、図55がアクティビティ別の工数推移です。
 
開発工数
図54. プロジェクト構造軸 工数推移
 
開発工数
図55. アクティビティ軸 工数推移
 
 このプロジェクトは、大きくベースバンド(BB)、ネットワーク(Network)、プラットフォーム(Platform)、無線(RF)、ソフトウェア(SW)、機構(ME)、システム(System)という7つのブロックに分かれて開発を進めており、図54を見ると、機構(ME)ブロックが最も早く開発に着手していることがわかります。また、システム (System) というアーキテクチャ設計など製品全体を担当しているブロックが継続的に全体の3~4割の大きな工数割合になっていることがわかります。このことから、この製品開発は機構面の新規開発要素を持ち、全体のアーキテクチャ設計が重要であると分析できます。そして、この分析が実際は違うということになれば、プロジェクトの進め方に問題がある可能性が高いことになります。
 
 また、図55を見ると、開発の最初から基本設計に入ってしまいシステム設計が後回しになっていることがわかります。先ほどの図54と合わせて考えると、機構ブロックがシステム設計を待たずに基本設計を行っていると想像できますが、機構ブロックのアクティビティ別工数推移グラフを見ればそれが正しいことが確認できます(グラフは掲載しませんが実際そうでした)。したがって、システム設計の結果次第では手戻りになる可能性が高く、機構ブロックの仕事に進め方には問題があると判断できます。さらに、グラフからは、基本設計や詳細設計、そして、システムテストまでもがシステム設計と並行して実施されていることがわかります。設計重視とは反対の、作ってみて動作確認するという開発スタイルになっていると考えられます。
 
 単純に基本メトリクスセットの基本である2軸で開発工数メトリクスを見るだけでも、プロジェクトの状況を客観的に把握できることがわかっていただけたと思います。開発工数メトリクスはプロジェクトメンバーの振る舞い、すなわち、メンバーが何をやっているのかを知ることができる指標であり、それを積み上げたものがプロジェクトの振る舞いをあらわしているのです。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
『価値づくり』の研究開発マネジメント (その14)

    今回も、前回から引き続きオープンイノベーションの経済学の5つ目、「オープンイノベーションによる研究開発に関わる固定費の変動費化」...

    今回も、前回から引き続きオープンイノベーションの経済学の5つ目、「オープンイノベーションによる研究開発に関わる固定費の変動費化」...


設計の信頼性・安全性を考える

 設計のしくみ確立と設計品質作り込み法として、今回は、設計ミスと信頼性・安全性について考えてみます。新製品を開発する場合、お客様の要求を理解して、デザイン...

 設計のしくみ確立と設計品質作り込み法として、今回は、設計ミスと信頼性・安全性について考えてみます。新製品を開発する場合、お客様の要求を理解して、デザイン...


QNP法1 【快年童子の豆鉄砲】(その53)

  ◆QNP(Quality table-Neck engineering-PDPC)法 1.QNP法 「夢商品開発七つ道具(Y7)」...

  ◆QNP(Quality table-Neck engineering-PDPC)法 1.QNP法 「夢商品開発七つ道具(Y7)」...


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

もっと見る
コアコンピタンスを生かした開発と販売の発展とは

        今回は、次のような想定企業の状況で、自社の独自技術を生かした製品開発と販売方法について解説します。   1. 想定企業の経営状況...

        今回は、次のような想定企業の状況で、自社の独自技術を生かした製品開発と販売方法について解説します。   1. 想定企業の経営状況...


設計部門の仕組み構築(その1)

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...


高齢化社会の「アンメットニーズ」ー米国3M社の事例

 技術から事業価値への転換こそが、成長戦略成功の鍵と言われて久しい。しかし今年に入っても設備投資に踏み切る企業が多いとは言えないのは、稼げる事業テーマや新...

 技術から事業価値への転換こそが、成長戦略成功の鍵と言われて久しい。しかし今年に入っても設備投資に踏み切る企業が多いとは言えないのは、稼げる事業テーマや新...