要件定義書の書き方サンプル｜必須6項目とGood例/Bad例・アジャイル対応まで

「要件定義書をどう書けばいいか分からない」「サンプルを真似て書いたのに、結局後から手戻りが多発する」――このような悩みを抱えるPdM・SE・事業担当者は少なくありません。

本記事では、要件定義書の書き方を 必須6項目のサンプル構成・具体的な記載例（Good 例 / Bad 例の対比付き） で解説します。プロジェクト目的の定義から機能要件・非機能要件の数値化、ステークホルダーとの合意形成、アジャイル開発での進め方、スコープクリープ対策まで、現場ですぐ流用できる粒度に揃えました。

なお、「アジャイル開発における要件定義そのものの必要性・仕様書代替・進め方」についてはアジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップ【Scrum Guide 2020準拠】で詳しく解説しているため、本記事では 要件定義書そのものの章立て・項目・サンプル文の書き方 に絞って解説します。

独立行政法人情報処理推進機構（IPA）が公開する「ソフトウェア開発分析データ集」では、ソフトウェア開発の遅延・予算超過を生む主因として「要件定義工程の品質不足」が継続的に上位に挙げられています。さらに、IPA 社会基盤センター（SEC）が公開する 「非機能要求グレード」 （2018 年版）は、非機能要件を 6 大項目に整理した国内デファクト標準として広く使われています。本記事は、これら一次ソースに沿った形で、現場で再現できる書き方サンプルに落とし込みました。

まず押さえる：要件定義書とは何を書くドキュメントか

要件定義書とは、システム開発において「 何を実現するか（What） 」を明確に定め、発注者・開発チーム・経営層の三者で合意形成するためのドキュメントです。後工程の基本設計書が「どう実現するか（How）」を扱うのに対し、要件定義書は意図と範囲を確定させる役割を担います。

書き方を誤る典型的なパターンは次の 3 つです。

• 抽象度が高すぎる ：「使いやすい画面」「快適な動作」など、人によって解釈が割れる表現で止まっている
• 対象外要件が書かれていない ：何を「やらない」かが未定義のため、開発中に要望が無限に追加される
• 数値の単位・条件が抜けている ：「速い」「安全」のように、テストで合否判定できない記述

本記事の以降の章では、6 つの必須項目それぞれについて「Bad 例（よくある曖昧な書き方）」と「Good 例（手戻りが起きない書き方）」を対比しながら、具体的な記載サンプルを示します。

プロジェクト目的とスコープを最初に確定する

要件定義書を作成する最初のステップは、プロジェクトの目的（Why）とスコープ（範囲）を確定することです。システム開発の現場では、「何を作るか」と同じくらい「 何を作らないか（対象外要件） 」を明記することが重要になります。

対象外要件を初期段階で合意しておくことで、開発途中の仕様変更や追加要望による手戻りを防ぎ、コスト超過やスケジュールの遅延を回避できます。プロジェクトマネジメントの国際標準である PMBOK Guide 第7版 （PMI 発行）でも、「スコープのベースライン化と、変更に対する統制プロセスの確立」が成果実現の前提条件として位置づけられています。

また、システム開発の前段となる事業計画や企画の段階から、目的を明確にしておくことが要件定義の質を高めます。企画フェーズの進め方については、【実例あり】新規事業の企画書の作り方とプレゼン資料例｜決裁を通す立ち上げプロセス7ステップを参考にしてください。

目的・スコープの書き方サンプル（経費精算システムの場合）

観点	Bad 例（避けたい書き方）	Good 例（手戻りを防ぐ書き方）
目的	経費精算を効率化する	紙ベースの経費精算を Web 化し、経理部門の入力工数を 2026 年度末までに月間 50 時間以上削減する
対象範囲	経費精算機能全般	国内子会社 3 社・正社員 800 名の交通費／出張費／接待費の申請〜承認〜仕訳連携まで
対象外	（記載なし）	海外子会社、業務委託者の精算、法人カード明細の自動取り込みは本フェーズ対象外（次期検討）

要件定義書の必須6項目と章立てサンプル

開発現場ですぐに活用できる実践的な目次構成を示します。Excel・Word・Notion のいずれで作成する場合も、以下 6 項目を基本骨格として準拠することで、レビュー時の指摘漏れを大幅に減らせます。

すぐ流用できる要件定義書の目次構成（サンプル）

