PMBOKでWBSの意味を理解すると実務で役立つ
プロジェクトとは、プロダクトを作成するために必要な作業であると説明しました。そしてその全作業を記載したものが、プロジェクト・スコープ記述書です。
PMBOKでは、プロジェクト・スコープ記述書に記載された内容は「粗いもの」だという前提です。「ハイレベル」という意味ですね。
そこからさらに、管理できるレベルまで、階層的に詳細化していきます。それは、WBSを作成することです。
WBSとは？
WBSの定義
プロジェクトを遂行していく上で、WBSを使っていないプロジェクトに携わったことがある方はいますか？
管理人は、いないと思っています。それくらい浸透した概念です。
WBSとは「Work Breakdown Structure」の略です。ダブリュー・ビー・エスと呼んでいます。
さてWBSですが、PMBOKのプロジェクト・スコープ・マネジメント知識エリアに「WBSの作成」というプロセスがあります。（第6版が対象です）
そのプロセス定義の説明は、次の通りです。
- プロジェクトの成果物や作業をより細かくわかりやすい構成要素に分解すること
WBSのイメージ
WBSのイメージですが、下図のように考えてみます。
WBSはどのようにして作るのか？
PMBOKでは、WBS作成までにいくつかのプロセスを踏む手順で説明しています。
もともと粗い要件のかたまりである「要求事項文書」から、今回のプロジェクトの作成対象を「プロジェクト・スコープ記述書」に記載します。
要求事項文書に記載された内容がすべて「プロジェクト・スコープ記述書」に記載するわけではないことに注意していください。
上図WBSのイメージでも、要求事項文書とプロジェクト・スコープ記述書は一致していないことを表しています。
WBSは、「プロジェクト・スコープ記述書を、管理できるレベルまで分解してく」という、イメージを持ってもらえればよいかと思います。
作業をより細かく
プロジェクト・スコープ記述書は、作業の大見出しを書いたレベルです。しかし実務では、このような名称の資料は使っていないかもしれません。
見積を作成するときの、ざっくりとした作業一覧のようなものをイメージしてもらえればと思います。
それを詳細化していきます。
わかりやすい構成要素に分解する
たとえば設計作業という作業があれば、それを概要設計・詳細設計にわけ、さらに概要設計を画面設計・帳票設計にわけていく、ということです。
この作業項目を構成要素に分解してく方法も、各社によって違いますよね。
WBSの構成要素を表現する方法は、作業を分解していくことです。ただし管理できるレベルであることという条件です。
管理できるレベルが条件
PMBOK上で一貫している思想として、「計測できること」、「検証できること」をあげています。要は「管理できること」ということです。
成果物や作業を「管理できるレベルまで分解していく」ことが、WBS作成の目的です。
管理できる最小の単位を「ワーク・パッケージ」と呼んでいます。この呼び名は、実務で使ったことはありません。
段階的詳細化
「WBSの作成」プロセスは、計画段階で作成しています。
そのため未確定事項に関しては、作成時点ではわかりません。作成時点では粗いままの状態にしておき、内容が確定した時点で、WBSに落とすということをします。
作成時点ですべて先のことを見通すことは難しいからです。PMBOKの考え方のひとつです。
しかし段階的詳細化も程度によります。未決定事項が多い場合、粗いままのWBSとなってしまいがちです。
そうすると必要な作業やリソースを見積りできぬまま、プロジェクトが動き出してしまい、結果予想外にコストがかかったり、日数がかかったりと困ったことが発生します。
便利な考え方なのですが、使い方を間違えないように注意が必要です。
実務ではどうか？
ながながと、WBSの作り方を書いてきましたが、実際には、会社で用意されている標準WBSを使用している方が多いでしょう。というより使うことが義務付けられていたりします。
標準WBSの存在
プロジェクトの独自性は考えなければなりませんが、似たような開発手法の場合、ある程度の作業は標準化できるものです。
これは母体組織で準備している「標準WBS」のことを表しています。組織のプロセス資産として蓄積されているものですね。
あとは、この標準WBSに各プロジェクトの独自性を味付けしていけば、おおむねプロジェクト独自のWBSを完成できます。
標準WBSを大いに活用する
せっかくの組織のプロセス資産である、標準WBSがあるのだから大いに活用してください。メリットは次の通りです。
- WBS項目の抜け・モレを防ぐため
- WBSの品質均一化のため
とはいえPMP試験の学習をしているならば、その作成された背景にも目を向けてください。
先人たちの知恵が詰まっている
標準WBSは、先人たちの知恵が詰まっているものです。過去の成功事例などをもとに、編纂されてきた経緯があります。
できれば、成り立ちや背景、なぜこのような作業をしなければならないのかなど、一つひとつの項目に疑問を持って読んでみてほしいと思います。
そしてPMBOKから学んだWBSの概念と結びつけてみてください。
相乗効果が得られる
そうすれば「PMBOKの知識＋組織のナレッジ」が相乗効果となり、さらにみなさんの血肉になっていきます。
WBSを作成したあと
さてWBSを作成することで、スコープ・ベースラインが完成します。正確には、ステークホルダーの承認を受けたあとです。
まとめ
WBSに関する疑問は多いと思いますが、まずは、所属する組織で定義している標準版を理解することが大切です。
学問的にWBSの構成や作業項目を学ぶことは重要ですよ。知ることで、母体組織の標準WBSの内容を深く理解できます。
情報処理技術者試験でもプロジェクトマネージャ試験以外は、WBSの一部分しか試験対象になりません。一番広いと思われるのは、システムアーキテクトでしょう。
しかしプロジェクトマネージャは違います。プロジェクトで作成する成果物に責任を持たなければなりません。システク構築プロジェクトであれば、すべてのWBS項目を管理します。
そのためプロジェクトマネージャは、WBSを作成できる技量が必要です。すべては難しくても、担当が作成してきたWBSの内容を理解・指摘できる技量は必要でしょう。