計画倒れを防ぐ「高解像度WBS」の作り方／分解・断捨離・最適化・逆算【Claudeスキル＋Excelダウンロード】

そのWBSは、現場が迷わない「設計図」になっていますか？

「スケジュールは引いた。あとは現場にお任せだ」

そう思ってプロジェクトを始めたのに、リリース直前になって混乱が起きる。
進捗会議では「順調です」と聞いていたのに、ふたを開けると「まだ着手できていません」というタスクが出てくる。

こうした事態は、メンバーの能力不足やPMの努力不足が原因ではありません。
多くの場合、原因はWBSの「解像度」が足りていないことにあります。

「何を作るか（What）」だけを並べたリストでは、メンバーは「どう進めれば完了か（How／Done）」に迷いながら作業することになります。
この「迷う時間」が見えない遅延を生み、「タスクが大きすぎて進捗が見えない（90%完了症候群）」や「完了基準が曖昧で手戻りが続く」といった事態につながります。

WBSは単なるタスクリストではなく、プロジェクトを成功させるための「設計図」です。
本記事では、WBSを「人が迷わず動けるレベル」まで高める「高解像度WBSの型」を、4つの工程に分けて紹介します。

1. 分解
   • タスクを「誰が・何を・どうすれば完了か」がわかる粒度まで刻みます。
2. 断捨離
   • リソースは有限だと認め、やらないことを決めます（スコープ・マネジメント）。
3. 最適化
   • エース級の人材をコア業務に集中させ、定型業務はAIやツールに回します（リソース配分）。
4. 逆算
   • 積み上げではなく、納期から現実的な線を引きます（スケジューリング）。

なぜWBSの作り方で失敗してしまうのか

WBS作りが失敗する最大の理由は、「タスクを書き出しているだけ」になっていることです。
正しい作り方を知らずに進めると、次の8つの課題が起きます。

• 成果物ベースで分解できていない
  • 「〇〇機能開発」のような抽象的なタスクを並べても、全体像はつかめません。何を作るための作業かが曖昧なまま進むと、優先度や依存関係もわからなくなります。
• タスク粒度の肥大化（90%症候群）
  • 大きなタスクのまま放置され、担当者が何日もボールを持ち続けてしまう状態です。粒度が大きすぎると進捗が見えず、小さすぎると管理の手間が増えます。
• 完了定義の欠如による差し戻し
  • 「できたと思ったのに、顧客からNGが出た」という手戻りは、着手前に「何を確認できたら完了か（クローズ条件）」を合意していないことが原因です。
• 依存関係と担当の未整理
  • 「誰のOKがあれば次へ進めるか」という承認フローや前後関係が不明確だと、作業が止まったときの影響範囲が見えません。
• 消えないタスク（ゾンビチケット）
  • 「やるかやらないかわからないタスク」がバックログに残り続け、チームの認知負荷を高めます。
• 非本質的なタスクでの疲弊
  • 「念のため」のドキュメント作成や定例会議に追われ、肝心の設計や品質管理がおろそかになります。
• 「人間がやるべきでない仕事」による高コスト化
  • AIや自動化ですぐに終わる作業に単価の高いエンジニアを当て、予算を使い切ってしまいます。
• メリハリのないリソース配分
  • すべてのタスクを「重要」として扱い、エース級の人材を単純作業ですり減らしてしまいます。

これらの課題は、後で紹介する4つの工程で解消します。
1・2つ目は「分解」、5・6つ目は「断捨離」、3・7・8つ目は「最適化」、4つ目は「最適化」と「逆算」で対処します。

INPUT 高解像度なWBSを作るための前提条件

WBSの主な材料は企画書・提案書です。ただし、それだけでは足りないため、記載の不足と現場固有の制約をヒアリングで補います。
書かれていない制約を作成前に引き出しておくと、後の手戻りを防げます。

企画書・提案書から読み取る7つの項目

企画書・提案書の各項目は、WBS作成で次のように使います。
記載がない、または曖昧なときは、「ヒアリング例」の質問で確認します。

1. プロジェクトの背景と課題
   • WBS作成での使い方：WBS作成の時点では、振り返る程度でよい
