「AIにWBSを作らせたのに、出てきた内容が現場に合わない」
ChatGPT、Gemini、Claudeなどの生成AIを使えば、WBSのたたき台は短時間で作れます。
しかし、実際に使ってみると、次のような違和感が出ることがあります。
- 教科書的な工程しか出てこない
- 今回やらない作業までWBSに含まれている
- 成果物が曖昧で、何を作れば完了なのか分からない
- 顧客都合、体制、納期、外部依存などの制約が反映されていない
- そのまま工数見積やスケジュールに使えない
これは、AIの性能が低いからではありません。
多くの場合、AIに渡す前提情報が不足していることが原因です。
WBSの精度は、プロンプトの上手さだけで決まりません。
その前に、PMがプロジェクトの前提をどれだけ整理できているかで大きく変わります。
この記事では、AIでWBSを作る前にPMが整理すべき4つの前提条件を、チェックリスト、悪い入力例・良い入力例、コピペ用テンプレート付きで解説します。
この記事で分かること
この記事では、次の内容を扱います。
| 分かること | 内容 |
|---|---|
| AIのWBSが実務に合わない理由 | なぜ一般的な工程表になってしまうのか |
| 事前に整理すべき4つの前提 | スコープ・成果物・対象外・前提条件 |
| AIに渡す情報の書き方 | 悪い入力例と良い入力例 |
| コピペ用テンプレート | WBS作成前の前提情報シート |
| AI出力後のレビュー観点 | 粒度・成果物・マイルストーン・チーム確認 |
なお、具体的なWBS作成プロンプトそのものは、AIでWBSを作成するプロンプト例で詳しく解説しています。
この記事では、その前段階である「AIに渡す情報をどう整理するか」に絞って説明します。
AIにWBSを丸投げすると何が起きるか
たとえば、次のようにAIへ依頼したとします。
受注管理システム開発プロジェクトのWBSを作ってください。この依頼でも、AIは何かしらのWBSを作ってくれます。
おそらく、次のような項目が出てくるはずです。
- 要件定義
- 基本設計
- 詳細設計
- 開発
- 単体テスト
- 結合テスト
- 受入テスト
- リリース
- 運用保守一見すると、それらしい内容に見えます。
しかし、このWBSは「受注管理システム一般」のWBSです。
実際のプロジェクトでは、次のような個別事情があります。
- 今回は受注登録とステータス管理だけが対象
- 請求機能は対象外
- 既存データ移行は別チームが担当する
- テスト環境は顧客側が準備する
- 受入テストは顧客の業務部門が週2日しか対応できない
- リリース日は月末締め処理を避ける必要がある
こうした現場固有の条件をAIに渡さなければ、AIは一般的な工程しか作れません。
つまり、AIでWBSを作る前に必要なのは、プロンプトのテクニックよりも、PMによる前提整理です。
AIでWBSを作る前に整理すべき4つの前提
WBS作成前に最低限整理すべき情報は、次の4つです。
| 前提 | 書く内容 | 未整理だと起きる問題 |
|---|---|---|
| スコープ | 今回作るもの・実施すること | 対象外の作業までWBSに入る |
| 成果物 | 納品物・作成物・完了条件 | 何を作れば終わりか分からない |
| 対象外 | 今回やらないこと | 不要なタスクが混ざる |
| 前提条件 | 期間・体制・制約・依存関係 | 現実と合わない計画になる |
この4つを整理してからAIに渡すだけで、WBSの精度は大きく変わります。
1. スコープ：今回どこまで作るのか
スコープとは、今回のプロジェクトで作るもの、実施すること、対象とする業務範囲のことです。
AIにWBSを作らせるときは、まず「今回はここまで」と明示します。
たとえば、次のように書きます。
今回のスコープは、受注管理システムのうち、受注登録、受注ステータス管理、出荷指示の3機能です。
請求管理、在庫管理、会計連携は今回の対象外です。スコープが曖昧だと、AIはシステム全体を対象にしたWBSを作ります。
その結果、本来は対象外の作業が混ざり、後からPMが削除する手間が増えます。
スコープを書くときの観点
スコープを書くときは、次の観点で整理します。
| 観点 | 確認すること |
|---|---|
| 対象業務 | どの業務を扱うのか |
| 対象機能 | どの機能を作るのか |
| 対象ユーザー | 誰が使う機能なのか |
| 対象システム | どのシステム・画面・APIが対象か |
| 対象期間 | どのリリース・フェーズに含めるのか |
「受注管理システムを作る」だけでは広すぎます。
AIには、少なくとも「今回作る機能」と「今回作らない機能」をセットで渡すようにしましょう。
2. 成果物：何ができたら完了なのか
WBSは、作業を並べるだけのものではありません。
各作業が何を生み出すのか、つまり成果物が重要です。
成果物が明確であれば、AIはそこから逆算して必要なタスクを出しやすくなります。
たとえば、次のように書きます。
主な成果物は、要件定義書、基本設計書、API仕様書、テスト仕様書、テスト結果報告書、操作マニュアル、本番リリース済みシステムです。成果物が曖昧だと、AIのWBSも曖昧になります。
悪い例：
テストを行う
改善例：
テスト仕様書を作成する
結合テストを実施する
テスト結果報告書を作成する
未解決不具合一覧を整理するこのように、成果物を明確にすることで、WBSのタスクも具体化されます。
成果物を書くときの観点
成果物は、次の種類に分けて考えると整理しやすくなります。
| 種類 | 例 |
|---|---|
| 業務系成果物 | 業務フロー図、業務要件一覧、利用シナリオ |
| 設計成果物 | 基本設計書、詳細設計書、API仕様書、画面設計書 |
| 開発成果物 | 実装済み機能、設定済み環境、移行ツール |
| テスト成果物 | テスト仕様書、テスト結果、未解決不具合一覧 |
| 移行成果物 | データ移行方針、移行マッピング、移行結果 |
| 教育・運用成果物 | 操作マニュアル、運用手順書、問い合わせ体制表 |
| 管理成果物 | WBS、課題管理表、リスク一覧、リリース判定資料 |
成果物を先に書くと、AIは「その成果物を作るには何が必要か」を考えやすくなります。
3. 対象外：今回やらないこと
対象外は、WBS作成で非常に重要です。
なぜなら、AIは一般的に必要そうな作業を広めに出す傾向があるからです。
たとえば、システム導入プロジェクトなら、AIはデータ移行、ユーザートレーニング、運用設計などを自然に含めることがあります。
しかし、実際には一部が別プロジェクトや別チームの担当になっていることもあります。
その場合は、次のように明示します。
以下は今回の対象外です。
- 既存データのクレンジング作業
- 請求管理機能の開発
- 会計システムとの連携
- 本番サーバーの構築
- 運用保守契約の設計対象外を書いておくことで、AIが不要なタスクをWBSに含めるリスクを下げられます。
対象外を書くときの観点
対象外は、次の観点で確認します。
| 観点 | 確認すること |
|---|---|
| 機能 | 今回作らない機能は何か |
| 業務 | 今回扱わない業務範囲は何か |
| システム | 連携しないシステムは何か |
| データ | 移行しないデータは何か |
| 環境 | 構築しない環境は何か |
| 運用 | 今回設計しない運用範囲は何か |
| 契約 | 契約範囲外の作業は何か |
対象外は、WBSの抜け漏れ防止だけでなく、スコープ膨張を防ぐうえでも有効です。
4. 前提条件：計画に影響する制約は何か
前提条件とは、WBSの内容、粒度、順序、工数、スケジュールに影響する制約です。
たとえば、次のようなものです。
- 開発期間は3ヶ月
- PM1名、エンジニア2名の体制
- テスト環境は顧客が準備する
- 受入テストは顧客の業務部門が実施する
- 受入テスト担当者は週2日しか時間が取れない
- リリース作業は深夜2時から4時の間に限定される
- 外部APIの仕様確定は来月末予定このような前提条件をAIに渡すと、WBSに制約を反映しやすくなります。
たとえば、受入テスト担当者が週2日しか時間を取れないなら、受入テスト期間は長めに見積もる必要があります。
外部API仕様の確定が来月末なら、それまでに詳細設計や結合テストの一部が進められない可能性があります。
前提条件を書くときの観点
前提条件は、次の観点で整理します。
| 観点 | 確認すること |
|---|---|
| 期間 | 納期、リリース日、フェーズごとの期限 |
| 体制 | PM、エンジニア、業務部門、ベンダーの人数 |
| スキル | 担当者が持っているスキル、足りないスキル |
| 予算 | 追加要員や外部委託の余地 |
| 顧客都合 | レビュー可能日、受入テスト可能日、繁忙期 |
| 外部依存 | 他プロジェクト、外部API、ベンダー、インフラ |
| 技術制約 | 既存システム、セキュリティ、運用ルール |
| リリース制約 | 停止可能時間、リリース不可期間、承認フロー |
AIに前提条件を渡すときは、確定していることと未確定のことを分けて書くと、さらに使いやすくなります。
AIにWBSを依頼する前のチェックリスト
AIにWBS作成を依頼する前に、次のチェックリストを確認してください。
| チェック項目 | 確認内容 |
|---|---|
| プロジェクト目的 | 何のために実施するプロジェクトか説明できる |
| スコープ | 今回作るもの・実施することが明確になっている |
| 成果物 | 納品物・作成物・完了条件が列挙されている |
| 対象外 | 今回やらないことが明記されている |
| 期間 | 納期・主要な節目・制約日が分かっている |
| 体制 | PM、開発者、業務部門、ベンダーなどの役割が分かっている |
| 依存関係 | 外部API、顧客作業、別チーム作業などが分かっている |
| リスク | 遅延しそうな要素、未確定事項、品質懸念が分かっている |
| レビュー方法 | WBSを誰と確認するか決まっている |
| 出力形式 | AIにどの形式で出してほしいか決めている |
すべて完璧に埋める必要はありません。
ただし、空欄が多いほど、AIの出力は一般論に近づきます。
悪い入力例と良い入力例
同じプロジェクトでも、AIに渡す情報の粒度で出力は変わります。
悪い入力例
受注管理システムのWBSを作ってください。
3ヶ月くらいで開発します。この入力では、AIは一般的なシステム開発工程を返すしかありません。
対象範囲、成果物、体制、対象外、制約が分からないからです。
良い入力例
受注管理システム開発プロジェクトのWBSを作成したいです。
# プロジェクト目的
紙とExcelで管理している受注情報をシステム化し、受注状況の確認漏れと出荷指示の遅れを減らす。
# スコープ
今回の対象は、以下の3機能です。
- 受注登録
- 受注ステータス管理
- 出荷指示
# 成果物
- 要件定義書
- 基本設計書
- 画面設計書
- テスト仕様書
- テスト結果報告書
- 操作マニュアル
- 本番リリース済みシステム
# 対象外
- 請求管理機能
- 在庫管理機能
- 会計システム連携
- 既存データのクレンジング
- 運用保守契約の設計
# 前提条件
- 開発期間は3ヶ月
- 体制はPM1名、エンジニア2名、業務部門代表1名
- テスト環境は顧客側が準備する
- 受入テストは顧客の業務部門が実施する
- 外部API仕様は来月末に確定予定
# 出力してほしい形式
WBSコード、フェーズ、タスク、成果物、注意点を表形式で出してください。このように書くと、AIは一般論ではなく、今回のプロジェクトに合わせたWBSを作りやすくなります。
コピペ用：WBS作成前提情報テンプレート
以下のテンプレートを使うと、AIへ渡す前提情報を整理しやすくなります。
# WBS作成前提情報
## プロジェクト名
ここに記入
## プロジェクト目的
このプロジェクトで達成したいことを書く
## 背景・現状課題
なぜこのプロジェクトが必要なのかを書く
## スコープ
今回作るもの・実施することを書く
## 成果物
納品物・作成物・完了条件を書く
## 対象外
今回やらないことを書く
## 期間・納期
開始日、終了予定日、主要な節目を書く
## 体制
PM、開発者、業務部門、ベンダーなどの役割を書く
## 前提条件・制約
予算、レビュー可能日、外部依存、技術制約、リリース制約を書く
## 未確定事項
まだ決まっていないことを書く
## AIに注意してほしいこと
特に考慮してほしい点を書く
## 出力形式
WBSコード、フェーズ、タスク、成果物、注意点など、出してほしい形式を書くこのテンプレートを埋めてからAIに渡すと、WBSの出力精度が上がります。
より具体的なプロンプトにしたい場合は、このテンプレートを埋めたうえで、AIでWBSを作成するプロンプト例のプロンプトに差し込むと使いやすくなります。
WBSを実務で使える形にしたい方へ
AIでWBSの草案を作る前に前提を整理できても、実務では「粒度」「工数見積」「スケジュール化」「遅延時の判断」が必要です。
WBS・スケジュール管理をケースで学びたい方は、関連講座も確認してください。
WBS・スケジュール管理の講師クーポン対象講座を見る
AIが出したWBSをレビューする観点
前提を整理してAIからWBSを受け取ったら、次はPMがレビューします。
AI出力は、完成版ではありません。
少なくとも、次の観点で確認してください。
| 観点 | 確認すること | よくある問題 |
|---|---|---|
| スコープ | 対象業務・対象外業務が混ざっていないか | 対象外と書いた作業が入っている |
| 成果物 | 各タスクの完了条件が明確か | 何を作れば終わりか分からない |
| 粒度 | 担当者を割り当てられ、工数見積できる単位か | 「開発」「テスト」など粗すぎる |
| 依存関係 | 前後関係や待ちが見えているか | 外部API確定前に結合テストが置かれている |
| マイルストーン | 顧客確認・承認・リリース判定の節目があるか | タスクだけで判断ポイントがない |
| プロジェクト管理 | 進捗管理、課題管理、リスク管理が含まれているか | 作る作業だけで管理作業が抜ける |
特に重要なのは、対象外が混ざっていないか と 成果物が明確か です。
AIは、一般的に必要そうな作業を広めに出すことがあります。
そのため、契約範囲や合意事項と照らし合わせながら、WBSを必ず見直してください。
WBSにマイルストーンを追加する
AIが作るWBSには、タスク一覧は入っていても、マイルストーンが不足していることがあります。
マイルストーンは、プロジェクトの重要な節目です。
たとえば、次のようなものです。
| マイルストーン | 確認すること |
|---|---|
| 要件定義完了 | スコープ・優先順位・成果物が合意できているか |
| 設計完了 | 実装に入れる状態か |
| テスト開始判定 | テスト対象・環境・データが準備できているか |
| 受入テスト完了 | 顧客が利用開始できると判断しているか |
| リリース判定 | 未解決課題と残リスクを踏まえて本番移行できるか |
AI出力にマイルストーンが不足している場合は、次のように追加依頼します。
このWBSに、プロジェクトの主要マイルストーンを追加してください。
マイルストーンは4〜6個程度とし、要件定義完了、設計完了、テスト開始判定、受入テスト完了、リリース判定など、顧客確認や意思決定が必要な節目を含めてください。
各マイルストーンについて、確認すべきことも表形式で整理してください。WBSは、タスクを並べるだけでは不十分です。
PMとしては、どこで何を判断するかまで見えるようにする必要があります。
WBSをチームで確認する
AIで作ったWBSを、PMだけで完成させるのは危険です。
実作業を担当するメンバーには、PMが見落としている作業、技術的な制約、実装上の依存関係が見えていることがあります。
そのため、AIが作ったWBSは、チームで確認するプロセスを設けてください。
チームレビューでは、次のように聞くとよいです。
このWBSを見て、担当する作業で抜けているものはありますか？
この粒度で見積もりできますか？
順序が逆になっているタスクはありますか？
技術的に待ちが発生しそうなタスクはありますか？
このタスクの成果物は明確ですか？AIが下書きを作り、PMが前提を整え、チームが実務観点で直す。
この流れにすると、WBSの品質と作成スピードを両立しやすくなります。
WBSを更新するときも前提を渡す
プロジェクトが進むと、WBSは更新が必要になります。
たとえば、次のような状況です。
- スコープが変更された
- 外部APIの仕様確定が遅れた
- テスト環境の準備が遅れた
- 顧客レビューに時間がかかった
- 追加タスクが発生した
このときも、AIに「WBSを直して」とだけ依頼するのではなく、変更内容を具体的に渡します。
以下のWBSについて、外部API仕様の確定が2週間遅れました。
この影響を受けるタスク、順序を見直すべきタスク、追加すべきリスク、関係者へ確認すべきことを整理してください。
# 変更内容
外部API仕様の確定予定が6月末から7月中旬に変更
# 確認したいこと
- 影響を受けるWBSタスク
- 後続タスクへの影響
- スケジュール上のリスク
- 顧客・ベンダーへ確認すべきことAIは、変更点を整理する壁打ち相手としても使えます。
ただし、最終的にWBSを更新し、関係者と合意するのはPMの役割です。
よくある質問
前提情報がまだ決まっていない場合はどうすればよいですか？
未確定事項として明示してAIに渡してください。
たとえば、
受入テストの担当者は未確定です。
外部API仕様の確定日は未確定です。
データ移行の対象範囲は現在確認中です。のように書きます。
未確定であることをAIに伝えれば、確認タスクやリスクとしてWBSに含めやすくなります。
対象外はどこまで細かく書くべきですか？
契約範囲や責任範囲に関わるものは、できるだけ明記してください。
特に、データ移行、インフラ構築、外部連携、運用保守、ユーザートレーニングは、プロジェクトによって扱いが変わりやすい領域です。
このあたりを曖昧にすると、AIが一般論でWBSに含めてしまう可能性があります。
成果物がまだ決まっていない場合はどうすればよいですか？
成果物候補として書いてください。
成果物候補：
- 要件定義書
- 画面設計書
- テスト仕様書
- 操作マニュアル
- リリース判定資料のように書いたうえで、AIに「成果物として不足しているものがあれば指摘してください」と依頼すると、整理が進みます。
WBS作成前提情報は誰と確認すべきですか？
少なくとも、PM、開発リーダー、顧客窓口、業務部門代表で確認するのが望ましいです。
案件によっては、インフラ担当、セキュリティ担当、運用担当、外部ベンダーも含めます。
AIに渡す前提情報を整理する過程そのものが、関係者の認識合わせになります。
関連講座
WBS作成、工数見積、スケジュール管理を体系的に学びたい方は、以下の講座が参考になります。
WBS・スケジュール管理を実務ケースで学ぶ
AIでWBSの草案を作る前に前提を整理できても、実務ではタスク粒度、工数見積、スケジュール遅延時の判断が必要です。
WBS・スケジュール管理の講師クーポン対象講座を見る
生成AIをPM実務に活用する
WBS、見積、前提整理、報告資料作成など、AIをPM業務に活用したい方におすすめです。
生成AI活用の講師クーポン対象講座を見る
まとめ
AIでWBSを作るときに重要なのは、AIに丸投げしないことです。
WBSの精度は、AIに渡す前提情報で大きく変わります。
最低限、次の4つを整理してからAIに依頼しましょう。
スコープ
成果物
対象外
前提条件この4つを整理すると、AIの出力は一般論から現場寄りのWBSに近づきます。
そして、AIが作ったWBSは完成版ではなく、あくまで下書きです。
PMがレビューし、チームで確認し、マイルストーンや制約を反映して、実際に管理できるWBSへ育てる必要があります。
AIは、WBS作成を代替する存在ではありません。
PMが考えるべき論点を早く見える化し、白紙から考える時間を減らしてくれる道具です。