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導入や業務自動化の技術選定・設計整理については、対応できる範囲を確認のうえご相談を承ります。