課題が滞留するPMへ｜使える課題管理台帳の設計と運用法
Yukke
PMへの道
WBSの作り方と分解基準｜PMが初めて作るときに押さえる3原則と6ステップ
Yukke
WBSってどこまで細かく書けばいいんでしょう…？ 自分なりに作ってみたんですが、これで合ってるのか自信がなくて。
「WBSは作っているけど、進捗会議で『結局どうなっているのか分からない』と言われる」「タスクの粒度がバラバラで、見積もりにも自信が持てない」――。PM歴1〜3年のころは、私もそんな悩みをずっと抱えていました。
本記事では、使えるWBSを作るために押さえるべき3つの原則と、現場で迷わない6ステップをまとめます。「なんとなく分解する」から「根拠を持って分解する」に変えるための土台になるはずです。
Contents
WBSとは？ なぜ「土台」なのか
WBS（Work Breakdown Structure）とは、プロジェクトの成果物と作業を階層的に分解した構造図のことです。プロジェクト計画の土台であり、スコープ・スケジュール・コスト管理のすべてはWBSから始まります。
用語メモ
WBS：成果物と作業を階層的に分解した構造図
ワークパッケージ：WBSの最下層に位置する、管理可能な最小作業単位
100%ルール：上位の要素は、下位の合計で100%カバーされる
逆にいえば、WBSの精度がそのままプロジェクト全体の見積もり精度と進捗管理の質を決めるということです。
WBSが曖昧だと何が起きるか
「とりあえず動かないと…」とWBSをざっくり作って走り出すと、こんなトラブルが連鎖します。
- 見積もりの根拠がなくなり、工数が「なんとなく」の数字になる。結果として赤字プロジェクトの引き金になる
- タスクの粒度がバラバラで、進捗報告が「80%完了」のまま何週間も動かない状態になる
- 誰が何をやるのか不明確で、作業の抜け漏れや重複が発生する
- スコープ変更の際、影響範囲を正しく評価できず、安易に「やります」と回答してしまう
特につらいのが、クライアントから「この見積もりの内訳は？」と聞かれて答えに詰まる場面です。WBSがしっかりしていれば「この成果物にはこれだけの作業が必要で…」と即座に説明できますが、ふわっとしたWBSしかないと根拠を示せません。
ここがポイント
WBSは「作っただけ」では意味がない。スコープ・スケジュール・コスト・進捗管理の根拠として機能して、はじめて価値が出ます。
押さえるべき3つの原則
私が現場で何度もハマって、最終的に行き着いた原則は次の3つです。
原則1：成果物ベースで分解する
WBSの分解軸は「作業」ではなく「成果物（Deliverable）」にします。「設計する」ではなく「基本設計書」「詳細設計書」を起点に分解する。作業ベースで分解すると、何をもって完了とするかが曖昧になりやすいからです。
原則2：100%ルールを守る
上位の要素は、下位の要素の合計で100%カバーされなければなりません。逆にいえば、下位に含まれない作業は上位にも存在しないということ。これを守るだけで抜け漏れがぐっと減ります。
原則3：ワークパッケージの粒度を揃える
最下層のワークパッケージは「1人が1〜2週間で完了できる」サイズが目安です。これより大きいと進捗が見えず、小さすぎると管理コストが膨らみます。
3つとも当たり前に見えますが、現場で守れていないことが本当に多いです。
WBSの作り方｜6ステップで使えるWBSをつくる
ここからは具体的な手順です。私はこの順番で作るようにしています。
ステップ1：プロジェクトの最終成果物を定義する
契約書・RFP・要件定義書をもとに「何を作って納品するのか」をまず確認します。出発点が曖昧だとここから先がすべてズレるので、ここには時間を使ってOKです。
ステップ2：フェーズで第1階層を分ける
ウォーターフォールなら「要件定義／基本設計／詳細設計／開発／テスト／移行・リリース」がベースになります。プロジェクト管理作業（PM作業）も1つの階層として必ず含めるのがコツです。あとで漏れに気づくと厄介なので。
ステップ3：各フェーズの成果物を洗い出す
フェーズごとに「何が完成すればこのフェーズは終わりか」を考えます。基本設計フェーズなら「画面設計書」「DB設計書」「IF設計書」「基本設計レビュー議事録」など。
ステップ4：成果物をワークパッケージに分解する
各成果物について「作成」「レビュー」「修正」「承認」などの作業単位に分解します。レビューと修正を明示的に入れることで、手戻りコストを計画段階で織り込めます。これを抜くとあとで必ず炎上します。
ステップ5：粒度と網羅性をチェックする
全体を俯瞰し、100%ルールに照らして抜け漏れがないかを確認します。ワークパッケージが「1〜2週間」に収まっているかもチェック。
ステップ6：関係者でレビューする
WBSはPMだけで作りません。テックリード・業務チーム・クライアント側PMと一緒にレビューし、認識のズレを早期に解消します。「自分の頭の中だけで作ったWBS」には必ず漏れがあります。
実践のコツ
・最初から完璧を目指さない。要件定義時は上位2〜3階層まで作り、後続フェーズはフェーズが進むたびに詳細化する「ローリングウェーブ計画法」が現実的
・ワークパッケージごとに「完了基準」を文章で定義する（例：「レビュー完了」「指摘事項ゼロ」「承認印あり」）
・WBS番号（例：1.2.3）を振ると、スケジュール・課題管理との紐づけが容易になる
WBSのよくあるアンチパターン3つ
「自分も該当しているかも…」と感じるものがあれば、レビュー時の見直しポイントです。
NG1：作業ベースで分解してしまう
「設計する」「レビューする」のように動詞で分解すると、完了基準がぼやけます。「何ができたら終わりか」が定義できないタスクは、進捗80%のまま止まる典型です。
NG2：テストや移行を後回しにしてしまう
開発フェーズの分解は細かいのに、テスト計画・テストケース作成・移行リハーサルなどが「テスト」の一言で済まされている。これがテストフェーズで炎上する最大の原因です。
NG3：PM作業をWBSに含めない
進捗会議の準備、課題管理、ステコミ資料作成などのPM作業は、見積もりから漏れやすいわりに工数の10〜20%を占めることも少なくありません。最初からPM作業を一つの階層として明示的に確保するのが安全です。
今日からできる一歩
最後に、この記事を読み終わったあとにできる行動を1つだけ。
手元のWBSからワークパッケージを1つ取り出して、「このタスクの進捗を0%か100%でしか報告できないか？」と自問してみてください。
「中間状態（30%、50%、80%）が発生する」と感じたら、もう一段分解が必要なサインです。逆に「もう0/100で判定できる」と即答できれば、そのワークパッケージの粒度はOK。
この自問を続けると、WBSが「作って終わるドキュメント」から「現場で機能する管理ツール」に変わっていきます。
ABOUT ME
ITプロジェクトを15年以上担当。プログラマー→SE→PM→PMOコンサルタントとして、さまざまなレイヤーでプロジェクトに関わってきた経験から、実践的なプロジェクトマネジメントノウハウを発信します。