「とりあえずWBSを作った」で止まっていないか——WBSを”プロジェクトの骨格”として機能させる設計思想と実践技法

＜目次＞

WBSは「タスク一覧」ではない

プロジェクトの立ち上げ時、多くのPMがまず着手するのがWBS（Work Breakdown Structure）の作成だ。しかし現場を見渡すと、「Excelに作業をずらっと並べただけ」「ガントチャートの行ラベルと変わらない」という状態になっているケースが少なくない。

WBSの本質は、「プロジェクトのゴールを達成するために必要な作業を、管理可能な単位に構造的に分解する」こと。タスクを列挙するツールではなく、プロジェクト全体を設計するための思考フレームワークだ。この視点のズレが、後工程での見積もり精度の低下、作業漏れ、責任の曖昧化といった問題を引き起こす。

本稿では、WBSを”作るだけ”で終わらせず、プロジェクト運営の中心軸として機能させるための考え方と実践手法を解説する。

WBSの分解は「作業」ではなく「成果物（Deliverable）」を起点にするのが鉄則だ。「会議をする」「レビューする」という行為ベースで分解すると、何が完成すれば終わりなのかが曖昧になる。

【Before】：要件定義ミーティングを実施する
【After】：要件定義書（承認済み）を作成する

成果物ベースで考えることで、完了条件が明確になり、品質基準や検収の判断もしやすくなる。

WBSの各レベルを合算すると、親ノードの作業範囲が100%カバーされていなければならない。これを「100%ルール」と呼ぶ。分解が不完全だと、見積もりや担当割り当てに抜け漏れが生じる。

実務では「どちらでもないタスク」が出てきがちだ。たとえば、設計フェーズと開発フェーズをまたぐ技術検証作業。こういった横断タスクは、あらかじめWBSに「統合管理」「技術基盤」などの独立した分類項目を設けて受け皿を作っておくとよい。

分解の深さに迷うPMは多い。目安として使われるのが「8/80ルール」だ。ワークパッケージ（最下位の作業単位）は、8時間（1人日）以上、80時間（約2週間）以内に収まる粒度が適切とされる。

これより細かいと管理コストが増大し、粗すぎると見積もり精度が落ちてリスクが見えなくなる。プロジェクトの規模や期間に応じて柔軟に調整しながら、「1人が1週間以内に完了できる単位」を基準にすることを推奨する。

PMが一人でWBSを作り、チームに配布するプロジェクトは多い。しかしこのやり方には見えないコストがある。作業の当事者がWBSの構造を理解していないという問題だ。

推奨するのは、チームワークショップ形式でのWBS作成だ。具体的には以下のステップで進める。

このプロセスを経ることで、メンバーは「自分がWBSを作った」という当事者意識を持つ。後工程での「そんな作業、聞いていません」というトラブルも激減する。

完成したWBSは、週次ステータス会議での進捗確認の基準にする。「WBSのどのワークパッケージが完了したか」を軸に会話することで、曖昧な「80%完了」報告を排除できる。完了の定義が明確なWBSは、客観的な進捗の物差しになる。

追加要望が来たとき、「できます/できません」の二択で議論するのは危険だ。WBSを開いて「この変更はどのワークパッケージに影響するか」「新たなワークパッケージが必要か」を議論する。WBSが変更管理の入口になることで、影響範囲の見える化と合意形成が格段にスムーズになる。