要件定義書の作り方｜必須項目・手順・品質基準

要件定義書は、開発目的、対象範囲、業務・機能・非機能要件、データ移行、運用、受入条件を発注者と開発会社で合意する文書です。作り方の要点は、業務を可視化し、優先順位と測定可能な合格条件を付け、未決事項と変更手順まで残すことです。

• 要件定義書とは？発注者が作成前に押さえること
  • RFPや基本設計書との違い
  • 作成前に準備する情報
• 要件定義書に必要な項目と実務用テンプレート
  • 機能要件は「操作」ではなく「目的と結果」まで書く
  • 非機能要件は数値と確認方法をセットにする
  • 受入条件は見積もり前から考える
• 要件定義書の作り方7ステップと期間・費用の目安
  • 1. 目的と成功条件を決める
  • 2. 関係者と意思決定ルールを整理する
  • 3. 現行業務と例外処理を可視化する
  • 4. 導入後の業務と開発範囲を決める
  • 5. 機能・データ・外部連携・非機能要件を整理する
  • 6. 受入条件・移行・運用を決める
  • 7. レビュー・承認・変更管理を行う
  • 要件定義にかかる期間・費用の一般的な目安
• 要件定義書の品質基準と失敗を防ぐ見積もり・会社選び
  • 品質チェックリスト
  • よくある失敗と回避策
  • 見積書で確認する項目
  • 要件定義を任せる開発会社の見極め方
• まとめ
• よくある質問
  • Q. 要件定義書は誰が作成しますか？
  • Q. 要件定義にはどのくらいの期間と費用が必要ですか？
  • Q. 要件定義が完成する前に開発見積もりを依頼できますか？
  • Q. 要件定義書とRFP、基本設計書の違いは何ですか？
  • Q. 要件変更を完全に防ぐことはできますか？

要件定義書とは？発注者が作成前に押さえること

要件定義書の役割は、「何を作るか」だけでなく、「なぜ作るか」「どこまで作るか」「何をもって完成とするか」を関係者で合意することです。画面や機能の一覧だけでは、業務上の例外、権限、性能、データ移行、リリース後の運用が抜けやすく、見積もりや検収の基準として十分ではありません。

まず、要求・要件・仕様の違いを整理します。

発注者が中心となって決めるのは、事業目的、業務ルール、優先順位、予算、納期、受入基準です。開発会社は、技術的な実現性、システム構成、セキュリティ、性能、開発工数などを整理します。どちらか一方に丸投げするのではなく、役割を分けて共同で作成するのが基本です。

RFPや基本設計書との違い

要件定義書と混同されやすい文書に、RFPと基本設計書があります。

RFPは提案を比較するための依頼文書であり、要件定義書ほど詳細である必要はありません。依頼先を選ぶ前の情報整理については、RFPの作り方｜システム開発の依頼準備も参考にしてください。

作成前に準備する情報

完成した資料がそろっていなくても要件定義は始められます。ただし、次の情報があるとヒアリングと見積もりが進みやすくなります。

• プロジェクトの背景と解決したい経営・業務課題
• 現行業務の流れ、帳票、表計算ファイル、操作マニュアル
• 現在利用しているシステムと外部サービス
• 利用者の役割、人数、利用場所、利用端末
• 希望予算、公開希望日、動かせない期限
• 個人情報、機密情報、決済情報などの取り扱い方針
• 現行データの件数、形式、品質、保存場所
• 意思決定者、業務部門の窓口、情報システム部門の窓口
• 今回の対象外にしたい業務や将来構想

発注のご相談を受ける開発会社の立場では、資料の不足よりも「誰が判断するのか分からない状態」のほうが進行に大きく影響します。業務部門ごとに要望が異なる場合に備え、最終的に優先順位と予算を決める責任者を着手前に明確にしてください。

要件定義書に必要な項目と実務用テンプレート

要件定義書には、事業目的から検収方法までを一貫して記載します。小規模な開発では一部を同じ資料にまとめても構いませんが、次の論点自体を省略しないことが重要です。

機能要件は「操作」ではなく「目的と結果」まで書く

