作業要素の進捗分析1 プロジェクト管理の仕組み (その18)

更新日

投稿日

 連載で、進捗管理に利用する基本メトリクスセット(図41)について解説を続けています。前回はソフトウェア開発における成果物メトリクスについて解説しました。ソフトウェア開発の場合、開発工程ごとに適切な成果物を選択し、それを定量的に測定することで進捗を把握することをお話ししました。また、開発工程ごとの基準モデル(図43)を作成し、それをつなぎ合わせることで見積もり精度を高くする仕組みを紹介しました。
 
R&D
図41.基本メトリックスセット
 
 今回は、基本メトリクスセットのうちの「作業要素(タスク)メトリクス」について解説します。作業要素とは、開発スケジュール上ではよく矢印で表現されている作業の一つひとつのことです。開発スケジュールが作成されていれば測定することが可能ですから比較的簡単に利用できるメトリクスですが、通常は、単にその矢印であらわされている作業一つひとつについてが遅れているかどうかを確認して、遅れている作業について個別に対応を考えるというような使い方です。また、もっとも遅れている作業を明らかにするためにイナズマ線と呼ばれる線をひいているところもよく見かけます。いずれにしても、進捗が定量化されているわけではありませんし、開発全体に対する現状の遅れの影響度合いを把握するような高度なことはできません。しかし、開発スケジュールにある情報を作業要素メトリクスの形にすることで、遅れを定量化することにより、より高度な進捗判断を可能にすることができます。ただし、いくつかの工夫が必要になりますので、ひとつずつ説明していきたいと思います。
 
R&D
図42. 管理のための二つの軸
 
R&D
図43. 基準モデルの作成方法 
 
 まず、図42 で解説したように開発スケジュールが WBS とアクティビティの2軸で表現されている必要があります。矢印で書かれている作業要素(タスク)が WBS とアクティビティの両方を特定できるようになっているということですが、そのためには、開発スケジュール上の作業要素がプロジェクト構造もしくは製品構造に合わせて分類されている必要があります。図42 ではカテゴリーと表現している部分です。たとえば、入力サブシステム、出力サブシス...
 連載で、進捗管理に利用する基本メトリクスセット(図41)について解説を続けています。前回はソフトウェア開発における成果物メトリクスについて解説しました。ソフトウェア開発の場合、開発工程ごとに適切な成果物を選択し、それを定量的に測定することで進捗を把握することをお話ししました。また、開発工程ごとの基準モデル(図43)を作成し、それをつなぎ合わせることで見積もり精度を高くする仕組みを紹介しました。
 
R&D
図41.基本メトリックスセット
 
 今回は、基本メトリクスセットのうちの「作業要素(タスク)メトリクス」について解説します。作業要素とは、開発スケジュール上ではよく矢印で表現されている作業の一つひとつのことです。開発スケジュールが作成されていれば測定することが可能ですから比較的簡単に利用できるメトリクスですが、通常は、単にその矢印であらわされている作業一つひとつについてが遅れているかどうかを確認して、遅れている作業について個別に対応を考えるというような使い方です。また、もっとも遅れている作業を明らかにするためにイナズマ線と呼ばれる線をひいているところもよく見かけます。いずれにしても、進捗が定量化されているわけではありませんし、開発全体に対する現状の遅れの影響度合いを把握するような高度なことはできません。しかし、開発スケジュールにある情報を作業要素メトリクスの形にすることで、遅れを定量化することにより、より高度な進捗判断を可能にすることができます。ただし、いくつかの工夫が必要になりますので、ひとつずつ説明していきたいと思います。
 
R&D
図42. 管理のための二つの軸
 
R&D
図43. 基準モデルの作成方法 
 
 まず、図42 で解説したように開発スケジュールが WBS とアクティビティの2軸で表現されている必要があります。矢印で書かれている作業要素(タスク)が WBS とアクティビティの両方を特定できるようになっているということですが、そのためには、開発スケジュール上の作業要素がプロジェクト構造もしくは製品構造に合わせて分類されている必要があります。図42 ではカテゴリーと表現している部分です。たとえば、入力サブシステム、出力サブシステム、画像処理エンジンサブシステムというようなカテゴリーに分かれているということです。基本的に、進捗管理の観点で管理が必要な単位に分かれているはずですが、この分類が製品構造の観点からも適切なものになっているとスムーズな進捗管理、スムーズな製品開発が可能になります。
 
 次回は、作業要素(タスク)メトリクスについて具体的に見ていきます。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
1枚の基本設計構想図法 【快年童子の豆鉄砲】(その48)

  ◆1枚の基本設計構想図法 1.商品化プロセス これ以降は「夢商品開発七つ道具」の残り6つの説明になるのですが、この6つは「プロシュ...

  ◆1枚の基本設計構想図法 1.商品化プロセス これ以降は「夢商品開発七つ道具」の残り6つの説明になるのですが、この6つは「プロシュ...


10年後のロードマップの考え方 新規事業・新商品を生み出す技術戦略(その14)

        今回は、「10年後のロードマップの考え方」について解説します。    事業や組...

        今回は、「10年後のロードマップの考え方」について解説します。    事業や組...


R&D変革できるできないの違いとは~技術企業の高収益化:実践的な技術戦略の立て方(その29)

【目次】   今回の記事では、R&Dの変革をやり遂げる会社とそうでない会社の相違点について解説します。この記事を...

【目次】   今回の記事では、R&Dの変革をやり遂げる会社とそうでない会社の相違点について解説します。この記事を...


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

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

 前回のその1に続いて解説します。   1. 政治的要因のリストアップ    設計部門と組織政治の影響を考察する際に、最初にや...

 前回のその1に続いて解説します。   1. 政治的要因のリストアップ    設計部門と組織政治の影響を考察する際に、最初にや...


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

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

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


‐企業内に発生している問題点を徹底的に追求 ‐  製品・技術開発力強化策の事例(その3)

 前回の事例その2に続いて解説します。企業内では解決が容易でない様々な問題が生じています。しかし、これらの問題解決に取り組まない限り、競争に勝つことが出来...

 前回の事例その2に続いて解説します。企業内では解決が容易でない様々な問題が生じています。しかし、これらの問題解決に取り組まない限り、競争に勝つことが出来...