章	章タイトル	主な記載内容
1	はじめに	目的、背景、用語定義、版管理履歴
2	システム概要	全体像、ターゲットユーザー、システム化の範囲、対象外要件
3	業務要件	現状（As-Is）の業務フローと導入後（To-Be）の業務フロー、定量目標
4	機能要件	画面一覧、機能一覧、ユースケース、権限マトリクス
5	非機能要件	可用性、性能、運用保守、移行性、セキュリティ、システム環境（IPA SEC 非機能要求グレード 6 大項目に準拠）
6	プロジェクト管理・その他	スケジュール、体制図、運用保守要件、前提・制約条件

必須項目ごとの書き方サンプル（Good 例 / Bad 例の対比）

要件定義書の書き方のコツは、曖昧な表現を排除し、「 誰が読んでも一つの意味にしか受け取れない 」状態にすることです。以下に、主要項目の Good 例・Bad 例を対比で示します。

必須項目	Bad 例（あいまい）	Good 例（テストで合否判定できる粒度）
システム概要	経費精算を Web 化する	紙ベースの経費精算を Web システム化し、経理部門の月間入力工数を 50 時間削減する。利用想定ユーザーは 800 名／月間申請件数は 4,000 件を上限とする
業務フロー（As-Is / To-Be）	業務をシステム化する	As-Is：申請者（紙提出）→上長（押印）→経理（手入力、平均 7 営業日） To-Be：申請者（スマホ撮影）→上長（Web 承認）→経理（自動仕訳、3 営業日以内）
機能要件	領収書を読み取れること	ユーザーがスマートフォンのカメラで領収書を撮影し、OCR 機能によって金額・日付・取引先名が入力フォームに自動反映されること。読取精度は金額フィールドで 95% 以上
非機能要件（性能）	レスポンスが速いこと	申請一覧画面の初回表示は同時 100 ユーザーアクセス時で 2 秒以内とする（95 パーセンタイル基準）
非機能要件（可用性）	落ちないこと	AWS マルチ AZ 構成により月間稼働率 99.9% を保証する。SLA の詳細条項は別添
権限・運用	上長が承認できること	「申請者ロール」「一次承認者ロール」「経理ロール」の 3 つを定義。一次承認者は申請者の直属上長のみが承認可能とし、代理承認時はログに代理者 ID を記録する

業務要件をまとめる際は、ユーザーの「現状の業務（As-Is）」を深く理解し、「あるべき姿（To-Be）」に落とし込むためのヒアリングが不可欠です。要件の抜け漏れを防ぐために、標準的なヒアリングシートやテンプレートを事前に準備し、体系的に情報を収集することをおすすめします。

非機能要件の定義と数値化（IPA SEC 非機能要求グレード 6 項目）

目に見える機能だけでなく、パフォーマンスやセキュリティといった「非機能要件」を明確に定義することが、システム安定稼働の鍵となります。IPA SEC が公開する「 非機能要求グレード 」では、非機能要件を以下の 6 大項目に整理しています。要件定義書ではこの 6 項目を漏れなくカバーすることが推奨されます。

大項目	主な検討観点	記載サンプル（Good 例）
可用性	運用スケジュール、稼働率、目標復旧時間	月間稼働率 99.9%／RTO 4 時間／RPO 1 時間
性能・拡張性	応答時間、スループット、同時接続数	一覧画面表示 2 秒以内（同時 100 ユーザー、95 パーセンタイル基準）
運用・保守性	監視、バックアップ、定期メンテ枠	日次フルバックアップ・週次リストアテスト・月 1 回のメンテナンス停止枠（日曜 2:00〜4:00）
移行性	既存システムからの移行方式・並行稼働	旧システムから過去 3 年分のデータを移行、移行期間中は 1 か月の並行稼働
セキュリティ	認証、認可、ログ、脆弱性対応	多要素認証必須、操作ログ 1 年保管、年 1 回の脆弱性診断実施
システム環境・エコロジー	構成（クラウド/オンプレ）、制約事項	国内リージョンの AWS 上に構築、本番／検証／開発の 3 環境を分離

SaaS ビジネスにおいては、リリース後のユーザー増加を見据えた拡張性も事業成長を大きく左右します。SaaS の基本的な仕組みについてはSaaSとは？意味・読み方・サブスクとの違いをわかりやすく解説【2026年版】もご覧ください。また、特に「可用性」を契約で担保する SLA の書き方はSLAとは？SaaS契約で発注側が確認すべき7つのポイント【稼働率・ペナルティ計算付き】で詳細を解説しています。

