WBSの作成手順と実務の注意点｜よくある失敗を避けるレビュー観点

WBSのレビューは、成果物の網羅・作業の粒度・前後関係の整合という3つの観点を順に確認すると、短い時間でも抜け漏れを見つけやすくなります。

WBSの品質は、作る人だけでなく、確認する側の見方でも大きく変わります。本記事では、若手PMOやチームリーダーなど、他の人が作成したWBSをレビューする立場の方に向けて、確認する順番と観点、指摘の伝え方、レビュー後も更新を続けるための仕組みを整理します。WBSそのものの作成手順はWBSの作り方・作成手順で解説しているため、ここではレビューの視点に絞ります（2026年10月時点の内容です）。

レビューの前提

レビューは、WBSが何のために作られ、成果物を単位に組まれているかを確認するところから始めます。この2点が曖昧なまま細部を見ても、指摘がずれやすくなります。

WBSの目的の確認

WBSの目的は、やるべき作業と担当範囲を具体的にし、役割分担とスケジュールの土台をつくることです。

WBSの解説記事では、WBSを作る目的として「やるべき作業内容と受け持つ範囲が具体的になる」「役割分担が明確になる」「立てたスケジュールと実際の進行状況を比較しやすくなる」といった点が挙げられています（Workship MAGAZINE、2019年公開・2019年10月更新）。また、経済産業省とIPA（情報処理推進機構）のITスキル標準V3では、WBS作成はスコープ計画・スコープ定義・スコープ検証などと並ぶ、プロジェクト・スコープ・マネジメントの項目として整理されています。こうした位置づけから、WBSのレビューは「プロジェクトの範囲が過不足なく作業に落ちているかを検証する作業」と捉えると、見る対象がぶれません。

レビューに入る前に、次の3点を手元に揃えておくと確認が速くなります。

• プロジェクトの目的とゴール（何ができれば完了か）
• スコープの記述（対象に含むものと含まないもの）
• 契約形態と体制（自社が担う範囲と、顧客や他社が担う範囲）

成果物ベースかどうか

WBSの第1階層が成果物で組まれているか、「打ち合わせ」「調整」のような作業名で並んでいないかを最初に見ます。

成果物を起点にした分解では、下位の作業をすべて足し合わせると上位の成果物になり、取りこぼしも余分な作業もない状態をめざします。この考え方は「100%ルール」と呼ばれ、解説記事では、WBSで必ず適用すべきルールとして紹介されています（ITmedia エンタープライズ、2010年公開）。作業名から書き始められたWBSは、この突き合わせができず、抜け漏れの有無を判断する基準が失われます。

フリーコンサルの案件では、準委任契約で参画するケースが多く、約7〜8割とされています。準委任では、成果物の完成義務を負わない形が一般的です。完成義務がないからこそ、完了の定義が曖昧なWBSは、どこまでが自分の担当範囲かを巡って揺らぎやすくなります。契約上の責任範囲の判断が必要になった場面では、個別の契約書の内容に沿って、法務などの専門家に確認してください。

編集部としては、成果物の欄に「完了とみなす状態」を1行添えておくことを、レビューの最初の確認項目として勧めます。これだけで、後続の抜け漏れや粒度の議論が具体的になります。

抜け漏れのチェック

抜け漏れは、成果物の一覧とWBSを1行ずつ突き合わせ、特にテストと移行の工程が入っているかを確かめると見つかりやすくなります。

成果物の網羅

成果物の一覧にある項目すべてに、対応する作業がWBS上にあるかを突き合わせます。

1. 契約書や計画書から、納品する成果物の一覧を作ります。
2. WBSの各成果物・作業を、一覧の項目と1対1で対応づけます。
3. 対応する作業がない成果物に印を付けます。これが抜け漏れの候補です。
4. 逆に、どの成果物にもつながらない作業も洗い出します。根拠のない作業が混ざっていないかを確認するためです。