機能要件には、「検索機能を作る」「メールを送る」といった機能名だけでなく、利用者、利用目的、事前条件、例外、処理結果を記載します。各要件に一意のIDを付けると、見積もり、設計、テスト、変更履歴を関連付けやすくなります。

1件の機能要件は、次の形式で整理できます。

• 要件ID：REQ-001
• 要件名：経費申請の承認
• 目的：承認者が申請内容を確認して判断できるようにする
• 利用者：申請者の承認者として登録された利用者
• 事前条件：申請が承認待ちの状態である
• 基本の流れ：内容確認、承認、状態更新、申請者への通知
• 例外：権限不足、承認済み、二重操作、通知失敗
• 入出力：表示項目、入力項目、更新するデータ
• 優先順位：今回のリリースに必須か、後回しにできるか
• 受入条件：承認後の状態、履歴、通知を確認できること

優先順位には、Must（今回必須）、Should（重要だが代替手段がある）、Could（余力があれば対応）、Won't（今回は対象外）という分類が使えます。すべてをMustにすると予算調整ができないため、Mustの理由と、実装しない場合の代替運用も確認します。

非機能要件は数値と確認方法をセットにする

非機能要件とは、機能そのものではなく、速度、安全性、安定稼働、保守性などの品質条件です。「高速に表示する」「十分なセキュリティを確保する」といった表現では、工数も合否も判断できません。

例えば応答時間は、「主要画面を通常負荷時に一定割合で2秒以内」のように、対象画面、負荷条件、基準、測定方法を定めます。ただし、2秒という数値が常に正しいわけではありません。現在の利用状況、業務への影響、外部サービスの制約、実現コストを踏まえて決定します。

受入条件は見積もり前から考える

受入条件とは、納品物を発注者が検収するときの合格基準です。完成後に考えるのではなく、要件と同時に決めると認識差を減らせます。

「適切に通知されること」ではなく、次のように確認可能な結果を記載します。

• 承認が完了したとき、対象の申請状態が「承認済み」になる
• 承認日時と承認者が履歴に記録される
• 申請者へ承認完了通知が1回送られる
• 権限を持たない利用者は承認操作を実行できない
• 通知に失敗しても承認結果は失われず、運用担当者が失敗を確認できる

この粒度まで整理すると、発注者は必要な動作を確認でき、開発会社も例外処理を含めて見積もりやすくなります。

要件定義書の作り方7ステップと期間・費用の目安

要件定義は、ヒアリングした要望をそのまま並べる作業ではありません。要望の背景を確認し、矛盾や重複を解消し、予算内で検証可能な条件に変換する工程です。

1. 目的と成功条件を決める

最初に、誰のどの課題を解決するのかを明確にします。「顧客管理システムを作る」ではなく、「営業担当者による案件情報の二重入力を減らし、管理者が最新状況を確認できるようにする」と表現します。

KPI（＝成果を測るための指標）を設定する場合は、入力時間、処理件数、転記回数、問い合わせ件数など、導入前後で測定できる指標を選びます。現状値が分からなければ、短期間の業務調査やログ取得から始めます。

2. 関係者と意思決定ルールを整理する

利用者、業務責任者、決裁者、情報システム担当者、法務・セキュリティ担当者などを洗い出します。そのうえで、誰が意見を出し、誰がレビューし、誰が最終承認するのかを決めます。

多数決で要件を決めると、利用頻度が低い要望まで膨らむことがあります。事業目的、利用頻度、リスク、費用を踏まえて優先順位を決められる責任者が必要です。

3. 現行業務と例外処理を可視化する

担当者、操作、帳票、データ、承認の流れを時系列で整理します。現行マニュアルだけでなく、実際の担当者へのヒアリングや操作確認も行います。文書上の業務と実態が異なることがあるためです。

特に次の例外を確認します。

• 入力に誤りがあった場合の訂正・差戻し
• 申請後の取消や再申請
• 担当者が不在・退職した場合の引き継ぎ
• 同じ処理が二重に実行された場合
• 外部システムや通信が停止した場合
• 月末や繁忙期に処理が集中した場合
• 管理者による代理操作や強制修正

