要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説

要件定義書を初めて書くことになった担当者や、開発会社から受け取った要件定義書をレビューする立場になった方に向けて、本記事では要件定義書の記載項目、そのまま使える章立てサンプル、項目ごとの書き方のコツ、レビュー時の点検観点までを解説します。

まとめ：要件定義書は「章立ての型」に沿って書けば、初めてでも抜け漏れを大きく減らせる

要件定義書とは、システムで実現する内容（機能・性能・制約）を発注側と開発側が合意するための文書です。書き方の要点は次の通りです。

• 要件定義書の骨格は「背景・目的」「業務要件」「機能要件」「非機能要件」「その他制約」の5ブロックで構成するのが基本形
• いきなり機能一覧から書き始めず、背景・目的から書くことで、後続のすべての記述に判断基準が生まれる
• 機能要件は「一覧＋概要」の粒度で書き、詳細な画面仕様は設計工程に委ねると、工程の役割分担が崩れない
• 非機能要件（性能・可用性・セキュリティ・運用）は漏れの常習地帯であり、観点リストで機械的に点検する
• 「やらないこと（対象外事項）」を明記した要件定義書は、範囲の膨張と認識ずれを防ぐ力が強い

要件定義書の基本を理解する

要件定義書の役割と読者

要件定義書には二つの役割があります。一つは合意形成の道具としての役割で、発注側の責任者が内容を承認することで開発範囲が確定するという性質のものです。もう一つは後工程へのインプットとしての役割で、設計者はこの文書を判断基準として基本設計を進めます。読者が「業務側の責任者」と「開発側の技術者」の両方にまたがる点が、要件定義書の書き方を難しくしている要因です。業務側が読めない専門用語の羅列も、技術者が判断に使えない曖昧な表現も、どちらも役割を果たせません。

誰が書くのか

受託開発では開発会社側が執筆を主導し、発注側がインプット提供とレビューを担う分担が一般的です。ただし執筆の主体がどちらであっても、業務要件の正しさに責任を持てるのは発注側だけです。「書いてもらう文書」ではなく「共同で作り、自社が承認する文書」と捉えることが、書き方以前の前提になります。

記載項目の全体像

要件定義書に盛り込む標準的な項目は次の通りです。プロジェクトの規模によって増減はあるものの、この一覧から「意図的に削る」形で調整すると抜け漏れを防げます。

• 背景・目的：現状の課題、システム化の目的、達成したい状態
• 対象範囲と対象外事項：対象業務・対象部門と、今回は扱わない範囲の明記
• 業務要件：現行業務フロー（As-Is）と導入後の業務フロー（To-Be）
• 機能要件：機能一覧、画面一覧、帳票一覧、外部システム連携の一覧
• データ要件：主要なデータ項目、データ量の見込み、既存データの移行方針
• 非機能要件：性能、可用性、セキュリティ、運用・保守の条件
• 制約条件：予算、納期、利用技術や既存環境の制約
• 体制・スケジュール：推進体制、マイルストーン、承認プロセス

章立てサンプルと項目別の書き方を検討する

そのまま使える章立てサンプル

上記の項目を文書に落とし込む際の章立てサンプルです。この順序には意味があり、読み手が「なぜ作るのか、何の業務のためか、何を作るのか、どんな品質で作るのか」という順に自然に理解できる流れになっています。

• 1章 はじめに（背景・目的・本書の位置づけ）
• 2章 プロジェクト概要（対象範囲・対象外事項・前提条件）
• 3章 業務要件（現行業務フロー・新業務フロー・業務上の課題と解決方針）
• 4章 機能要件（機能一覧・画面一覧・帳票一覧・外部連携一覧）
• 5章 データ要件（主要データ項目・データ移行方針）
• 6章 非機能要件（性能・可用性・セキュリティ・運用保守）
• 7章 制約条件（技術・予算・納期）
• 8章 体制とスケジュール（役割分担・マイルストーン）
• 9章 用語集

機能要件の書き方：一覧＋概要の粒度を守る

機能要件は「機能ID・機能名・概要・優先度」を持つ一覧表で管理するのが定石です。概要は「受注情報を登録・修正・削除できる」程度の粒度にとどめ、入力チェックの詳細やボタン配置まで書き込まないのがコツです。詳細を書きすぎると設計工程の裁量を奪い、変更のたびに要件定義書の改訂が発生して文書が形骸化します。優先度は「必須／あれば良い」の二段階でも構わないので必ず付けてください。予算超過時にどこから削るかの判断が、この欄の有無で大きく変わります。

業務フローと構成図の書き方

業務フロー図は、部門をスイムレーンで分け、現行（As-Is）と導入後（To-Be）を同じ粒度で並べると変化点が一目で伝わります。システム全体の構成を示す図もこの文書の定番要素ですが、構成図やアーキテクチャ図の描き方には唯一の正解がなく、読者と目的に応じて詳細度を調整する判断が必要です。この論点はアーキテクチャ図に「正解」がない理由と背景が参考になります。全体構造の選択肢を踏まえて図の粒度を決めたい場合は、システムアーキテクチャの種類と選び方もあわせて確認してください。

