本ガイドは、IT未経験の発注側（営業・企画など）が、要件定義を「ムダなく、揉めずに」進めるための実務手順をまとめたものです。専門用語を避け、準備→合意→検証の流れで説明します。読み手がすぐ使えるよう、チェック欄と記入例も付けています。
目的を言語化する（仕様の前に）
- なぜ作るのかを一文で書きます。例：「見込み客の追客を自動化し、月次成約率を＋3ptする」。
- 成功条件を数値で添えます（期間・範囲・例外）。例：「3ヶ月以内に営業10名で運用」「既存SFAの範囲に限定」。
- 目的に合わない要望は一旦保留。根拠のない“念のため機能”は後で検討します。
関係者と権限を確定する
- 意思決定者／レビュー参加者／現場ヒアリング対象を表にし、欠員を埋めます。
- 承認の段取り（誰がいつ何にOKを出すか）を先に合意します。
- 「後出しの口出し」を減らす仕組み。議事録は承認期限つきで回覧します。
現状業務を見える化する
- 部門横断で“事実”を集め、事実（現状）と要望（理想）を分けて記録。
- 例：事実「営業が二重入力」→ 要望「自動連携」→ 要件候補「SFAとMAの双方向同期」。
- 業務フロー図は簡易でよく、更新履歴を残します。定量データ（件数・頻度・所要時間）も添えます。
非機能要件を穴埋めする
- 性能（レスポンス）、可用性（稼働時間・復旧）、セキュリティ（権限・監査）、法令・運用体制を最低限決めます。
- 例：「主要画面は3秒以内」「障害時は30分以内に連絡」「個人情報の閲覧は権限ロールで制限」。
- 非機能は後からの修正コストが大きいため、早期に明文化します。監査ログやバックアップ手順も範囲に含めます。
合意の作り方＝説明＋了承
- 文書配布だけでは合意になりません。レビュー会を設定し、観点（目的適合・影響範囲・運用実現性・費用）で確認。
- 変更管理のルール（提出→影響評価→承認→追跡）を先に決め、履歴を残します。
- 判断保留は期限と追加情報の条件を明記します。
不確実な点は軽い検証で詰める
- モックやPoCで“見て触って”判断します。期間・評価軸（やる／やらないの条件）を明記。
- すべてを前倒しで決め切らず、仮決め→短期検証→確定を回します。検証は1〜2週間単位で小さく区切ります。
最低限そろえる成果物（テンプレ）
- 目的と成功条件（1枚）
- 関係者一覧と承認プロセス（責任・権限・期限）
- 現状業務の要点図と課題リスト（定量つき）
- 機能要件一覧／非機能要件の最小セット（数値基準を明記）
- 変更管理ルールとレビュー記録（版管理）
着手前チェックリスト
- 目的は数値で書けているか
- 関係者と権限が明示されているか
- 非機能の空欄がないか
- レビュー会と承認手順が決まっているか
- 検証（モック/PoC）の枠が確保されているか
要件定義は「ITの専門知識」を競う場ではなく、後戻りコストを抑える合意形成の仕組みです。本ガイドを土台に、合意の作り方と検証の段取りを先に整えれば、開発は驚くほどスムーズになります。迷ったら、目的・関係者・非機能・検証の4点に立ち返ってください。