例外処理は画面数に現れにくい一方、開発工数と運用負担へ影響します。見積もり前に主要な例外を整理することが重要です。

4. 導入後の業務と開発範囲を決める

現行業務をそのままシステム化するのではなく、廃止、統合、自動化する作業を検討します。そのうえで、システム対応、手作業での代替、将来対応に分けます。

スコープ（＝今回取り組む範囲）は、対象だけでなく対象外も明記します。例えば「CSV出力は対象だが、会計システムとの自動連携は対象外」「日本語表示は対象だが、多言語化は次期対応」と記載します。対象外の合意は、追加費用を巡る認識差を防ぐうえで有効です。

5. 機能・データ・外部連携・非機能要件を整理する

業務フローを基に、必要な機能を要件へ変換します。画面だけでなく、権限、通知、帳票、検索、履歴、管理機能も確認します。

データ移行では、件数だけでなく、重複、欠損、表記揺れ、文字コード、添付ファイルも調査します。古いデータをすべて移すより、必要な期間だけ移行して残りを参照用に保管するほうが合理的な場合もあります。

外部連携では、API（＝システム同士がデータをやり取りする接続口）の仕様、利用料金、接続申請、利用上限、障害時の再処理を確認します。連携先の仕様が未入手なら、見積もりの前提とリスクとして明記します。

6. 受入条件・移行・運用を決める

各要件に受入条件を付け、誰がどの環境で確認するかを決めます。同時に、データ移行のリハーサル、利用者への説明、問い合わせ窓口、障害時の連絡、リリース後の保守範囲も整理します。

発注者側の作業も計画に含めてください。テストデータの準備、受入テスト、社内承認、利用規約やマニュアルの確認が遅れると、開発が完了していても公開できません。

7. レビュー・承認・変更管理を行う

レビューでは資料を配るだけでなく、未決事項と矛盾を会議で解消します。未決事項には、担当者、決定期限、判断に必要な情報、決まらない場合の影響を記載します。

承認時点の文書を基準版として保存しますが、これは以後の変更を禁止するという意味ではありません。変更が生じたら、理由、対象の要件ID、費用、納期、他機能への影響、承認者を記録します。

要件定義にかかる期間・費用の一般的な目安

要件定義の期間と費用は、画面数よりも、関係部門、業務ルール、外部連携、データ移行、セキュリティ要件、意思決定の速さに左右されます。以下は、要件定義だけを外注する場合の一般的な目安であり、設計・実装費は含みません。

同じ規模でも、既存資料が整理されている案件と、現行業務の調査から必要な案件では費用が変わります。また、要件定義費が開発見積もりに含まれている場合もあるため、見積書では工程別の費用と成果物を確認してください。

不確定要素が多い段階で開発全体を固定価格にすると、開発会社がリスク分を上乗せするか、後から追加見積もりが増える可能性があります。要件定義を先行契約し、完了後に実装範囲を再見積もりする方法も有効です。

要件定義書の品質基準と失敗を防ぐ見積もり・会社選び

良い要件定義書は、ページ数や図の多さではなく、見積もり、設計、実装、受入テスト、変更判断に使えるかで評価します。

品質チェックリスト

レビューでは、次の観点を確認してください。

承認前には、次のチェックリストも利用できます。

• 開発目的と成功条件が一文で説明できる
• 今回の対象と対象外が明記されている
• 利用者区分ごとの権限が整理されている
• 正常処理だけでなく主要な例外処理がある
• 機能要件にIDと優先順位が付いている
• 性能やセキュリティに確認方法がある
• データ移行の対象、担当、照合方法が決まっている
• 外部連携先の仕様と契約条件を確認している
• 発注者側の受入テスト担当者と期間が決まっている
• 未決事項に責任者と期限がある
• 要件変更時の見積もり・承認手順がある
• 決裁権を持つ責任者が内容を承認している

よくある失敗と回避策

特に発注者が誤解しやすいのは、「要件定義書があれば追加費用は一切発生しない」という点です。要件定義書は変更をなくす文書ではなく、変更前の基準と、変更の影響を判断するための文書です。

見積書で確認する項目

