要件定義書とは？書き方と記載項目、規模別テンプレート｜誰が作り、誰が承認するか
要件定義書（ようけんていぎしょ）とは、これから作るシステムやWebサイトで「何を実現するか」を、発注者と受注者が合意した内容としてまとめた文書である。業務の流れ、必要な機能、性能やセキュリティなどの条件を書き、双方が確認して確定させる。確定した要件定義書が、その後の設計・開発・テスト・検収の基準になる。
この記事のポイント（TL;DR）
- IPA（情報処理推進機構）は、要望を文書にまとめ、関係者と合意したものが「要件」になると説明しています。要件定義書は、その合意の記録です。
- 要件定義の成果物に責任を持つのは、作ったシステムを使う発注者（ユーザー企業）です。受注者が書く作業を手伝う場合でも、この点は変わらない、とIPAは説明しています。
- IPAのモデル契約（第二版）では、要件定義書は「点検期間」内に双方が点検し、双方の責任者が記名押印して確定します。確定後の変更は、変更管理書で協議して決めます。
- 一般的な解説記事は業務要件・機能要件・非機能要件の3つを中心に書かれますが、受託・制作の現場で後から揉めやすいのは「範囲外」「受入れ基準」「未決事項」「変更の扱い」が空欄のケースです。この記事ではこの4つを必須項目として扱います。
- 小規模Web制作と中規模の業務システム、2つの規模のテンプレートを本文にそのまま写せる形で載せています。
どこから読むか
| 当てはまる状況 | 先に読むところ |
|---|---|
| 要件定義書が何の文書か、RFPや設計書と何が違うかを知りたい | 要件定義書とRFP・要求仕様書・基本設計書・見積書の違い |
| 発注者と受注者のどちらが書くのか、誰の承認で確定するのかを決めたい | 要件定義書は誰が作り、誰が承認するか |
| これから書くので、項目とひな形がほしい | 規模別の要件定義書テンプレート |
| 確定した後に「やっぱり変えたい」と言われた | 確定した要件定義書を変えるとき |
| 前の案件で要件定義書があったのに揉めた | 要件定義書でよくある失敗と対策 |
要件定義書とは｜意味と、要件定義との関係
要件定義書とは、作るものについて発注者と受注者が合意した内容を、後から確かめられる形で残した文書です。要件定義という作業の結果をまとめたもの、と言い換えることもできます。
IPAの解説では、要件定義はシステム開発の初期に行う工程で、企画の後、基本設計の前に置かれています。利用者のニーズを分析し、関係者と合意して「要件」をまとめる工程です。同じ解説の中で、ビジネス上の要求とシステムに対する要求を要件定義書として文書化し、ステークホルダーと合意したものが「要件」になる、と説明されています（IPA DX SQUARE：要件定義とは？）。
ここで押さえたいのは、「要求」と「要件」は別のものだという点です。
- 要求：発注者が「こうしたい」「これが欲しい」と望んでいること。まだ合意していない
- 要件：要求のうち、実現することを双方で確かめて合意したもの。文書になっている
打ち合わせで出た要望をそのまま箇条書きにしただけの資料は、まだ要求の一覧です。どれを実現し、どれを今回は見送るかを決め、双方が確認した時点で、要件定義書になります。
モデル契約での「要件定義書」の定義
IPAが公開している「情報システム・モデル取引・契約書（第二版）」（原版は経済産業省が2007年に公開）は、受託開発の契約書のひな形です。その第2条では、要件定義書を、機能要件と非機能要件をとりまとめた文書と定義しています。
- 機能要件：発注者の要求を満たすために、ソフトウェアが実現しなければならない機能に関する要件。システムの機能とデータで定義する
- 非機能要件：機能要件以外のすべての要素に関する要件。品質、技術、移行、運用、セキュリティの各要件と付帯作業などから成り、目標値と具体的な事項で定義する
（出典：IPA：情報システム・モデル取引・契約書（第二版）の「第二版 ひな型」第2条）
第二版では、この定義の中で、セキュリティ要件が非機能要件の1つであることが明記されました。Webサイトの制作でも、ログイン機能や問い合わせフォームがあるなら、セキュリティは「後で考えること」ではなく、要件定義書に書くことになります。
「要件定義書」という名前でなくてもよい
小規模なWeb制作では、「要件定義書」という名前の文書を作らず、「仕様書」「制作概要」「ご提案内容の確認書」といった名前で同じ役割の文書を作ることもあります。IPAの解説も、作る文書はプロジェクトによって異なるとしています。大事なのは名前ではなく、次の3つがそろっていることです。
- 何を作り、何を作らないかが書いてある
- 何をもって完成とするかが書いてある
- 発注者と受注者の双方が確認した記録がある
この3つがそろっていれば、名前が「仕様書」でも、要件定義書の役割を果たします。逆に、名前が要件定義書でも、2と3が無ければ、納品のときに合否の判断で揉める原因になります。
要件定義書とRFP・要求仕様書・基本設計書・見積書の違い
似た文書との違いは、「誰が作るか」「いつ作るか」「何が決まるか」で整理すると分かりやすくなります。発注の流れでは、RFP（提案依頼書）→提案書・見積書→要件定義書→基本設計書の順に作られるのが一般的です。
| 文書 | 主に作る人 | 作る時点 | 何が書かれているか | 確定のしかた |
|---|---|---|---|---|
| RFP（提案依頼書） | 発注者 | 依頼先を選ぶ前 | 目的・背景、依頼したい範囲、予算、スケジュール、提案の評価方法 | 発注者の社内で決める。受注者とは合意しない |
| 提案書 | 受注者（候補） | RFPを受けた後 | 課題の捉え方、解決策、体制、進め方 | 発注者が比較・選定する |
| 見積書 | 受注者（候補） | 提案と同時か直後 | 作業の範囲と金額、前提条件、有効期限 | 発注・契約で取引条件になる |
| 要求仕様書 | 発注者 | 要件定義の前や途中 | 発注者が実現したいこと（要求）の一覧 | 合意前の資料。要件定義で絞り込む |
| 要件定義書 | 発注者（受注者が支援） | 契約後、設計の前 | 業務・機能・非機能の要件、範囲外、受入れ基準、変更の扱い | 双方が点検し、確認の記録を残して確定 |
| 基本設計書（外部設計書） | 受注者 | 要件定義書の確定後 | 画面・帳票・外部とのやり取りなど、要件をどう実現するか | 発注者が点検・承認する |
RFPとの違い
RFPは、発注者が依頼先を選ぶために出す文書で、受注者とはまだ何も合意していません。要件定義書は、依頼先が決まった後に、作るものを双方で合意する文書です。RFPに「会員登録機能が欲しい」と書いてあっても、どの項目を登録させるか、パスワードを忘れたときはどうするかまでは決まっていません。その詳細を決めて合意するのが要件定義書の役割です。RFPそのものの意味やRFI・RFQとの違いはRFPとは、書き方はRFPの書き方完全ガイドで扱っています。
要求仕様書との違い
要求仕様書は、発注者が望むこと（要求）をまとめた文書で、まだ受注者と合意していない段階のものを指すことが多い言葉です。要件定義書は、その要求のうち、実現すると決めて双方で合意したものです。会社によっては両者を同じ意味で使うこともあるため、案件の最初に「この案件でいう要件定義書は、双方の確認を経た確定版を指す」と決めておくと混乱しません。
基本設計書との違い
要件定義書が「何を実現するか」を決める文書なのに対し、基本設計書（モデル契約では外部設計書）は「それをどう実現するか」を決める文書です。モデル契約の定義でも、外部設計書は、要件定義書に基づいて画面・帳票などのユーザーインターフェースや、他のシステムとのやり取りなどの仕様を定めた設計書とされています。要件定義書が固まらないまま設計を始めると、設計の段階で要件の議論が蒸し返され、手戻りの原因になります。
見積書との違い
見積書は金額と作業範囲を示す文書で、要件定義書は作るものの中身を示す文書です。ただし両者は強くつながっています。見積もりは「この範囲を作る」という前提で出しているので、要件定義で範囲が広がれば、見積もりの前提が崩れます。そのため、要件定義書には「見積もりの前提とした範囲」と「範囲外」を書いておき、要件定義の結果、範囲が見積もりの前提から変わった場合は、見積もりと契約条件を見直す手続きにつなげます。見積書の書き方と前提条件の書き方は見積書テンプレートの書き方で扱っています。
要件定義書は誰が作り、誰が承認するか
要件定義書の内容に責任を持つのは、作ったものを使う発注者です。受注者は、専門家として書く作業を支援します。
IPAの解説は、要件定義は発注者であり利用者であるユーザー企業の仕事だとしたうえで、ITベンダーに支援してもらう場合でも、要件定義でつくった成果物に対する責任はユーザー企業にある、と述べています（IPA DX SQUARE：要件定義とは？）。IPAの「ユーザのための要件定義ガイド 第2版」の公開ページでも、システムの要件を定義する責任は、システムを使ってビジネスに貢献する役目を負うユーザにあると言われている、と書かれています（IPA：ユーザのための要件定義ガイド 第2版）。
モデル契約での役割分担
モデル契約（第二版）は、この役割分担を条文の形で示しています。委託者（発注者）を「甲」、受託者（受注者）を「乙」としたうえで、要件定義の段階を次のように定めています。
| 条文 | 内容 | 受託・制作の実務に置き換えると |
|---|---|---|
| 第14条（要件定義作成支援業務の実施） | 受注者は、発注者の構想書・計画書などをもとに、発注者による要件定義書の作成を支援する。専門的な知識と経験に基づき、善良な管理者の注意をもって、調査・分析・整理・提案・助言を行う | 受注者の役割は「代わりに決める」ことではなく、決めるための材料と選択肢を出すこと |
| 第16条（要件定義検討会） | 発注者は、要件定義書の作成に必要な事項を明確にしたり、内容を確認したりするため、必要な頻度で検討会を開く。受注者も必要と認めれば開催でき、発注者は参加する | 要件を決める打ち合わせの場を、頻度と参加者を決めて設ける |
| 第17条（要件定義書の確定） | 発注者が作成を終えたら、双方は個別契約で定めた「点検期間」内に、要件定義書が検討会での決定事項に合っているかを点検する。合っていれば双方の責任者が記名押印し、それをもって確定する | 「いつまでに確認してもらうか」と「誰が承認したか」を記録に残す |
| 第17条第3項 | 修正によって作業期間や委託料などの条件を変える必要が出たら、契約内容の変更の手続き（第33条）による | 要件定義の結果で範囲が変われば、金額と期間も見直す |
（出典：IPA：情報システム・モデル取引・契約書（第二版）の「第二版 ひな型」第14条・第16条・第17条）
モデル契約は大規模なシステム開発を想定したひな形で、そのまま小規模なWeb制作の契約に使うものではありません。それでも、「中身に責任を持つのは発注者」「受注者は支援する」「双方が点検して確定させ、確定の記録を残す」という骨組みは、規模に関係なく役に立ちます。
受注者が下書きを書く場合に気をつけること
発注者側に要件定義の経験がある担当者がいない案件では、受注者が叩き台を書き、発注者に確認してもらう進め方もあります。その場合も、次の3点を守ると、後で「受注者が勝手に決めた」と言われにくくなります。
- 決める人を最初に確認する：窓口の担当者と、最終的に承認する人が違うことはよくあります。承認者の名前と役職を、要件定義書の表紙か承認欄に書きます。体制図の書き方はプロジェクト体制図の書き方とテンプレートで扱っています。
- 受注者が決めたように見える書き方を避ける：「〜とする」と書く前に、その判断が誰の発言に基づくかを、議事録で辿れるようにしておきます。
- 選択肢と推奨を分けて書く：「A案（推奨）／B案」のように、受注者の推奨と、発注者が選んだ結果を区別して残します。
「言った・言わない」の食い違いを防ぐ記録の残し方は、「言った言わない」をなくす方法でも詳しく扱っています。
承認は「誰が・いつ・どの版を」の3点で残す
承認の記録は、押印やサインでなくてもかまいません。メールやチャットで「この版で確定とします」と返事をもらう方法もあります。ただし、次の3点が後から分かる形にしておきます。
- 誰が：承認した人の名前と役職
- いつ：承認した日付
- どの版を：版番号（例：v1.0）と、その版のファイルそのもの
特に3つめが抜けやすく、「承認はもらったが、どのファイルに対する承認だったか分からない」という状態がよく起きます。承認の返事には、版番号を必ず含めてもらいます。
要件定義の段階を、本番の制作と分けて契約するか
モデル契約は、要件定義の段階を「要件定義作成支援業務」として、本番の開発とは別の個別契約で結ぶ形にしています（第15条）。受注者の義務も、完成させたものを引き渡すことではなく、専門的な知識と経験に基づいて、善良な管理者の注意をもって支援することとして書かれています（第14条）。
この形には、受託・制作の側から見て2つの利点があります。1つは、要件定義の結果として範囲が見えてから、本番の制作の見積もりを出せることです。要件が固まる前に全体の金額を約束すると、要件定義で範囲が広がったときに、その差を受注者がかぶることになりがちです。もう1つは、要件定義そのものにかかる打ち合わせや調査の工数が、無償の「提案活動」として扱われにくくなることです。
一方、小規模なWeb制作では、要件定義だけを別契約にすると、発注者にとって手続きが重く感じられることもあります。その場合でも、見積書に「要件定義の結果、範囲が見積もりの前提から変わった場合は再見積もりとする」と書いておけば、同じ効果の一部を得られます。請負と準委任で、完成や終了の判断がどう変わるかは、キックオフミーティングの進め方とクライアントワークとはで扱っています。
要件定義書に書く項目
要件定義書には、「何を作るか」を決める項目と、「どこまでで合意したか」を決める項目の2種類を書きます。一般的な解説の多くは前者（業務・機能・非機能の要件）が中心ですが、受託・制作の案件で後から揉めやすいのは、後者が空欄のときです。
| 区分 | 項目 | 何を書くか | 書き方の例 |
|---|---|---|---|
| 何を作るか | 目的と背景 | なぜ作るのか、今の何が困っているのか、完成後に何が良くなるのか | 「問い合わせの多くがよくある質問。FAQページと問い合わせフォームの分類で、電話対応を減らす」 |
| 何を作るか | 業務要件 | 作るものを使う業務の流れ、誰が・いつ・何をするか | 「問い合わせを受けたら、担当部署に自動で振り分け、2営業日以内に返信する」 |
| 何を作るか | 機能要件 | システムやサイトが持つ機能、扱うデータ、画面 | 「問い合わせフォーム：氏名・会社名・メール・種別・本文。送信後に自動返信メール」 |
| 何を作るか | 非機能要件 | 性能、使いやすさ、セキュリティ、運用・保守、移行など、機能以外の条件 | 「スマートフォンで表示が崩れない。フォームはSSL（https）で送信する」 |
| どこまでで合意か | 対象範囲と範囲外 | 今回作るもの、今回作らないもの | 「範囲外：多言語対応、会員機能、既存ブログ記事の移行」 |
| どこまでで合意か | 前提条件と制約 | 成り立つための前提、動かせない条件 | 「原稿・写真は発注者が用意する。公開日は4月1日で動かせない」 |
| どこまでで合意か | 受入れ基準 | 何を確認できたら完成（検収合格）とするか | 「主要ブラウザで表示と送信を確認。確認項目一覧の全項目が合格」 |
| どこまでで合意か | 未決事項 | まだ決まっていないこと、決める人、決める期限 | 「料金ページの掲載可否：発注者の営業部長が5月10日までに決定」 |
| どこまでで合意か | 変更の扱い | 確定後に変えたくなったときの手続き | 「変更は依頼書で受け付け、影響（費用・期間）を見積もってから実施を決める」 |
| どこまでで合意か | 承認の記録 | 誰が、いつ、どの版を承認したか | 「v1.0 を 5月15日 発注者○○部長が承認（メール）」 |
非機能要件は「グレード」で決めると漏れにくい
非機能要件は、発注者から要望として出てきにくい項目です。IPAの解説も、非機能面はビジネス上の要求には表れにくいため、システム部門が主体となって業務部門から聞き出すのが効率的だとしています。
業務システムの場合、IPAの「非機能要求グレード」が参考になります。非機能要求について、ユーザ（発注者）と開発者の認識の行き違いや、互いの意図と異なる理解を防ぐことを目的に作られたもので、非機能要求の項目を網羅的に挙げ、要求のレベルを段階的に示しています（IPA：非機能要求グレード）。2018年版の改訂情報によると、従来の236項目に2項目を加えた238の項目（メトリクス）があり、可用性、性能・拡張性、セキュリティなどの区分に分かれています（IPA：非機能要求グレード2018 改訂情報）。なお、この事業は2009〜2018年度に実施されたもので、IPAの紹介ページには、事業が終了しているため問い合わせには対応できないと書かれています。
238項目すべてを小規模な案件で決める必要はありません。Web制作なら、次の5つを最低限決めておくと、公開後の「こんなはずではなかった」を減らせます。
- 対応するブラウザと端末（例：Chrome・Safari・Edgeの最新版、iPhoneとAndroidのスマートフォン）
- 表示速度の目安と、測り方
- フォームやログインのセキュリティ（https、送信データの扱い、管理画面のパスワード）
- 公開後の更新を誰がやるか（発注者が自分で更新するなら、管理画面の使い方の説明が要る）
- バックアップと障害時の連絡先
範囲外を空欄にしない
範囲外は、要件定義書で一番書かれていないことが多い項目です。「書いていないことは作らない」で通じそうに思えますが、実際には、書いていないことは「当然入っていると思っていた」と受け取られがちです。
範囲外には、次のようなものを具体的に書きます。
- 発注者が話題にしたが、今回は見送ると決めたもの（例：会員機能、多言語対応）
- 似た作業で、範囲に入っていると誤解されやすいもの（例：既存記事の移行、写真の撮影、原稿の作成、公開後の運用）
- 他社や他部署が担当するもの（例：サーバー契約、ドメインの管理、社内システムとの連携）
範囲外に書いたものも、後から追加することはできます。その場合は、変更の手続きを通して、費用と期間を見直してから追加します。
受入れ基準は、検収の基準につなげる
受入れ基準は、何を確認できたら完成とするかの約束です。ここが曖昧だと、納品のときに「確認するたびに新しい指摘が出る」状態になり、検収が終わりません。
受入れ基準には、「確認する対象」「確認の方法」「合格の条件」の3つを書きます。たとえば「問い合わせフォーム（対象）を、指定のブラウザで実際に送信して（方法）、自動返信メールが届き、担当者に通知が届くこと（合格の条件）」です。要件定義の段階で受入れ基準を決めておくと、そのまま検収の確認項目の一覧になります。検収基準の書き方と、検収が止まる理由は検収とはで詳しく扱っています。
未決事項は「決める人と期限」をつけて残す
要件定義の期間内に、すべてが決まるとは限りません。決まっていないことを書かずに確定させると、後から決まった内容で範囲が広がっても、それが追加なのかどうかが分からなくなります。
未決事項は、「何が決まっていないか」「誰が決めるか」「いつまでに決めるか」「決まった結果で費用や期間が変わる可能性があるか」の4点を書いて残します。モデル契約（第二版）の第36条も、発注者がやむを得ない事情で必要な事項を確定できない場合に、未確定事項の内容と確定予定時期、確定によって委託料や納期などの条件が変わる場合に発注者がそれを受け入れることなどを、書面にして双方が記名押印する仕組みを定めています。
規模別の要件定義書テンプレート
要件定義書の書き方に、決まった公式の書式はありません。案件の規模に合わせて、項目の深さを変えます。ここでは、小規模なWeb制作と、中規模の業務システムの2つのひな形を載せます。どちらも Terasu 編集部が作成したひな形で、実在の企業や案件のものではありません。
| 項目 | 小規模（Webサイト制作、数ページ〜数十ページ） | 中規模（業務システム、複数部署が使う） |
|---|---|---|
| 分量の目安 | A4で数枚。1つのファイルにまとめる | 業務要件・機能要件・非機能要件を別冊に分けることもある |
| 業務要件 | 誰が何のためにサイトを使うか、を数行で | 業務フロー図、業務ごとの担当者と頻度・件数 |
| 機能要件 | ページ一覧と、フォームなど動きのある部分 | 機能一覧、画面一覧、帳票一覧、データ項目、外部連携 |
| 非機能要件 | 対応端末、表示速度、セキュリティ、更新方法の4〜5点 | 非機能要求グレードなどを使って区分ごとに目標値を決める |
| 範囲外・前提 | 必須。原稿・写真・サーバーの担当を明記 | 必須。データ移行、教育、運用の担当を明記 |
| 受入れ基準 | 確認項目の一覧（ページ数×端末） | テストの種類ごとの合格条件、受入れテストの期間 |
| 承認 | 発注者の決裁者1人がメールで承認 | 業務部門・情報システム部門の責任者が承認欄に記名 |
テンプレート1：小規模Web制作の要件定義書
コーポレートサイトや採用サイトなど、数ページから数十ページの制作を想定したひな形です。「○○」の部分を書き換えて使います。
要件定義書（○○株式会社 コーポレートサイト リニューアル）
版：v0.1（下書き） 作成日：2026-○-○ 作成：○○（制作会社） 確認：○○（発注者）
1. 目的と背景
- 今の課題：○○（例：問い合わせの多くが、サイトに載っていない質問）
- 完成後に良くなること：○○（例：よくある質問を自己解決できるようにする）
2. 対象範囲
- 制作するページ：トップ／会社概要／サービス（3ページ）／よくある質問／問い合わせ
- 動きのある部分：問い合わせフォーム（項目：氏名・会社名・メール・種別・本文）、自動返信メール
3. 範囲外（今回は作らないもの）
- 会員機能、多言語対応、既存ブログ記事の移行
- 原稿の作成、写真の撮影（発注者が用意する）
- サーバー・ドメインの契約（発注者の契約を使う）
4. 前提条件と制約
- 原稿と写真は ○月○日 までに発注者から受け取る
- 公開日：○月○日（動かせない）
- 公開後の更新は発注者が管理画面で行う（使い方の説明を1回行う）
5. 非機能要件
- 対応端末：パソコン（Chrome・Safari・Edge の最新版）、スマートフォン（iPhone・Android）
- セキュリティ：全ページ https、フォームの送信内容は○○に通知
- 表示速度：○○で計測し、目安は○○
6. 受入れ基準
- 確認項目の一覧（別紙）の全項目が合格すること
- 確認期間：納品から○営業日。期間内に指摘が無い場合の扱い：○○
7. 未決事項
| 内容 | 決める人 | 期限 | 費用・期間への影響 |
| 料金ページの掲載可否 | 発注者 ○○部長 | ○月○日 | 掲載する場合は1ページ追加 |
8. 変更の扱い
- 確定後の変更は、変更依頼として受け付け、費用と期間への影響を示してから実施を決める
9. 承認
- v1.0 を ○月○日 に ○○（発注者・役職）が承認（承認の方法：メール）
テンプレート2：中規模の業務システムの要件定義書（目次）
複数の部署が使う業務システムを想定した目次です。各章を別のファイルに分けてもかまいませんが、その場合も表紙と承認欄、変更履歴は1か所にまとめます。
要件定義書（○○業務システム）
0. 表紙・承認欄・変更履歴
- 版、日付、変更内容、承認者（業務部門・情報システム部門）
1. 概要
1.1 目的と背景（今の課題、システム化で解決すること）
1.2 対象範囲と範囲外
1.3 前提条件と制約（予算・期間・使う技術・既存システム）
1.4 用語の定義
2. 業務要件
2.1 業務一覧（業務名、担当部署、頻度、件数）
2.2 業務フロー（今の流れ／システム化後の流れ）
2.3 システム化する範囲（どの業務のどこまでをシステムで行うか）
3. 機能要件
3.1 機能一覧
3.2 画面一覧・帳票一覧
3.3 データ項目（扱うデータ、件数、保存期間）
3.4 外部とのやり取り（連携するシステム、方式、頻度）
4. 非機能要件
4.1 可用性（稼働時間、止まってよい時間）
4.2 性能・拡張性（応答時間、同時利用者数、データ量の伸び）
4.3 運用・保守（バックアップ、監視、問い合わせ窓口）
4.4 移行（既存データの移行範囲と方法）
4.5 セキュリティ（利用者の認証、権限、ログ）
5. 受入れ基準
5.1 受入れテストの範囲と期間
5.2 合格の条件
6. 未決事項の一覧（内容、決める人、期限、影響）
7. 変更の扱い（変更依頼の出し方、協議の場、承認者）
要件定義書の書き方｜合意を取り切る進め方
要件定義書は、書くこと自体よりも、関係者の合意を取り切ることに時間がかかります。進め方は次の順番が基本です。
1. 要求を集め、目的に照らして仕分ける
最初に、発注者から要望を集めます。ヒアリングでは「何が欲しいか」より先に「今何に困っているか」「完成したら何が良くなっていればよいか」を聞くと、目的に関係のない要望を見分けやすくなります。ヒアリングで聞く項目はヒアリングシートのテンプレートが参考になります。
集めた要望は、「今回実現する」「今回は見送る（範囲外）」「まだ決められない（未決事項）」の3つに仕分けます。この時点で範囲外と未決事項の欄が埋まり始めるのが、良い進み方です。
2. 決める場と、決める人を決める
モデル契約が「要件定義検討会」を置いているように、要件を決める打ち合わせは、頻度と参加者を決めて定例化します。毎回の打ち合わせで「決まったこと」「持ち帰ったこと（誰がいつまでに）」を議事録に残し、要件定義書には決まったことだけを反映します。議事録の書き方は議事録の書き方で扱っています。
案件の最初の打ち合わせで、要件定義の進め方そのもの（打ち合わせの頻度、承認者、点検期間）を決めておくと、後の段取りが楽になります。最初の打ち合わせで決める項目はキックオフミーティングの進め方にまとめています。
3. 下書きを書き、項目の空欄を残さない
上のテンプレートを使って下書きを書きます。この段階で大切なのは、空欄を残さないことです。決まっていない項目は空欄にせず、「未決事項」として決める人と期限を書きます。「該当なし」の項目も、空欄ではなく「該当なし」と書きます。空欄は、書き忘れなのか、該当がないのかを区別できないからです。
4. 点検の期間を決めて、確認してもらう
下書きができたら、発注者に確認を依頼します。依頼のときに「いつまでに確認してほしいか」を明示します。モデル契約でも、点検期間は個別契約で定めることになっています。確認が止まったときの連絡の仕方は、催促メールの書き方に例文があります。
確認してもらうときは、全文を読んでもらうより、「特に判断してほしい箇所」を3〜5点に絞って示す方が、確認が早く、漏れも減ります。範囲外、受入れ基準、未決事項は、必ずこの中に入れます。
5. 指摘を反映し、版を上げる
指摘を反映したら、版番号を上げます。版の付け方は、たとえば「下書きは v0.1、v0.2…、承認された確定版を v1.0、確定後の変更は v1.1、v1.2…」のように決めておきます。ファイル名にも版番号を入れ、変更履歴の表に「版・日付・変更内容・変更理由・承認者」を残します。
6. 承認をもらって確定させる
最後に、承認者から「この版で確定」という返事をもらいます。承認の記録は、前の章で書いた「誰が・いつ・どの版を」の3点がそろう形で残します。確定した版は、関係者全員がいつでも見られる場所に置き、古い版と混ざらないようにします。
承認を依頼する前に確かめたい10の問い
下書きを発注者に渡す前に、受注者の側で次の10の問いに答えられるかを確かめます。答えられない問いがあれば、その項目がまだ合意の記録になっていないということです。
- この案件で何が良くなれば成功なのかを、1文で言えるか
- 今回作るものを、ページ名や機能名の一覧で数えられるか
- 話題に出たが今回は見送ったものが、範囲外に書いてあるか
- 原稿・写真・データ・サーバーなど、発注者が用意するものと期限が書いてあるか
- 動かせない日付（公開日、社内の発表日など）が書いてあるか
- 対応する端末とブラウザが書いてあるか
- 何を確認できたら完成とするかが、確認項目として数えられる形になっているか
- 決まっていないことに、決める人と期限が書いてあるか
- 確定後に変えたくなったとき、どう依頼し、誰が承認するかが書いてあるか
- 最終的に承認する人の名前と役職が書いてあるか
このうち、受注者の側だけで答えを決めてよいものはありません。答えが空いている問いは、そのまま次の打ち合わせの議題になります。課題や持ち帰り事項を一覧で管理する方法は、課題管理表のテンプレートでも扱っています。
要件定義の作業そのものを、計画に入れておく
要件定義は、「設計の前に少し話し合う時間」と見なされると、日程が足りなくなります。打ち合わせの回数、下書きを書く時間、発注者の点検期間、指摘を反映する時間を、作業の一覧に入れておきます。特に発注者の点検期間は、受注者の努力では短くできないため、日程表の上で発注者の作業として見えるようにしておくと、遅れたときに理由を説明しやすくなります。顧客側の作業を作業一覧に入れる方法は、WBSの作り方とテンプレートで扱っています。
確定した要件定義書を変えるとき
確定した後に要件が変わること自体は、珍しいことではありません。問題になるのは、変更が手続きを通らずに入り込み、費用や期間の見直しがされないまま作業だけが増えることです。
モデル契約の変更管理書に書く8項目
モデル契約（第二版）の第37条（変更管理手続）は、変更の提案を受け取った側が、一定の日数以内に「変更管理書」を相手方に渡し、協議の場で変更の可否を話し合うと定めています。変更管理書に書く事項は次の8つです。
- 変更の名称
- 提案の責任者
- 年月日
- 変更の理由
- 変更に関わる仕様を含む、変更の詳細事項
- 変更に費用がかかる場合は、その額
- 検討期間を含めた、変更作業のスケジュール
- その他、変更が契約の条件（作業期間や納期、委託料、契約条項など）に与える影響
協議の結果、変更してよいとなった場合は、双方の責任者が変更管理書の内容を承認して記名押印し、それをもって変更が確定します。契約の条件に影響する場合は、変更契約を結んだ時点で確定します（出典：IPA：情報システム・モデル取引・契約書（第二版）の「第二版 ひな型」第37条）。
小規模な案件で、ここまでの書式を毎回作る必要はありません。それでも、8項目のうち「変更の内容」「理由」「費用」「スケジュールへの影響」「承認した人」の5つは、メール1通でもよいので必ず残します。
「直し」と「追加」を分けて受け付ける
確定後に出てくる要望は、大きく2種類あります。
- 直し（不具合）：要件定義書に書いてあるとおりになっていない。受注者が直す
- 追加（変更）：要件定義書に書いていないことを、新しく求められている。変更の手続きに乗せる
この2つを区別できるかどうかは、要件定義書に範囲外と受入れ基準が書いてあるかで決まります。どちらにも書いていない要望は、直しなのか追加なのかの判断で揉めます。手戻りの種類と、仕様変更の費用の扱いは手戻りとはで詳しく扱っています。小さな追加が積み重なって範囲が広がっていく状態と、追加依頼を線引きするときの伝え方は、スコープクリープとはにまとめています。
変更履歴の書き方
変更が確定したら、要件定義書の版を上げ、変更履歴に記録します。
変更履歴
| 版 | 日付 | 変更内容 | 理由 | 費用・期間への影響 | 承認者 |
| v1.0 | 2026-05-15 | 初版確定 | - | - | 発注者 ○○部長 |
| v1.1 | 2026-06-02 | お知らせ一覧にカテゴリ絞り込みを追加 | 営業部からの要望 | 追加見積もり○○、公開日は変更なし | 発注者 ○○部長 |
変更履歴は、「なぜ今の形になっているか」を後から説明できる唯一の記録です。担当者が替わったとき、追加費用の根拠を示すとき、次の案件で同じ議論を繰り返さないために役立ちます。
要件定義書でよくある失敗と対策
要件定義書を作ったのに揉めた、という案件には、いくつか共通する形があります。
| よくある失敗 | 何が起きるか | 対策 |
|---|---|---|
| 範囲外が空欄 | 「当然入っていると思った」と言われ、無償の追加作業になる | 話題に出て見送ったもの、誤解されやすい作業、他社の担当を範囲外に書く |
| 受入れ基準が無い | 納品後、確認のたびに新しい指摘が出て、検収が終わらない | 確認の対象・方法・合格の条件を書き、確認項目の一覧にする |
| 未決事項を書かずに確定 | 後で決まった内容で範囲が広がっても、追加かどうか判断できない | 未決事項の一覧に、決める人・期限・影響を書く |
| 承認者が窓口の担当者だけ | 決裁者が後から見て、ひっくり返る | 承認者を最初に確認し、承認欄に名前と役職を書く |
| 版が複数の場所に分散 | メール添付・チャット・共有フォルダに別の版があり、どれが最新か分からない | 確定版を置く場所を1か所に決め、ファイル名と変更履歴に版番号を入れる |
| 要望の一覧のまま確定 | 実現するかどうかを決めていない要望まで約束したことになる | 要望を「実現する・範囲外・未決」に仕分けてから確定させる |
この中で、受託・制作の案件で特に起きやすいのが、最後から2つめの「版の分散」です。要件定義書そのものはよく書けていても、確定版がどれかを双方が同じように答えられない状態では、合意の記録として機能しません。
要件定義書を、顧客と同じ場所で最新に保つ
要件定義書の価値は、確定した瞬間よりも、その後の設計・制作・検収の間ずっと「今の正しい版」として参照され続けることにあります。そのためには、最新版と、それを決めた議事録、承認の記録、確定後の変更の履歴が、発注者と受注者の双方から同じ場所で見えていることが大切です。
ファイルをメールに添付して往復させる進め方では、どうしても版が分散します。決めたことと、その根拠になった資料、承認の記録を1か所にまとめておくと、担当者が替わっても、「なぜこの仕様になっているか」をすぐに説明できます。顧客と同じものを見ながら仕事を進める考え方は、クライアントワークとはで整理しています。
よくある質問（FAQ）
要件定義書とは何ですか？
これから作るシステムやWebサイトで何を実現するかを、発注者と受注者が合意した内容としてまとめた文書です。業務の流れ、機能、性能やセキュリティなどの条件を書き、双方が確認して確定させます。確定した内容が、その後の設計・開発・検収の基準になります。
要件定義書は誰が作るものですか？
内容に責任を持つのは、作ったものを使う発注者です。IPAは、ITベンダーに支援してもらう場合でも、要件定義の成果物に対する責任はユーザー企業にあると説明しています。受注者が下書きを書く進め方もありますが、その場合も決める人と承認者は発注者側です。
要件定義書と要求仕様書の違いは何ですか？
要求仕様書は、発注者が望むこと（要求）をまとめた、まだ合意していない段階の文書を指すことが多い言葉です。要件定義書は、その要求のうち実現すると決めて、双方で合意したものをまとめた文書です。会社によって使い分けが違うため、案件の最初に定義をそろえておくと混乱しません。
要件定義書とRFPの違いは何ですか？
RFPは、発注者が依頼先を選ぶ前に、候補の会社に提案を依頼するための文書で、まだ受注者と何も合意していません。要件定義書は、依頼先が決まった後に、作るものの詳細を双方で決めて合意する文書です。RFPの要望が、要件定義で具体的な要件に絞り込まれます。
要件定義書のテンプレートや決まった書式はありますか？
公式に決まった書式はありません。この記事では、小規模Web制作向けと中規模の業務システム向けの2つのひな形を載せています。どの書式でも、範囲外、受入れ基準、未決事項、変更の扱い、承認の記録の5つは空欄にしないことをおすすめします。
小規模なWeb制作でも要件定義書は必要ですか？
「要件定義書」という名前の文書でなくてもかまいませんが、何を作り何を作らないか、何をもって完成とするか、双方が確認した記録の3つは必要です。数ページのサイトなら、A4数枚の文書とメールでの承認で十分です。
確定した要件定義書を変更したいと言われたらどうすればよいですか？
変更の内容、理由、費用、スケジュールへの影響をまとめて示し、承認をもらってから作業します。IPAのモデル契約では、変更管理書を交わして協議し、双方の責任者が承認して変更が確定する仕組みになっています。確定後は要件定義書の版を上げ、変更履歴に残します。
まとめ
- 要件定義書は、作るものについての合意の記録：要望を文書にし、関係者と合意したものが「要件」になります（IPA）
- 責任を持つのは発注者、受注者は支援する：受注者が下書きを書く場合も、決める人と承認者は発注者側です
- 確定は「誰が・いつ・どの版を」で残す：モデル契約では、点検期間内に双方が点検し、責任者が記名押印して確定します
- 「何を作るか」に加えて「どこまでで合意か」を書く：範囲外、受入れ基準、未決事項、変更の扱い、承認の記録を空欄にしません
- 確定後の変更は手続きを通す：内容・理由・費用・スケジュール・承認者を残し、版を上げて変更履歴に記録します
進行中の案件があれば、まず要件定義書の「範囲外」と「受入れ基準」の欄が埋まっているかを確認してみてください。
本記事の情報について: 要件定義の考え方はIPAのDX SQUAREと「ユーザのための要件定義ガイド 第2版」の公開ページ、要件定義書の定義・確定・変更管理の手続きはIPAが公開する「情報システム・モデル取引・契約書（第二版）」のひな型、非機能要求の項目数はIPAの「非機能要求グレード2018」の改訂情報で、2026年10月14日に確認しています。テンプレートと記入例は Terasu 編集部が作成したひな形で、実在の企業や案件のものではありません。個別の契約への当てはめは、法務担当者や弁護士に確認してください。
