要件定義書を初めて書くことになった担当者や、開発会社から受け取った要件定義書をレビューする立場になった方に向けて、本記事では要件定義書の記載項目、そのまま使える章立てサンプル、項目ごとの書き方のコツ、レビュー時の点検観点までを、実際に手を動かす順番で解説します。
あわせて、公開されている一次資料のどれをどの章の下敷きにできるかも示しました。機能一覧や業務フロー図をテキストで管理して差分レビューできる形にする書き方は、コピーしてそのまま自分の文書に貼れる状態で載せています。各資料の所在と更新時点は2026年9月時点で公開ページを確認しました。
まとめ：要件定義書は「章立ての型」に沿って書けば、初めてでも抜け漏れを大きく減らせる
要件定義書とは、システムで実現する内容（機能・性能・制約）を発注側と開発側が合意するための文書です。書き方の要点は次の通りです。
- 要件定義書の骨格は「背景・目的」「業務要件」「機能要件」「非機能要件」「その他制約」の5ブロックで構成するのが基本形
- いきなり機能一覧から書き始めず、背景・目的から書くことで、後続のすべての記述に判断基準が生まれる
- 機能要件は「一覧＋概要」の粒度で書き、詳細な画面仕様は設計工程に委ねると、工程の役割分担が崩れない
- 非機能要件（性能・可用性・セキュリティ・運用）は漏れの常習地帯であり、観点リストで機械的に点検する
- 「やらないこと（対象外事項）」を明記した要件定義書は、範囲の膨張と認識ずれを防ぐ力が強い
- 白紙から起こす必要はなく、デジタル庁の標準ガイドライン群には要件定義書の標準テンプレートが同梱されている
- 機能一覧・フロー図・非機能要件の点検表をテキスト形式で持つと、版が変わったときの差分レビューが一気に楽になる
要件定義書の役割と読者を押さえてから、書き始める前に決めておくこと
合意形成の道具と後工程へのインプットという二つの役割を分けて考える
要件定義書には二つの役割があります。一つは合意形成の道具としての役割で、発注側の責任者が内容を承認することで開発範囲が確定するという性質のものです。もう一つは後工程へのインプットとしての役割で、設計者はこの文書を判断基準として基本設計を進めます。読者が「業務側の責任者」と「開発側の技術者」の両方にまたがる点が、要件定義書の書き方を難しくしている要因です。業務側が読めない専門用語の羅列も、技術者が判断に使えない曖昧な表現も、どちらも役割を果たせません。
この二役をひとつの文章で兼ねようとすると、どちらつかずの記述になります。実務では「本文（業務側が読む説明）」と「別紙（設計者が使う一覧表）」に分け、本文から別紙を参照する構成にすると両立します。工程全体の中での位置づけを先に確認しておきたい場合は要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを、要件定義書が確定させる範囲と設計書・仕様書が担う範囲の線引きは仕様書とは？設計書・要件定義書との違いを先に読んでおくのが近道です。
誰が書くのかを決めて、発注側と開発側の作業分担を先に確定させる
受託開発では開発会社側が執筆を主導し、発注側がインプット提供とレビューを担う分担が一般的です。ただし執筆の主体がどちらであっても、業務要件の正しさに責任を持てるのは発注側だけです。「書いてもらう文書」ではなく「共同で作り、自社が承認する文書」と捉えることが、書き方以前の前提になります。
分担を曖昧にしたまま着手すると、発注側が出すべき「やりたいこと（要求）」と、開発側がまとめる「作るもの（要件）」の境目が溶けます。この境目の引き方は要求定義と要件定義の違いとは？責任範囲・成果物・契約の分界点で整理しています。契約面の分界点についても、IPAと経済産業省が公開する情報システム・モデル取引・契約書（第二版）（2020年12月22日公開）が、企画・要件定義・開発・運用・保守の各プロセスごとに契約類型の考え方を示しており、社内稟議の根拠として引きやすい資料です。RFPを先に出す進め方を取るなら、RFPと要件定義の違いとは？書き分ける範囲と発注者の作業分担もあわせて確認してください。
記載項目の全体像を一覧にして、削る前提で自社向けに調整する手順
要件定義書に盛り込む標準的な項目は次の通りです。プロジェクトの規模によって増減はあるものの、この一覧から「意図的に削る」形で調整すると抜け漏れを防げます。
- 背景・目的：現状の課題、システム化の目的、達成したい状態
- 対象範囲と対象外事項：対象業務・対象部門と、今回は扱わない範囲の明記
- 業務要件：現行業務フロー（As-Is）と導入後の業務フロー（To-Be）
- 機能要件：機能一覧、画面一覧、帳票一覧、外部システム連携の一覧
- データ要件：主要なデータ項目、データ量の見込み、既存データの移行方針
- 非機能要件：性能、可用性、セキュリティ、運用・保守の条件
- 制約条件：予算、納期、利用技術や既存環境の制約
- 体制・スケジュール：推進体制、マイルストーン、承認プロセス
このうち業務要件だけは、書く量も関係者も突出して多くなります。業務要件をどこまで書けば機能要件へ渡せるのかという段取りは業務要件定義とは？8つの記載項目と機能要件との階層で扱っているので、業務側の巻き込みが必要な案件では先に目を通しておくと手戻りが減ります。
そのまま使える章立てサンプルを写して、自社の要件定義書の目次にする
9章構成の章立てサンプルと、各章に何を置くかの対応を確認する
上記の項目を文書に落とし込む際の章立てサンプルです。この順序には意味があり、読み手が「なぜ作るのか、何の業務のためか、何を作るのか、どんな品質で作るのか」という順に自然に理解できる流れになっています。
- 1章 はじめに（背景・目的・本書の位置づけ）
- 2章 プロジェクト概要（対象範囲・対象外事項・前提条件）
- 3章 業務要件（現行業務フロー・新業務フロー・業務上の課題と解決方針）
- 4章 機能要件（機能一覧・画面一覧・帳票一覧・外部連携一覧）
- 5章 データ要件（主要データ項目・データ移行方針）
- 6章 非機能要件（性能・可用性・セキュリティ・運用保守）
- 7章 制約条件（技術・予算・納期）
- 8章 体制とスケジュール（役割分担・マイルストーン）
- 9章 用語集
9章の用語集は省かれがちですが、業務側と開発側で同じ単語を別の意味で使っている状態は要件のずれを直接生みます。「受注」「案件」「顧客」のような、社内で自明だと思われている語ほど定義を書き残す価値があります。
デジタル庁とIPAの公開テンプレートを下敷きにして白紙から書かない
章立てをゼロから起こす必要はありません。デジタル庁が公開するデジタル社会推進標準ガイドラインは、政府情報システムの整備手順をDS-100番台の文書群として体系化しており、DS-120「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」のテンプレート一式（ZIP、2026年7月15日更新）には「第5章 要件定義書標準テンプレート」が含まれています。民間案件でも章立ての骨格として参照でき、公共案件に近い体裁が求められる場面ではそのまま土台にできます。
民間向けの下敷きとしては、IPAのシステム構築の上流工程強化に関する成果物一式が使えます。要件定義・システム再構築・非機能要求グレードの各成果物がまとまっており、2023年8月時点でアーカイブ扱いとして公開が続いている資料群です。テンプレートは「削る前提」で使うものなので、下敷きにした資料名と、自社案件で削った章の理由を1章の「本書の位置づけ」に書き残しておくと、後任者が判断を追跡できます。
機能要件を一覧表に落として、粒度と優先度を全機能でそろえる作業
機能一覧の列構成と、概要欄に書き込む粒度の線引きを最初に決める
機能要件は「機能ID・機能名・概要・優先度」を持つ一覧表で管理するのが定石です。概要は「受注情報を登録・修正・削除できる」程度の粒度にとどめ、入力チェックの詳細やボタン配置まで書き込まないのがコツです。詳細を書きすぎると設計工程の裁量を奪い、変更のたびに要件定義書の改訂が発生して文書が形骸化します。優先度は「必須／あれば良い」の二段階でも構わないので必ず付けてください。予算超過時にどこから削るかの判断が、この欄の有無で大きく変わります。
機能要件・非機能要件・業務要件が階層としてどう積み上がるかを整理しておくと、一覧のどの行に何を書くかで迷わなくなります。三者の関係は機能要件とは？非機能要件・業務要件との違いと定義する5つの事項で解説しました。振る舞いの合意をどこまで詰めるかについては、IPAの機能要件の合意形成ガイド（2010年3月公開、概要編に加えて画面・システム振舞い・データモデル・帳票・バッチ・外部インターフェースの6分冊）が、合意の成熟度を「仕掛レベル」「充実レベル」「完成レベル」の3段階に分けて示しています。自分たちの一覧がどのレベルで止まっているかを測る物差しとして機能します。
機能一覧をテキストで管理して、版ごとの差分をレビューできる形にする
機能一覧をExcelだけで持つと、版が上がったときに「どこが変わったか」を人が目で追う作業が発生します。一覧をテキスト形式でも持ち、バージョン管理ツールに置いておくと、差分が機械的に出せます。次はそのまま貼って使える機能一覧の記述例です。
- id: FN-010
name: 受注登録
summary: 受注情報を登録・修正・削除できる
actor: 営業担当
priority: 必須
screen: SC-010
note: 入力チェックの詳細は基本設計で確定する
- id: FN-020
name: 在庫引当
summary: 受注明細に対して在庫を引き当てる
actor: 業務担当
priority: 必須
screen: SC-020
note: 引当ロジックの詳細は基本設計で確定する
- id: FN-110
name: 受注実績のCSV出力
summary: 期間を指定して受注実績を出力する
actor: 営業担当
priority: あれば良い
screen: SC-110
note: 予算超過時の削減候補この形にしておくと、レビュー会の前に「前回から3行増えて1行が必須からあれば良いへ落ちた」という事実を全員が同じ画面で確認できます。承認済みの版にタグを打っておけば、いつの合意内容かを後から特定する作業も一瞬で終わるはずです。画面一覧・帳票一覧・外部連携一覧も同じ書式で並べておくと、機能IDと画面IDの対応漏れが目視で拾えます。
業務フロー図と構成図をテキストで書いて、As-IsとTo-Beの変化点を見せる
スイムレーンでAs-IsとTo-Beを同じ粒度に並べて差分を可視化する
業務フロー図は、部門をスイムレーンで分け、現行（As-Is）と導入後（To-Be）を同じ粒度で並べると変化点が一目で伝わります。システム全体の構成を示す図もこの文書の定番要素ですが、構成図やアーキテクチャ図の描き方には唯一の正解がなく、読者と目的に応じて詳細度を調整する判断が必要です。この論点はアーキテクチャ図に「正解」がない理由と背景が参考になります。全体構造の選択肢を踏まえて図の粒度を決めたい場合は、システムアーキテクチャの種類と選び方もあわせて確認してください。
書き方の面では、フロー図の中に「システムが担う処理」と「人が担う作業」を色や形で区別して示すと、システム化の範囲が視覚的に確定します。導入後フローで人の作業として残る部分こそ、運用設計やマニュアル整備の対象になるため、あえて明示しておく価値が大きい部分です。要件定義から設計にかけて必要になる図の種類そのものは要件定義と設計で作る7つの図｜画面遷移図・ER図とデザイナーの担当範囲に一覧があり、利用者と機能の関係を示すユースケース図の書き方はユースケース図とは？UMLの書き方・アクターと関係で扱っています。
作図ツールに依存せずテキストからフロー図を生成する書き方に変える
図を作図ツールの独自ファイルで持つと、編集できる人が限られ、差分も追えません。フロー図をテキストで記述しておけば、機能一覧と同じようにバージョン管理下に置けます。Mermaidの記法は公式のflowchart構文ドキュメントにまとまっており、GitHubやNotionなど主要な文書ツールがそのまま描画に対応しています。次は現行業務のスイムレーン記述例です。
flowchart LR
subgraph 営業部
A1[受注連絡を電話で受ける] --> A2[受注票をExcelに手入力]
end
subgraph 業務部
A2 --> B1[在庫を倉庫へ電話で確認]
B1 --> B2[受注確定をメールで返信]
B2 --> B3[受注一覧を日次で集計]
end同じ書式でTo-Be側も書き、変わった工程だけ色を変えると、業務側の責任者が「自分の部門の作業がどう減るのか」を一読で把握できます。稟議の場で最初に問われるのはこの差分なので、要件定義書の中では業務要件の章の先頭に置くと説明が通りやすくなります。図が読めない状態で機能一覧だけを見せると、必要性の議論が空転しがちです。
非機能要件はIPAの観点リストに当てて、対象外の判断まで書き残す
6つの大項目をそのまま観点リストにして「要件なし」も記録に残す
非機能要件は「思いついたものを書く」方式では必ず漏れます。性能（応答時間・同時利用者数）、可用性（稼働時間帯・障害時の復旧目標）、セキュリティ（認証・アクセス権限・ログ）、運用（バックアップ・監視・問い合わせ窓口）といった観点リストを先に用意し、各観点について「要件あり／なし」を明示的に判断する書き方に変えてください。IPAの非機能要求グレードを観点リストとして流用する方法も実務でよく採られます。「なし」と判断した観点も削除せず「対象外」と書き残すことで、検討済みであることが後から証明できます。
非機能要求グレードは、非機能要求を可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーの6つの大項目に分けて階層化した資料です。すべての項目を一度に均一に評価するのは現実的でないという前提に立ち、重要項目から段階的に確認していく手順が設計されています。最新版は2018年版で、日本語・英語・中国語の本体に加え、利用シーン別の利用ガイド第2版が公開されています。資料の成り立ちと使いどころは非機能要求グレードとは？IPAが提唱するフレームワークの概要で詳しく扱いました。
| 大項目 | 要件定義書で決める代表例 |
|---|---|
| 可用性 | 稼働時間帯と目標復旧時間 |
| 性能拡張性 | 同時利用者数と応答時間 |
| 運用保守性 | バックアップと監視の範囲 |
| 移行性 | 移行対象データと移行方式 |
| セキュリティ | 認証方式と権限・ログ要件 |
| システム環境エコロジー | 設置環境と省電力の制約 |
点検結果を表形式で持ち、要求値の根拠まで一行で追えるようにする
観点ごとの判断は、要求値だけでなく「なぜその値なのか」の根拠を同じ行に置くと、レビューでの押し問答が減ります。次の書式で持てば、開発会社から提示された値を発注側が検算する作業も進めやすくなります。
大項目,中項目,要求値,判断,根拠
可用性,運用スケジュール,平日8時から20時,要件あり,現行の受付時間に合わせる
可用性,目標復旧時間,4時間以内,要件あり,当日出荷業務が止まる上限
性能拡張性,同時利用者数,80人,要件あり,営業部と業務部の在籍数
性能拡張性,応答時間,検索3秒以内,要件あり,現行Excel運用と同等以上
セキュリティ,認証方式,社内IdPのSSO,要件あり,情報システム部の全社標準
移行性,移行データ量,受注3年分,要件あり,監査で必要な保存期間
システム環境エコロジー,環境影響評価,設定なし,対象外,自社データセンターを持たない「対象外」の行を残す意味は、後任者への引き継ぎにあります。空欄と対象外は見た目が似ていても意味が正反対で、空欄は検討していない状態、対象外は検討したうえで不要と判断した状態です。この区別が書面に残っていれば、稼働後に問題が起きたときも、判断の誤りなのか検討漏れなのかを切り分けられます。
データ要件と移行方針を先に書いて、後工程で起きる手戻りを止める
データ要件は、機能一覧ほど注目されないわりに、抜けたときの影響が最も大きい章です。既存システムから引き継ぐデータの量、品質（表記ゆれ・重複・欠損）、移行の基準日、移行しないデータの扱いを、要件定義の段階で文章にしておきます。ここが空白のまま設計へ進むと、移行作業の直前に「旧システムの取引先マスタに同一企業が3件登録されていた」といった事実が判明し、名寄せの工数がまるごと追加になります。
書き方としては、主要なデータ項目（エンティティ）ごとに「件数の見込み」「発生・更新の頻度」「保存期間」「移行の要否」を並べた表を1枚用意すると、設計者がデータベース構成を検討する材料としてそのまま使えます。あわせて、旧システムのどの時点のデータを正とするか（移行基準日）と、移行後に旧システムを参照専用で残す期間を決めておいてください。この2点が決まっていない移行案件は、切り替え当日の判断が属人化します。
要件定義書に書いたデータ要件が、その後どう基本設計へ渡っていくのかは基本設計とは？システム開発での位置づけと成果物、要件定義・詳細設計との違いで確認できます。工程全体のどこに要件定義が挟まるかを俯瞰したい場合はシステム開発の流れとは？工程の全体像と各フェーズのポイントを参照してください。
レビューで落ちるNGパターンを型で見つけて承認前に書き直す観点
測れない形容詞・対象外なし・例外系なしという三つの型を先に探す
レビューで頻出する問題には型があります。第一に、「柔軟に」「使いやすく」「迅速に」といった測定できない形容詞が要件として書かれているパターンで、これらは数値または具体的な動作に置き換える必要があります。第二に、対象外事項が書かれておらず、範囲の境界が読み手の解釈に委ねられているパターン。第三に、正常系の記述だけで例外時の扱い（入力ミス、連携先の停止、月次処理の失敗など）に触れていないパターンです。レビュー時はこの三つを重点的に探すと効率が上がります。
三つ目の例外系は、機能一覧に「異常時の動作」列を1本足すだけで拾える範囲が広がります。「連携先が応答しないとき、画面にどう出して、誰に通知して、再送はどうするか」を1行で書ければ十分で、詳細な設計は後工程に渡せます。この列が空欄の機能が多い文書は、まだ充実レベルに達していないと判断してください。
承認前のチェックリストと変更管理の運用ルールを合わせて決める
承認の前に、次の問いで完成度を判断してください。目的から読んだとき、各機能が「何のためにあるか」を説明できるか。対象外事項は明記されているか。すべての機能に優先度が付いているか。非機能要件は観点リストに対して網羅的に判断されているか。業務側の責任者が読んで理解できる言葉で書かれているか。この5問に「はい」と答えられれば、設計工程に引き渡せる水準に達していると判断できます。レビューは一度で終えず、章単位の中間レビューと全体の最終レビューの二段階に分けると、指摘の手戻りが小さくなり、承認会議での差し戻しも起きにくくなります。
承認と同時に決めておきたいのが変更管理のルールです。承認済みの版をどういう手続きで改訂するか（誰が起票し、誰が影響を判断し、誰が再承認するか）を要件定義書の1章に書いておくと、稼働までの間に必ず発生する仕様変更を制度として処理できます。ルールがないまま個別のメールで変更が積み上がると、最終的にどれが合意内容なのか誰にも分からなくなります。
要件定義書を自社だけで書き切れないときの依頼先の見極め方と順序
要件定義書の執筆経験が社内にない場合、たたき台の作成から開発会社に伴走を依頼する方法が現実的です。依頼時は、過去の要件定義書のサンプル（守秘の範囲で構成だけでも）を見せてもらうと、その会社の文書品質を事前に判断できます。見るべきは分量ではなく、対象外事項が書かれているか、非機能要件が観点リストで点検されているか、機能に優先度が付いているかの三点です。複数社を比べる段取りを取るなら、RFI・RFP・RFQの違いとは？意味・使い分けと発行の流れとRFPの書き方とは？記載項目・章立てサンプルと作成手順が、先に出す文書の順番を決める助けになります。
たたき台の生成に生成AIを使う選択肢も出てきました。要件定義に特化したツールの機能と料金はGEAR.indigoとは？AI駆動要件定義ツールの機能・料金・使い方で整理しています。ただし現時点では、業務の暗黙ルールや部門間の力関係といった、文書に書かれていない前提を機械が拾うのは困難です。生成物は章立てと初稿の下書きまでと考え、対象外事項の判断と優先度付けは人が引き取ってください。当社（株式会社一創）も要件定義・RFP作成・PMO支援で要件定義からの支援に対応しており、要件定義書の作成を含む上流工程からの参画が可能です。
要件定義書の書き方についてよくある質問と、実務での答え方の目安
要件定義書のボリュームはどれくらいが適切ですか？
規模によって数十ページから数百ページまで幅があり、ページ数そのものに正解はありません。判断基準は量ではなく、「設計者が判断に迷わないか」「業務側の責任者が読み切れるか」の両立です。読み切れない分量になる場合は、本編と別紙（一覧表類）に分冊する構成が有効です。
ExcelとWordのどちらで書くべきですか？
本文の説明はWordや文書ツール、機能一覧・画面一覧などの表はExcelやスプレッドシート、と使い分ける形が実務では多数派です。ツールより重要なのは版管理で、どれが最新版かを一意に特定できる運用（版番号・更新履歴・保管場所の一元化）を最初に決めておくことを推奨します。一覧や図をテキスト形式でも持てば、差分の確認まで機械に任せられます。
テンプレートをそのまま使っても問題ありませんか？
出発点としては有効です。ただしテンプレートは汎用的に作られているため、自社のプロジェクトに関係ない章を惰性で埋めると、読み手の集中力を奪う文書になります。本記事の章立てサンプルを含め、テンプレートは「削る前提」で使い、削った理由を記録しておく運用が健全です。
要件定義書のサンプルやテンプレートはどこで手に入りますか？
公的機関の公開資料が手堅い出発点です。デジタル庁の標準ガイドライン群には要件定義書の標準テンプレートが同梱され、IPAは非機能要求グレードと機能要件の合意形成ガイドを公開しています。いずれも本記事のリンクからそのまま辿れるはずです。市販テンプレートを使う場合も、非機能要件の観点リストだけは公的資料側に合わせるやり方をおすすめします。
要件定義書と提案書・見積書の関係はどうなりますか？
提案書・見積書は契約前の想定に基づく文書であり、要件定義書は工程を経て確定した内容を記す文書です。要件定義の結果、提案時の想定と範囲が変わることは珍しくなく、その場合は見積もりの再提示を受けるのが正常な流れです。差分がどこにあるかを明示してもらうよう依頼してください。逆に、要件定義を終えても見積もりが一切変わらない場合は、提案時の粒度が粗すぎた可能性も含めて内訳を確認する余地があります。
作成後に要件が変わったら要件定義書は書き直しますか？
承認済みの要件定義書は勝手に上書きせず、変更管理のルールに沿って改訂します。変更内容・理由・影響（費用・納期）・承認者を変更履歴として残し、版番号を上げて再承認を得る流れが標準です。この運用があるだけで、「いつの間にか仕様が変わっていた」という事故を防げます。
アジャイル開発でも要件定義書は必要ですか？
作る対象を一度で確定させる書き方は取りませんが、目的・対象範囲・対象外事項・非機能要件は先に文書化しておくのが実務的です。反復のたびに変わるのは機能の詳細であって、システム全体の目的や守るべき性能・セキュリティの水準ではありません。契約面でも、成果物の完成に対して対価を払う請負ではなく、業務の遂行に対して払う準委任を前提とする整理があり、IPAのモデル契約書にアジャイル開発版が用意されています。
