要件定義書（サンプル：経費精算システム刷新）
システム名・版数・作成者と承認者・対象範囲・スケジュール、目的・背景、業務要件、機能要件（ID・優先度・根拠）、非機能要件、制約・前提・未決事項。
登録不要・無料。Word版は1ページ目が空欄、2ページ目が記入例（A4縦）。
要件定義書 テンプレート
要件定義書のテンプレート（Word・Excel）。サンプルと書き方
要件定義書のテンプレートを、Word版（表紙・7章、2ページ目にサンプル）とExcel版（要件一覧つき）で無料配布しています。要件定義書は、システムや業務改善で「何を実現するか」を目的・背景、業務要件、機能要件、非機能要件、制約・前提、スケジュール、未決事項に分けて書き、発注側と開発側が合意するための文書です。サンプルは経費精算システム刷新（架空）で、表紙と改版履歴、各章の書き方、ヒアリングから要件を起こす例まで載せています。
公開日・更新日：
執筆・運営：Klang AI AB
構成
要件定義書の構成：7つの章と書く内容
要件定義書の章立てに決まった形はありませんが、次の7つの章があれば、発注側と開発側が「何を作り、何を作らないか」を合意できます。テンプレートもこの順番です。
| 章 | 書く内容 | 記入のポイント |
|---|---|---|
| 表紙・概要 | システム名、版数・日付、作成者・承認者、対象範囲、スケジュール | 版数と日付を必ず入れ、変更のたびに更新する |
| 1. 目的・背景 | なぜ作るのか。現状の問題と、達成したい状態 | 「承認まで平均6日→2日」のように数字で書く |
| 2. 業務要件 | 新しい業務の流れ（誰が・いつ・何をするか） | システムの機能ではなく、業務の言葉で書く |
| 3. 機能要件 | システムが提供する機能と、その内容・優先度 | 1行に1機能。どの業務要件から来たかを書く |
| 4. 非機能要件 | 可用性・性能・運用・移行・セキュリティなどの目標値 | 「速く」ではなく「3秒以内」のように測れる形で |
| 5. 制約・前提 | 予算、既存システム、法令・社内規程、使える期間 | 前提が崩れたら要件を見直す、と明記する |
| 6. 未決事項 | 決まっていないこと、確認先、期限 | 推測で埋めず、ここに残して管理する |
違い
要件定義・要求定義・基本設計の違いは？
要求定義は「やりたいこと」、要件定義は「実現すると決めたこと」、基本設計は「どう実現するか」です。誰が書き、誰が読むかで区別すると混乱しません。
| 要求定義 | 要件定義 | 基本設計 | |
|---|---|---|---|
| 答える問い | 何に困っていて、何をしたいか | 何を実現するか（範囲と条件） | どう実現するか（画面・データ・処理） |
| 主に書く人 | 発注側・利用部門 | 開発側（情報システム部門・ベンダー） | 開発側 |
| 例 | 「外出先から経費を申請したい」 | 「スマートフォンで領収書を撮影して申請できる」 | 「申請画面の項目、読み取り結果の確認画面、APIの仕様」 |
| 合意の相手 | 利用部門の中 | 発注側と開発側 | 開発側の中（発注側は主要部分を確認） |
表紙
要件定義書の表紙と改版履歴の書き方
要件定義書は、承認されたあとも変更が入る文書です。表紙には「どの版を、誰が承認したか」が一目で分かる項目を置き、改版履歴で変更の理由を追えるようにします。テンプレートの表紙欄は、下の表の上から5項目です。
| 項目 | 記入例 | 書き方のポイント |
|---|---|---|
| システム名 | 経費精算システム刷新 | 文書名は「〇〇 要件定義書」とする |
| 版数・日付 | 第1.2版 2026年10月14日 | 承認前は0.x、承認した版を1.0にする |
| 作成者・承認者 | 作成：情報システム部 林／承認：経理部長 小川 | 承認者は発注側の責任者。押印欄の代わりに承認日を書いてもよい |
| 対象範囲 | 全社員（約450名）の経費申請・承認・経理での確認 | 対象外にしたものと未決のものも書く |
| スケジュール | 要件確定 11月末／設計 12〜1月／本番 2027年4月 | 要件確定の日付を先に置く |
| 関係文書（任意） | 要求一覧、ヒアリング議事録 10/2・10/7、経費規程 | 根拠にした資料の名前と版を並べる |
改版履歴の例（表紙の次に追加して使う）
| 版数 | 日付 | 変更内容 | 理由・承認 |
|---|---|---|---|
| 0.9 | 10/9 | 初版（レビュー用） | ― |
| 1.0 | 10/10 | レビューの指摘を反映して承認 | 経理部長 小川 |
| 1.1 | 10/14 | F-02の承認経路を、金額と部署の2条件で決める内容に変更 | 経費規程 第5条との不一致の指摘。経理部長承認 |
| 1.2 | 10/14 | 非機能要件の利用時間を平日8〜22時に変更 | 10/7 ヒアリング（22:10）の発言を反映。経理部長承認 |
書き方
要件定義書の書き方：6つの手順
要件定義書は、いきなり機能の一覧から書き始めると、目的に合わない機能が混ざります。目的から順に、上の章で決めたことを下の章の根拠にしていきます。
- 01
目的と対象範囲を1ページで合意する
「何のために」「どの業務・部署・利用者までを対象にするか」を先に決め、発注側の責任者に確認します。範囲の外に置くものも書きます。
- 02
利用部門にヒアリングし、要求を集める
現在の業務の流れ、困りごと、例外の処理を聞きます。ヒアリングは録音か詳しい議事録で残し、発言者と日付を記録します。
- 03
要求を業務要件に整理する
集めた要求を、新しい業務の流れとして書き直します。矛盾する要求は両方残し、どちらを採るかを未決事項にします。
- 04
機能要件と非機能要件に分ける
業務要件ごとに必要な機能を1行ずつ書き、IDと優先度、根拠の業務要件を付けます。性能や可用性は目標値で書きます。
- 05
制約・前提と未決事項を書き出す
予算や既存システムなどの制約、決まっていないことと確認先・期限を一覧にします。未決事項を隠すと、後の工程で手戻りになります。
- 06
レビューして版を固め、承認を得る
利用部門と開発側で読み合わせ、修正を版数で管理します。承認後の変更は、変更の理由と影響を記録してから反映します。
作成例
ヒアリングの記録から要件を起こす例
経費精算システム刷新（架空）の、営業部と経理部へのヒアリングの発言を、要件定義書のどこにどう書いたかを並べました。要件の「根拠」に発言の日付と時刻を残しておくと、レビューで理由を問われたときに元の発言を確かめられます。
| 日付（録音の経過時間） | 発言（抜粋） | 区分 | 要件定義書の記載 |
|---|---|---|---|
| 10/2（12:40） | 営業部 斎藤「出張先で領収書をなくすので、その日のうちに申請したい」 | 業務要件 | B-01 スマートフォンで領収書を撮影し、外出先から申請できる |
| 10/2（18:15） | 営業部 斎藤「金額や日付を手で打つのが面倒」 | 機能要件 | F-01 撮影画像から日付・金額・支払先を読み取り、申請者が確認・修正する |
| 10/7（08:30） | 経理部 小川「承認者が誰か分からず、申請が止まることが多い」 | 機能要件 | F-02 金額と部署で承認者を自動で決め、差し戻し理由を記録する |
| 10/7（22:10） | 経理部 小川「月末は夜まで処理するので、22時までは使いたい」 | 非機能要件 | 可用性：平日8〜22時に利用できる。計画停止は月1回まで |
| 10/7（31:05） | 経理部 小川「海外出張は年に十数件。外貨はどうするか決めていない」 | 未決事項 | 海外出張の外貨精算を対象に含めるか（10/21 経理部長に確認） |
ヒアリングの質問の作り方と進め方は要件定義ヒアリングの質問例、初回の聞き取りで使う項目はヒアリングシートのテンプレートで紹介しています。Excel版の「要件一覧」シートには、根拠（発言・資料）・発言者・状態（未確認・確定・保留・対象外）の列があり、この例と同じ形の記入例が入っています。ヒアリングの録音がある場合は、会議の文字起こしで発言を時刻つきの文字にしてから要件を起こすと、「根拠」欄の時刻をそのまま写せます。
非機能要件
非機能要件は何を書けばよい？
非機能要件は、機能以外の品質の条件です。IPA（情報処理推進機構）の「非機能要求グレード」は、非機能要件を6つの大項目に整理しています。テンプレートの非機能要件の表は、このうち5項目を記入例にしています。
| 大項目 | 決めること | 書き方の例 |
|---|---|---|
| 可用性 | 使える時間帯、停止の許容範囲、障害時の復旧 | 平日8〜22時に利用できる。計画停止は月1回まで |
| 性能・拡張性 | 応答時間、同時利用数、データ量の増加 | 月末の同時利用100名で画面表示3秒以内 |
| 運用・保守性 | 監視、バックアップ、マスタの変更方法 | マスタの承認者変更を経理部が画面から行える |
| 移行性 | 移行するデータの範囲と時期、並行稼働 | 過去3年分の申請データを移行する |
| セキュリティ | 認証、権限、ログ、データの保護 | SSOでログイン。操作ログを1年保存する |
| システム環境・エコロジー | 設置環境、利用する機器、消費電力など | 社員の業務用スマートフォン（iOS・Android）で使える |
よくある失敗
要件定義書のよくある失敗
要件定義書の不備は、設計やテストの工程で手戻りとして表に出ます。書いた時点では気づきにくい失敗を、書き方の例で示します。
避けたい書き方
使いやすい画面にする。
改善例
初めて使う社員が、説明なしで3分以内に申請を完了できる（受け入れテストで5名に確認）
「使いやすい」は人によって基準が違い、完成したかどうか判断できません。
避けたい書き方
外貨精算にも対応する（たぶん必要）。
改善例
未決：海外出張の外貨精算を対象に含めるか（10/21 経理部長に確認）
確認していない要件を確定として書くと、見積と範囲が後から変わります。
避けたい書き方
承認機能を作る。
改善例
F-02 金額と部署で承認者を自動で決め、差し戻し理由を記録する（根拠：B-02、経費規程 第5条）
機能名だけでは中身が分からず、根拠がないと要件を削ってよいかも判断できません。
要件定義の打ち合わせでは、決定事項と未決事項を分けて議事録に残しておくと、要件定義書の「未決事項」をそのまま更新できます。書式は議事録テンプレートを使えます。プロジェクトの開始時の会議はキックオフミーティングの進め方を参照してください。設計の段階で開くレビューの指摘を、処置と確認まで追う記録の付け方はデザインレビュー（DR）の議事録にまとめています。
ダウンロード
要件定義書のテンプレートとサンプル（Word・Excel）
Word版は1ページ目が空欄のテンプレート、2ページ目がサンプル（記入例、A4縦）です。Excel版には、要件定義書の記入用シート、要件を1行1件で管理する要件一覧（優先度・状態の選択つき）、記入例が入っています。
要件定義書のサンプルを読む
要件定義書
記入例・架空記入例（架空の企業の「経費精算システム刷新」です）。数値・人名・日付はすべて例です。
- システム名
- 経費精算システム刷新
- 版数・日付
- 第1.2版 2026年10月14日
- 作成者・承認者
- 作成：情報システム部 林／承認：経理部長 小川
- 対象範囲
- 全社員（約450名）の経費申請・承認・経理での確認
- スケジュール
- 要件確定 11月末／設計 12〜1月／本番 2027年4月
1. 目的・背景
- ・紙の領収書と表計算ソフトでの申請により、月末の経理の確認に1人あたり約3日かかっている
- ・領収書の電子保存と、承認までの日数の短縮（平均6日→2日）を目的とする
2. 業務要件
| ID | 業務 | あるべき姿 | 根拠 |
|---|---|---|---|
| B-01 | 経費申請 | スマートフォンで領収書を撮影し、外出先から申請できる | 10/2 営業部ヒアリング |
| B-02 | 承認 | 金額10万円以上は部長、それ未満は課長の承認で完了する | 経費規程 第5条 |
3. 機能要件
| ID | 機能 | 内容 | 優先度 | 根拠 |
|---|---|---|---|---|
| F-01 | 領収書読み取り | 撮影画像から日付・金額・支払先を読み取り、申請者が確認・修正する | 必須 | B-01 |
| F-02 | 承認経路 | 金額と部署で承認者を自動で決め、差し戻し理由を記録する | 必須 | B-02 |
| F-03 | 会計連携 | 承認済みの仕訳を会計ソフト用のCSVで出力する | 高 | 10/7 経理部ヒアリング |
4. 非機能要件
| 区分 | 要件・目標値 | 根拠 |
|---|---|---|
| 可用性 | 平日8〜22時に利用できる。計画停止は月1回まで | 10/7 経理部 |
| 性能・拡張性 | 月末の同時利用100名で画面表示3秒以内 | 申請件数の実績 |
| 運用・保守性 | マスタの承認者変更を経理部が画面から行える | 10/7 経理部 |
| 移行性 | 過去3年分の申請データを移行する | 保存期間の規程 |
| セキュリティ | SSOでログイン。操作ログを1年保存する | 情報セキュリティ規程 |
5. 制約・前提・未決事項
- ・制約：既存の会計ソフトは更新しない。予算は初年度の範囲内
- ・未決：海外出張の外貨精算を対象に含めるか（10/21 経理部長に確認）
- ・未決：交通費の定期区間の控除を自動で行うか
KLANG
ヒアリングの発言を、要件の根拠として残す
Klangは、要件定義のヒアリングや打ち合わせの録音から、発言の時刻つきの文字起こしと要約を作成します。要件一覧の「根拠」欄に日付・発言者・時刻を書いておけば、後で「誰がそう言ったのか」を元の発言で確かめられます。
- Zoom・Microsoft Teams・Google Meetの打ち合わせに自動で参加し、録音と文字起こしを行います
- 要約から決定事項・タスク・未決事項を拾い、要件一覧に写せます。Word・Excel・CSVで書き出せます
- 会話データをAIの学習に使いません。ISO/IEC 27001:2022の認証を取得しています
発言者ごとに分ける話者の自動識別はプロプランの機能です。打ち合わせを録音するときは、参加者に目的を伝えてから始めてください。
無料で試すよくある質問
要件定義書には何を書けばよいですか。
目的・背景、対象範囲、業務要件、機能要件、非機能要件、制約・前提、スケジュール、未決事項を書きます。各要件にはIDと根拠（ヒアリングの日付・発言者、または規程や資料の名前）を付けると、変更や確認のときに追いやすくなります。
要件定義書は誰が書くものですか。
一般的には、開発側（ベンダーや情報システム部門）が利用部門へのヒアリングをもとに作成し、発注側・利用部門が内容を確認して承認します。発注側が要求を整理した要求定義書を先に作り、それをもとに要件定義書を作る進め方もあります。
要件定義と要求定義の違いは何ですか。
要求定義は利用者や発注側が「何をしたいか・何に困っているか」をまとめたもので、要件定義はそれを実現するためにシステムや業務が満たすべき条件を、実現可能性や予算を踏まえて決めたものです。要求のすべてが要件になるわけではありません。
非機能要件には何を書けばよいですか。
可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境の観点で、目標値と根拠を書きます。IPA（情報処理推進機構）の「非機能要求グレード」は、これらを6つの大項目に整理しており、抜け漏れの確認に使えます。
要件定義書の表紙には何を書けばよいですか。
文書名、版数と日付、作成者と承認者、対象範囲、関係文書を書きます。承認前は0.x、承認した版を1.0とし、変更のたびに改版履歴へ版数・日付・変更内容・理由と承認者を残します。
Word版とExcel版はどう使い分けますか。
Word版は、表紙と7章を順に読んで承認する文書として使います。Excel版は、要件を1行1件でID・優先度・根拠・状態つきで管理する要件一覧として使い、変更の多い期間はExcelで管理してから、承認の版をWordにまとめる使い方が向いています。
Web制作やアプリ開発にも使えますか。
使えます。Web制作では業務要件の代わりに「サイトの目的と対象ユーザー」、機能要件に「ページ構成・フォーム・管理画面」を書くなど、章の中身を置き換えてください。構成（目的・要件・制約・スケジュール・未決事項）はそのまま使えます。