システム開発や業務改善の打ち合わせでは、「何を作るのか」「どこまで対応するのか」があいまいなまま進んでしまうことがあります。
最初は口頭でも何となく話が通じます。会議室でホワイトボードに業務の流れを書いて、担当者同士で「たぶんこの範囲ですね」と確認する。ここまではよくあります。ただ、後からメールやチャットを見返すと、決めたはずの内容が残っていないことも多いです。
このページでは、要件定義書テンプレートを無料で配布しています。Word版・Excel版・PDF版・Googleスプレッドシート版を用意しているので、社内説明、ベンダー共有、機能一覧の整理など、使う場面に合わせて選べます。
- Word版：背景・目的・スコープを文書としてまとめたい場合
- Excel版：機能一覧、画面一覧、項目定義を表で管理したい場合
- PDF版：完成サンプルを見て、記入イメージを先に確認したい場合
- Googleスプレッドシート版：複数人でコメントしながら整理したい場合
用途別に選ぶ｜要件定義書テンプレート早見表
「とりあえず要件定義書を作りたい」といっても、使う人の立場で向いている形式が少し変わります。
新人の担当者が初めて作るなら、まずPDFサンプルで完成形を見る方が早いです。情報システム部門や開発会社との打ち合わせに使うなら、Word版で背景やスコープを文章にしておくと話がずれにくいですね。機能数が多い案件なら、Excel版で機能IDや優先度を付けた方が後から追いやすいです。
| 使う場面 | おすすめ形式 | 使いどころ |
|---|---|---|
| 初めて要件定義書を作る | PDF版 | 完成サンプルを見て、どのくらい書けばよいか先に確認できます。 |
| 社内稟議やベンダー共有に使う | Word版 | 背景、目的、スコープ、合意事項を文書として残したいときに向いています。 |
| 機能一覧や画面一覧を管理する | Excel版 | 機能ID、優先度、担当者、確認状況を一覧で見られます。レビュー時も楽です。 |
| 複数人で同時に編集する | Googleスプレッドシート版 | 情報システム部門、現場担当、外部ベンダーでコメントを入れながら進める場合に使いやすいです。 |
| ECサイトやWebサイト制作で使う | Excel版＋補足メモ | 商品管理、決済、配送、会員登録、SEO要件などを追加して使うと整理しやすいです。 |
要件定義書テンプレートの形式比較
要件定義書は、1つの形式だけで完結させなくても大丈夫です。
現場では、Wordで全体方針をまとめて、Excelで機能一覧を管理する使い方もよくあります。最初からきれいにまとめるより、打ち合わせで出た内容をExcelにざっと入れて、後からWordに整理する方が進むこともあります。夕方のレビュー前に慌ててまとめる場面だと、この流れの方が手戻りは少ないです。
| 形式 | 特徴・用途 | テンプレート |
|---|---|---|
| Word版 | 背景、目的、スコープ、業務フロー、機能要件を文章でまとめる形式です。社内稟議やベンダーとの合意資料として残したい場合に向いています。 | Word版を見る |
| Excel版 | 機能一覧、画面一覧、インターフェース一覧、非機能要件を表で整理する形式です。件数が増える案件では、フィルタや並べ替えがかなり助かります。 | Excel版を見る |
| PDF版 | 完成済みの要件定義書サンプルです。テンプレートを編集する前に、全体の流れや記入量を確認したいときに使えます。 | PDF版を見る |
| スプレッドシート版 | Googleスプレッドシートで共同編集する形式です。外部ベンダーや在宅メンバーと同時に確認したい場合に向いています。 | スプレッドシート版を見る |
要件定義書テンプレートのダウンロード
ここから、各テンプレートを紹介します。
先に完成形を確認したい方はPDF版、文書としてまとめたい方はWord版、機能や項目を一覧で管理したい方はExcel版が使いやすいと思います。迷ったら、PDFを見てからWordかExcelを選ぶ流れで十分です。
要件定義書テンプレート（Word版）
要件定義書テンプレート（Excel版）
要件定義書サンプル（PDF版）
完成見本つきの要件定義書サンプルPDFです。架空の見積管理システムを題材に、背景、目的、スコープ、機能要件、非機能要件などを入れています。
テンプレートを使う前にPDFを一度見ておくと、「この項目はどのくらい具体的に書くのか」がつかみやすいです。特に新人担当者が最初に作る場合、白紙のWordを開くより気が楽だと思います。
要件定義書テンプレート（Googleスプレッドシート版）
Googleスプレッドシート版は、複数人で同時に編集したい場合に向いています。
たとえば、現場担当者が業務要件を入力し、情報システム部門がシステム範囲を確認し、外部ベンダーが実装可否をコメントする。こういう進め方なら、メール添付でファイルを回すよりも管理しやすいです。変更履歴が残るので、「どこがいつ変わったか」も後から確認できます。
要件定義書とは
要件定義書は、システム開発や業務改善で「何を実現するのか」「どこまで対応するのか」をまとめる文書です。
もう少し現場寄りに言うと、後から揉めそうなことを先に書いておく資料です。たとえば、見積管理システムを作る場合、「見積書を作れるようにする」だけでは足りません。誰が作るのか、承認はいるのか、PDF出力するのか、過去データを移行するのか、スマホでも見るのか。このあたりを決めずに進めると、開発途中で話が増えます。
要件定義書があると、開発側、利用側、管理側で同じ資料を見ながら話せます。もちろん、書いた内容がすべて固定というわけではありません。現場では途中で調整もあります。ただ、最初の基準があるだけで、変更の話がしやすくなります。
要件定義書の主な役割
- プロジェクトの背景や目的を共有する
- 対象範囲と対象外の範囲をはっきりさせる
- 機能要件、非機能要件、画面、帳票、データ項目を整理する
- 社内担当者、管理者、開発会社の認識違いを減らす
- 設計、開発、テスト、運用の判断材料として残す
要件定義書を使う場面
- 新規システム開発を外部ベンダーに依頼するとき
- 既存システムを改修するとき
- Excel管理していた業務をシステム化するとき
- 社内ワークフローや承認ルートを見直すとき
- RFPや見積依頼の前に、発注側の希望を整理するとき
要件定義書・要求仕様書・基本設計書の違い
要件定義書と似た書類に、要求仕様書、RFP、基本設計書があります。名前が似ているので、ここで迷う人は多いです。
ざっくり分けると、要求仕様書は「利用者や発注側が求めていること」、要件定義書は「今回のプロジェクトで実現すること」、基本設計書は「どう実現するか」をまとめる文書です。
| 書類名 | 主な役割 | 使うタイミング |
|---|---|---|
| 要求仕様書 | 発注側や利用者側の希望、困りごと、実現したい内容を整理する | 企画段階、ベンダー相談前 |
| 要件定義書 | 今回実現する範囲、機能、条件、対象外を合意する | 開発前、見積確定前、設計前 |
| RFP | ベンダーへ提案や見積を依頼するための条件をまとめる | ベンダー選定時 |
| 基本設計書 | 要件をもとに、画面、機能、帳票、システム構成へ落とし込む | 要件定義の後 |
小さな改修なら、これらを1つの資料にまとめることもあります。逆に基幹システムの入れ替えや、関係部署が多い案件では、書類を分けた方がレビューしやすいです。ここは会社の進め方や案件規模で調整してよいところです。
要件定義書に入れる項目
要件定義書には、最低限入れておきたい項目があります。
ただし、すべての案件で同じ深さまで書く必要はありません。小さな社内ツールなら、システム構成図や詳細な非機能要件は簡略化してもよいでしょう。逆に、外部公開するWebサービスや顧客情報を扱うシステムでは、セキュリティやバックアップの記載を薄くしすぎると後で困ります。
1. プロジェクト概要
- 背景
- 現状の課題
- 目的
- 期待する効果
- 完了後にどうなっていればよいか
2. スコープ
- 対象業務
- 対象システム
- 対象部署
- 今回対応しない範囲
- 将来対応として残す範囲
3. 業務フロー
- 現在の業務フロー
- 改善後の業務フロー
- 手作業が残る部分
- 承認や確認が入るタイミング
4. 機能要件
- 機能一覧
- 利用者
- 入力情報
- 出力情報
- 処理内容
- 優先度
5. 非機能要件
- レスポンス時間
- 同時利用人数
- 権限管理
- ログ管理
- バックアップ
- 障害時の連絡方法
6. 画面・帳票・インターフェース
- 画面一覧
- 帳票一覧
- CSV出力
- 外部システム連携
- メール通知
- API連携
7. データ項目定義
- 項目名
- データ型
- 桁数
- 必須・任意
- 入力例
- 備考
8. 運用条件
- 利用時間帯
- 保守時間帯
- 管理者
- 問い合わせ先
- データ確認の頻度
- 月末・年度末など繁忙期の扱い
要件定義書の記入例
テンプレートを開いたときに迷いやすいのが、「どのくらい具体的に書けばいいのか」です。
たとえば「業務効率化を図る」とだけ書くと、読む人によって受け取り方が変わります。もう一歩だけ具体化して、「見積作成から承認までの手作業を減らし、承認待ちの状況を一覧で確認できるようにする」と書いた方が、開発側も判断しやすいです。
| 項目 | 記入例 |
|---|---|
| 背景 | 見積書をExcelで個別作成しており、最新版の確認や承認状況の把握に時間がかかっている。 |
| 目的 | 見積作成、承認、PDF出力、履歴確認を1つのシステムで行えるようにし、営業担当者と管理者の確認作業を減らす。 |
| 対象範囲 | 見積作成、承認申請、承認状況の確認、見積書PDF出力、顧客別の履歴表示を対象とする。 |
| 対象外 | 請求書発行、入金管理、会計ソフト連携は今回の対象外とする。次期対応として別途検討する。 |
| 機能要件 | 営業担当者は顧客名、商品名、数量、単価を入力し、見積書を作成できる。作成後、管理者へ承認申請できる。 |
| 非機能要件 | 社内ネットワークから利用する。営業担当者と管理者で権限を分け、承認済みデータの編集は管理者のみ許可する。 |
要件定義書の書き方
要件定義書は、テンプレートの上から順番に埋めるだけだと詰まりやすいです。
先に現状の困りごとを出して、次に対象範囲を決めて、それから機能に落とす。この順番の方が自然です。いきなり機能一覧から書くと、「この機能、本当にいるんだっけ？」となりやすいですね。
ステップ1：現状の困りごとを書き出す
まず、現場で起きている困りごとをそのまま書き出します。
月末になると承認待ちの見積が増える、担当者のPCにだけ最新版が残っている、過去の見積を探すのに時間がかかる。こういう具体的な話から入ると、要件に落とし込みやすいです。
ステップ2：対象範囲と対象外を分ける
要件定義で特に迷うのが、どこまでを今回やるかです。
「見積管理システム」と言っても、請求書まで含めるのか、入金確認まで含めるのか、顧客管理まで含めるのかで規模が変わります。ここを曖昧にすると、後半で追加要望が増えます。
対象外の欄は、少し冷たく見えるくらい具体的に書いておく方が後で助かります。
ステップ3：機能を業務フローに沿って並べる
機能一覧は、思いついた順に書くより、業務の流れに沿って並べる方が見やすいです。
見積作成、承認申請、承認、PDF出力、履歴確認、管理者確認。このように実際の動きに沿って並べると、抜けている機能に気づきやすくなります。
ステップ4：非機能要件を後回しにしすぎない
非機能要件は、性能、セキュリティ、バックアップ、権限、ログなどの条件です。
画面や機能に比べると地味ですが、運用が始まってから効いてきます。たとえば「誰が承認済みデータを修正できるのか」「削除したデータは戻せるのか」「夜間メンテナンスはいつ行うのか」などです。
ここを空欄のままにすると、開発後の調整が増えます。
ステップ5：レビューで合意内容を残す
要件定義書は、作って終わりではありません。
現場担当者、管理者、情報システム部門、開発会社で確認し、合意した日付と担当者を残しておくと安心です。会議中は話が早く進んでも、数週間後に見返すと記憶が薄れています。議事録とセットで残すくらいがちょうどいいと思います。
要件定義書でありがちなミス
要件定義書は、きれいな言葉でまとめるより、後から確認できる形にしておく方が実務では助かります。
ここでは、実際に詰まりやすいところをまとめます。
要望と要件が混ざる
「使いやすくしたい」「早く処理したい」「ミスを減らしたい」は、要望としては自然です。ただ、そのままだと開発側は判断しにくいです。
たとえば「早く処理したい」なら、「見積一覧の検索結果を3秒以内に表示する」「承認待ち件数を一覧で確認する」くらいまで落とすと、要件として扱いやすくなります。
対象外を書かない
要件定義書で意外と抜けやすいのが、対象外の範囲です。
「今回は請求書発行を含めない」「既存データの移行は過去3年分まで」「スマホ対応は次期対応」など、やらないことも書いておきます。ここを省くと、後から「当然入っていると思っていた」と言われることがあります。
少し面倒ですが、ここは書いておいた方が楽です。
Word本文とExcel一覧がずれる
Word版とExcel版を併用するときに起きやすいミスです。
Wordでは「承認機能あり」と書いているのに、Excelの機能一覧では承認画面が抜けている。逆にExcelには機能があるのに、Wordのスコープに書いていない。レビュー直前にこういうズレが出ると、会議室の空気が少し重くなります。
機能IDを付けて、Word本文にも同じIDを入れておくと確認しやすいです。
非機能要件を空欄にする
非機能要件は、最初の打ち合わせでは話題に出にくいです。
ただ、ログ、権限、バックアップ、障害時の対応は、運用が始まると急に現実的になります。詳しく決めきれない場合でも、「管理者のみ編集可」「日次バックアップ」「操作ログを保存」くらいはメモしておくと後で助かります。
要件定義書テンプレートの使いどころ
同じ要件定義書でも、案件によって見るべき場所が変わります。テンプレートをそのまま全部使うより、案件に合わせて項目を足したり減らしたりする方が自然です。
システム開発で使う場合
システム開発では、機能一覧、画面一覧、データ項目、権限、外部連携を中心に整理します。
たとえば、販売管理システムなら、見積、受注、請求、入金、在庫のどこまでを対象にするかを先に分けます。ここを曖昧にすると、開発会社の見積金額もブレやすいです。
Word版で背景とスコープをまとめ、Excel版で機能一覧を管理する使い方が合います。
業務改善で使う場合
業務改善では、現行業務の流れを先に出した方が進めやすいです。
朝の事務所で、紙の申請書を誰が受け取り、誰が確認し、どこで止まるのか。こういう流れをそのまま書き出します。きれいな図にする前に、まずは付箋やメモで十分です。
その後、テンプレートに現状業務、改善後の業務、手作業として残す部分を入れていくと、関係者が見ても分かりやすい資料になります。
Webサイト・ECサイトで使う場合
WebサイトやECサイトでは、通常の機能要件に加えて、ページ構成、商品管理、会員登録、決済、配送、メール通知、SEO要件、アクセス解析タグなどを入れます。
ECサイトの場合、「商品を登録できる」だけでは足りません。商品画像は何枚までか、在庫切れ表示はどうするか、送料は地域別か一律か、クーポンを使うか。このあたりを詰めると、制作後の修正が減ります。
汎用のExcel版をベースにして、ECサイト用の項目を追加する使い方が向いています。
RPA・小規模改修で使う場合
RPAや小さな改修では、分厚い要件定義書を作るより、対象業務、入力データ、処理手順、例外処理、確認者を短くまとめる方が現実的です。
たとえば、毎朝9時にCSVを取り込み、顧客管理表へ転記する作業なら、通常時の流れだけでなく、CSVに空欄があった場合、同じ顧客が重複した場合、処理に失敗した場合も書いておきます。
例外処理は後回しにされがちですが、実際にはここで止まることが多いです。
テンプレートを使う前と使うときの違い
テンプレートを使う前は、担当者ごとに書き方がばらばらになりがちです。
ある人は背景だけ詳しく書き、別の人は機能一覧だけ作る。会議では話が合っているように見えても、資料を並べると抜けている部分が出てきます。特に、対象外、非機能要件、運用条件は空欄になりやすいです。
テンプレートを使うと、最初から項目が並んでいるので、「ここは今回は省略」「ここは後で確認」「ここは管理側に聞く」と判断しながら進められます。
全部を完璧に埋めるためのものではありません。抜けを見つけるための下書きとして使う方が、実務には合っています。
よくある質問
関連テンプレート
要件定義書を作る前後で、業務フロー図、WBS、ガントチャートも一緒に使う場面が多いです。
業務の流れを先に見たい場合は業務フロー図、作業を分解したい場合はWBS、スケジュール管理まで進める場合はガントチャートが使いやすいです。
