要件定義書は、作る側と使う側が「何を作り、何を作らないか」を同じ内容で確認し、完成したときの検収の基準にもなる文書です。現場で使われる要件定義書にするには、機能の一覧だけでなく、業務の流れ、例外のときの動き、数値で書いた非機能要件、まだ決まっていないことまでを1冊に入れておきます。この記事では、章立てのテンプレートと各項目の記入例を順に説明します。
要件定義書が読まれなくなる理由
時間をかけて作った要件定義書が、開発が始まると誰にも開かれなくなることがあります。理由はたいてい次のどれかです。
- 機能の一覧が並んでいるだけで、業務のどの場面で使うのかが分からない
- 「使いやすい」「迅速に」のように、読んだ人によって解釈が変わる言葉が多い
- 決まっていないことが書かれておらず、後から「決めたはず」「聞いていない」の争いになる
- 改訂の履歴がなく、どれが最新版か分からない
要件の書き方そのもの（機能要件の型、異常系、非機能要件の6カテゴリー）は要件定義の進め方の記事で扱っています。この記事は、それを1冊の文書にまとめるときの構成と書き方に絞ります。
章立てのテンプレート
次の構成をそのまま使えます。小さな案件なら、章を統合して10ページ程度にまとめても構いません。
要件定義書：［システム名］
0. 文書情報
- 版数／作成日／作成者／承認者
- 改訂履歴（版・日付・変更内容・変更者）
1. 背景と目的
- 現状の課題（数字つき）
- 導入の目的と、達成を測る指標
2. スコープ
- 対象とする業務（IN）
- 対象としない業務（OUT）と、その扱い
3. 用語の定義
4. 業務フロー
- 現状の業務フロー（ASIS）の要約
- 導入後の業務フロー（TOBE）
5. 機能要件
- 機能一覧（ID・名称・概要・利用者・優先度）
- 主要な機能の詳細（正常の流れ・例外の流れ）
6. データ要件
- 扱うデータの一覧
- 誰がどのデータを作成・参照・更新・削除できるか
- ステータスの定義と遷移
7. 画面・帳票・外部連携
8. 非機能要件
- 性能／可用性／セキュリティ／保守性／拡張性／移行性
9. 移行要件
10. 運用と定着の体制
11. 前提条件と制約
12. 未決事項
13. 承認
以下、金属加工会社の「見積依頼管理システム」を例に、主な章の書き方を見ていきます。
1. 背景と目的：課題を数字で書く
背景には、なぜ作るのかを数字で書きます。目的には、何がどうなれば成功かを測れる形で書きます。
- 悪い例：見積業務を効率化し、顧客満足度を向上させる
- 良い例：見積依頼は月約120件。共有Excelで管理しており、回答期限を過ぎた依頼が月に5件前後ある。導入後は期限超過を月0件にし、依頼1件あたりの管理作業（登録・確認・共有）を10分から3分にする
目的に書いた指標は、導入後の効果確認でそのまま使います。
2. スコープ：やらないことを理由つきで書く
INだけを書くと、後から「これも入っていると思っていた」が出てきます。OUTには理由と、いつ扱うかを添えます。
| やらないこと | 理由・扱い |
|---|---|
| 見積書PDFの自動作成 | 原価の計算方法が担当者ごとに異なり、先に統一が必要。次の段階で検討 |
| 受注後の生産指示との連携 | 生産管理システムの更新が来年予定のため、その後に検討 |
| 社外（顧客）からの直接入力 | 第1段階は社内利用のみ |
3. 用語の定義：社内の言葉をそろえる
同じ言葉が部署によって違う意味で使われていることはよくあります。「回答」が「見積金額の提示」なのか「受注の可否の連絡」なのか、「失注」に辞退を含めるのか。こうした言葉を表にして定義しておくと、以降の章の読み違いが減ります。
4. 業務フロー：機能より先に流れを載せる
機能要件の前に、導入後の業務の流れ（TOBE）を載せます。誰が、どのタイミングで、システムに何をするかが見えると、機能一覧が業務のどこに当たるかを読み手が確かめられます。図にするときは、関係者ごとに横の帯（スイムレーン）を分け、人が判断する箇所とシステムが自動で行う箇所を区別します。描き方はTOBE業務フロー設計の記事を参照してください。
5. 機能要件：一覧と詳細を分ける
機能一覧は1行1機能で、IDを振ります。IDがあると、テストや議事録から参照できます。
| ID | 機能名 | 概要 | 利用者 | 優先度 |
|---|---|---|---|---|
| F-01 | 依頼登録 | 顧客名・品名・数量・図面・回答期限を登録する | 営業担当 | 必須 |
| F-02 | 担当割り当て | 依頼に見積担当を割り当てる | 営業課長 | 必須 |
| F-03 | 期限アラート | 回答期限の2営業日前と当日に、担当と課長に通知する | システム | 必須 |
| F-04 | 依頼検索 | 顧客名・品名・期間で過去の依頼を検索する | 全員 | 推奨 |
主要な機能は、正常の流れと例外の流れを分けて書きます。例えばF-03なら、「担当が割り当てられていない依頼は課長だけに通知する」「通知メールの送信に失敗したら画面に警告を表示する」といった例外を書きます。1行の要件は「［主語］は［条件］のとき、［目的語］を［動詞］する」の型で書くと、あいまいさが減ります。
6. データ要件：権限とステータスを表にする
誰がどのデータを作成（C）・参照（R）・更新（U）・削除（D）できるかを表にします。
| データ | 営業担当 | 営業課長 | 見積担当 | システム |
|---|---|---|---|---|
| 顧客 | CRU | CRU | R | R |
| 見積依頼 | CRU | RU | RU | U |
| 見積回答 | R | R | CRU | — |
ステータスは、遷移と操作者、期限を表にします。「受付 → 担当決定 → 見積中 → 回答済 → 受注／失注」に加えて、差し戻しや取り消しの経路も書きます。状態の持たせ方はステータス管理とテーブル分割の記事で詳しく扱っています。
8. 非機能要件：すべて数値か手段で書く
| カテゴリー | 書き方の例 |
|---|---|
| 性能 | 一覧画面は、依頼1万件の状態で3秒以内に表示する |
| 可用性 | 平日8時〜19時に利用できること。障害時は翌営業日中に復旧する |
| セキュリティ | 社員アカウントでのみログインできる。図面ファイルへのアクセスは操作ログを1年保存する |
| 保守性 | 依頼の入力項目は、管理者が画面操作で追加できる |
| 移行性 | 既存Excelの過去2年分を取り込み、件数が一致することを確認する |
数値は業務の実態から決めます。上の値は書き方の例として読んでください。
10. 運用と定着の体制
導入後に、誰が利用状況を確認し、誰が改善の判断をするかを書きます。例えば「営業課長が週次で期限超過の件数を確認し、3ヶ月後に目的の指標を振り返る」のように、確認する人・頻度・節目を入れます。ここが空欄だと、導入後に誰も見ていない状態になりやすくなります。
12. 未決事項：決まっていないことを隠さない
未決事項は、要件定義書の中で最も読まれる章の1つです。
| No | 内容 | 決める人 | 期限 | 決まらない場合の扱い |
|---|---|---|---|---|
| 1 | 失注理由を選択式にするか自由記述にするか | 営業部長 | 11月15日 | 自由記述で開始し、3ヶ月後に見直す |
| 2 | 図面ファイルの保存期間 | 品質保証課 | 11月末 | 5年で仮置きする |
決まらない場合の扱いまで書いておくと、未決事項が開発を止めずに済みます。
13. 承認
最後に、誰がどの版を承認したかを残します。承認者は、費用を出す部門の責任者と、実際に使う部門の責任者の両方にします。使う側の承認がないまま進めると、導入の段階で「現場は聞いていない」が起きます。
よくある失敗
- 機能一覧から書き始める：業務の流れがないため、例外の場面が抜ける
- OUTを書かない：開発の終盤で「これも必要」と追加が続く
- 用語を定義しない：同じ言葉を部署ごとに違う意味で読み、テストで食い違う
- 未決事項を書かない：後から「決めたはず」「聞いていない」の争いになる
- 改訂履歴を残さない：古い版を見て作業する人が出る
- 使う側の承認を取らない：完成後に現場が受け入れない
この記事のまとめ
- 要件定義書は、作るもの・作らないものを確認し、検収の基準にもなる文書
- 章立ては、背景と目的・スコープ・用語・業務フロー・機能・データ・非機能・移行・運用・未決事項・承認
- 背景と目的は数字で書き、目的の指標を導入後の効果確認に使う
- OUTは理由といつ扱うかを添え、用語は表で定義する
- 機能要件の前にTOBE業務フローを載せ、権限とステータスは表にする
- 未決事項は決める人・期限・決まらない場合の扱いまで書き、使う側の承認も取る
この記事の内容は、ロードマップのStep 5「決める」にあたります。要件定義書ができたら、Step 6「進めて作る」で開発と導入に進みます。要件の抜け漏れ事例や演習で学ぶなら、FDEガイドの現場導入のための要件定義を、状態とデータの設計はステータス管理とテーブル分割を参照してください。演習とテストはlecture.iplot.jpで取り組めます。