📊 WBS作成・管理に特化したAIプロンプト術【コピペOK】

はじめに

「WBSを作るたびに抜け漏れが出る…」
「タスクの粒度が人によってバラバラになる…」
「工数見積もりがいつも甘くて、後半に詰まる…」
「仕様変更でWBSが崩壊して、更新が追いつかない…」

WBSは「作る」より**「使い続ける」ことの方が難しい**。
このプロンプト集は、WBSの作成・分解・工数見積もり・更新・管理まで、プロジェクトの一生をAIでサポートする設計にしました。

---

🗺️ WBS活用フロー

[プロジェクト概要の整理]
      ↓
[成果物ベースの分解（WBS第1〜2層）]
      ↓
[タスクへの展開（WBS第3層以降）]
      ↓
[工数・期間の見積もり]
      ↓
[依存関係・クリティカルパスの整理]
      ↓
[進捗管理・変更対応]

---

フェーズ1：プロジェクト概要の整理

✅ プロンプト①：プロジェクト概要からWBSの骨格を作る

以下のプロジェクト概要をもとに、WBSの骨格（第1層・第2層）を作成してください。

【プロジェクト概要】
- プロジェクト名：
- 目的・ゴール：
- 対象範囲（スコープ）：
- 対象外（スコープ外）：
- 開始日・終了日：
- 主な成果物（納品物）：
- チーム構成：

【出力形式】

■ WBS 骨格

1. プロジェクト管理
   1.1 キックオフ・計画
   1.2 進捗管理・報告
   1.3 品質管理
   1.4 リスク管理
   1.5 クローズ・振り返り

2. [成果物1]
   2.1
   2.2
   …

3. [成果物2]
   3.1
   3.2
   …

■ WBS作成の前提・判断メモ
- スコープに含めた理由 / 除外した理由
- 「ここは第2層のまま」にした理由（詳細分解が不要な部分）

最後に「このWBSで見落としがちな作業カテゴリ」を3つ指摘してください。

---

✅ プロンプト②：スコープ外・グレーゾーンを明確にする

以下のプロジェクト概要について、「スコープの境界線」を明確にしてください。

【プロジェクト概要】
（貼り付け）

【出力内容】

■ スコープ内（明確にやること）

■ スコープ外（明確にやらないこと）

■ グレーゾーン（解釈によってスコープに入り得るもの）
  → 各項目に「どちらと判断すべきか・確認が必要か」のコメントを添える

■ スコープクリープが起きやすいポイント
  → 後からタスクが増えやすいリスクポイントTop3

■ ステークホルダーとの合意が必要な確認事項
  → 合意しておくべき質問リスト（5問以内）

「後からスコープが広がって破綻するプロジェクト」のパターンを踏まえて分析してください。

---

フェーズ2：成果物ベースの分解

✅ プロンプト③：成果物をWBSの第3層まで分解する

以下のWBS第2層の項目を、第3層（実際の作業タスク）まで分解してください。

【WBS第2層の項目】
（例：「3.2 APIサーバー実装」）

【プロジェクト文脈】
- 技術スタック：（例：Python / FastAPI / PostgreSQL）
- チームスキル：（例：Python中級者2名）
- 期間：（例：3週間）

【分解ルール】
- 1タスクは「1人が1〜3日で完了できる粒度」に
- タスク名は「動詞＋目的語」の形式で（例：「認証APIを実装する」）
- テスト・レビュー・ドキュメントも必ずタスクに含める

【出力形式】

3.2 APIサーバー実装
  3.2.1 API設計書を作成する
  3.2.2 開発環境をセットアップする
  3.2.3 〇〇エンドポイントを実装する
  3.2.4 単体テストを実装する
  3.2.5 APIドキュメント（Swagger）を整備する
  3.2.6 コードレビューを実施する

各タスクに「担当者区分（開発者/リーダー/全員）」と「成果物（何が完成すればOKか）」を添えてください。

---

