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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

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

      研究開発担当者のオープンイノベーションへの抵抗の要因として、前回のその18で解説した「組織のホメオスタシス」の他に...

      研究開発担当者のオープンイノベーションへの抵抗の要因として、前回のその18で解説した「組織のホメオスタシス」の他に...


行動の重要性 普通の組織をイノベーティブにする処方箋 (その146)

  前回まで「失敗のコストのマネジメント」を考えてきました。失敗のコストを低減して、多くの失敗をし、そこから多くを学ぼうという内容でした。...

  前回まで「失敗のコストのマネジメント」を考えてきました。失敗のコストを低減して、多くの失敗をし、そこから多くを学ぼうという内容でした。...


新入社員の技術者倫理教育とは、技術者の誠実さが未来を創る 

【目次】  ▼さらに深く学ぶなら!「技術者倫理」に関するオンデマンドセミナーはこちら! 1. 「倫理」という見えないが最...

【目次】  ▼さらに深く学ぶなら!「技術者倫理」に関するオンデマンドセミナーはこちら! 1. 「倫理」という見えないが最...


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

もっと見る
追求するのは擦り合わせ能力を活かすマネジメント(その3)

 前回のその2に続いて解説します。図15は製品開発(設計)における調整の仕組みを詳細化したものです。「可視化」「分析」「視点切り替え」3つの要素から成り立...

 前回のその2に続いて解説します。図15は製品開発(設計)における調整の仕組みを詳細化したものです。「可視化」「分析」「視点切り替え」3つの要素から成り立...


システム設計2 プロジェクト管理の仕組み (その34)

 前回でシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなこ...

 前回でシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなこ...


設計部門と組織政治の影響(その1)

 これまで数回にわたって、設計部門における仕組み構築の考え方や手順を解説してきました。仕組み構築のためのシステム化計画作成は、頂上を目指す登山ルートを設計...

 これまで数回にわたって、設計部門における仕組み構築の考え方や手順を解説してきました。仕組み構築のためのシステム化計画作成は、頂上を目指す登山ルートを設計...