WBSの作り方：成果物ベースで分解し、粒度と漏れをコントロールする実践手順

WBSはスコープの道具であって、スケジュールの道具ではない

WBS（Work Breakdown Structure、作業分解構成図）は、プロジェクトの目的を達成し必要な成果物を生み出すために、プロジェクトチームが実行する作業スコープの全体を、階層的に分解したものです。PMIの定義でも「成果物指向の階層的分解」と表現されます。分解の目的はスコープを定めることにあり、日程を引くことではありません。

階層の最下層に置く要素をワークパッケージと呼びます。コストと所要期間を見積もれて、実績を測れて、コントロールできる単位です。「これなら工数が読める」「終わったかどうか判定できる」ところまで落ちたものが、ワークパッケージになります。

実務で作られているWBSの多くは、この定義から外れています。思いついた順にタスク名を並べただけの一覧表。あるいはガントチャートの左側の列そのもの。手順に入る前に何のための成果物なのかを揃えておくと、以降の判断がぶれません。

作業ベースではなく成果物ベースで分解する理由

最初の分岐点は、何を軸に分解するかです。多くの人は「要件定義をする」「設計をする」「テストをする」と、動詞で切りはじめます。しかしWBSの原則は成果物を軸に置くことです。「要件定義書」「基本設計書」「テスト計画書」「移行手順書」というように、名詞で並べるのが基本形になります。

理由は3つあります。第1に、抜け漏れが目に見えます。作業は主観で増減しますが、成果物なら「納品物リストにあるのにWBS上にない」という形で欠落が現れます。第2に、完了判定が割れません。「設計をした」は人によって解釈が分かれますが、「基本設計書がレビューを通過した」は分かれない。第3に、進め方が変わっても構造が壊れません。開発手法や体制が途中で変わっても、作るべき成果物が同じなら骨格は生き残ります。

とはいえ、成果物として表現しにくい作業もあります。進捗会議の運営、課題管理、ベンダー折衝といったプロジェクトマネジメント業務がその代表です。これらは「プロジェクトマネジメント」という枝を最上位に1本立て、そこにまとめて置くのが一般的な扱いです。WBSはマネジメント作業も含めて100%を表す必要があるため、ここを省くと次に述べる100%ルールに反します。

100%ルール：子を足すと親になる

WBSの設計原則の中核は、プロジェクトスコープで定義された作業の100%を含み、かつ100%を超えないことです。内部成果物も外部成果物も中間成果物も取り込み、同時にスコープ外の作業を紛れ込ませない。この2つを同時に要求します。

適用されるのは、階層のすべてのレベルです。ある親の下にぶら下がる子を全部足し合わせると、ちょうど親の100%になっていなければならない。足りなければ作業漏れ、超えていればスコープクリープか重複です。

作業中の確かめ方としては、1つの親を分解し終えるたびに「この子要素を全部やり切ったら、親は完成していると言い切れるか」と自問します。ここで「言い切れない、たぶん他にもある」と感じたら、その時点で足りていません。各階層でこれを繰り返すのが、抜け漏れを潰す最も安上がりな方法です。

8/80ルールは目安、実際の基準は報告サイクル

最下層のワークパッケージを、おおむね8時間（1日）から80時間（2週間）の工数に収まるところまで分解する。粒度の判断で広く使われている経験則です。8時間を下回るほど細かい要素は管理コストが見合わないので統合を検討し、80時間を超えるものは進捗が読めなくなるのでさらに割ります。

ただしこの数値は、PMIが標準として規定したものではありません。実務で共有されている目安にすぎない点は押さえておいてください。実際に決めるときは、プロジェクトの進捗報告サイクルに合わせるのが現実的です。週次で進捗会議を回すなら、ワークパッケージは1週間以内で終わるサイズにしておく。そうすれば報告のたびに「30%完了です」という主観的な数字を扱わずに済みます。月次報告のフェーズなら、もう少し粗くても運用は回ります。

分解が足りているかの簡易チェックとして、「この作業、何日かかりますか」と担当者に聞く方法があります。即答が返ってこないなら、まだ中身が見えていない。分解の余地があります。

深くしすぎないことも同じくらい効きます。1つの親にぶら下がる子は7つ程度まで、全体の階層も7階層程度まで、という考え方が実務でよく用いられます。階層が深くなるほど全体像は掴みにくくなり、更新もされなくなっていく。粒度は細かければ良いものではなく、管理できる範囲に収めるためのものです。

最終成果物から一段ずつ降りていく

第1に、最終成果物とプロジェクトの完了条件を確認します。スコープ記述書、提案書、契約書から「何が納品されたらこのプロジェクトは終わりなのか」を洗い出す。ここが曖昧なまま分解を始めると、以降がすべてぶれます。

第2に、最上位の枝を決めます。フェーズ（要件定義、設計、開発、テスト、移行）で切る方法と、主要成果物やサブシステム単位で切る方法があります。どちらでも構いませんが、同じ階層の中では切り口を統一してください。フェーズと成果物が同じ階層に混在すると、100%ルールの確認ができなくなります。

第3に、各枝を成果物ベースで一段ずつ分解します。一気に最下層まで掘らず、階層ごとに横並びで揃えながら降りると、粒度のばらつきが出にくくなります。

