工数メトリクス メトリクス管理手法(その4)

更新日

投稿日

【メトリクス管理 連載目次】

 

1. 管理できる指標に加工する

 
 基本メトリクスセットの工数メトリクスについて、その詳細を紹介したいと思います。
 
  メトリクス
 
 メトリクスで大切なのが、プロジェクトの関係者、とくに、管理する責任を持った人にわかりやすい形に加工するということでした。これについて例を使って考えてみたいと思います。
 
 工数(時間)をデータとして収集したものは右図のような形になります。これは、ある製品開発プロジェクトのデータで、誰が、どのプロジェクトの、どのユニットの、どういう開発工程に、いつ、どれだけの工数(時間)をかけたのかというデータです。
 
 これは、単なる「データ」です。プロジェクトの状況はわかりません。
 
 メトリクス
 
 これを、開発工程ごとに集計して、その時間の推移がわかるように加工するとどうでしょうか。しっかり見ると、プロジェクトの状況がわかるようになりました。たとえば、システム設計は早い時期の終わらせなくてはいけないのに、その後工程である基本設計よりも後でやっていることなどが読み取れます。さらに、これを次のようなグラフにすれば、状況を理解することは格段に簡単になります。
 
 メトリクス
   
 このように理解できる形になったものがメトリクスです。理解できる形になっていなければ進捗管理など、プロジェクトのコントロールに使うことは無理だということがわかります。もう一つ、大切なことがあります。
 
 データではなくメトリクスにするためには、プロジェクトをどのようにしてコントロールするのかを明確にしておく必要があるということです。ここが明確になっていなければ、手間暇かけてやみくもにデータを収集し、そのデータの中でおぼれてしまって有効な情報を取り出せないということになってしまいます。プロジェクトに対してどのようなコントロールをするのか、そのためにはどんなメトリクスが必要なのか、そして、そのメトリクスのためにはどういうデータを収集しなければならないのかが決まります。
 

