HOME > PMウェブ・サービス > PM課外授業 > PM Tools A to Z-Q&A「要素分解」
PM雑記帳

■PM Tools A to Z_No.28
  Q&A「要素分解」

2005.07.13

この連載も早1年を超え、PMBOKでいうところのPMツールと技法については、大よそのところはカバーしたように思います。ただし、リスク・マネジメント関係は、同僚の課外授業「PMBOKドリルダウン」に譲っています。
この間、読者の皆さまからのお問合せや、PM研修の場での質問などがありましたが、今回から、その中から主なものをピックアップして説明していきたいと思います。
今日は要素分解についてです。

Q:要素分解について

PMBOKで定義されているツールと技法「要素分解」は、スコープ・マネジメントとタイム・マネジメントの2ヵ所に定義されているが、その考え方や適用対象が理解しにくい。

A:PMBOK2000年版では、要素分解(Decomposition)はスコープ・マネジメントの「スコープ定義プロセス」
とタイム・マネジメントの「アクティビティ定義プロセス」で適用される技法として選定されています。ちなみにPMBOK第3版では、前者は新設された「WBS作成プロセス」に置かれています。
ここでPMBOKの該当部分をおさらいしておきましょう。

「スコープ定義」の要素分解は、プロジェクトのWBS(Work Breakdown Structure)を作成するためにすべての要素成果物(deliverables)をより小さなマネジメントしやすい構成要素に分解すること、即ち、分解の対象は要素成果物です。
例えば、システム設計書はシステム設計フェーズの要素成果物の一つですが、このシステム設計書を要素分解するとは、一例として、当設計書を構成している章 ⇒ 節  のようにより細かく分解することです。
また、プログラミング・フェーズの要素成果物の一つに(作成すべき)ソフトウェアがありますが、これを要素分解すると、機能別のプログラム ⇒ サブ・プログラム ⇒ モジュールのように分解できます。
なお、分解された要素成果物もまたそれぞれ要素成果物になります。

次に、「アクティビティ定義」の要素分解は、スコープ定義で作成されたWBSの最下層(ワーク・パッケージ)における要素成果物をさらにより小さいマネジメントしやすい要素(これをアクティビティと呼びます)に分解すること、と定義されています。
例えば、上例で示したモジュールがWBSにおけるワーク・パッケージだとすると、そのモジュールを更にアクティビティに分解するとは、モジュール設計書作成、モジュール設計書レビュー、モジュール・テスト仕様書作成、モジュール製作、モジュール・テスト、テスト結果レビューのように作業レベルに分解することです。

このことを図示すると次のようになります。


現実には、WBSの各階層特にワーク・パッケージのレベルにおいて、作業要素も盛り込んで分解してしまうことは、よく行われます。これは、要素成果物を分解の対象にするということが、その要素成果物を作成する作業を分解するとも言えるからで、要素成果物とそれを作る作業とは表裏一体のものだからです。
PMBOKでは要素分解の対象(要素成果物とワーク・パッケージ)により、それを規定するマネジメント・エリア(スコープとタイム)が異なるために不連続の活動のように見えますが、現実にはこれらは連続して行われる活動として違和感はありません。
なお、PMの書籍によっては、ワーク・パッケージのレベルをアクティビティ的に扱っているものもあります。

ちなみに、ワーク・パッケージのサイズは1〜2人週程度の工数というのがよく使われていますが、どの程度が適切なのかは、プロジェクトによって異なります。アクティビティの概念を導入した場合のワーク・パッケージのサイズは2〜4人週と少し大きめになることが多いようです。

要素分解に関連した当シリーズのバックナンバーとしてNo.2がありますので、合せてご覧ください。


参考文献:
  1. PMBOK(R) ガイド2000年版 PMI
  2. PMBOK(R) ガイド第3版 PMI

※PMBOKはProject Management Instituteの米国及びその他の国における登録商標です。