第4に、各階層で100%ルールを確認します。子を足したら親になるか、スコープ外が混ざっていないか。

第5に、ワークパッケージの粒度が目安に収まっているかを点検します。細かすぎるものは統合、大きすぎるものは分解。

第6に、WBSコード（1、1.1、1.1.1という採番）を振ります。後工程で見積もり、担当割り当て、実績集計をするときに、このコードが共通のキーになります。

第7に、実行部隊のメンバーにレビューしてもらいます。WBSはPM1人で完成させるものではありません。実際に手を動かす人が見れば「この作業がない」がすぐ出てきます。ここを省くと、漏れは実行フェーズまで見つかりません。

WBS辞書までがワンセット

図や表だけでは、実務は回りません。分解の都合上、各要素には短い名前しか付けられないため、「基本設計書」と書かれていても、その中身がどこまでを指すのかは人によって解釈が割れます。この割れを潰すために作るのがWBS辞書です。

WBS辞書には、WBSコード、その要素の作業内容の説明、含む範囲と含まない範囲、成果物の定義と完了条件、担当組織や担当者、前提条件と制約条件、マイルストーンや必要な工数といった情報を書きます。とりわけ「含まない範囲」を明記しておくと、後から出てくる「これもやってくれると思っていた」という認識ずれを大きく減らせます。

PMBOKの枠組みでは、スコープ記述書、WBS、WBS辞書の3点セットがスコープ・ベースラインを構成します。WBS辞書は付属資料ではなく、スコープを固定する正式な構成要素です。変更要求が来たときに「それはベースライン外の作業です」と根拠を持って言えるかどうかは、辞書があるかどうかで決まります。

全要素に詳細な辞書を書くのは負担が重いので、金額が大きい枝、外部委託する枝、解釈が割れそうな枝から優先します。逆に、社内で1人が2日で終える作業まで辞書を起こすと、更新されないまま古い記述が残り、辞書そのものが信用されなくなります。

WBSとガントチャート・スケジュールの違い

両者は目的も、載っている情報も違います。WBSが答えるのは「何を作るのか、作業範囲はどこまでか」というスコープの問い。ガントチャートが答えるのは「いつ、どの順番で、どれくらいの期間で進めるのか」という時間軸の問いです。

順序としては、WBSが先でガントチャートが後です。WBSでワークパッケージを確定し、そこから実行可能なアクティビティを洗い出し、順序関係と所要期間を設定して、はじめてスケジュールが引けます。PMBOKの体系でも、WBSはスコープ・マネジメントの成果物、ガントチャート（バーチャート）はスケジュール・マネジメントの表現形式として、別の領域に置かれています。

混同が起きる大きな理由は、プロジェクト管理ツールの表示形式です。多くのツールは、左側にタスクの階層構造、右側にバーチャートを1画面で並べるため、両者が同じものに見えてしまいます。しかし左側の階層に日付が入った瞬間、それはWBSではなくスケジュールです。

分けて持つ実務上の利点は、変更が起きたときの対応が変わることです。納期が動いただけならスケジュールの引き直しで済みますが、作るものが増えたのならWBSとWBS辞書、つまりスコープ・ベースラインそのものの変更手続きが要ります。両者を分けていないと、スコープの増加が「スケジュールの遅れ」として処理され、追加費用も追加期間も交渉できないまま現場が疲弊します。

作ったWBSが機能しなくなる5つのパターン

第1は、作業ベースで分解して漏れることです。「テストをする」という枝しかないと、テストデータの準備、テスト環境の構築、不具合の修正と再テストが抜けます。成果物ベースで並べ直し、各成果物について「これを作るのに必要な入力物は何か」を逆算すると、抜けが見つかります。

第2は、粒度がばらばらになることです。同じ階層に「画面設計」と「ログイン画面のボタン配置検討」が並んでいるWBSでは、見積もりも進捗管理も成立しません。階層ごとに横並びでレビューし、明らかに大きさが違うものを揃えてください。

第3は、WBS辞書がないことです。WBSだけを配って認識合わせは完了、としてしまうと、後工程で必ず解釈のずれが出ます。少なくとも外部委託部分と金額の大きい部分は文書化しておくべきです。

第4は、ガントチャートと混同することです。スケジュール表をWBSと呼んでいると、スコープの議論とスケジュールの議論が常に混ざります。成果物の構造だけを表した状態のWBSを一度きちんと作り、それを合意の基準として残してください。

第5は、作って終わりにすることです。WBSはスコープ・ベースラインの一部なので、スコープが変われば正式な変更管理を経て更新されます。更新されないまま実績だけが積み上がると、計画と実績の比較そのものが意味を失います。

作成に使うツールについても触れておきます。表計算ソフト、マインドマップツール、プロジェクト管理ツールなど選択肢は多く、どれでもWBSは作れます。選定より先に効くのは、成果物ベースで分解されていること、100%ルールを満たしていること、粒度が運用サイクルに合っていること、WBS辞書が伴っていることの4点です。まずは手元の表計算ソフトで、最上位の枝を5つから7つ書き出すところから始めてみてください。