• ここでは、要件定義工程の成果物である要件定義書を定義し、果たすべき役割を定めている。

要件定義工程の成果物は、要件定義書として1つに統合される。
統合されている成果物は、要件定義書の要素とみなす。

1つのファイルとして統合する必要はない。要件定義書からリンク等でたどり着ければよい。

ステークホルダー間で「何を実現するか」合意し、文書化し、承認を受けた唯一の根拠である。単なるドキュメントではなく、顧客と開発側の合意の証であり、契約・品質・スコープを規定する中核的な資産である。

要件定義書は、正式な合意に達するために、案件によって定められたプロセスで承認される。

要件定義書は、ToBe の業務を実現するためのシステムの要件を仕様として文書化する。

システムに関与するステークホルダーが、実現手段の外観を理解し、導入する情報システムや製品が技術面、運用面で実現可能か、利用面で問題ないかの確認できる文書である。

要件定義書は、単に「顧客とベンダーで合意したことを書いた文書」ではなく、プロジェクトの全工程にわたって効力を持つ基盤になる。

そのため、要件定義書はシステム開発プロジェクトにおいて、以下の役割を果たすものでなければならない。

• 妥当性の保証：プロジェクトの目的を達成するための最適解であることを保証する。
• 設計の指針：後工程である設計・開発・テストの指針、達成目標となる。
• 変更管理・契約の基準：プロジェクトマネジメントにおけるスコープ基準（ベースライン）。見積はもちろん、仕様変更や契約変更の判断基準にもなる。

flowchart TB
    A[プロジェクト目的] -->|分析・検討| B[要件定義書]
    B --> C[設計]
    B --> F[契約・変更管理]

要件定義書は、要件通りに開発されたシステムが、プロジェクトの制約をクリアしつつ、プロジェクト目的を達成するために最適なものであることを保証する。

• 果たす役割
  • 「役に立たないシステム」をコストをかけて構築してしまうことを防止する。
  • 期待通りの品質で、予定と予算通りに、運用を開始できることを保証する。
• 果たされない場合のリスク
  • 本来必要な工数が見積りに入っておらず、納期遅延や追加コスト発生。ベンダーの利益圧迫や顧客との紛争につながる。
  • 顧客が合意した期待と成果物が異なり、検収を通らず支払い遅延や再作業要求が発生する。

要件定義書は、設計・開発・テストといった後続工程における「基準点（リファレンス）」になる。設計者は要件を満たす構造を考え、開発者はその設計をコード化し、テスターは「要件を満たしているかどうか」を検証する。

• 果たす役割
  • 設計：システム構造やUI設計の妥当性を「要件に照らして」判断できる。
  • 開発：機能実装の範囲や優先度を「定義された要件」に沿って明確にできる。
  • テスト：受入テストやシステムテストのケースを「要件」を基準に作成できる（要件がテスト仕様のソース）。
• 果たされない場合のリスク
  • 設計者・開発者が独自解釈で進めてしまい、業務要件に合わないシステムができあがる。
  • テストで「何をもって合格とするか」が不明確になり、品質保証が成立しない。

プロジェクト進行中に「新しい要望」や「外部環境の変化」に直面した場合、要件定義書が「現時点の合意内容」を示す基準になる。つまり、要求が「契約の範囲内か範囲外か」を判断するための比較対象（ベースライン）になる。

• 果たす役割
  • プロジェクト開始後に「そんな機能は頼んでいない」「ここまではやる約束だったはずだ」という認識齟齬を防止する。
  • 発注者側にとっては「業務上必要なことを確実に要求した証拠」、受注者側にとっては「要求された範囲以上を強要されないための防御線」となる。
  • 変更要求が発生した際に「要件定義書との差分」を客観的に、明確にし、見積の根拠を説明可能にする。
  • プロジェクトマネージャーにとっては「スコープ管理」「契約管理」の実務的な支えとなる。
• 果たされない場合のリスク
  • 認識齟齬から追加工数・追加費用・納期遅延が発生。契約紛争時に立証できず、立場が弱くなる。
  • 顧客の「ちょっとした追加要望」が、なし崩し的に取り込まれ、スコープクリープが起こる。
  • 予算やスケジュールに大きな影響が出ても、誰も責任を負えず、プロジェクトが炎上する。

次のページ → 📄要件定義書の完成条件