架空の販売管理システム刷新プロジェクトを例にすると、次のような突き合わせ表になります。

テスト・移行の工程

テストと移行は、開発の見積もりに押されて後回しにされやすく、WBSで最も抜けやすい工程です。

開発や設計の作業は細かく書かれているのに、終盤の工程が1行で済まされているWBSは珍しくありません。次の項目が作業として存在するかを確認します。

• 単体・結合・総合の各テストと、ユーザー受入テストの支援
• テスト環境の構築と、テストデータの準備
• データ移行のリハーサルと、本番移行の手順確認
• 本番切替と、問題が出た場合の切り戻しの準備
• 利用部門への説明やマニュアルの整備
• 稼働直後の問い合わせ対応と、安定稼働までの見守り

必要な工程はプロジェクトの性質によって異なります。全項目を機械的に求めるのではなく、「このプロジェクトでは不要」と判断した工程には、その理由が記録されているかを確認します。

粒度のチェック

粒度は、見積もり・担当割り当て・進捗確認ができる大きさに揃っているかで判断します。

工数の偏り

一部の作業だけが極端に大きい、または極端に小さい場合は、粒度が揃っていないサインです。

粒度の目安として、最小の作業を8時間以上80時間以内に収める「8/80ルール」がよく知られています。2週間を超える作業を1行にまとめると、細部が詰め切れておらず作業のイメージがしにくくなり、不確実性が高まると解説されています（Workship MAGAZINE）。IT案件のワークパッケージでは40時間前後を目安にする説明もありますが、このルールと、分解を7要素・7階層程度に収める「7×7ルール」は、必ず守る規則ではなく目安とされています（ITmedia エンタープライズ）。プロジェクトの規模や体制に合わせて運用します。

粒度の失敗例や修正の考え方は、WBSの作成手順の記事でも扱っています。

担当の過負荷

担当の過負荷は、担当者別・週別に工数を集計し、稼働できる時間と並べると見つかります。

1. WBSの最下層の作業を、担当者ごとに並べ替えます。
2. 各作業の工数を、開始週から終了週に均等に割り振り、週ごとに合計します。
3. 各担当者の稼働可能な時間（週の勤務時間に稼働率を掛けた値）と比べ、超えている週に印を付けます。

次の表は架空の例です。Aさんは3週目だけ稼働上限を超えており、この週に集中している作業のうち、前倒しできるものや、他の担当へ移せるものを探します。

担当者が1人しかいない作業は、その人が休むと止まる点にも注意します。代わりに対応できる人がいるかを、レビューの時点で確認しておくと安心です。

依存関係のチェック

依存関係は、後続の作業が始められる条件を、前の作業の成果物で説明できるかを確認します。

前後関係の整合

後続の作業に必要な入力が、前の作業の出力として存在するかを、1行ずつ確かめます。

たとえば結合テストを始めるには、結合テストの仕様書とテスト環境が必要です。WBSに環境構築の作業がなければ、結合テストの開始日は根拠のない日付になります。ITスキル標準V3では、スコープ管理とは別に、プロジェクト・タイム・マネジメントの項目として「アクティビティ順序設定」が挙げられており、作業の順序を決めることが独立した管理項目として扱われています。レビューでは、次の3つを確認します。

• 後続作業の開始条件となる成果物が、前の作業のどれかで作られているか
• 前後関係が逆になっていないか（例：画面設計の完了前に、画面のテスト仕様書が完成する日程になっていないか）
• 並行で進められる作業が、不必要に直列に並んでいないか

前後関係は、WBSの表だけでは見えにくいため、ガントチャートなどで日程を並べると確認しやすくなります。両者の役割の違いはWBSとガントチャートの違いで整理しています。

外部依存の洗い出し

自チームの外が握っている前提は、通常の作業とは別に洗い出し、期日と責任者を置きます。

