要件定義書の書き方・テンプレート
要件定義はシステム開発の成否を左右する最重要フェーズです。「何を作るか」を漏れなく・矛盾なく定義した要件定義書が、設計・開発・テストすべての基盤になります。
要件定義とは
要件定義とは、発注者・利用者が「システムに何をしてほしいか」を明確化し、開発側と合意するプロセスです。「要件」には大きく3つの層があります。
システムが支援する業務・プロセスの定義。「誰が」「何を」「どのような手順で」行うかを記述する。ユースケース図・業務フロー図が使われる。
システムが持つべき機能・画面・API・データ処理の定義。「システムは○○できなければならない」という形で記述する。
性能・可用性・セキュリティ・スケーラビリティ・保守性など、機能以外の品質要件。見積もりコストと可用性に直結するため、曖昧にすると後工程で大問題になる。
要件定義書の構成テンプレート
- ·目的・背景
- ·スコープ（対象業務・対象システム）
- ·スコープ外
- ·関係者・利害関係者一覧
- ·現状の業務フロー（As-Is）
- ·理想の業務フロー（To-Be）
- ·ユースケース一覧
- ·RACI表（誰が何をする責任か）
- ·機能一覧（機能ID・機能名・概要・優先度）
- ·画面一覧・画面遷移図
- ·API一覧（外部連携含む）
- ·帳票・出力物一覧
- ·可用性（稼働率・RTO/RPO）
- ·性能（応答時間・スループット）
- ·セキュリティ（認証・暗号化・アクセス制御）
- ·スケーラビリティ・保守性・コンプライアンス
- ·概念データモデル
- ·エンティティ一覧・データ量見積もり
- ·個人情報・機密データの分類
- ·技術制約（使用技術・既存システム連携）
- ·予算・スケジュール制約
- ·法規制・コンプライアンス制約
- ·前提条件（ユーザー教育・インフラ準備等）
- ·リスク一覧と対策
- ·未確認事項・オープン課題
ステークホルダーヒアリングの進め方
業界・業務の基礎知識をインプットし、仮説（As-Is課題・To-Be像）を用意する。「何も知らない状態でヒアリングに臨む」のは最悪のスタート。
「今回のヒアリングで何を決めるか」を冒頭で明確にする。ゴールが曖昧なまま進めると雑談で終わる。
現状の業務プロセスをホワイトボードや付箋で可視化しながら聞く。「例外処理」「担当が不明瞭な境界」を重点的に掘り下げる。
「なぜ問題なのか」「どのくらいの頻度で発生するか」「影響範囲はどこか」をなぜなぜ5回で掘り下げる。表面的な要望の奥にある本質的な課題を特定する。
「こういう仕組みになったら解決しますか？」と仮説を提示して検証する。担当者の「はい」は表面的な同意のことも多く、複数ステークホルダーとクロスチェックする。
「何人が同時に使うか」「止まったら何分以内に復旧が必要か」「個人情報は何件保持するか」を具体的な数字で確認する。後から「そんな要件は言っていない」を防ぐ。