はじめに
要件定義書の作成に悩んでいませんか？「何を書けばいいかわからない」「後工程で使いにくいと言われる」「ステークホルダーとの認識がズレる」——こうした課題は、要件定義書の構造化で大きく改善できます。
今回の記事では、実務で使える要件定義書の構造化ノウハウを、章立ての考え方から各章の具体的な書き方まで解説します。
要件定義書の本質を理解する
要件定義書は「仕様書」ではなく「合意形成ドキュメント」
まず押さえるべき重要な前提があります。要件定義書は詳細な仕様書ではありません。ステークホルダー間で「何を作るか」を合意するためのドキュメントです。
そのため、構造化の目的は次の3点に集約されます。
-
Why → What → How の流れが自然につながる
なぜ作るのか（背景・目的）から、何を作るのか（機能要求）、どう守るのか（非機能要求）へとスムーズに展開できる構造にします。 -
後工程にそのまま分解できる
設計・開発・テストの各フェーズで、要件定義書から直接作業項目を抽出できる粒度と構造を意識します。 -
各ステークホルダーが必要な部分だけ読める
業務部門、IT部門、セキュリティ担当など、それぞれの関心領域に応じて必要な章だけを読めるようにします。
全体構造の設計：三層構造を意識する
要件定義書の章立てを考える際、最も重要なのは 「Why → What → How制約」の三層構造 を明確にすることです。
| 軸 | 内容 | 該当する章 |
|---|---|---|
| Why（背景・目的） | なぜこのシステムが必要か | システム導入の目的と目標 |
| What（業務・機能） | 何を実現するか | システムの概要、業務フロー、機能要求、入出力要求 |
| How制約（非機能） | どう守るか・品質をどう担保するか | 品質・性能要求、セキュリティ要求 |
この構造を意識することで、読み手は文書の流れを理解しやすくなり、各章の役割も明確になります。
要件定義書の基本的な構造
1. システム導入の目的と目標
2. システムの概要／システムの構想
3. システム導入後の業務フロー
4. 機能要求
5. 入力要求と出力要求
6. 品質・性能要求
7. セキュリティ要求
各章の構造化ノウハウ
ここからは、各章をどう構造化するかの具体的なノウハウを解説します。
1. システム導入の目的と目標
ノウハウ：目的と目標を混ぜない
多くの要件定義書で曖昧になりがちなのが、目的と目標の区別です。次のように明確に分けて記述します。
1.1 導入背景（現状課題）
1.2 解決したい本質的な課題
1.3 システム導入の目的（定性的）
1.4 システム導入の目標（定量・KPI）
1.5 成功条件／非対象範囲
押さえるべきポイント
- 目的 = Why（理由）：「業務効率化」「顧客満足度向上」など定性的な狙い
- 目標 = 測れるもの（数値・状態）：「処理時間を30%削減」「月間アクティブユーザー1000人達成」など定量的な指標
ここが曖昧だと、後続のすべての要求がブレる原因になります。KPIは具体的な数値で示すことが重要です。
2. システムの概要／システムの構想
ノウハウ：「全体像だけ」を描き、詳細に踏み込まない
この章は業務視点とIT視点を橋渡しする重要な役割を持ちます。
2.1 システム全体像（俯瞰図）
2.2 システム化範囲／非システム化範囲
2.3 利用者・関係者一覧（ペルソナ）
2.4 他システムとの関係（IF概要）
2.5 前提条件・制約条件
押さえるべきポイント
- 構想レベルで止める：詳細設計に踏み込まず、あくまで全体像の共有に留める
- 技術要素の扱い：AWS、SaaSなどの技術名を記載してもOKですが、詳細な構成確定はこの段階ではしない
- 境界の明確化：何をシステム化し、何を人手で行うかの境界線を明示する
システム全体像は図表を活用し、一目で全体が把握できるようにするのがベストプラクティスです。
3. システム導入後の業務フロー
ノウハウ：As-Is / To-Be を必ず分ける
業務フローは機能要求の母体となる重要な章です。
3.1 現行業務フロー（As-Is）
3.2 課題のあるポイント
3.3 新業務フロー（To-Be）
3.4 システムが担う部分／人が担う部分
押さえるべきポイント
- 現状と未来の対比：As-IsとTo-Beを明確に分けることで、システム導入による変化が可視化される
- トレーサビリティの確保：フロー番号と後述の機能IDを紐づけられるようにする
- 5W1Hの明確化：特に「誰が・いつ・何をするか」を明確に記述する
業務フローには、判断分岐や例外処理も含めて記述することで、後工程での見落としを防げます。
4. 機能要求
ノウハウ：機能を"粒度"で分解する
機能要求は要件定義書の中核です。適切な粒度で整理することが重要です。
4.1 機能一覧（機能ID付き）
4.2 各機能の詳細
- 機能ID（例：F-001）
- 機能名
- 概要
- 利用者
- 前提条件
- 処理概要
- 関連する業務フロー番号
押さえるべきポイント
- CRUD + 業務イベントで洗い出す：Create（登録）、Read（参照）、Update（更新）、Delete（削除）に加えて、承認や通知などの業務イベントも機能として整理
- 画面単位にしない：画面ベースで考えると設計に寄りすぎる。あくまで「やりたいこと」ベースで機能を定義
- テストケースに落とせる粒度：1つの機能が複数のテストケースに分解できる程度の粒度がベスト
機能IDは一意で、後工程のトレーサビリティを確保するために必須です。
5. 入力要求と出力要求
ノウハウ：機能要求から分離して整理する
データの入出力は機能要求とは別に整理することで、後のDB設計やインターフェース設計に直結します。
5.1 入力データ要件
- 項目名
- データ型
- 必須/任意
- 入力元（画面/API/ファイル等）
- バリデーション内容
- 入力例
5.2 出力データ要件
- 出力物名（画面/帳票/API）
- 項目一覧
- 出力タイミング
- 利用目的
- 出力先
押さえるべきポイント
- 「画面仕様書」にはしない：レイアウトや配置ではなく、データ中心で考える
- バリデーションの明確化：入力チェックのルールを具体的に記述
- 後工程への接続：この情報がDB設計やインターフェース設計に直結することを意識
データ項目の定義は、データディクショナリとして別途整理するのも効果的です。
6. 品質・性能要求
ノウハウ：非機能は「測れる表現」にする
非機能要求は曖昧になりがちですが、明確な基準を設定することが重要です。
6.1 可用性（稼働時間、MTBF/MTTR）
6.2 性能
- レスポンスタイム（画面遷移：3秒以内など）
- スループット（同時接続数：100セッションなど）
- バッチ処理時間
6.3 拡張性・将来性
6.4 運用・保守性
6.5 障害対応・監視
押さえるべきポイント
- 「速い」「安定」はNG：「3秒以内」「稼働率99.9%」など数値または明確な状態で記述
- 測定可能な指標：後でテストや検証ができるよう、測定可能な形で要求を定義
- クラウド前提の考慮：クラウド環境を前提とする場合、スケーラビリティや従量課金も考慮
性能要求は、ピーク時と平常時を分けて記述すると、より実用的です。
7. セキュリティ要求
ノウハウ：原則 → 具体 → 例外の順で整理
セキュリティは包括的かつ具体的に記述する必要があります。
7.1 セキュリティ方針（全体的な考え方）
7.2 認証・認可
- 認証方式（パスワード、MFA、SSO等）
- 権限管理（ロールベース、属性ベース等）
7.3 データ保護
- 暗号化（保管時・通信時）
- マスキング対象データ
7.4 操作ログ・監査
7.5 法令・社内規定対応（個人情報保護法、GDPR等）
押さえるべきポイント
- 「全部セキュアに」ではダメ：何を守るのか、優先度は何かを明確にする
- 3点セットで考える：利用者（誰が）、データ（何を）、操作（どうやって）の3つの観点で整理
- 監査対応を忘れない：後で証跡を追えるよう、ログ要件も明確に
セキュリティ要求は、コンプライアンス部門や情報セキュリティ部門のレビューを受けることを推奨します。
構造化の最重要ノウハウ（まとめ）
最後に、要件定義書を構造化する上で絶対に外せない5つのポイントをまとめます。
1. Why → What → How制約 の流れを崩さない
この三層構造が明確であれば、読み手は文書の意図を理解しやすくなります。章の順序も、この流れに沿って配置します。
2. 業務 → 機能 → データ の流れを意識
業務フローから機能を抽出し、機能から必要なデータを定義する。この自然な流れを文書構造に反映させます。
3. 機能と非機能を混ぜない
「ログイン機能は3秒以内に応答すること」のように、機能要求と非機能要求を混在させると、後で整理が難しくなります。明確に章を分けて記述します。
4. 後工程（設計・テスト）に分解できる粒度
要件定義書から設計書やテスト仕様書を作成できる粒度を意識します。粗すぎても細かすぎてもいけません。
5. 「合意できる言葉」で書く
技術者だけでなく、業務部門や経営層も読む文書です。専門用語の使用は必要最小限にし、必要に応じて用語集を付けます。
おわりに
要件定義書の構造化は、一度マスターすれば多くのプロジェクトで応用できる強力なスキルです。本記事で紹介したノウハウは、実務で試行錯誤を重ねて磨かれたものです。
まずは自分のプロジェクトで一部を取り入れることから始めてみてください。構造が整理されることで、ステークホルダーとの合意形成がスムーズになり、後工程での手戻りも大幅に削減できるはずです。
良い要件定義書が、良いシステム開発の第一歩となることを願っています。
参考資料
- IPA「非機能要求グレード」
- JIS X 0160:2012（ISO/IEC/IEEE 29148:2011）システムライフサイクルプロセス—要求事項プロセス
人気の登壇者を招いて、イベントを開催します。
私も、登壇し、Udemyの講座を無料で提供予定です。(現地参加者のみ)
ご都合付くようでしたら、ご参加いただき、懇親会で、会話しましょう。