2. プロジェクトコンセプト
   • WBS作成での使い方：目的・ゴール・KPIから、QCDのどれを重視するかを読み取る。断捨離の判断基準にする
   • 記載がないときのヒアリング例：QCDのどれを重視するか、別途確認の場を設ける
3. システム構成図
   • WBS作成での使い方：インフラ構築の作業と、外部連携の有無を洗い出す
   • 記載がないときのヒアリング例：「連携先の外部システムの仕様書はありますか？テスト環境は使えますか？」「CI/CD環境の構築はスコープに含みますか？」
4. 非機能要件定義（概要）
   • WBS作成での使い方：負荷テスト・セキュリティ診断・バックアップや運用設計の要否と、工数の規模をつかむ
   • 記載がないときのヒアリング例：「セキュリティ要件の準拠基準はありますか？」「目標の同時アクセス数やレスポンスタイムはありますか？」「特別なレガシー要件はありますか？」
5. マスタスケジュール
   • WBS作成での使い方：リリース日が絶対に動かせない壁か、努力目標かを確かめる
   • 記載がないときのヒアリング例：「このリリース日は必達ですか？」「お客様側の検収期間は何営業日ありますか？」
6. スコープ定義
   • WBS作成での使い方：作る機能・成果物・作業・役割分担の大枠をつかむ。自社と顧客の責任の境界線も確かめる
   • 記載がないときのヒアリング例：「既存のロジックを引き継ぎますか？業務フローから見直しますか？」「スマホ対応は必須ですか？」「操作マニュアルも納品物ですか？」
7. 体制図とスキルセット
   • WBS作成での使い方：エース級とジュニア層、AI活用の可否を確かめ、最適化の判断材料にする
   • 記載がないときのヒアリング例：「エースの方は、この期間100%稼働できますか？」「生成AIの利用に、セキュリティ上の制限はありますか？」

QCDのどれを重視するかで、予算や納期を超えそうなときの調整方法が変わります。

• Q（品質）重視
  • 予算や期日を超えても、機能追加やテストを実施します。
• C（コスト）重視
  • 許容範囲内で、重要度の低い機能を切り捨てるか、期日を延ばします。
• D（納期）重視
  • 重要度の低い機能を切り捨て、人員やツールを追加してでも期日を守ります。

企画書・提案書には書かれない現場の制約

次の6つは、企画書・提案書にはまず書かれていません。
作成前にヒアリングし、確認できなかった点は調査タスクとしてWBSに入れます。

• 【環境】関連システムの制約
  • WBSへの反映：連携先の都合に合わせる作業を洗い出し、調査・調整タスクにする
  • 確認のポイント：連携先のセキュリティ要件（特殊な通信、IPアドレスの制約など）、回線の速度と品質、接続申請の承認にかかる期間
• 【移行】現行システムが移行に割けるリソース
  • WBSへの反映：稼働中の現行システムへの影響を調べ、移行計画のタスクにする
  • 確認のポイント：CPU・メモリ・転送速度に余裕はあるか。平日日中が無理なら、土日や深夜はどうか。一時的なスケールアップはできるか
• 【移行】現行データの「汚れ」具合
  • WBSへの反映：移行プログラムの開発前に「データクレンジング」の大きなタスクを置き、十分な期間を取る
  • 確認のポイント：電話番号欄に「同上」と入っているなど、そのままでは移行できないデータがどれくらいあるか
• 【移行】現行ドキュメントの信頼性
  • WBSへの反映：資料が古ければ「資料確認」ではなく「ソースコード解析・現行調査」のタスクにし、工数を厚く積む
  • 確認のポイント：「資料あり」とされている資料の最終更新日はいつか
• 【組織】顧客側の承認リードタイム
  • WBSへの反映：タスクの間に「顧客承認待ち」のマイルストーンやバッファを入れる
  • 確認のポイント：「承認は3日で」という口約束ではなく、実際の意思決定プロセス（月1回の会議でしか決まらないなど）はどうなっているか
