要件定義のWBS・タスク一覧｜「聞いてない！」を防ぐ成果物とスケジュール管理【現場PM向け】
この記事は「要件定義の実践ガイド（全9回）」の第5回です。
本記事は単体でもお読みいただけますが、システム開発の最難関である要件定義を成功に導くためのノウハウを体系的にまとめています。
前後のプロセスもあわせて読むことで、より深い理解に繋がります。ぜひ他の連載記事もご活用ください！
全9回のシリーズ記事一覧はこちら（ページ下部へ）
「システム開発の後半になって、『そんな話、聞いていない！』とお客様から怒られた……」
「開発に入ってから足りない機能が次々と発覚し、スケジュールが完全に破綻した……」
システム開発において、後工程でこのような厳しい声が上がり、デスマーチ化する原因の多くは、要件定義フェーズの「計画不足」にあります。スケジュール遅延の50%以上が要件定義の不備から始まると言われる今、プロジェクトマネージャー（PM）にとって「漏れのないWBS（作業分解構成図）」を引くことは、プロジェクトを成功させるための必須スキルです。
本記事では、数多くのプロジェクト現場を見てきた経験から、要件定義で作成すべき「成果物」とそれを実現するための「主要タスク」、そして現場ですぐに使える「WBSのサンプル」を詳しく解説します。
プロジェクトの命運を握る「要件定義」の役割
具体的なWBSを作成する前に、全体の立ち位置を再確認しましょう。要件定義は、いきなり機能の話を始めるのではなく、以下の図のように「3つのステップ」で進めるのが迷走を防ぐ鉄則です。
| Step | フェーズ | 焦点（フォーカス） | 主な活動内容 |
|---|---|---|---|
| 1 | 企画構想 | 経営・戦略 | プロジェクト目的の確認、体制構築、計画立案 |
| 2 | 要求定義 | 業務・プロセス | 現状把握、課題抽出、あるべき業務の可視化 |
| 3 | 要件定義 | システム・機能 | システム機能の整理、非機能要件、仕様決定 |
ここでの決定が、その後の設計・開発・テストすべての基準になります。「何を作るか」の合意を形成するまでのプロセスを、計画的にタスク化（WBS化）して管理することが重要です。
要件定義の主要タスクと成果物一覧
要件定義で作成すべき主な成果物と、それに付随するタスクを各ステップごとに整理しました。プロジェクトの規模や特性に合わせて、必要なものをピックアップして活用してください。
Step 1: 企画構想（土台作り）
プロジェクトの目的や体制、ルールを決める最上流のタスクです。
| タスク（やるべきこと） | 主な成果物 |
|---|---|
| プロジェクト目的の確認・言語化 | プロジェクト定義書 |
| 制約事項（予算・納期・技術）の確認 | 制約事項一覧 |
| ステークホルダーの特定・確認 | ステークホルダー一覧 |
| 投資対効果（ROI）の検討 | 費用対効果算出シート |
| 意思決定ルールと承認フローの定義 | プロジェクト運営ルール |
| 実行体制の構築・メンバーの確保 | プロジェクト体制図 |
| プロジェクト計画書へのまとめ上げ | プロジェクト計画書 |
| 要件定義の活動スケジュール作成 | ヒアリング日程計画表 |
Step 2: 要求定義（業務の可視化）
システムの話に入る前に、現場の「今の業務」と「あるべき業務」を整理するタスクです。
| タスク（やるべきこと） | 主な成果物 |
|---|---|
| 現状業務の洗い出し | 業務機能一覧 / 業務用語集 |
| 既存システム調査（現行仕様の確認） | 現行システム調査報告書 |
| 現状（As-Is）の業務フロー作成 | 業務プロセス関連図 / 業務フロー |
| 問題・課題の抽出と認識合わせ | 要求事項一覧 |
| 要求の優先順位付けとスコープの合意 | 優先順位付要求一覧 |
| 解決策（To-Be）の検討・効果の可視化 | ビフォーアフター図 / 新業務フロー |
Step 3: 要件定義（システム仕様の決定）
あるべき業務を実現するための、具体的なシステム仕様を決めるタスクです。
| タスク（やるべきこと） | 主な成果物 |
|---|---|
| システム化機能の整理・範囲の明確化 | システム構成図 / システム化機能一覧 |
| あるべき姿（To-Be）のシステム化業務フロー作成 | システム化業務フロー |
| 画面・帳票の基本方針と一覧の作成 | 画面一覧 / 帳票一覧 |
| データ定義・コード定義の整理 | データ辞書 / コード定義書 |
| 非機能要件（性能・セキュリティ等）の決定 | 非機能要求グレード表 |
| 運用要件・移行要件の検討 | 運用要件定義書 / 移行計画書 |
| 整合性の検証・概算見積もりの作成 | 要件定義書 / 概算見積書 |
| システムテスト計画の策定 | システムテスト計画書 |
現場で使える！WBS作成「3つの鉄則」
洗い出したタスクを時系列に並べてWBS（スケジュール）に落とし込む際、プロジェクトを泥沼化させないための「実務的な工夫」が3つあります。
1. ヒアリング期間には「バッファ（予備日）」を持たせる
お客様側のキーマン（業務部門の責任者など）は多忙であることが多く、予定していたヒアリング会議が急遽キャンセルになることは日常茶飯事です。最初から予備日を含めた余裕のある計画（バッファ）にしておかないと、開始早々スケジュールが破綻してしまいます。
2. 「合意形成（サインオフ）」のタイミングをマイルストーンにする
要件定義は「ドキュメントを作って終わり」ではありません。作成した成果物をお客様にレビューしてもらい、いつ「サインオフ（内容承認・凍結）」するのかをWBS上に明確なマイルストーンとして配置します。この節目を設けることで、後からの「言った・言わないの蒸し返し」を防ぐ強力な抑止力になります。
3. 「移行」と「運用」を絶対に後回しにしない
ついつい「新しい画面や機能」の議論に目が行きがちですが、初期段階から「現行システムからのデータ移行はどうするのか？」「夜間のバッチ処理やバックアップ運用はどう回すのか？」をWBSに組み込んでおくことで、終盤での「想定外の工数爆発」を劇的に減らすことができます。
要件定義のWBS（スケジュール）サンプル
約3ヶ月間の要件定義フェーズを想定した、標準的なWBSのサンプルです。これをベースに、自プロジェクトの規模に合わせて期間やタスクを調整してください。
【参考】成果物のイメージが湧かない場合のリソース
「業務プロセス関連図ってどう書くの？」「要求事項一覧のフォーマットが欲しい」など、成果物の具体的なイメージが湧きにくい場合は、IPA（独立行政法人情報処理推進機構）が公開している資料を参照するのが一番の近道です。
これらの資料には、豊富なサンプルやフォーマットが掲載されています。ただし、「これらすべてを完璧に作らなければならない」と捉えるのではなく、自プロジェクトにとって「お客様との合意形成に本当に価値があるドキュメントはどれか」を選択・カスタマイズする基準として活用してください。
まとめ：要件定義の精度（計画）がプロジェクトを救う
要件定義は、単なるドキュメント作成作業ではありません。お客様と「これから何を作るのか」という約束を交わし、プロジェクトの航海図を完成させる極めて重要なプロセスです。
- 「企画・要求・要件」の3ステップでタスクを整理する
- 作成すべき成果物を定義し、タスクのゴールを明確にする
- バッファを持たせた日程と、確実な合意形成（サインオフ）の場を設ける
ここで手を抜かず、丁寧にWBSを引くことが、最終的に自分たち開発チーム、そして何よりお客様を救うことになります。本記事のタスク一覧を一つの地図として、精度の高い要件定義を進めていきましょう。
綿密な計画（WBS）を立てたら、次はそれを実際に動かすための「体制」と「ルール」を整える必要があります。 第6回では、現場のキーマンを確実に巻き込み、成果物の品質を担保するための具体的な「要件定義の準備術」について掘り下げます。
要件定義シリーズ：実践ガイド一覧
[第1回] 要件定義の失敗しない進め方
[第2回] 企画構想の落とし穴を回避する点検ポイント
[第3回] 要求定義の具体的な進め方
[第4回] 非機能要件の進め方とヒアリング術
[第5回] 要件定義のWBS・タスク一覧（本記事）
[第6回] 要件定義の準備術（体制と成果物）
[第7回] 業務フローの基本的な書き方
[第8回] 業務フローのフレームワーク活用術（5W3H・As-Is/To-Be）
[第9回] 業務フローの書き方完全ガイド