✅ プロンプト④：見落としがちな「隠れタスク」を洗い出す

以下のWBSを読み、見落とされがちな「隠れタスク」を洗い出してください。

【現在のWBS】
（貼り付け）

【プロジェクト種別】
（例：Webシステム開発 / データ分析基盤構築 / 業務自動化ツール開発）

【チェックカテゴリ】
以下の観点で隠れタスクを探してください：

□ 環境構築系
  - 開発環境・テスト環境・本番環境のセットアップ
  - CI/CDパイプラインの構築

□ 連携・調整系
  - 外部システムとの接続テスト
  - ステークホルダーとのレビュー・承認フロー
  - ベンダーとの調整

□ ドキュメント系
  - 設計書・仕様書・手順書の作成
  - 運用マニュアルの整備

□ テスト・品質系
  - テスト計画書の作成
  - 結合テスト・受け入れテスト
  - 性能テスト・セキュリティチェック

□ 移行・リリース系
  - データ移行手順の設計と実施
  - リリース手順書の作成
  - 本番リリース・切り替え作業
  - リリース後の監視・ホットフィックス対応

□ プロジェクト管理系
  - 週次報告・議事録作成
  - リスク管理台帳の更新
  - 変更管理プロセス

追加すべきタスクを、WBSの該当箇所に挿入する形で出力してください。

---

フェーズ3：工数・期間の見積もり

✅ プロンプト⑤：タスクの工数を三点見積もりで算出する

以下のWBSタスクリストについて、三点見積もりを実施してください。

【タスクリスト】
（タスクを列挙）

【チーム情報】
- スキルレベル：（例：シニアエンジニア1名、ミドル1名）
- このプロジェクト技術の習熟度：（例：メイン技術は経験あり、一部ライブラリは初使用）
- 過去の類似プロジェクト実績：（例：類似システム開発を1件経験済み）

【三点見積もり形式】

| タスクID | タスク名 | 楽観値(O) | 最頻値(M) | 悲観値(P) | PERT期待値 | 標準偏差 | バッファ込み |
|---------|---------|----------|----------|----------|----------|---------|-----------|
※ PERT期待値 = (O + 4M + P) / 6
※ バッファ込み = PERT期待値 × 1.2（通常）または × 1.5（不確実性高）

【追加出力】
- 見積もりの不確実性が高いタスク（バッファを多めに取るべきもの）と理由
- 「この工数見積もりが大きく外れるシナリオ」Top3
- 工数削減のために事前に解消すべきリスク

---

✅ プロンプト⑥：プロジェクト全体のスケジュールを組む

以下のWBSと工数見積もりをもとに、プロジェクトスケジュールを作成してください。

【WBSと工数見積もり】
（タスク名と工数を列挙）

【プロジェクト条件】
- 開始日：
- 終了期限：
- 稼働日数（週何日か）：
- 開発者人数と稼働率：（例：2名、各80%稼働）
- 休日・特定の不稼働日：

【出力内容】

■ マイルストーン一覧
| マイルストーン名 | 目標日 | 完了条件 |
|--------------|-------|---------|

■ タスクのスケジュール表（テキストガントチャート）

タスク名	W1	W2	W3	W4	W5	W6
1.1 要件定義	██
1.2 設計		██	█
…

■ スケジュールリスク
- バッファが少ないタスク（クリティカルパス候補）
- 並行作業が難しい依存関係
- 期限に間に合わないリスクと対応策

■ 「この日程で進めるための前提条件」リスト

---

✅ プロンプト⑦：クリティカルパスを特定する

以下のタスクリストの依存関係を整理し、クリティカルパスを特定してください。

【タスクリスト（工数付き）】
（タスク名・工数・前提タスクを列挙）
例：
- T01：要件定義（3日）　前提：なし
- T02：DB設計（2日）　前提：T01
- T03：API設計（2日）　前提：T01
- T04：DB構築（1日）　前提：T02
- T05：API実装（5日）　前提：T03、T04