• 【組織】リリース許容日時
  • WBSへの反映：リリースできない期間を考慮し、余裕を持った最終工程を引く
  • 確認のポイント：「平日日中のリリースは不可」「金曜は不可」などの運用ルールはあるか

PROCESS 高解像度WBSの作り方：分解・断捨離・最適化・逆算の4工程

INPUTの情報を「分解」してスコープを「断捨離」し、リソースを「最適化」したうえで、納期から「逆算」して配置します。
4つの工程は、この順番で進めます。順番を入れ替えたり飛ばしたりすると、後の工程で計画が破綻します。

Step 1 分解：タスクを「最大3営業日」の粒度まで刻む

分解では、INPUTの情報を漏れなくタスクにし、担当者が最大3営業日程度で完了できるサイズまで刻みます。
このサイズなら、進捗が止まってもすぐに気づけます。

分解は、次の6つの手順で進めます。

1. 企画書・提案書から転記する
   • スコープ定義とマスタスケジュールから、タスクと成果物を書き写します。この段階では粒度を気にせず、漏れがないことを優先します。仕様凍結・稼働判定・リリースなどのマイルストーンも書き出します。
2. 作業工程ごとに分解する
   • 要件定義は成果物単位、基本設計は機能単位で分けます。
   • 詳細設計・開発・単体テストは画面・バッチ処理単位、結合テストは機能単位、総合テスト・受入テストはサイクル単位で分けます。
   • マイルストーンは準備と実施に分けます。たとえば稼働判定なら、「稼働判定資料の作成」「資料のレビュー」「稼働判定会の実施」です。
   • 機能や処理がまだ決まっておらず分解できない工程は、上流の各工程の最後にWBSへ追記します。
3. インフラ・非機能要件のタスクを追記する
   • システム構成図に描かれたリソースや外部接続先ごとに、「環境構築」と「連携設定」が漏れていないかを確認します。非機能要件からは、負荷テストやバックアップなど、品質を満たすために必要な作業を拾います。
4. 成果物とタスクを紐付ける
   • スコープ定義に書かれた成果物と各タスクを紐付けます。紐付くタスクがない成果物があれば、作成タスクを追加します。
5. ヒアリング結果をタスクにする
   • INPUTのヒアリングで確認できなかった点は調査タスクに、問題が見つかった点は対応検討タスクにします。
6. 粒度を適正化する
   • すべてのタスクを、担当者が最大3営業日程度で完了できるサイズまで分けます。

この段階では、「いつ・誰が」は考えません。
スケジュールや担当を決め始めると、タスクの洗い出しに集中できなくなります。まずは「やるべきことの総量」を確定させます。

粒度を適正化するときは、ドキュメントなら「章・項目」で、開発なら「レイヤー（層）」で切ると分けやすくなります。

• ドキュメント作成（章・項目で切る）
  • Before：基本設計書の作成（5日）
  • After：
    1. 表紙・変更履歴・機能一覧の作成（1日）
    2. 画面遷移図・画面レイアウトの作成（2日）
    3. 帳票レイアウト・バッチ処理フローの作成（2日）
• 画面開発（レイヤーで切る）
  • Before：会員登録機能の実装（5日）
  • After：
    1. DB定義・Entityの作成（0.5日）
    2. バリデーション・ビジネスロジックの実装（2.5日）
    3. 画面UIの実装・APIとの接続（1日）
    4. 単体テストコードの作成・実施（1日）

あわせて、「レビュー」「修正」「会議資料の作成」「議事録の確認」など、成果物に直結しない隠れタスクも洗い出します。
隠れタスクが抜けていると、工数が見えないまま膨らみます。

DOWNLOAD CONTENTで、Excel「隠れタスク・ライブラリ」を無料配布しています。
権限やファイアウォールの申請、セキュリティ部門の事前審査、業務部門との合意など、炎上の原因になりやすいタスクを工程別にまとめたものです。
自分のWBSと突き合わせて、入っていないものを取り込んでください。

Step 2 断捨離：QCDの優先度でやらないことを決める

断捨離では、「本当にやる必要があるか？」を問い、QCDの優先度に合わせてタスクを削ります。
分解したタスクは、山のような量になります。リソースは有限なので、すべてをやる前提を一度捨てます。

