要件定義は、プロジェクトの成功・失敗を左右する最重要フェーズです。
PMBOKでいうところの 計画プロセス群 × スコープマネジメントの中心 に位置し、
「何を作るのか」を明確にする段階です。
しかし実務では、この要件定義が曖昧なまま進められ、
後半で手戻り・予算超過・納期遅延などが起こるケースが非常に多いです。
ここでは、初心者でも理解できるように
要件定義の基本・流れ・よくある落とし穴・成功のコツ
を体系的に整理します。
要件定義とは何か？
要件定義とは
「顧客が求める成果物の内容・機能・条件を明文化する作業」
のことです。
言い換えれば、
“何を作るのか”を曖昧さゼロで決める工程。
PMBOKでは主に以下の範囲に該当します：
スコープマネジメント
要求事項の収集
スコープ定義
WBS作成
要件定義は、プロジェクトの“設計図”となるため、
この段階でのブレは後半ですべてコストとなって跳ね返ります。
要件定義の流れ（PMBOKの手順に沿って整理）
ステークホルダーの特定
誰がプロジェクトに影響するのか明確にします。
（←本編 第1章・第6章と連動）
要求事項の収集
ヒアリング・インタビュー・既存資料を使い、
「顧客が必要としていること」を漏れなく拾います。
要件の分類（機能要件 / 非機能要件）
- 機能要件：何ができるか（画面・機能・動作）
- 非機能要件：品質・セキュリティ・性能・拡張性
スコープ定義
計画として成立するレベルまで要件を具体化します。
「何を作る／作らない」を明確にするのがポイント。
WBSの作成
スコープを構造化し、
プロジェクト全体のタスクと粒度を揃えます。
（←本編「WBS不十分の落とし穴」にリンク）
スコープベースラインの確定
変更があれば、変更管理プロセスで判断するための基準になります。
要件定義でよくある落とし穴
これは本編「実務の落とし穴」と強くリンクする部分です。
落とし穴1：顧客の要求とプロジェクトのスコープを混同する
要求＝希望であり、
スコープ＝実際にやること。
ここを混同すると、後半で必ず炎上します。
落とし穴2：抽象的な言葉で合意してしまう
「使いやすくしたい」
「見た目をキレイに」
「スピード改善したい」
これらはすべてNGワードです。
落とし穴3：非機能要件が抜け落ちる
特に
・レスポンス速度
・セキュリティ
・バックアップ
は忘れられがちで後半に問題化します。
落とし穴4：WBSが粗い
本編でも触れた通り、
粒度が荒いと進捗管理できず、遅延の原因になります。
落とし穴5：変更管理が無い
要件定義の不足は後半に“変更要求”として現れます。
これを無秩序に受けると崩壊します。
要件定義を成功させるコツ（現場で必須）
成功基準（What does success look like?）を最初に定義する
立ち上げフェーズとつながるポイント。
ユースケース・業務フローで共通認識を作る
文章だけでは誤解が生まれるため、図解は必須。
“作らないもの”を明確にする（非スコープ）
プロジェクトの安定度が跳ね上がるポイント。
WBSは細かすぎるくらいでちょうど良い
プロジェクト管理費の記事とも整合。
変更要求は必ず統合変更管理で判断
本編「第5章・第6章」で強調した通り。
5. 要件定義書に含めるべき項目チェックリスト
プロジェクト目的
成功基準
スコープ（含めるもの／含めないもの）
機能要件
非機能要件
業務フロー・画面フロー
利害関係者
制約条件・前提条件
WBS
リスク一覧
変更管理フロー
このチェックリストは、実務の品質とプロジェクト安定度を大幅に向上させます。
要件定義とプロジェクト管理費の関係
内部リンク先（プロジェクト管理費の割合）と直結する部分です。
要件定義が曖昧だと、
手戻り
再作業
仕様追加
調整の増加
などが発生し、管理費が膨らみます。
逆に、要件定義がしっかりしているほど、
PM費は抑えられ、プロジェクト成功率も上がります。
まとめ：要件定義は“成功するプロジェクトの通行証”
要件定義は、プロジェクトの成否を最初に決めるフェーズです。
・スコープを明確にする
・WBSで構造化する
・変更管理の基準を作る
これらを押さえることで、
プロジェクトは計画どおり・予算どおりに進めることができます。
本編（PMBOKプロセス群・知識エリア）と合わせて読むと、
要件定義の位置づけがよりクリアになります。
- → プロジェクト管理費の割合とは？
（管理費が増える／減る理由を理解するならこちら） - → PMBOKプロセス群を完全整理｜5つのステップと10の知識エリアを図解で理解
（要件定義がプロセス群のどこにあるか分かります）