この連載も早1年を超え、PMBOKでいうところのPMツールと技法については、大よそのところはカバーしたように思います。ただし、リスク・マネジメント関係は、同僚の課外授業「PMBOKドリルダウン」に譲っています。
この間、読者の皆さまからのお問合せや、PM研修の場での質問などがありましたが、今回から、その中から主なものをピックアップして説明していきたいと思います。
今日は要素分解についてです。
Q:要素分解について
| PMBOKで定義されているツールと技法「要素分解」は、スコープ・マネジメントとタイム・マネジメントの2ヵ所に定義されているが、その考え方や適用対象が理解しにくい。 | ||
| A:PMBOK2000年版では、要素分解(Decomposition)はスコープ・マネジメントの「スコープ定義プロセス」 | ||
| とタイム・マネジメントの「アクティビティ定義プロセス」で適用される技法として選定されています。ちなみにPMBOK第3版では、前者は新設された「WBS作成プロセス」に置かれています。 ここでPMBOKの該当部分をおさらいしておきましょう。 「スコープ定義」の要素分解は、プロジェクトのWBS(Work Breakdown Structure)を作成するためにすべての要素成果物(deliverables)をより小さなマネジメントしやすい構成要素に分解すること、即ち、分解の対象は要素成果物です。 例えば、システム設計書はシステム設計フェーズの要素成果物の一つですが、このシステム設計書を要素分解するとは、一例として、当設計書を構成している章 ⇒ 節 のようにより細かく分解することです。 また、プログラミング・フェーズの要素成果物の一つに(作成すべき)ソフトウェアがありますが、これを要素分解すると、機能別のプログラム ⇒ サブ・プログラム ⇒ モジュールのように分解できます。 なお、分解された要素成果物もまたそれぞれ要素成果物になります。 次に、「アクティビティ定義」の要素分解は、スコープ定義で作成されたWBSの最下層(ワーク・パッケージ)における要素成果物をさらにより小さいマネジメントしやすい要素(これをアクティビティと呼びます)に分解すること、と定義されています。 このことを図示すると次のようになります。 |
||

ちなみに、ワーク・パッケージのサイズは1〜2人週程度の工数というのがよく使われていますが、どの程度が適切なのかは、プロジェクトによって異なります。アクティビティの概念を導入した場合のワーク・パッケージのサイズは2〜4人週と少し大きめになることが多いようです。
要素分解に関連した当シリーズのバックナンバーとしてNo.2がありますので、合せてご覧ください。
| 参考文献: |
|
※PMBOKはProject Management Instituteの米国及びその他の国における登録商標です。