削るときは、次の3つの代替案（トレードオフ）を使います。

• お金で解決する
  • テストをやめて、サーバーのスペックを上げる
• 工程を短縮する
  • テスト工程を統合する
• ドキュメントを減らす
  • 詳細設計書を省略し、ソースコードを正とする

特に見直したいのが「過剰品質」です。
社内向けのシステムを、一般消費者向けと同じ品質基準で作ろうとしていないかを確認します。
問題が起きても「謝って直す」で済むなら、予防のためのタスクは捨てることも検討します。

トリアージの判断基準

削減・省略を検討できるタスクと、その条件の例です。
どれもリスクとのトレードオフなので、リスクを関係者と合意したうえで判断します。

• 要件定義：現行業務調査（AsIsフローの作成）
  • 省略できる条件：新システムやパッケージの標準フローに業務を合わせる場合
  • 考え方：新しい業務では使わない分析になるため
  • リスク：現場の「変えたくない」という反発
• 設計：詳細設計書（パラメータシート）
  • 省略できる条件：IaC（Terraform、Ansibleなど）やクラウドの標準構成を採用する場合
  • 考え方：Excelはすぐに古くなるため、コードを最新の設計図とする
  • リスク：エンジニア以外が設定値を読めなくなる
• 設計：外部IF仕様書
  • 省略できる条件：接続先がSalesforceやSlackなどの公開APIで、公式ドキュメントがある場合
  • 考え方：自社フォーマットへの転記をやめ、公式ドキュメントのURLを参照する
• 実装・単体テスト：単体テストの仕様書・成績書
  • 省略できる条件：EOL対応（単純移行）や、バグをすぐに修正・デプロイできる環境の場合
  • 考え方：文書作成の時間を、結合テスト（実際の動作確認）に回す
  • リスク：潜在バグが残る
• 結合・総合テスト：異常系・レアケースのテストシナリオ
  • 省略できる条件：業務への影響が小さい、または利用頻度が極めて低い機能（年1回の処理など）の場合
  • 考え方：正常系のみを実施する
  • リスク：エラー時の挙動が未検証になる
• 非機能：負荷テスト
  • 省略できる条件：ユーザー数が固定（社内）で、クラウドで後からスペックを上げられる場合
  • 考え方：テストの工数より、本番環境のスペックを上げる費用のほうが安い
  • リスク：最適なサイジングにならない
• 非機能：セキュリティ診断
  • 省略できる条件：VPNやイントラ内に限定され、インターネットからのアクセスが物理的に遮断されている場合
  • 考え方：WAFや境界防御で代替する
  • リスク：内部犯行や踏み台攻撃に弱くなる
• 移行：移行ツールの開発
  • 省略できる条件：データが数千件程度と少なく、移行が1回きりの場合
  • 考え方：ツールの開発より、手入力のほうが安く確実
  • リスク：入力ミス（ダブルチェックで対応）
• 移行：移行リハーサル
  • 省略できる条件：失敗しても業務が止まらず、翌週の再実施が許される場合
  • 考え方：リハーサルを省き、失敗時の切り戻し手順だけを用意する
  • リスク：リリースが延期になる可能性
• リリース：リリース判定資料（判定会議）
  • 省略できる条件：決裁者がPMや部門長レベルで、形式的な会議が不要な場合
  • 考え方：チケット管理ツールやチャットでの「Goサイン」を証跡にする
  • リスク：組織としての手続きを省くことになる

Step 3 最適化：完了定義を決め、担当と手段を割り振る

最適化では、残ったタスクごとに完了定義を明文化し、エース人材・ジュニア層・AIのどれに任せるかを決めます。
完了定義が曖昧なままだと、手戻りと担当者の「迷う時間」が生まれます。

完了定義を明文化する

曖昧な要件には、「これが確認できたら完了」という具体的な条件（テスト項目、承認者など）を書きます。
完了定義の厳しさは、INPUTで確かめたQCDの優先度で決めます。