非機能要件を定義する際は、「速く動くこと」といった抽象的な表現は避け、「画面遷移は 2 秒以内 とする」「月間稼働率は 99.9% を保証する」のように、 テストで合否を機械的に判定できる 粒度まで数値化することが不可欠です。

ステークホルダーとの合意形成

要件定義書は、開発者だけが読む技術文書ではありません。経営層、業務部門の担当者、開発チームの全員が完成イメージを共有し、同じゴールに向かって進むための羅針盤としての役割を持ちます。

多様なステークホルダー間の合意形成を円滑に進めるためには、顧客の漠然とした「要求（Requirement）」を、テスト可能な「要件（Specification）」に変換するプロセスが必要です。Why-How ツリーなどのフレームワークを活用し、要求の背景にある真の課題を掘り下げます。同時に、各部門の役割分担を明確にすることも欠かせません。部門間の連携や目標設定の整理については、カスタマーサクセスと営業の違いは？8つの観点とKPI早見表で役割を整理の考え方も参考になります。

IT の専門用語ばかりが並んだ文章では、業務担当者や経営層は内容を正確に把握できず、表面的な承認で終わってしまう危険性があります。 画面のレイアウト案（モックアップ）やプロトタイプ を要件定義書に添付し、システム導入後の業務がどのように変化するのかを具体的にイメージできる状態にすることが不可欠です。さらに、レビュー時には「この要件はどのテストケースで確認するか」までセットで合意しておくと、後の検収トラブルを大幅に減らせます。

アジャイル開発における要件定義書の書き方

近年主流となっているアジャイル開発では、ウォーターフォールモデルのように初期段階で全ての要件を固定するのではなく、柔軟に変更を受け入れるアプローチをとります。しかし、「アジャイルだから要件定義書は不要」というのは大きな誤解です。Scrum Guide 2020 でも、プロダクトバックログを「 プロダクトに対する変更の唯一の発生源 」と位置づけ、要件の整理と優先順位付けを必須としています。

アジャイル開発における要件定義書の書き方の特徴は次のとおりです。

• プロダクトビジョン ：開発着手前に「誰の・どの課題を・どう解決するか」を 1 ページに集約して固定する
• ユーザーストーリー ：「〈ロール〉として、〈目的〉のために、〈機能〉が欲しい」の形式で、機能要件をユーザー視点で分割記述する
• 受入基準（Acceptance Criteria） ：各ユーザーストーリーに対し、「Given / When / Then」形式でテスト条件を明記する
• プロダクトバックログ ：上記をリスト化し、優先順位を都度入れ替えながらスプリントごとに詳細化する

この手法により、市場の変化やユーザーのフィードバックに素早く対応しながら、必要最小限の機能（MVP）から開発をスタートさせることができます。MVP の概念については、MVPとは？ビジネスでの意味とMVP開発の進め方｜Dropbox・Airbnb・Instagram事例【2026年版】で詳しく解説しています。

ユーザーストーリーの書き方サンプル

経費申請者として、出張先で受け取った領収書を即座に登録できるために、スマートフォンのカメラで撮影するだけで申請データの下書きが自動生成される機能が欲しい。

受入基準：

• Given：ログイン済みの申請者がモバイル Web からアクセスしている
• When：領収書をカメラで撮影し「下書き作成」をタップする
• Then：金額・日付・取引先名が 95% 以上の精度で自動入力された下書きが 3 秒以内に表示される

変更管理とスコープクリープ対策

プロジェクトが進行する中で、初期の想定から仕様変更が発生することは珍しくありません。Standish Group の CHAOS Report をはじめとした業界調査でも、ソフトウェア開発プロジェクトの遅延要因として「スコープの肥大化（スコープクリープ）」は常に上位に挙げられます（参考：アジャイル開発のメリット・デメリット完全比較｜成功率39%の根拠と失敗事例7選）。そのため、変更管理プロセスの策定と、要件が際限なく膨れ上がる「スコープクリープ」への対策が必須です。

仕様変更の要望が出た際の具体的な判断ポイントは、次の 2 点です。

1. 事業価値との整合性 ：その変更が事業目標やユーザーへの提供価値に直結するか
2. 影響範囲の定量評価 ：開発スケジュール（追加工数）・コスト（追加費用）・他要件への影響範囲はどの程度か

これらを客観的に評価する基準を設けることで、不要な機能追加によるプロジェクトの遅延を防ぐことができます。

現場で要件定義書を運用する際は、口頭での変更指示を避け、必ずドキュメントに変更履歴を残す仕組みを構築してください。 変更要求管理票（CR：Change Request） を導入し、「誰が変更を起案し」「どのような基準で評価し」「最終的に誰が承認するのか」というルールを事前に定めることが、要件定義書を形骸化させないための基本事項です。

