「WBSは分解すれば完成」という思い込みを捨てる——”問いの構造”から設計するWBS作成と活用の実践技法

＜目次＞

WBSに何が書いてあるか、より「何が書いていないか」が問題だ
WBS設計の起点は「動詞」ではなく「成果物」である
1. タスク起点の罠
2. 成果物（Deliverable）を起点に分解する
実践：WBSを「3つの問い」で構造化する
WBSを”生きた道具”として使い続けるための3つの習慣
まとめ：WBSは「分解の技術」ではなく「問いの設計」である

WBSに何が書いてあるか、より「何が書いていないか」が問題だ

WBS（Work Breakdown Structure）を作ること自体は、多くのPMが経験している。しかし、「作ったWBSがプロジェクトの途中で形骸化した」「タスクが増え続けて管理しきれなくなった」「メンバーがWBSを見ずに動いている」——そんな経験はないだろうか。

問題の根源は、WBSを「タスクの一覧表」として捉えているところにある。WBSの本質は、「プロジェクトの成果物を生み出すために必要な作業を、漏れなく・重複なく構造化する思考の地図」だ。分解することが目的ではなく、「何を作るか」という問いに答える構造を設計することが目的である。

本記事では、WBSを初めて作る方から、これまでの作り方に限界を感じているPMまでを対象に、「問いの構造」から設計するWBSの作り方と、プロジェクト全体を通じた活用法を実践的に解説する。

WBS設計の起点は「動詞」ではなく「成果物」である

タスク起点の罠

WBSを作るとき、多くの人が「何をするか（Do）」から考え始める。「要件定義をする」「設計書を書く」「テストをする」——こうした動詞中心のリストは、一見WBSに見えるが、実際には作業手順書と大差ない。

この方法の問題点は、「作業が終わった」かどうかの判断が曖昧になることだ。「設計書を書く」は、いつ完了したと言えるのか。書き終わったとき？レビューが通ったとき？顧客が承認したとき？

成果物（Deliverable）を起点に分解する

WBSの正しい起点は「何が出来上がるか（成果物）」である。PMBOKでも、WBSはプロジェクトの成果物と作業をより小さな管理可能な要素に分解したものと定義されている。

たとえば、新しい社内システムを導入するプロジェクトであれば、最上位の成果物は「稼働中の社内システム」だ。それを分解すると「要件定義書」「システム設計書」「テスト済みアプリケーション」「運用マニュアル」「研修完了済みユーザー」といった成果物の階層が現れる。

成果物を起点にすることで、「何が完了したか」が明確になり、完了基準（Definition of Done）を自然に設計できるようになる。

実践：WBSを「3つの問い」で構造化する

問い① 最終成果物は何か？

プロジェクトの終わりに「何が存在しているか」を具体的に言語化する。曖昧なゴール設定はWBS全体を歪める。「システムの改善」ではなく「月次レポートの自動生成機能が実装されたシステム」のように、検証可能な形で定義することが重要だ。

問い② その成果物を生み出すために、何が”完成”している必要があるか？

最終成果物を1段階分解し、中間成果物を列挙する。このとき、「作業」ではなく「状態」で表現するのがコツだ。「テストをする」ではなく「テスト合格済みの機能一式」と書く。これにより、何が揃えば次のフェーズに進めるかが明確になる。

問い③ 分解の「底」をどこにするか？

WBSを細かく分解しすぎると、管理コストが爆発する。目安は「1人が1〜2週間で完結できる作業単位」。これを「ワークパッケージ」と呼ぶ。ここまで分解できれば、担当者のアサインと進捗確認が可能になる。

Tips：分解が難しい領域は、それ自体が「不確実性のシグナル」だ。分解できないなら、その成果物の定義がまだ曖昧だということ。WBS作成中に発見できるリスクは、プロジェクト開始後に発覚するよりはるかに安価だ。

WBSを”生きた道具”として使い続けるための3つの習慣

① WBSとスケジュールを「別物」として扱わない

WBSのワークパッケージに工数・担当者・依存関係を紐づけることで、はじめてスケジュールが生まれる。WBSとガントチャートを別々に管理しているチームは多いが、それでは更新の手間が倍になり、どちらも陳腐化する。WBSを「計画の親」として、スケジュール・コスト計画・リスク管理と連動させる設計が理想だ。