要件定義を外注する場合は、金額だけでなく、何をどこまで整理する契約かを確認します。

• 調査、ヒアリング、会議の回数と参加者
• 作成される文書、図、一覧表などの成果物
• 業務フロー、画面案、データ項目の詳細度
• セキュリティやインフラ検討の範囲
• 現行データや既存システムの調査範囲
• 発注者が準備する資料と作業
• レビュー回数と修正対応の範囲
• 対象外の作業と追加費用になる条件
• 要件定義後に再見積もりする項目
• 成果物の納品形式と利用条件

相見積もりでは総額だけを並べず、前提条件、対象範囲、担当者の役割、成果物の粒度をそろえて比較します。詳しくはシステム開発の相見積もり｜取り方と比較方法をご覧ください。

要件定義を任せる開発会社の見極め方

要件定義を支援する会社は、単に要望を肯定する会社ではなく、背景を確認し、選択肢と影響を説明できる会社を選びます。

• 機能の希望だけでなく、業務目的や利用頻度を質問する
• 正常処理だけでなく、例外、移行、運用まで確認する
• 未確定事項を隠さず、見積もりへの影響を説明する
• 実装しない選択肢や手作業による代替案も提示する
• 専門用語を発注者が判断できる言葉に言い換える
• 要件ごとの優先順位と概算費用の関係を示す
• 会議後に論点、決定事項、宿題を記録する
• 要件定義後の再見積もり条件を事前に説明する

提案時の見栄えだけでなく、質問の質と前提条件の説明を確認してください。事業目的の整理から要件定義、開発見積もりまで支援が必要な場合は、開発のご相談はこちらからお問い合わせください。

まとめ

• 要件定義書は、目的、対象範囲、業務、機能、非機能、移行、運用、受入条件を合意する文書です
• 発注者は事業目的、業務ルール、優先順位、予算、受入判断を担い、開発会社と共同で作成します
• 機能要件には、利用者、事前条件、例外、優先順位、受入条件を記載します
• 非機能要件は「高速」「安全」といった表現を避け、数値と確認方法をセットにします
• 要件定義の一般的な目安は、小規模で2〜4週間・50万〜150万円程度、中規模で1〜3カ月・150万〜500万円程度です
• 見積もりでは総額だけでなく、成果物、前提条件、対象外、再見積もりの条件を確認します
• 要件変更を禁止するのではなく、費用・納期への影響と承認履歴を管理することが重要です
• 品質は文書量ではなく、見積もり、実装、検収、変更判断に使えるかで評価します

よくある質問

Q. 要件定義書は誰が作成しますか？

発注者と開発会社が共同で作成します。事業目的、業務ルール、優先順位、予算、受入判断は発注者が担い、技術的な実現性、非機能要件、システム上の制約は開発会社が整理するのが基本です。最終的には決裁権を持つ責任者が承認します。

Q. 要件定義にはどのくらいの期間と費用が必要ですか？

一般的な目安は、小規模で2〜4週間・50万〜150万円程度、中規模で1〜3カ月・150万〜500万円程度です。複数部門、多数の外部連携、大規模なデータ移行、厳格なセキュリティ要件がある場合は、3〜6カ月以上・500万円以上かかることもあります。

Q. 要件定義が完成する前に開発見積もりを依頼できますか？

概算見積もりは依頼できますが、前提条件と金額の幅を確認してください。不確定要素が多い段階の見積もりは確約額ではありません。要件定義後に再見積もりする項目と、追加費用が発生する条件を事前に合意することが重要です。

Q. 要件定義書とRFP、基本設計書の違いは何ですか？

RFPは候補会社へ提案を依頼するための文書、要件定義書は作るものと合格条件を合意する文書、基本設計書は要件を実現する画面やデータなどの方式を具体化する文書です。ただし、文書名や工程の境界は開発会社や契約によって異なります。

Q. 要件変更を完全に防ぐことはできますか？

完全に防ぐことは困難です。市場環境、利用者の検証結果、外部サービスの仕様などによって必要な変更は生じます。変更理由、対象要件、費用、納期、影響範囲、承認者を記録する変更管理の手順を、要件定義の段階で決めてください。