• 顧客の承認や意思決定（要件の確定、仕様の承認など）
• 他ベンダーや他チームからの納品物
• 環境・アカウント・権限の提供
• データの提供や、現行システムの担当者への確認

外部依存は、遅れても自チームでは取り戻せないため、WBS上で見落とされると影響が大きくなります。「誰が、いつまでに、何を渡すか」を1行で書けない依存は、まだ合意が取れていない可能性があります。契約上の責任の所在が絡む場合は、個別の契約内容に沿って、専門家に確認してください。

指摘のしかた

レビューの指摘は、事実・影響・改善案をセットにして伝えると、受け取る側が直しやすくなります。

改善案とセットで伝える

「粒度が粗い」と伝えるだけで終わらせず、どう分ければよいかの案まで添えます。

編集部の実務上の見立てとして、レビューの冒頭で、作成者本人にWBSの全体像を口頭で説明してもらう進め方が有効です。説明の途中で言葉に詰まる箇所は、前提の整理が足りない可能性が高く、指摘すべき場所を絞り込めます。

優先度を付ける

指摘は、直さないと計画が成り立たないもの、直した方がよいもの、好みの範囲のものの3段階に分けて伝えます。

すべての指摘を同じ重さで並べると、作成者はどこから直せばよいか分からなくなります。たとえば、成果物の抜けや前後関係の誤りは、日程や見積もりに直結するため最優先です。粒度のばらつきや担当の偏りは、影響の大きさを見て次の優先度に置きます。表記の揺れや並び順の好みは、最後にまとめて伝えれば足ります。

1. 必ず直す：成果物の抜け、前後関係の誤り、担当の過負荷
2. 直した方がよい：粒度のばらつき、完了条件の未記載
3. 任意：表記の統一、並び順の工夫

更新を続けるために

WBSは作って終わりではなく、変更の記録と進捗報告に連動させて更新し続けることで、レビューの効果が保たれます。

変更管理

WBSの変更は、誰が・何を・なぜ・どの作業に影響するかを記録し、承認を経て反映します。

プロジェクトを進める中で、最初に作ったWBSを随時修正していく必要があると解説されています。その際は、キックオフの時点で、変更が起こり得ることを関係者で合意し、変更の連絡先と承認の基準を決めておくことが勧められています（Workship MAGAZINE）。

1. 変更の依頼を受け付け、内容と理由を記録します。
2. 影響する作業・成果物・日程・担当を洗い出します。
3. 事前に決めた基準で、承認するかどうかを判断します。
4. 承認された変更だけをWBSに反映し、版数と日付を残します。

進捗報告との連動

進捗報告の単位をWBSの最下層に揃えると、報告とWBSの食い違いが減ります。

• 週次の報告フォーマットに、WBSの番号と作業名をそのまま使います。
• 完了の判断は、成果物に書いた「完了とみなす状態」に照らして行います。
• 報告で見つかった遅れや新しい作業は、その場でWBSに反映するか、変更管理に回します。

レビューの観点である成果物の網羅、粒度、前後関係は、一度確認して終わりにせず、変更が入るたびに見直す対象です。WBSのレビューで確認する3つの観点を、進捗報告の場で繰り返し点検することが、WBSを現実に合わせて保つ近道になります。PMOとして関わる場合の役割はPMOの意味と役割、求められるスキルはPMOに求められるスキルで整理しています。

出典・参考情報

1. Workship MAGAZINE「すべてのPMに贈る、WBSの書き方におけるたった3つのルール」（2026-10-08参照）
2. ITmedia エンタープライズ「WBSには、たった3つのルールがある」（2026-10-08参照）
3. 経済産業省・IPA「ITスキル標準V3 スキル領域とスキル熟達度（5）プロジェクトマネジメント」（2026-10-08参照）

本記事は2026年10月時点の一般的な情報を基に、WBSレビューの観点を整理したものです。契約や責任範囲の個別の判断が必要な場合は、専門家に確認してください。最終更新日：2026年10月8日