2. 工数メトリクスで振る舞いを把握する

 
 では、工数メトリクスを使ったプロジェクト管理の例をいくつか紹介しましょう。
 
 まず、先ほどの開発工程別工数(時間)のグラフについてもう少し解説します。製品開発の場合、うまくコントロールするために守らなければならない作業の流れ(工程)があります。理想的には、このグラフの凡例に示している工程を下から順々にやっていくのがいいのですが、開発現場ではいろいろなことが起こりますから、そう単純にはいきません。それでも、たとえば次のことを守るのは大切です。
 
  • ルール1:最初に「構想」にじっくりと時間をかける
  • ルール2:「システム設計」は「基本設計」の前に実施しておく
  • ルール3:「単体テスト」は「システムテスト」の前に実施しておく
 
 工数メトリクスを使うとこれらのルールが守られているかどうかを把握できます。実際、次のようにルールが守られていません。
 
  • 「構想」を開発がはじまってしばらくしてから実施している
  • 「システム設計」は開発が終わるまでずっとやっている
  • 「単体テスト」は「システムテスト」と並行してやっている
 
 先ほどのルールは守るべき最低限のレベルなので、ルール通りにできていないのは、プロジェクトがうまく管理できていないということになります。予期せぬトラブルや遅れにつながる可能性が非常に高くなります。後の祭りにならないように、プロジェクトの責任者は工数メトリクスを見ながら、早め早めに対策を打つことが大切です。グラフでは開発の最後までの工数(時間)を表示していますが、開発の途中でも先ほどのことは確認は可能ですよね。
 
 では、同じプロジェクトですが、ユニット別工数(時間)推移を見てみましょう。
 
 メトリクス
 
 工数(時間)の合計値はもちろん同じです。ただ、凡例に示しているようにユニット別になっているところが先ほどのグラフとは違うところです。このプロジェクトは、ベースバンド(BB)、ネットワーク(Network)、プラットフォーム(Platform)、無線(RF)、ソフトウェア(SW)、機構(ME)、システム(System)という7つのユニットに分かれて開発を進めています。どんな製品なのか、それぞれのユニットはどういうものなのかを想像できる人もいるかと思いますが、そうでなくても気にしないでください。
 
 このプロジェクトで進捗管理の上で大切なのは、次のことでした。
 
  1. 機構(ME)が新しい仕組みなので早期に実現性検証をやる
  2. 全体を担当しているシステム(System)チームは開発前半で作業を完了させる
 
 グラフを見ると、機構(ME)は確かに、他のユニットよりも早く前倒しで工数(時間)が発生しているので、うまく作業が進んでいるようです。しかし、システム(System)は開発後半になっても工数(時間)が収束していません。遅くても 11月には工数(時...

【メトリクス管理 連載目次】

 

1. 管理できる指標に加工する

 
 基本メトリクスセットの工数メトリクスについて、その詳細を紹介したいと思います。
 
  メトリクス
 
 メトリクスで大切なのが、プロジェクトの関係者、とくに、管理する責任を持った人にわかりやすい形に加工するということでした。これについて例を使って考えてみたいと思います。
 
 工数(時間)をデータとして収集したものは右図のような形になります。これは、ある製品開発プロジェクトのデータで、誰が、どのプロジェクトの、どのユニットの、どういう開発工程に、いつ、どれだけの工数(時間)をかけたのかというデータです。
 
 これは、単なる「データ」です。プロジェクトの状況はわかりません。
 
 メトリクス
 
 これを、開発工程ごとに集計して、その時間の推移がわかるように加工するとどうでしょうか。しっかり見ると、プロジェクトの状況がわかるようになりました。たとえば、システム設計は早い時期の終わらせなくてはいけないのに、その後工程である基本設計よりも後でやっていることなどが読み取れます。さらに、これを次のようなグラフにすれば、状況を理解することは格段に簡単になります。
 
 メトリクス
   
 このように理解できる形になったものがメトリクスです。理解できる形になっていなければ進捗管理など、プロジェクトのコントロールに使うことは無理だということがわかります。もう一つ、大切なことがあります。
 
 データではなくメトリクスにするためには、プロジェクトをどのようにしてコントロールするのかを明確にしておく必要があるということです。ここが明確になっていなければ、手間暇かけてやみくもにデータを収集し、そのデータの中でおぼれてしまって有効な情報を取り出せないということになってしまいます。プロジェクトに対してどのようなコントロールをするのか、そのためにはどんなメトリクスが必要なのか、そして、そのメトリクスのためにはどういうデータを収集しなければならないのかが決まります。
 

2. 工数メトリクスで振る舞いを把握する

 
 では、工数メトリクスを使ったプロジェクト管理の例をいくつか紹介しましょう。
 
 まず、先ほどの開発工程別工数(時間)のグラフについてもう少し解説します。製品開発の場合、うまくコントロールするために守らなければならない作業の流れ(工程)があります。理想的には、このグラフの凡例に示している工程を下から順々にやっていくのがいいのですが、開発現場ではいろいろなことが起こりますから、そう単純にはいきません。それでも、たとえば次のことを守るのは大切です。
 
  • ルール1:最初に「構想」にじっくりと時間をかける
  • ルール2:「システム設計」は「基本設計」の前に実施しておく
  • ルール3:「単体テスト」は「システムテスト」の前に実施しておく
 
 工数メトリクスを使うとこれらのルールが守られているかどうかを把握できます。実際、次のようにルールが守られていません。
 
  • 「構想」を開発がはじまってしばらくしてから実施している
  • 「システム設計」は開発が終わるまでずっとやっている
  • 「単体テスト」は「システムテスト」と並行してやっている
 
 先ほどのルールは守るべき最低限のレベルなので、ルール通りにできていないのは、プロジェクトがうまく管理できていないということになります。予期せぬトラブルや遅れにつながる可能性が非常に高くなります。後の祭りにならないように、プロジェクトの責任者は工数メトリクスを見ながら、早め早めに対策を打つことが大切です。グラフでは開発の最後までの工数(時間)を表示していますが、開発の途中でも先ほどのことは確認は可能ですよね。
 
 では、同じプロジェクトですが、ユニット別工数(時間)推移を見てみましょう。
 
 メトリクス
 
 工数(時間)の合計値はもちろん同じです。ただ、凡例に示しているようにユニット別になっているところが先ほどのグラフとは違うところです。このプロジェクトは、ベースバンド(BB)、ネットワーク(Network)、プラットフォーム(Platform)、無線(RF)、ソフトウェア(SW)、機構(ME)、システム(System)という7つのユニットに分かれて開発を進めています。どんな製品なのか、それぞれのユニットはどういうものなのかを想像できる人もいるかと思いますが、そうでなくても気にしないでください。
 
 このプロジェクトで進捗管理の上で大切なのは、次のことでした。
 
  1. 機構(ME)が新しい仕組みなので早期に実現性検証をやる
  2. 全体を担当しているシステム(System)チームは開発前半で作業を完了させる
 
 グラフを見ると、機構(ME)は確かに、他のユニットよりも早く前倒しで工数(時間)が発生しているので、うまく作業が進んでいるようです。しかし、システム(System)は開発後半になっても工数(時間)が収束していません。遅くても 11月には工数(時間)が収束しない原因を明らかにして対策を打っておくべきだったといえるでしょう。
 
 この2つの例から気がつくことはありませんか? 気づいた人は「メトリクス管理の手法」をしっかり読んでいただいた方ですね。そうです、この2つはアクティビティとプロダクトの2軸管理の実例になっています。
 
 アクティビティ軸というのは作業工程という視点で見ること、プロダクト軸というのは製品の構造のようにできあがるものの構造という視点で見ることでした。この2軸を使ってプロジェクトの進捗を見る(コントロールする)とプロジェクトの状態を把握しやすいことがわかっていただけたのではないでしょうか。
 
 このように、工数メトリクスはプロジェクトのメンバーや、ユニットを担当しているチームが、どのような作業をやっているのか、その振る舞いを把握するための有力な手段です。ぜひ、工数メトリクスを使うことを検討してください。
 
 次回は、ソフトウェアメトリクスの解説です。
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


「プロジェクトマネジメント一般」の他のキーワード解説記事

もっと見る
PDCA-TC法 【快年童子の豆鉄砲】(その49)

  ◆PDCA-TC法 1.PDCA-TC(Tracing Chart)法 夢商品の開発・商品化は、開発したい商品が極めて新規性が高い...

  ◆PDCA-TC法 1.PDCA-TC(Tracing Chart)法 夢商品の開発・商品化は、開発したい商品が極めて新規性が高い...


プロジェクト管理:プロジェクトを可視化する重要性(その2)

 前回のその1に続いて解説します。 ◆関連解説『プロジェクトマネジメントとは』   2.可視化で浮かび上がる問題    プロ...

 前回のその1に続いて解説します。 ◆関連解説『プロジェクトマネジメントとは』   2.可視化で浮かび上がる問題    プロ...


基準モデルはどこにも必ずある成功パターン(実践的メトリクス管理その7)

  【必要最小限の手間で行う開発の見える化 連載目次】 1、必要最小限の手間で行う開発の見える化 2、工数メトリクスでわかるプロジェク...

  【必要最小限の手間で行う開発の見える化 連載目次】 1、必要最小限の手間で行う開発の見える化 2、工数メトリクスでわかるプロジェク...


「プロジェクトマネジメント一般」の活用事例

もっと見る
コンパクト物流センターとしての薬局を考える(その1)

 「日本の高齢化社会をこのように活用すれば、新しいビジネスチャンスはある」と申し上げたいので、この連載はコンサルタントから見た、「高齢化社会になった今、見...

 「日本の高齢化社会をこのように活用すれば、新しいビジネスチャンスはある」と申し上げたいので、この連載はコンサルタントから見た、「高齢化社会になった今、見...


中小規模組織でのプロジェクト管理システムの課題(その1)

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...


中小規模組織でのプロジェクト管理システムの課題(その2)

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...