また、外部ベンダーに開発を委託する場合は、要件定義フェーズを準委任契約（成果物責任なし、工数ベース）とし、要件が固まった後の開発フェーズを請負契約（成果物責任あり）とするなど、契約形態の工夫もスコープクリープ対策として有効です。開発手法の選定そのものに迷う場合はアジャイル開発・ウォーターフォール開発の違いを徹底比較！失敗しない選び方も併せてご確認ください。

提出前セルフチェックリスト（必須6項目）

要件定義書を関係者に共有する前に、以下のチェックリストでセルフレビューを実施してください。1 つでも該当しない項目があれば、書き直し対象です。

• 1. 目的とスコープ ：定量目標（数値・期日）と対象外要件の両方が明記されているか
• 2. 業務要件 ：As-Is と To-Be が並列に図解され、所要時間・件数などの定量差分が示されているか
• 3. 機能要件 ：すべての機能がユースケース／ユーザーストーリー単位で書かれ、受入基準まで定義されているか
• 4. 非機能要件 ：IPA SEC の 6 大項目（可用性／性能・拡張性／運用・保守／移行／セキュリティ／システム環境）を漏れなくカバーしているか
• 5. 権限・運用 ：ロール定義と権限マトリクスがあり、ログ要件・運用時間帯まで明文化されているか
• 6. 前提・制約・変更管理 ：契約形態、変更要求プロセス（CR）、版管理の運用ルールが明記されているか

よくある質問

要件定義書と基本設計書の違いは何ですか？

要件定義書は「システムで何を実現するか（What）」を定義するドキュメントであり、基本設計書は「それをどのように実現するか（How）」を定義するドキュメントです。要件定義書で決めた内容をもとに、画面レイアウトやデータベース構造などを具体化していくのが基本設計書の役割です。

要件定義書の作成にはどのくらいの期間がかかりますか？

プロジェクトの規模によりますが、一般的な中規模システム開発の場合、1 か月〜2 か月程度が目安です。ステークホルダーの数や業務の複雑さによって変動するため、十分なヒアリング期間と、レビュー反映の往復回数（最低 2〜3 回）を見込んだスケジュールにすることが重要です。

要件定義書は Excel・Word・Notion のどれで作るのが正解ですか？

媒体に正解はありません。重要なのは「 最新版が常に一意に特定でき、変更履歴が追える 」状態を保つことです。Excel・Word はバージョン管理が属人化しやすいため、Notion・Confluence・Google Docs などのクラウドベースで運用するか、Excel／Word を使う場合でも Git 管理や共有フォルダ＋版番採番ルールを併用することを推奨します。

要件定義書のサンプル・テンプレートはどこから入手すればよいですか？

IPA SEC が公開している「非機能要求グレード」のドキュメント類は、非機能要件のテンプレートとして信頼性が高く、無償で利用できます。機能要件側のテンプレートは社内で 1 つを標準化し、案件ごとにカスタマイズして使い回す運用が現実的です。

アジャイル開発でも要件定義書は必要ですか？

必要です。Scrum Guide 2020 でもプロダクトバックログを必須の作成物としています。ただし、ウォーターフォールのように冒頭で全要件を固定するのではなく、 プロダクトビジョンとユーザーストーリー＋受入基準 という形で、優先順位付き・段階的詳細化を前提に書きます。詳細はアジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップ【Scrum Guide 2020準拠】を参照してください。

まとめ

SaaS 開発やシステム構築を成功に導くためには、質の高い要件定義書の作成が不可欠です。本記事で解説したとおり、必須 6 項目（はじめに／システム概要／業務要件／機能要件／非機能要件／プロジェクト管理）を、Good 例 / Bad 例の対比で示した「 テストで合否判定できる粒度 」まで書き切ることが、手戻りを防ぐ最大の武器となります。

さらに、IPA SEC「非機能要求グレード」の 6 大項目に準拠した非機能要件、PMBOK 第 7 版に沿ったスコープ統制、Scrum Guide 2020 に基づくユーザーストーリー形式のアジャイル要件定義、変更要求管理票（CR）を中心とした厳格な変更管理プロセス――これらを組み合わせることで、要件定義フェーズを起点とした手戻りを最小限に抑えることができます。提出前には本記事のセルフチェックリストで漏れを確認し、開発チームと事業部門が一体となって目標達成を目指せる「生きたドキュメント」を作成してください。