作業要素の進捗分析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 ではカテゴリーと表現している部分です。たとえば、入力サブシステム、出力サブシステム、画像処理エンジンサブシステムというようなカテゴリーに分かれているということです。基本的に、進捗管理の観点で管理が必要な単位に分かれているはずですが、この分類が製品構造の観点からも適切なものになっているとスムーズな進捗管理、スムーズな製品開発が可能になります。
 
 次回は、作業要素(タスク)メトリクスについて具体的に見ていきます。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
製品設計における納入仕様書の役割(その2)

  【目次】   ものづくりにおいては、顧客や協力会社、自社内の部署間において、様々な「文書」を取り交わす必...

  【目次】   ものづくりにおいては、顧客や協力会社、自社内の部署間において、様々な「文書」を取り交わす必...


アイディア創出 新規事業・新商品を生み出す技術戦略(その88)

  ◆ アイディア創出は時間と場所を選ぶ  みなさんは新しいビジネスや開発テーマのアイディアを出す時、どんなことに気を付けていますか?私...

  ◆ アイディア創出は時間と場所を選ぶ  みなさんは新しいビジネスや開発テーマのアイディアを出す時、どんなことに気を付けていますか?私...


激変を予測するとは 普通の組織をイノベーティブにする処方箋 (その66)

 今回も、ここまでと同様、「思い付く」ための「知識・経験を整理するフレームワーク」の中の、知識・経験を時系列で整理する「期」ついて議論をします。 ◆...

 今回も、ここまでと同様、「思い付く」ための「知識・経験を整理するフレームワーク」の中の、知識・経験を時系列で整理する「期」ついて議論をします。 ◆...


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

もっと見る
技術資源の有効活用: 事例紹介 (その1)

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...


設計部門の仕組み改革(その1)

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...


仕組みの見直しに成功する組織2 プロジェクト管理の仕組み (その26)

 前回の仕組みの見直しに成功する組織1に続いて解説します。    仕組みの見直しに成功する組織の考察ですが、今回は、マネジメントのコミットメ...

 前回の仕組みの見直しに成功する組織1に続いて解説します。    仕組みの見直しに成功する組織の考察ですが、今回は、マネジメントのコミットメ...