WBSの作り方｜成果物から分解する記入例と抜け漏れチェック
「予定表はあるのに、終わる直前になって作業が増える」。こうした状態では、日付を引き直す前に、必要な成果物と作業の抜けを確かめたいところです。WBSは、プロジェクトの仕事を階層で分け、管理できる単位へ落とすためのものです。
この記事では、社内の申請フォームを作るという説明用の例で、成果物から作業を洗い出します。実在の案件や著者の実績ではありません。Excelなどに移す際は、作業名だけでなく完了条件も残してください。
WBSとスケジュール表は、答える問いが違う
WBSでまず答えるのは「何を完成させるために、どんな仕事が必要か」です。「いつ取りかかるか」は、分解した仕事の依存関係や担当者の空きを踏まえて決めます。WBSに日付を併記する運用はできますが、日付を入れただけでは分解の不足は解消しません。
申請フォームなら、画面だけでなく、入力条件の合意、通知、権限、動作確認、利用者への案内も成果物になり得ます。一方、社内で不要と合意したものまで一般的な雛形から追加する必要はありません。対象範囲の合意を先に確認します。
成果物、作業、完了条件の順に書く
最初に大きな成果物を並べ、その下に、それを完成させる仕事を置きます。「開発対応」「確認」では、人によって想像する範囲が変わります。対象と動作を組み合わせて「入力エラー表示を実装する」「通知先を利用部門と確認する」と書くと、担当者との相談がしやすくなります。
次はWBSの一部を平らな表にした説明用の記入例です。列の担当は役割を示し、個人名ではありません。
| ID | 上位成果物 | 作業 | 主担当 | 完了条件 |
|---|---|---|---|---|
| 1.1 | 合意した要件 | 必須項目と入力例外を確認 | 業務担当 | 要件一覧に承認と未決事項を記録 |
| 2.1 | 申請画面 | 入力・エラー表示を実装 | 開発担当 | 合意した条件のテストが通る |
| 2.2 | 通知機能 | 通知先と権限を確認 | 開発担当 | 権限別の確認結果を保存 |
| 3.1 | 確認記録 | 利用部門の受入確認を実施 | 業務担当 | 指摘の処置と受入判断を記録 |
| 4.1 | 運用資料 | 問い合わせ先と復旧手順を整備 | 運用担当 | 後任が保管先と連絡経路を確認 |
表の「完了条件」は、その行を閉じるための確認です。上位の成果物が完成したかは、下位作業の完了に加えて、組み合わせた結果が要件を満たすかを確認します。画面と通知がそれぞれ動いても、入力後に通知されなければ全体の完成とは言えません。
分解を止める粒度は、時間より説明可能性で判断する
一律に「すべて何時間以内」とすると、仕事の種類やチームの規模に合わないことがあります。主担当が見積もり、進捗と残作業を説明でき、確認者が完了を判定できるかを目安にします。
たとえば「受入テスト」は長期間かつ複数人が関わるなら、観点作成、環境・データ準備、実施、指摘修正、再確認に分けると、停滞している場所が見えます。ただし、細分化した行を毎日埋める負荷の方が大きくなるなら、詳細は担当チームの表に置き、全体WBSでは成果物単位へまとめます。
分解の途中で判断が必要になった事項は、作業として黙って追加せず、未決事項にします。「通知をメールとチャットの両方に出すか」が未決なら、二つとも実装する前提で見積もらないことが大切です。
抜け漏れは、受け渡しと作業の前後で探す
- 作成前に、入力情報・権限・環境・外部回答が必要ではないか。
- 作成後に、レビュー・修正・再確認・受入判断が残らないか。
- チームをまたぐ受け渡しで、どちらが準備するか曖昧なものはないか。
- 公開後の運用・説明・問い合わせ・引き継ぎが対象なら含まれているか。
- 同じ仕事を別の成果物の下で二重に計上していないか。
確認には、成果物を受け取る側も参加してもらいます。作成者だけで点検すると、受け手が必要とする形式や証跡を見落としやすいためです。完成したものの保管先まで追うと、作業の終わり方を揃えられます。
初版を固定しすぎず、変更の理由を残す
WBSは初日にすべてを当てるための表ではありません。分かったことに応じて更新します。ただし、承認された範囲や日程が変わる場合は、変更理由・影響・判断を残し、計画の変更として扱います。行を追加しただけで納期を維持できると決めないでください。
コピー用の列は次の通りです。開始・終了日は、依存関係と担当の稼働を相談した後に埋めます。
ID 上位成果物 作業 主担当 入力・前提 完了条件 確認者 開始予定 終了予定 関連ID 状態最初の改善は、すべての行を細かくすることではなく、曖昧な一行を「担当・残作業・完了条件が説明できる一行」に変えることです。管理表の行数ではなく、仕事の抜けと受け渡しの不確実性が減ったかで見直します。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
WBSの階層分解という基本概念を確認した公開情報です。表の分類や例はこの記事用に作成しました。 Atlassian：Work Breakdown Structure（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
課題管理表の作り方も必要な作業に合わせて参照してください。
アイキャッチ写真：2H Media / Unsplash。職場の実写ではなくイメージ写真です。
