プロジェクト計画の中核を成すWBSは,プロジェクトで実施すべき作業を階層構造で規定する。そこには,成果物の作成作業と,成果物では表せないマネジメントに関する作業が含まれる。WBSに不備があると,プロジェクトで実施すべき作業の抜け・漏れや,各計画要素間の不整合という事態を招く。また,開発規模とベースライン(予実績を把握するために設定する計画値や予定値のこと)が不整合となったり,作業の実施責任者が不明確になったりといった問題も生じる。WBSを正しく作成することは,こうした問題を発生させなくする重要な作業である。

PMOの視点で確認

図1●WBSの良しあしを見抜く10のチェックポイント
図1●WBSの良しあしを見抜く10のチェックポイント
[画像のクリックで拡大表示]

 WBSを作成する目的は,大きく四つある。すなわち「作業の網羅」「計画値の整合性確保」「管理指標の提供」「担当者の明確化」である(詳しく別掲記事を参照)。これらの目的に照らした上で,作成したWBSをチェックする。思い込みや楽観的な予測を排除するには,作成者以外の視点が不可欠だ。

 そこで,PMO(Project Management Office)で数々のWBSを審査してきた筆者の経験に基づいて,WBSの良しあしを見抜く10のポイントを説明する(図1)。WBSそのもののチェックポイントと,WBSとほかの資料との整合性を確認するチェックポイントがある。これらは作成したWBSに対するレビューの視点で,プロジェクト規模の大小にかかわらず,すべてのプロジェクト・マネージャが押さえておくべき項目である。読者が作成したWBSのセルフチェックに役立ててほしい。

 以下では,10のポイントを順番に説明する。

(1)成果物ベースになっているか
 WBSを成果物ベースで作成することは,作業の抜け・漏れをなくす上で,筆者が最も重視するポイントだ。

 人が何かを作成する場合,頭の中でいくつかの作業手順を考える。しかし,これでは必要な成果物に抜け・漏れが出る可能性がある。大事なのは,各ステップで作成する成果物をまずイメージし,それを基点に必要な作業と手順を考えることだ。ハンドメイド家具やプラモデルの説明書と同じである。説明書には,ステップ別の完成イメージと,必要なパーツの種類や構造が書かれていることが多い。作業の手順ばかりで完成イメージのない説明書では「使わなかったパーツがあった」なんてことがあり得る。

 成果物ベースになっているかどうかは,必要な成果物の名称がWBSに明記されているか,それらが階層構造になっているか,などで確認できる。

(2)スコープを網羅しているか
 次は,スコープを網羅しているかである。スコープには「何を作るか」の範囲を示したプロダクト・スコープと,「どう作るか」の範囲を示したプロジェクト・スコープがある。プロダクト・スコープとは,(1)成果物ベースと置き換えていい。

 WBSではプロダクト・スコープを明確にした上で,プロジェクト・スコープを規定する。だが,プロダクト・スコープを網羅していても,プロジェクト・スコープを網羅できていないケースが目立つ。

 プロジェクト・スコープには,成果物を伴わないレビューなどの作業を規定する必要がある。そのためWBSの審査では,プロジェクトで開発するシステムや業務機能はもちろん,プロジェクトの目標を達成するための管理作業(レビュー,計画の見直しなど)をスコープとして過不足なく定義しているかどうかを確認しなければならない。

(3)段階的に詳細化しているか
 WBSは,一度作って終わりではない。プロジェクトが進むにつれて,さまざまなことが分かってくる。そうした状況に応じて,WBSを段階的に詳細化することが大切だ。

 このチェックは1回のレビューでは判別できない。工程を進める途中で複数回チェックすることで,詳細化されていることを確認する。例えば,提案時,プロジェクト開始時,工程開始時といったタイミングでWBSをチェックし,だんだんと詳細化されていることを確認する。

(4)詳細な開発工程を意識しているか
 WBSの作成で意外と軽視されるのが,詳細な開発工程の定義である。ここでいう詳細な開発工程とは,要件定義,基本設計,詳細設計といった一般的な開発工程よりもさらに細分化したものである。そのようなレベルの開発工程になると,パッケージ・ソフトの適用やインフラの再構築など,プロジェクトの特性によって大きく変わる。WBSのレビューでは,プロジェクトの特性をきちんと理解した上で,詳細な開発工程を正しく定義していることを確認する。

(5)下位が上位を構成しているか
 WBSは階層構造を成しているので,下位の成果物がすべてそろうと上位の成果物が完成するはずだ。これはWBSの基本的な特徴の一つであるが,意識せずにWBSを作成していると守れないことがある。レビュー時には,上位と下位の成果物を見比べて,その構造関係を検証する。

(6)ワークパッケージの詳細があるか
 ワークパッケージとは,成果物の最小構成要素にひも付く作業である。しかし,個々のワークパッケージの内容を定義していないことが多い。これでは,個々のワークパッケージをどのような手順で実施すればよいのか分からない。ワークパッケージの定義があるかどうかは,ワークパッケージを細かい作業単位に分解した「アクティビティ」があるかどうかで確認できる。