2026年10月10日確認。IT・AI導入の計画を作るとき、「何をどこまで渡すのか」「誰の確認で完了か」「見積と日程は成立するか」をそろえるためのWBSの作り方を整理します。
WBS（Work Breakdown Structure）は、プロジェクトの成果物と、その実現に必要な範囲を階層的に分解するものです。見積・担当・完了判断の土台になります。PMIの公式解説
この記事の判断の問いは、成果物をどの単位まで分け、どんな情報を付ければ、実行と完了確認に使える計画になるかです。
この記事はPMI・NASA・GAO・Scrum Guideの公開資料をもとにした実務への適用案です。問い合わせ下書き支援の例は架空の設計例であり、顧客案件の報告や本人のPM・コンサル実績ではありません。PoCの実行、工数・効果の測定、関係者との合意は未実施です。
1. WBS・作業一覧・ガントの役割を分ける
| 道具 | 答える問い | 問い合わせ下書き支援での例 |
|---|---|---|
| スコープ定義 | 何のために、どこまで引き受けるか | 導入可否の判断まで。実顧客への送信は対象外 |
| WBS | 何を完成させるか | 評価用データ、比較結果、導入判断書 |
| WBS辞書 | 各成果物の内容と完了条件は何か | 比較対象、担当、対象外、受入条件 |
| 作業一覧 | 成果物を作るために何をするか | データを用意する、実行する、結果を確認する |
| スケジュール・ガント | どの順序で、誰が、いつ行うか | 評価基準の合意後に検証し、確認期間を置く |
WBSで成果物を定義し、必要な活動を取り出して、依存関係・期間・稼働を日程へ反映します。日付付きの表を「WBS」と呼ぶ現場でも、この意味の区別を保つと計画を点検しやすくなります。PMI：WBSからスケジュールへの展開
この図は、記事の設計案を整理したものです。
2. 最初に目的・成果物・対象外を合わせる
今回の架空例では、最初の約束を次のように置きます。
| 項目 | 今回の設計例 |
|---|---|
| 目的 | 問い合わせ回答の下書きにAIを使うか判断できるようにする |
| 対象 | 業務整理、方式比較、架空データによるローカルPoC、判断資料、引継ぎ |
| 対象外 | 本番構築、実顧客への送信、全社展開 |
| 判断の選択肢 | 導入、見送り、条件を変えた追加検証 |
| 受入確認者 | 業務責任者・技術責任者。具体的な担当と権限は計画時に合意する |
AIの採用を成果物の受入条件にすると、検証で問題が見つかっても、採用に都合のよい報告へ寄せる誘因が生まれます。この例では、合意した方法で判断に使える証拠を渡すことを完了条件にします。
成果物の内容は、実際に作る人と受け取る人で確認します。「調査する」から一段進めて「選択肢比較表」「評価結果報告書」のように、確認できる結果を置きます。PMI：成果物を軸にした共同でのWBS作成
3. 漏れ・重複・粒度を点検する
合意した範囲の100%を含める
100%ルールは、合意したスコープの全体を含め、範囲外の仕事を混ぜない原則です。子の要素で親の内容を満たします。内部・中間成果物、プロジェクト管理も含まれます。PMI：100%ルール
IT案件へ適用するときは、機能の実装に加え、必要なデータ準備、テスト、レビュー、教育、移行、引継ぎを点検します。今回の例では本番移行は対象外なので、実施する仕事として混ぜません。
共通部品や同じレビューを複数の枝へ重複して置くと、見積を二重計上しやすくなります。置き場所を決め、利用する側から参照します。
要件と対応づける
小規模なら「要件ID／WBS ID／受入条件」の対応表から始められます。
- 要件があるのに対応する成果物がない：漏れの候補。
- 成果物に対応する要件・合意がない：対象外や追加作業の候補。
NASAのハンドブックも要件とWBSの対応表を紹介しています。NASA固有の契約・会計の手続きまで、小規模IT案件へ一律に持ち込む必要はありません。NASA WBS Handbook、本文17–18ページ
管理できる単位まで分ける
分解の深さは、規模・複雑さ・不確実性と、必要な管理の程度で変わります。全ての枝を同じ深さにする必要はありません。直近を具体化し、先の仕事は概要を保持して段階的に分解できます。NASA、本文18–20ページ
ここからの適用案として、次の四つが答えられる粒度を目安にします。
- 成果責任者を決められるか。
- 見積と、その前提を説明できるか。
- 完了条件と証拠を決められるか。
- 次の確認時に、残作業と障害を説明できるか。
一律の時間幅へ機械的に合わせるより、その案件で管理できるかを確認します。
4. AI導入判断のWBSを作る
以下は今回の架空の対象範囲を分解した例です。工数・担当者・期限は未合意です。
1 問い合わせ下書き支援の導入判断一式
├─ 1.1 業務・範囲の合意資料
│ ├─ 1.1.1 対象業務・現状の整理表
│ └─ 1.1.2 要件・対象外・受入条件の合意表
├─ 1.2 比較・評価の設計資料
│ ├─ 1.2.1 手作業／FAQ検索／AIの比較条件表
│ ├─ 1.2.2 架空データ・評価ケース・判定基準
│ └─ 1.2.3 データ・権限・人の確認・失敗時の設計表
├─ 1.3 PoCと検証証拠
│ ├─ 1.3.1 再現可能な最小PoCと実行手順
│ └─ 1.3.2 品質・費用・確認負担の比較結果
├─ 1.4 判断・引継ぎ資料
│ ├─ 1.4.1 条件付きの推奨・見送り・追加検証の判断書
│ └─ 1.4.2 次段階の範囲案・制約・引継ぎ手順
└─ 1.5 プロジェクト管理記録
├─ 1.5.1 役割・日程・合意した計画
├─ 1.5.2 進捗・課題・リスク・変更の記録
└─ 1.5.3 成果物の受入・終了確認記録
AI案件では、機能に加えて、許可する操作、人の承認、例外時の引渡し、評価・監視も範囲に含まれます。PMI：AIエージェントを含むWBS
この例では、PoCに先立つ「1.2.3」で、使う情報、許可する操作、人が確認する対象、回答できない場合の対応先を決めます。人の確認負担は「1.3.2」の評価対象にします。検証で残った制約と、実運用に進むなら必要な監視は「1.4.2」へ引き継ぎます。
5. 一つの成果物をWBS辞書で具体化する
「比較結果」という名前だけでは、対象・評価方法・完成の意味がそろいません。次は「1.3.2」を具体化した記入例です。
| 項目 | 架空の記入例 |
|---|---|
| 成果物 | 品質・費用・確認負担の比較結果 |
| 含む範囲 | 合意した条件での各方式の結果、失敗、未測定、制約の分析 |
| 対象外 | 本番品質保証、顧客データでの評価、未測定の年間削減効果 |
| 成果責任者 | 検証担当者。具体的な担当者は計画時に決める |
| 受入確認者 | 業務責任者。確認対象と権限を合意する |
| 前提 | 比較条件、評価ケース・基準、データ・権限設計が合意済み |
| 完了条件 | 全対象ケースの結果・未実行・失敗・未測定・制約を記録し、再現手順と条件付きの結論を説明。指定の確認者が受入条件への適合を確認する |
| 証拠 | 版管理した評価ケース、実行記録、比較表、受入確認記録 |
個別の成果物に責任の所在を明確にし、辞書で内容と受入条件を定義します。責任窓口を一つにすることは、一人で全作業を行うことを意味しません。PMI：WBS辞書と責任
この例では、AIの評価が悪くても、合意した条件で結果を記録し、見送りの根拠を説明できれば、比較報告として完成する余地があります。一方、対象ケースが未実行なら、その扱いを確認者と合意するまで完了にしません。
6. 依存関係と稼働から日程を組む
WBSの各成果物から活動を取り出し、前提・期間・稼働・確認待ちを加えます。成果物の階層と、作業の前後関係は別の情報です。
今回の例なら、比較条件・評価基準・権限設計の合意がPoCの前提になり、比較結果が判断書の前提になります。
工数は作業量、期間は経過する時間です。仮に8時間の仕事でも、一日2時間しか使えなければ作業には4稼働日が必要です。さらに受入確認があるなら、その期間も計画します。この数字は説明用の仮定で、実案件の見積ではありません。
スケジュールでは、担当者の兼務・休日・利用可能時間と、レビュー・承認の引渡しを反映します。更新後は依存関係から、全体の完了日を左右するクリティカルパスも確認します。GAO Schedule Assessment Guide、本文28・35・49–50・71–72・85ページ
技術やデータ条件が不明なら、先に調査・最小検証の成果物を置き、結果が分かった時点で後続の見積を更新する方法が考えられます。調査にも対象・終了条件・判断者を置きます。
7. 作成後は、証拠・残作業・変更を更新する
GAOは実績と残期間に基づくスケジュール更新を重視しています。GAO、本文123–125ページ
小規模IT案件への適用案として、更新時に次の五つを確認します。
- 何が完成し、どの証拠で確認できるか。
- 何が残り、どの前提でいつ終える見込みか。
- 誰の確認・決定を、いつまでに必要としているか。
- 後続と最終期限へどんな影響があるか。
- 範囲・品質・期限・支援体制について、何を選ぶ必要があるか。
追加要望が来たら、変更理由、追加する成果物、工数・費用・日程への影響、判断者を記録します。合意時の期限を消すのではなく、現在の完了予測と分けて残します。承認した範囲を基準にして変更を扱う考え方は、PMIのWBS品質基準にも含まれます。PMI公式解説
アジャイルと併用する場合
WBSで支援範囲の大枠を整理し、詳細はバックログと対応づけて更新する運用が可能です。ただし、Scrum GuideはWBSを必須としていません。Scrumでは、Product Backlogを継続的に整理し、Definition of Doneで完成の品質基準を共有します。Scrum Guide
併用するなら、成果物とバックログ項目の対応ID、更新する情報の正本を決めます。二つの表を別々に手更新して、範囲や状態が食い違う管理は避けたいところです。
計画を合意する前のチェックリスト
- 目的、成果物、対象外、受入確認者を説明できる。
- 合意した範囲の漏れ・重複を、実行者と確認者で点検した。
- 各成果物に責任者、完了条件、証拠を置いた。
- 要件と成果物の対応を追える。
- 依存関係、実際の稼働、レビュー・承認待ちを日程へ反映した。
- 不明点の調査・検証と、再見積の条件を決めた。
- 合意時の計画と現在の予測を分け、変更の判断を残せる。
- 完成したもの、残作業、障害、必要な決定を報告できる。
この設計案は、今回のように対象を絞った導入判断・PoCを計画するときの出発点になります。本番構築まで引き受ける場合は、移行、運用監視、障害対応、教育など、その範囲の成果物を追加して再合意する必要があります。
参考資料と確認範囲
- PMI：Work Breakdown Structure — WBSの原則、辞書、AIエージェントの追加範囲。
- NASA：WBS Handbook、2025年6月版 — 要件との対応、粒度、段階的な分解。
- GAO：Schedule Assessment Guide、2015年 — 依存関係、稼働、期間、進捗更新。
- Scrum Guide、2020年版 — バックログと完成の品質基準。
- PMI掲載：The ABC basics of the WBS、Developing and elaborating effective WBS — 成果物中心の分解とスケジュールへの接続を確認する補助資料。旧版の標準を参照する論文で、最新標準本文そのものではありません。
公開資料の該当箇所を確認して構成しました。正式なPMI Practice Standard全体を通読した解説ではありません。記入例の完成条件・役割・運用方法は、各資料の原則を小規模IT・AI案件へ当てはめた提案です。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表。AI × Web × 業務自動化の開発・検証に取り組んでいます。
技術選定・品質・運用の判断材料を、検証範囲と制約を示して発信しています。
AI導入や業務自動化の技術選定・設計整理については、対応できる範囲を確認のうえご相談を承ります。