• 要件定義・設計
  • Q重視：全ステークホルダーの承認を得る。未決事項ゼロが絶対条件。変更時は変更管理プロセスを経る
  • C/D重視：主要メンバー間で方針を合意する（メールやチャットでも可）。細部は残件管理表に移して完了とする
  • トレードオフ：Q重視は後工程の手戻りを防ぐが、合意に時間がかかる。C/D重視は着手が早いが、「言った言わない」のリスクがある
• レビュー
  • Q重視：上長や有識者を含めてレビューする。指摘をすべて直し、再確認を経てクローズする
  • C/D重視：チーム内（PLと担当者）でレビューする。修正は申し送りを付けて後に回し、タスクは完了とする
  • トレードオフ：Q重視は属人化を防ぐが、レビュアーの予定調整で止まりやすい。C/D重視は速いが、設計漏れがテストまで見つからないことがある
• プログラミング
  • Q重視：網羅率80%以上、静的解析の警告ゼロ、コードレビューの指摘対応まで完了する
  • C/D重視：動くことを最優先し、リファクタリングは後に回す
  • トレードオフ：Q重視は将来の保守が楽になるが、時間がかかる。C/D重視はPoCやプロトタイプ向き
• テスト
  • Q重視：全ケースを実施してOK。証跡を全件保存し、バグはゼロになるまで修正する
  • C/D重視：主要機能に絞る。証跡は実施ログ（OK／NG）のみ。軽微なバグは既知の不具合として台帳で管理し、完了とする
  • トレードオフ：Q重視は金融・基幹システム向け。C/D重視は重要度の低いサービス向けで、リリース後にすぐ修正する考え方
• データ移行
  • Q重視：全件の件数一致とハッシュ値の照合。本番相当のデータでリハーサルを終え、手順書を分単位で修正済み
  • C/D重視：主要テーブルの件数確認と、サンプリングチェックのみ。エラーデータは切り捨てるか、手動修正・再移行と割り切る
  • トレードオフ：Q重視はデータ消失のリスクを最小にするが、準備と移行当日の停止時間が長くなる。C/D重視は重要データ以外を後日再移行する
• リリース判定
  • Q重視：テスト消化率やバグ収束曲線などの判定基準を、すべて数値で満たす。運用マニュアルとオペレーター教育も完了する
  • C/D重視：致命的な問題がなく、残課題に運用回避策があればGoとする。マニュアルはドラフト版でも可
  • トレードオフ：Q重視はリリース延期もいとわない。C/D重視は商戦や決算など、特定の日に間に合わせることを最優先する

リソースを配分する

残ったタスクを次の3つに振り分け、担当と手段を仮決めします。

• A（注力）：エース人材
  • 難易度が高い、ロジックが複雑なタスクを任せます。「複雑な計算」や「特殊な商習慣」が絡む箇所が該当します。
• B（移譲）：ジュニア層・外注
  • 手順が決まっている定型業務を任せます。
• AI・ツール
  • 成果物のドラフト作成や定型的なコードは、AIを主体にします。

振り分けは、まずBに任せられるタスクを決め、残りをAに回します。そのうえで、AIやツールで省力化できるタスクがないかを考えます。
エース人材を単純作業ですり減らさないための順番です。

Step 4 逆算：納期から遡ってスケジュールを引く

逆算では、積み上げ式ではなく、納期（ゴール）から遡ってタスクを配置します。
直前のタスクを1つずつたぐり寄せるように、次の5つの手順で進めます。

1. ゴールを置く
   • マスタスケジュールの納期を、カレンダーに置きます。
2. 依存関係で配置する
   • 「これの直前に何が終わっていないといけないか？」を問い、直前のタスクを置きます。
3. バッファを挟む
   • 顧客承認のリードタイムやリリース不可日（金曜など）を考慮し、余白を入れながら開始日まで遡ります。
4. 並列化する
   • 並行して進められるタスクは、できるだけ並列にします。
5. 検証する
   • 開始予定日が、過去の日付になっていないかを確認します。

逆算していくと、余裕のない一本の線（クリティカルパス）が見えてきます。
この線上のタスクが遅れると、納期が遅れます。

OUTPUT 4つの工程を経たWBSの状態と効果

出力されるのはWBS1つですが、工程を経るごとにWBSの状態が磨かれていきます。