【出力内容】

■ タスク依存関係図（テキスト形式）
T01 → T02 → T04 → T05 → …
     → T03 ↗

■ クリティカルパス
（プロジェクト全体の最長経路）

■ 各タスクのフロート（余裕日数）
| タスクID | タスク名 | 最早開始日 | 最遅開始日 | フロート |
|---------|---------|----------|----------|--------|

■ クリティカルパスへの対策
- クリティカルタスクの工数を短縮する方法
- 並行作業できる可能性があるタスク
- リソースを重点投下すべきタスク

---

フェーズ4：依存関係・リスク管理

✅ プロンプト⑧：タスク間の依存関係と待ち時間リスクを整理する

以下のWBSについて、タスク間の依存関係と「待ち時間が発生するリスク」を整理してください。

【WBS】
（貼り付け）

【チーム・外部関係者】
（例：開発チーム2名、クライアント、外部APIベンダー）

【出力内容】

■ 依存関係マトリクス
| タスク | 先行タスク | 後続タスク | 依存の種別 |
|------|----------|----------|----------|
※ 依存種別：FS（前が終わったら開始）/ SS（前と同時開始可）/ FF（前と同時完了）/ 外部待ち

■ 外部待ちリスク一覧
（クライアント承認・ベンダー回答など、自チームでコントロールできない待ち時間）
| 待ちイベント | 影響タスク | 待ち期間の想定 | 対策 |
|-----------|---------|-------------|-----|

■ ボトルネックになりやすいタスク
（多くのタスクが依存している「詰まると全体が止まる」タスク）

■ 並行作業で短縮できるタスク組み合わせの提案

---

✅ プロンプト⑨：WBSベースのリスク管理台帳を作成する

以下のWBSをもとに、プロジェクトリスク管理台帳を作成してください。

【WBS】
（貼り付け）

【プロジェクト特性】
（例：新技術の採用あり、ステークホルダー多数、期限固定）

【出力形式】

■ リスク管理台帳

| リスクID | リスク内容 | 関連WBS項目 | 発生確率(H/M/L) | 影響度(H/M/L) | リスクスコア | 対応方針 | 対応アクション | 担当者 | 期限 |
|--------|---------|-----------|--------------|-------------|-----------|---------|-------------|------|-----|

■ 上位リスクTop5の詳細分析
各リスクについて：
- リスクシナリオ（どういう状況で発生するか）
- 早期警戒サイン（このサインが出たら要注意）
- 発生時の対応手順

■ リスク対応方針の分類
- 回避（リスクを発生させない）
- 軽減（発生確率・影響度を下げる）
- 転嫁（保険・契約で第三者に移す）
- 受容（対応コストが影響より大きい場合）

---

フェーズ5：進捗管理・変更対応

✅ プロンプト⑩：週次進捗レポートをWBSから自動生成する

以下のWBSの進捗状況をもとに、週次ステータスレポートを生成してください。

【WBSと進捗状況】
（タスク名・予定完了日・実際の完了状況・残作業を列挙）
例：
- T01 要件定義：完了（予定通り）
- T02 DB設計：完了（1日遅延）
- T03 API設計：進行中（70%完了、予定通り）
- T04 DB構築：未着手（開始予定日：今週）

【出力形式】

# 週次ステータスレポート（第〇週）

## 総合ステータス
🟢 オンスケ / 🟡 要注意 / 🔴 遅延リスク

## 今週の実績
- 完了タスク：
- 進行中タスク（進捗%）：
- 課題・ブロッカー：

## スケジュール状況
- 現在の遅延：（日数）
- クリティカルパスへの影響：
- 挽回計画（あれば）：

## 来週の予定タスク

## ステークホルダーへの共有事項・要判断事項

200字以内の「エグゼクティブサマリー」も冒頭に添えてください。

---

✅ プロンプト⑪：仕様変更のWBSへの影響を分析する