書き方の面では、フロー図の中に「システムが担う処理」と「人が担う作業」を色や形で区別して示すと、システム化の範囲が視覚的に確定します。導入後フローで人の作業として残る部分こそ、運用設計やマニュアル整備の対象になるため、あえて明示しておく価値があります。

非機能要件の書き方：観点リストで機械的に点検する

非機能要件は「思いついたものを書く」方式では必ず漏れます。性能（応答時間・同時利用者数）、可用性（稼働時間帯・障害時の復旧目標）、セキュリティ（認証・アクセス権限・ログ）、運用（バックアップ・監視・問い合わせ窓口）といった観点リストを先に用意し、各観点について「要件あり／なし」を明示的に判断する書き方に変えてください。IPAの非機能要求グレードを観点リストとして流用する方法も実務でよく採られます。「なし」と判断した観点も削除せず「対象外」と書き残すことで、検討済みであることが後から証明できます。

完成度を判断するレビュー観点

よくあるNGパターン

レビューで頻出する問題には型があります。第一に、「柔軟に」「使いやすく」「迅速に」といった測定できない形容詞が要件として書かれているパターンで、これらは数値または具体的な動作に置き換える必要があります。第二に、対象外事項が書かれておらず、範囲の境界が読み手の解釈に委ねられているパターン。第三に、正常系の記述だけで例外時の扱い（入力ミス、連携先の停止、月次処理の失敗など）に触れていないパターンです。レビュー時はこの三つを重点的に探すと効率が上がります。

承認前のチェックリスト

承認の前に、次の問いで完成度を判断してください。目的から読んだとき、各機能が「何のためにあるか」を説明できるか。対象外事項は明記されているか。すべての機能に優先度が付いているか。非機能要件は観点リストに対して網羅的に判断されているか。業務側の責任者が読んで理解できる言葉で書かれているか。この5問に「はい」と答えられれば、設計工程に引き渡せる水準に達していると判断できます。レビューは一度で終えず、章単位の中間レビューと全体の最終レビューの二段階に分けると、指摘の手戻りが小さくなり、承認会議での差し戻しも起きにくくなります。

自社だけで書き切れない場合

要件定義書の執筆経験が社内にない場合、たたき台の作成から開発会社に伴走を依頼する方法が現実的です。依頼時は、過去の要件定義書のサンプル（守秘の範囲で構成だけでも）を見せてもらうと、その会社の文書品質を事前に判断できます。当社（株式会社一創）も業務システム開発で要件定義からの支援に対応しており、要件定義書の作成を含む上流工程からの参画が可能です。

要件定義書の書き方に関するよくある質問（FAQ）

要件定義書のボリュームはどれくらいが適切ですか？

規模によって数十ページから数百ページまで幅があり、ページ数そのものに正解はありません。判断基準は量ではなく、「設計者が判断に迷わないか」「業務側の責任者が読み切れるか」の両立です。読み切れない分量になる場合は、本編と別紙（一覧表類）に分冊する構成が有効です。

ExcelとWordのどちらで書くべきですか？

本文の説明はWordや文書ツール、機能一覧・画面一覧などの表はExcelやスプレッドシート、と使い分ける形が実務では多数派です。ツールより重要なのは版管理で、どれが最新版かを一意に特定できる運用（版番号・更新履歴・保管場所の一元化）を最初に決めておくことを推奨します。

テンプレートをそのまま使っても問題ありませんか？

出発点としては有効です。ただしテンプレートは汎用的に作られているため、自社のプロジェクトに関係ない章を惰性で埋めると、読み手の集中力を奪う文書になります。本記事の章立てサンプルを含め、テンプレートは「削る前提」で使い、削った理由を記録しておく運用が健全です。

要件定義書と提案書・見積書の関係はどうなりますか？

提案書・見積書は契約前の想定に基づく文書であり、要件定義書は工程を経て確定した内容を記す文書です。要件定義の結果、提案時の想定と範囲が変わることは珍しくなく、その場合は見積もりの再提示を受けるのが正常な流れです。差分がどこにあるかを明示してもらうよう依頼してください。逆に、要件定義を終えても見積もりが一切変わらない場合は、提案時の粒度が粗すぎた可能性も含めて内訳を確認する余地があります。

作成後に要件が変わったら要件定義書は書き直しますか？

承認済みの要件定義書は勝手に上書きせず、変更管理のルールに沿って改訂します。変更内容・理由・影響（費用・納期）・承認者を変更履歴として残し、版番号を上げて再承認を得る流れが標準です。この運用があるだけで、「いつの間にか仕様が変わっていた」という事故を防げます。

関連記事

• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説
• システム開発とは？種類・工程・依頼方法までの全体像をわかりやすく解説
• システム開発の流れとは？工程の全体像と各フェーズのポイントをわかりやすく解説