1. 分解：総量が見える
   • スケジュールと担当は未定だが、すべてのINPUTが最大3営業日程度で終わる作業として洗い出されている。「レビュー」「修正」などの隠れタスクも含む
2. 断捨離：やらないことが決まっている
   • 過剰品質や優先度の低いタスクが、削除またはグレーアウトされている
3. 最適化：実行できるアサインリストになっている
   • 各タスクに完了定義と、誰が・何で（エース／ジュニア／AI）やるかが付いている。難所にはエース、定型にはAIが配置されている
4. 逆算：依存関係が整理され、期間に収まっている
   • ゴールから逆算して配置されている。顧客承認待ちなどのバッファや、物理的な制約も組み込まれている

完成したWBSには、次の3つの効果があります。

• 断捨離済みのタスクリスト
  • 「やらないこと」が明確なので、炎上を未然に防ぎ、関係者とスコープを合意できます。
• 実行可能なアサイン表
  • 完了定義と実行手段が決まっているので、担当者が迷わず動き出せます。着手遅れ（90%完了症候群）も解消します。
• 逆算されたスケジュール
  • 依存関係と物理的な制約が組み込まれ、無理が見えるので、手遅れになる前にアラートを出して調整できます。

改善の実例：炎上プロジェクトの鎮火

粗いWBSのまま遅延していた基幹システム刷新プロジェクトが、4つの工程を適用して納期内のリリースを達成しました。

• Before：WBSが粗すぎた
  • WBSは「詳細設計」「実装」という大項目だけで、担当も個人ではなく「チーム単位」でした。
  • 現場からは「仕様が決まっておらず着手できない」「誰がやるのかわからない」という声が出ていました。
  • リリース1か月前になっても進捗がわからず、大量の未着手タスクが見つかりました。
• Action 1：分解と断捨離
  • 残タスクを画面単位まで全量分解しました。
  • 利用頻度の低い機能（帳票）を、スコープから外しました。
• Action 2：最適化と逆算
  • 難易度の高いタスクはエース人材に、それ以外は外注に配分しました。
  • 納期から逆算し、テスト工程を圧縮しました。
• After：納期内にリリース
  • 「今日やること」が明確になり、チームが自律的に動けるようになりました。
  • 重要な機能に絞ったことで、納期内のリリースを達成しました。

よくある質問（FAQ）

WBSの作成でよくある疑問にお答えします。

高解像度WBSの型のまとめ

高解像度WBSとは、担当者が「何を・どうすれば完了か」を迷わず判断できる粒度まで分解したWBSです。
企画書・提案書とヒアリングで材料をそろえ、分解・断捨離・最適化・逆算の4つの工程で作ります。

4つの工程は、足し算ではなく掛け算です。どれか1つでも欠けると、計画は機能しません。

• 分解のないWBSは、プロジェクトの「視界不良」を生みます。
• 断捨離のないWBSは、リソース不足による「炎上」を生みます。
• 最適化のないWBSは、エース級メンバーへのしわ寄せから「組織の疲弊」を生みます。
• 逆算のないWBSは、絵に描いた餅になり、「納期遅延」を生みます。

失敗するプロジェクトの多くは、手間のかかるStep 1〜3を飛ばして、いきなりスケジュールの線を引き始めます。
準備のないまま線を引かないことが、プロジェクトを確実に終わらせる近道です。

まずは今のWBSから、3営業日を超えるタスクを探して分解するところから始めてください。
DOWNLOAD CONTENTのClaudeスキルとExcel「隠れタスク・ライブラリ」を使えば、抜けやすいタスクの洗い出しから、断捨離・逆算までを手早く進められます。

DOWNLOAD CONTENT

プロジェクトの解像度を高める【Claude専用スキル＋Excel「隠れタスク・ライブラリ」】を無料配布！

※本スキルはClaude専用の「AIエージェント構築セット」です。他AIでは設計通りの動作にならない場合があります。
※生成AIの特性上、回答の正確性は保証されません。本ツールの利用により生じた不具合・損害・法的トラブル等について、当社は一切の責任を負いかねます。