以下の仕様変更が発生しました。現在のWBSへの影響を分析してください。

【変更内容】
（変更の詳細を記述）

【現在のWBS（または該当部分）】
（貼り付け）

【現在のプロジェクト状況】
- 全体進捗：（例：40%完了）
- 残り期間：（例：4週間）
- 変更発生時点での完了済みタスク：

【出力内容】

■ 変更の影響範囲
- やり直しが必要なタスク（完了済みのもの）
- 追加が必要な新規タスク
- 変更が不要なタスク（影響なし）

■ 追加工数の見積もり
| 影響タスク | 変更前工数 | 変更後工数 | 差分 |
|----------|----------|----------|-----|
合計追加工数：

■ スケジュールへの影響
- 遅延日数の概算：
- マイルストーンへの影響：
- クリティカルパスの変化：

■ 意思決定オプション
- オプションA：変更を受け入れ、期限を延ばす → 影響：
- オプションB：変更を受け入れ、スコープを削る → 削れるタスク：
- オプションC：変更を断る / 次フェーズに先送り → リスク：

ステークホルダーへの説明資料として使える形で出力してください。

---

✅ プロンプト⑫：プロジェクト完了時のWBS振り返りを構造化する

以下のWBSと実績データをもとに、プロジェクト振り返りを構造化してください。

【WBS（計画値）と実績値】
| タスク名 | 計画工数 | 実績工数 | 完了日（計画） | 完了日（実績） |
|--------|---------|---------|------------|------------|
（貼り付け）

【出力内容】

■ 工数精度分析
- 見積もり精度（計画比）が高かったタスクTop3と理由
- 見積もりが大きく外れたタスクTop3と原因分析

■ スケジュール逸脱の要因分析
- 遅延の主原因（技術的困難 / 要件変更 / リソース不足 / 外部依存 / 見積もり甘さ）
- 遅延を防げたポイント（早期に発見できた兆候があったか）

■ WBS設計上の改善点
- タスク粒度が適切でなかった箇所
- 隠れタスクとして後から追加されたもの一覧
- 依存関係の見落としがあった箇所

■ 次プロジェクトへの教訓
- WBS作成時に追加すべきチェック項目（3〜5個）
- 見積もり精度を上げるための対策
- 再利用できるWBSテンプレートの候補部分

「同じ轍を踏まないための具体的なアクション」にフォーカスして出力してください。

---

🎁 WBSプロンプト強化ワード

状況	追加ワード
タスクの粒度を揃えたい	「1タスク＝1人が1〜3日で完了できる粒度で分解して」
抜け漏れを防ぎたい	「設計・実装・テスト・ドキュメント・レビューを全タスクに含めて」
工数を保守的に見積もりたい	「初めて使う技術のタスクはバッファ×1.5で計算して」
報告資料として使いたい	「非技術者のマネージャーが読んでも判断できる言葉で」
変更耐性を高めたい	「変更が発生した場合の影響範囲が最小になる分解構造で」

---

WBS設計の3原則

原則1：成果物ベースで分解する

「作業ベース（何をするか）」ではなく「成果物ベース（何ができるか）」で分解すると、完了条件が明確になり、進捗の判断が楽になります。

原則2：100%ルールを守る

WBSの各層は、親タスクの作業を100%カバーしていなければなりません。
「なんとなくタスクを並べる」のではなく、「これを全部やれば親タスクが完了する」という確認を必ずしましょう。

原則3：タスクの完了条件を言語化する

「実装する」ではなく「〇〇機能の実装が完了し、単体テストがすべてパスしている」のように、完了条件を具体化することで、チーム内の認識ズレを防げます。

---

おわりに

WBSは「プロジェクト開始時に完璧に作る」ものではなく、「プロジェクトを通じて更新し続ける」生き物です。

AIを使って初版の作成コストを大幅に下げて、その分を「レビューと更新」に使いましょう。

「この場面のプロンプトも欲しい！」はコメントへ🐇

---