要件定義書とは丨プロダクトマネージャー用語集
最終更新日:
2025年5月8日
ライター:
PM Career編集部
プロダクト開発
この記事の監修者
佐々木真
PM Career事業責任者（Xアカウント ＠shin_sasaki19）
株式会社リクルートにて「スタディサプリ」の初期メンバーとして事業開発・プロダクトマネージャー業を担当し全国展開を達成後、SmartHRのグループ会社としてToB向けSaaS「SmartMeeting」を立ち上げ2021年3月に退任。その後PMオンラインスクール「PM School」、プロダクト開発人材の転職サイト「PM Career」の事業を運営中。プロダクト開発の知見・人材の流動性を高め、日本のプロダクト作りをぶち上げるべく尽力中。個人としてもX（Twitter）アカウントのフォロワーは3万人超え、YouTubeやPodcastでもプロダクト開発のコンテンツを発信する日本で最も有名なプロダクト開発者の1人。
今すぐ転職をしたい人も、中長期的にしたい方も、PM Careerに無料会員登録をしておくことでキャリアに役立つ情報を定期的にキャッチアップすることが重要です。まだ登録されてない方はこちらからどうぞ。3分で完了します。
プロダクトマネージャー転職についての情報はこちらをご覧ください！
① 要件定義書の定義
要件定義書とは、開発するシステムやソフトウェアが “何を実現すべきか” （機能・非機能）と、それが満たされる評価基準を網羅的に記述した正式ドキュメント です。国際規格 ISO/IEC/IEEE 29148 では Software Requirements Specification として定義され、ビジネス・ユーザー・技術の三つの要求を一元化し、後続工程の契約・設計・テストの基盤となります。
PRD との違い
- PRD = “プロダクトのビジョンとユーザー価値” を示す 上位コンセプト
- 要件定義書/SRS = そのビジョンを実装できるレベルまで 詳細化した仕様
（例：PRD が“検索速度を 2 倍に”と示せば、要件定義書では “P95 < 300 ms／同時接続 5,000” まで数値指標を規定）
② 要件定義書の重要性／目的
観点 | 概要 | 主なリスク回避 |
|---|---|---|
契約／合意 | 発注者・受託者・開発チーム間の 公式合意文書 | スコープ論争・追加費用訴訟 |
品質保証 | テストケース・受入判定の 客観基準 を提供 | “出来上がったが使えない” リリース |
変更管理 | 追跡可能な ID 付き要件 → 変更影響分析が容易 | 手戻りコスト増・納期遅延 |
ナレッジ資産 | 運用・保守フェーズでの仕様参照点 | 属人化・ブラックボックス化 |
IPA の調査では、開発トラブルの約 60% が「要件不備・認識齟齬」に起因すると報告されており、初期に 1 人日投じると後工程で 5〜10 人日の損失を防ぐ とも言われます。
③ 要件定義書の実務例
シナリオ： EC プラットフォームに「定期購入（サブスク）機能」を追加
要件定義書セクション | 抜粋サンプル |
|---|---|
1. 目的 | GMV の 15% をサブスク経由にし、解約率を 5% /月 以下に抑制 |
2. 利用者像 | ・エンドユーザー：リピート購入者・店舗管理者：プラン作成／在庫同期 |
3. 機能要件 | FR-01 プラン作成 UI（ステップ数 ≤ 3）FR-02 顧客はマイページで一時停止／再開 |
4. 非機能要件 | NFR-01 決済成功率 ≥ 99.5%NFR-02 個人情報は PCI-DSS Lv1 準拠 |
5. 外部インタフェース | REST API |
6. 受入基準 | • P95 課金処理 ≤ 400 ms• E2E テスト 100 ケース合格 |
7. 変更管理 | 変更要求は JIRA “REQ-” 番号で管理し、影響分析結果を添付 |
Tips
- ID 体系（FR-/NFR-/BUS-） を付与すると Traceability Matrix が容易。
- 「非機能」「除外事項」も明示し、暗黙スコープをゼロにする。
④ 関連用語
用語 |
|---|
⑤ 参考サイト
- Asana “Software Requirements Specification (SRS) テンプレート”(Asana)
- Perforce “How to Write an SRS Document”(perforce.com)
- ISO/IEC/IEEE 29148 公式概要（要件エンジニアリング標準）(ISO)
- IPA 「要件定義を成功に導く 128 の勘どころ」(情報処理推進機構)
