WBS作成がしんどい人へ──AIで“成果物ベース”に整えるコツ

WBSづくりが大変なのは、タスクを並べる作業量よりも、計画書・議事録・スコープ・品質条件などに散らばる情報を、工程→タスク→成果物→受入条件へ落として、関係者の頭の中を揃える必要があるからです。

AIが役に立つのは「正解のWBSを当てる」ことではありません。
叩き台を速く作り、抜け漏れと未確認を可視化して、確認と合意を前倒しする。
この使い方なら、導入プロジェクトの手戻りを確実に減らせます。

先に決める：AIに作らせるのは“日程”ではなく“構造”

WBSで最初に崩れるのは、日付でも工数でもなく「構造」です。この記事では、AIに作らせる対象を最初から絞ります。

• 形式：工程 > タスク > 成果物 > 受入条件（Draft）

• 禁止：日付・人名・稼働率・金額は書かない

• 追加：最後に 未確認点／確認質問を20個 出す

この3点を固定すると、WBSが「会議で使える下書き」になります。

2つの作り方：①会話型 ②資料参照型

同じ目的（WBS叩き台）でも入口は2つあります。

• ①会話型：要点をこちらで要約して渡す（実案件で最も安全）

• ②資料参照型：計画書PDFなど“手元の資料”を参照させて作る（資料が整っているときに強い）

この記事では、サンプル計画書（PDF添付）を使い、どちらでも再現できる形にします。

① 会話型：要点を渡してWBS叩き台を作る（実案件で最も安全）

計画書の原文を貼らず、要点だけを箇条書きにしてAIへ渡します。
固有名詞・契約・金額・人名などを落としやすく、導入PJの現場で一番事故りにくい運用です。

ここでは、サンプル計画書の要点を短く整えて渡します（本文では要点抜粋、詳細は上記サンプル用プロジェクト計画書.pdfを参照）。

コピペ枠：会話型プロンプト

あなたはシステム導入プロジェクトのPM支援者です。
以下は機密を除いた“要点のみ”です（固有名詞・金額・契約条件・人名・稼働率・内部URLは含めません）。

【目的（Why）】
- {例：発注業務の電子化、リードタイム短縮、法対応、KPI など}

【スコープ（What）】
- 対象業務：{例：注文、納期回答、受領、検収、支払通知}
- システム範囲：{例：ERP連携IF、WEBフロント}
- 対象外：{例：海外仕入先は次フェーズ など}

【進め方（How）】
- 方式：{例：ウォーターフォール＋ゲート}
- 品質条件：{例：結合テスト重大バグゼロで次工程}
- 変更管理：{例：変更要求→影響評価→承認→反映}

【出力要件（必須）】
- 形式：工程 > タスク > 成果物 > 受入条件（Draft）
- 依存関係（前提タスク）があれば括弧で付記
- 日付・工数・人名・稼働率・金額は書かない
- 最後に「未確認点（Unknown）」と「確認質問」を20個出す
- “それっぽい一般論”に逃げず、上の要点に基づいて作る

まず成果物ベースでWBS叩き台を作ってください。

このプロンプトで出てきたWBSは、完成品ではなく「叩き台」です。
価値は、成果物の抜けや、未確認点（＝後で爆発するポイント）が前に出ることにあります。

【例：Geminiから上記プロンプトで出力したWBS】

② 資料参照型：計画書PDFを参照して作る（NotebookLM等）

計画書がPDFで整っている場合は、「資料を参照させて」WBSを起こす方法も強力です。
RAG：Retrieval-Augmented Generation（検索拡張生成）
の技術を使うと、AI特有のそれっぽい回答をしてしまうことの抑制や、一般論ではなく自社、自プロジェクトに沿った内容で回答を得ることができます。

ここで言いたいのは難しい用語ではなく、やっていることは単純です。

• 会話型：こちらの要点に依存する（要点整理の腕が効く）

• 資料参照型：資料から根拠を拾わせる（前提の取り違えを減らす）

Googleの NotebookLM は、PDFなどのソースを取り込み、その資料に基づいて要約・整理・質問作成を進めるためのツールです。
「計画書を読んだ上でWBSを起こす」という用途に向きます。

コピペ枠：NotebookLM向け依頼文

このノートブックに取り込んだ「プロジェクト計画書PDF」に基づいて、WBSの叩き台を作ってください。
（資料に書かれていないことは推測で断定せず、未確認として質問化してください）

【出力要件（必須）】
- 形式：工程 > タスク > 成果物 > 受入条件（Draft）
- 日付・工数・人名・稼働率・金額は書かない
- “計画書のどの記述に基づくか”が分かるように、各工程の末尾に根拠箇所（章番号や該当セクション名）を短く添える
- 最後に「未確認点（Unknown）」と「確認質問」を20個出す
- 可能なら、質問ごとに「誰に聞けば解決しやすいか（業務/IT/仕入先窓口など）」も付ける

まずは成果物ベースでWBS叩き台を提示してください。

【添付：NotebookLMを使って出力したWBS】

資料参照型の良さは、WBSが「一般論」ではなく、その計画書の前提に沿って形になりやすい点です。
レビューの場でも「どの記述を根拠にしているか」が見えると、合意が速くなります。

共通：仕上げは人がやる（ここが“手戻りを減らす”本体）

会話型でも資料参照型でも、AIが出したWBSは「仮置き」です。
手戻りを減らすのは、出力を“合意に変える”この仕上げです。

1) 成果物と受入条件を点検する

• 成果物が薄い工程はどこか（要件／移行／運用／展開が要注意）

• 受入条件が「レビュー完了」だけで終わっていないか
  → “何が満たされれば次へ進めるか”に言い換える

2) 未確認を“会議の質問”に整形する

• 誰に聞けば潰れる質問になっているか

• Yes/Noまたは選択肢で答えられる形になっているか
  未確認が質問として揃うと、WBSは「管理表」ではなく、合意形成の台本になります。

3) 抜けがちなタスク群を先に足す

WEB-EDI導入のような案件は、抜けどころがだいたい同じです。
仕入先オンボーディング（参加率90%を“作業”に落とす）、法対応（電帳法・インボイス）、運用窓口、変更管理の定着。ここを先に厚くすると、後半の炎上確率が下がります。

まとめ：AIは“WBS作成者”ではなく、叩き台と質問の製造機

整えながら進むために、叩き台を速く作り、未確認を前に出し、合意を前倒しする。
会話型で安全に始め、必要なら資料参照型（NotebookLM等）で根拠を揃える。最後は人が仕上げて、運用できるWBSにする。

次回は、ここで作ったWBSをそのまま 議事録・課題管理・リスク管理に接続して、現場で回るテンプレに落とします。

※本記事は一般的な情報提供です。実案件では所属組織の規程・契約条件・セキュリティ方針を優先してください。

新シリーズ：仕事で使えるAIの型

次に読む：

はじめての方へ