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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
クレーム率シングルppmをゼロに(9) 【快年童子の豆鉄砲】(その64)

  【連関図法で把握した原因に対する対策のまとめ】 【この連載の前回:【快年童子の豆鉄砲】(その63)へのリンク】 【連載記事】・新Q...

  【連関図法で把握した原因に対する対策のまとめ】 【この連載の前回:【快年童子の豆鉄砲】(その63)へのリンク】 【連載記事】・新Q...


未来志向でコア技術を設定する 普通の組織をイノベーティブにする処方箋 (その28)

 そろそろ自社の技術ではなく、社外の技術の収集の議論に移りたいのですが、私のところで起こったある出来事で、『未来志向でコア技術を設定する』ことを強調してお...

 そろそろ自社の技術ではなく、社外の技術の収集の議論に移りたいのですが、私のところで起こったある出来事で、『未来志向でコア技術を設定する』ことを強調してお...


イノベーションの発想 普通の組織をイノベーティブにする処方箋 (その120)

  前回までに「整理するフレームワークで整理・構造化した知識の中で焦点を当てる重要部分を切り取る」を解説しました。今回からは、「発想のフレ...

  前回までに「整理するフレームワークで整理・構造化した知識の中で焦点を当てる重要部分を切り取る」を解説しました。今回からは、「発想のフレ...


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

もっと見る
設計部門の課題と原因分析(その3)

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...


進捗の見える化:第2回 プロジェクト管理の仕組み (その11)

 進捗の見える化ですが、前回のその10に続いて解説します。今回考えるべきポイントは、可視化・見える化の方法です。図40 に示しているように、進捗管理では予...

 進捗の見える化ですが、前回のその10に続いて解説します。今回考えるべきポイントは、可視化・見える化の方法です。図40 に示しているように、進捗管理では予...


スケールド・アジャイル・フレームワーク (SAFe) の導入開始

        はたして僕が勤める企業はスケールド・アジャイル・フレームワーク (SAFe) を上手く導入で...

        はたして僕が勤める企業はスケールド・アジャイル・フレームワーク (SAFe) を上手く導入で...