「AIにWBSを作らせると、教科書的な構成しか出てこない」──実務で使えるWBSを求めてAIを使い始めたPMが最初に感じる壁です。
WBSの精度はインプットの精度と比例します。スコープ・成果物・除外範囲・前提条件を整理してからAIへ渡すと、出力が現場に近いものになります。
AIにWBSを丸投げするとズレる理由
「〇〇システムの開発プロジェクトのWBSを作って」という指示だけでは、AIはシステム開発の一般的な工程を網羅した構成を返します。要件定義・基本設計・詳細設計・実装・テスト・リリース、といった教科書的な骨格です。
問題は、実際のプロジェクトは常にその一般形から外れているところにあります。顧客が要件定義を省いてほしいと言っている、テストは顧客自身がやる、インフラは別チームが担当する──こういった現場固有の事情はPMしか知りません。
AIは入力した情報で作業を組み立てます。現場の事情を入力しなければ、一般形のWBSから先へ進めません。
決めること1：スコープ
今回のプロジェクトで何を作るか・何を実現するかを書きます。
例：
- 「受注管理システムの受注登録・ステータス管理・出荷指示の3機能を新規開発する」
- 「既存システムのAPIと連携するBFFレイヤーを構築する」
スコープが曖昧なまま渡すと、AIはシステム全体の開発を前提にした工程を出します。「今回はここだけ」を明示することが最初のステップです。
決めること2：成果物
最終的に何を顧客へ納品・引き渡すかを書きます。
例：
- 動作するシステム（本番環境へのリリース）
- 設計書・テスト仕様書・操作マニュアル
- 受け入れテスト合格報告書
成果物の一覧があると、AIはそれを作るために必要な工程を逆算して構成できます。「設計書が必要なら詳細設計フェーズのタスクを増やす」「マニュアルが必要なら執筆・レビューのタスクを追加する」という形です。
決めること3：対象外
今回のプロジェクトに含まれないものを明示します。
例：
- 「既存データの移行は対象外（別プロジェクトで扱う）」
- 「テスト環境の構築は顧客インフラチームが担当する」
- 「マスタデータの整備は別途ユーザー部門が実施する」
対象外を書くと、AIがWBSに含めてしまうタスクを事前に除外できます。出力後に「これは関係ない」とPMが削る手間が減ります。
決めること4：前提条件
プロジェクト特有の制約や、作業の前提となる条件を書きます。
例：
- 「開発環境は顧客側で提供される。準備完了は○月○日予定」
- 「受け入れテストは顧客の業務部門が実施する。参加者は週2日しか時間が取れない」
- 「リリースはメンテナンス時間帯（深夜2〜4時）に限定される」
前提条件は、WBSの工数やスケジュールに直接影響します。「テストが週2日しかできない」ということはWBSのテストフェーズが長くなることを意味し、AIへ渡せばそれを反映した構成が出やすくなります。
AI出力をレビューする観点
前提を整えてAIからWBSを受け取ったら、以下の観点でレビューします。
網羅性の確認
- 成果物に対応するタスクが全て含まれているか
- 対象外として書いたタスクが混じっていないか
- 前提条件に関わるタスクが反映されているか
粒度の確認
- 最小のタスクが「担当者1人が1〜2日で完了できる単位」になっているか
- 粗すぎるタスクはあるか（「実装」だけで1行の場合など）
依存関係の確認
- タスクの順番が論理的に正しいか
- 前後関係が逆になっているタスクはないか
AIが出したWBSは構成の出発点です。レビューを経て現場に合わせた修正を加えることで、実態に使えるものになります。
AIにWBSを生成させる前に確認すべきこと
AIにWBSの生成を依頼する前に、「プロジェクトの制約条件」を整理してください。確認すべき制約は「期間・人数・利用可能なスキルセット・依存する他プロジェクトや外部要因」の4点です。
これらの制約をAIへの入力に含めないと、AIは制約のない理想的なWBSを生成します。制約なしのWBSは、実際のリソースと乖離が大きく、修正に多くの時間がかかります。「入力を整える時間」に投資することで、「修正の時間」を大幅に節約できます。
AIが生成したWBSの「粒度」を確認する
AIが生成したWBSは、タスクの粒度が不均一になることがあります。ある部分は細かく分解されているのに、別の部分は大まかなままという状態です。
粒度の確認基準として「最小単位のタスクが1〜3人日以内で完了できるか」を使ってください。3人日を超えるタスクがある場合は、さらに分解が必要です。逆に0.5人日未満のタスクが多い場合は、統合を検討します。AIが生成した粒度をそのまま使わず、PMが確認して調整することで、追跡しやすいWBSが完成します。
WBSにマイルストーンを追加する
AIが生成するWBSにはタスクの一覧が含まれますが、マイルストーンが入っていないことがあります。マイルストーンは「顧客への確認タイミング」「フェーズの区切り」「主要な成果物の完成」を示す目印です。
「このWBSにプロジェクトのマイルストーンを追加してください。マイルストーンは4〜6個で、各フェーズの完了と顧客確認のタイミングを含めてください」という追加指示でAIにマイルストーンを加えてもらうか、PMが手動で追加してください。マイルストーンがあると、進捗の全体像が見やすくなります。
WBSを「チームで確認する」プロセスを設ける
AIで生成したWBSを、チームメンバーとレビューするプロセスを設けてください。PMだけで確認したWBSには、実作業の担当者から見た「見落とし」が含まれていることがあります。
「このWBSを見て、担当する作業で抜けているものがあれば教えてください」という問いかけで、チームからフィードバックを収集します。チームが参加して作ったWBSは、メンバーの納得感が高く、実行されやすくなります。AIが「下書き」を作り、チームが「完成させる」というプロセスが、WBS設計の質と効率を両立させます。
AIを使ったWBS生成は、設計の「起点作り」に最も効果を発揮します。ただし制約情報の整理・粒度の確認・マイルストーンの追加・チームレビューという後工程をPMが担うことで、実際に機能するWBSが完成します。AIは「ゼロからイチを作る手間」を省く道具であり、「イチを百に育てる」のはPMの仕事です。この役割分担を守ることがWBS設計の品質を高めます。
WBSをAIで更新・修正する方法
プロジェクトが進むにつれてWBSを更新する必要が生じます。AIを使ったWBSの更新も、最初の生成と同様に「現在の状態と変更内容を入力する」アプローチが有効です。「以下のWBSで〇〇のタスクが完了しました。残りのスケジュールを見直してください」という指示で、AIがWBSの修正提案を生成します。更新のたびに1からWBSを作り直す必要がなく、AIが変更点を反映した修正案を出すことで、管理コストが下がります。
WBS設計と受託開発PM実務を体系的に学びたい方は、生成AI×PM実務パックと受託開発PM向けの課題別パックをご覧ください。
Udemyコースの一覧はコース一覧ページで確認できます。