要件定義書テンプレート完全ガイド｜PdMが使える書き方と項目一覧【2026年版】

要件定義書テンプレートの全体像

要件定義書を初めて作成する場合も、既存フォーマットを見直したい場合も、まず「何を書くべきか」の全体像を把握することが出発点です。このセクションでは、実務で使えるテンプレートの構成サマリと、3ステップの使い方ガイドを紹介します。

テンプレートの構成サマリ（項目一覧早見表）

要件定義書は大きく8つのブロックで構成されます。各ブロックの役割を把握しておくと、どこに何を書くかで迷わなくなります。

• プロジェクト概要：プロジェクト名・作成者・バージョン・作成日・更新履歴
• 背景：このプロジェクトが生まれた経緯・解決したい課題
• 目的：達成したいビジネスゴール・KPI との紐付け
• スコープ：対象範囲（やること）と対象外（やらないこと）の明示
• 機能要件：システムが提供すべき機能の一覧と受け入れ基準
• 非機能要件：性能・セキュリティ・可用性・保守性などの品質基準
• 制約条件・前提条件・依存関係：技術スタック・予算・期日・外部連携
• 承認欄：ステークホルダーの署名・日付・役職

開発手法によって粒度は変わります。ウォーターフォール開発では全要件をフェーズ開始前に確定させる「凍結型」として設計し、アジャイル開発ではスプリントごとに更新できる「生きたドキュメント」として運用します。どちらの場合も上記8ブロックの骨格は共通です。

テンプレートの使い方ガイド（3ステップ）

テンプレートを手に入れたあと、どう使い始めるかを3ステップで整理します。

1. ステップ1：プロジェクト情報を埋める　プロジェクト名・目的・背景・ターゲットユーザーなど、「なぜ作るか」に関わる情報を最初に記入します。この段階で曖昧な部分があれば、ステークホルダーへのヒアリングを先に行います。
2. ステップ2：要件を機能要件と非機能要件に分類する　洗い出した要件を「機能要件（何ができるか）」と「非機能要件（どのくらいの品質で動くか）」に振り分けます。分類に迷う項目は非機能要件に仮置きし、レビュー時に確認します。
3. ステップ3：ステークホルダーレビューと承認　ドラフトを関係者に共有し、読み合わせを実施します。合意が取れたら承認欄に署名・日付を記入し、「合意した証跡」として保存します。

要件定義書とは何か｜仕様書・設計書との違いを整理

要件定義書・仕様書・設計書は混同されやすいドキュメントですが、それぞれが答える問いが異なります。違いを理解することで、テンプレートの各項目に何を書くべきかが明確になります。

要件定義書・仕様書・設計書の役割の違い

三者の関係は「何を作るか → どう作るか → どう実装するか」という三層構造で整理できます。

• 要件定義書：「何を作るか」を定義する。ビジネス要件・ユーザー要件を中心に記述し、エンジニアリングの詳細には踏み込まない。
• 仕様書（機能仕様書）：「どう作るか」を定義する。画面遷移・API インターフェース・データ構造など、実装に必要な詳細を記述する。
• 設計書（基本設計・詳細設計）：「どう実装するか」を定義する。クラス設計・DB スキーマ・アーキテクチャ図など、エンジニアが直接参照する技術ドキュメント。

PdM が主に責任を持つのは要件定義書です。仕様書・設計書はエンジニアやテックリードが主導することが多いですが、要件定義書の品質が低いと下流ドキュメント全体に影響が波及します。

PdMが要件定義書を書く目的と価値

要件定義書の最大の価値は、認識齟齬の防止と手戻りコストの削減です。口頭合意だけで開発を進めると、「言った・言わない」の問題が発生し、後工程での修正コストが膨らみます。要件定義書はその防止策であり、ステークホルダー合意の証跡でもあります。

もう一つの重要な役割は、ドキュメントを「生きた仕様」として機能させることです。作成して終わりではなく、仕様変更のたびに更新し、常に最新の合意内容を反映させる運用設計が必要です。そのためには、更新責任者・更新トリガー・バージョン管理ルールをドキュメント冒頭に明記しておくことが効果的です。

要件定義書の作成スキルを磨いてキャリアアップを検討している方は、Granty の PdM 特化転職エージェントに無料でご相談いただけます。

要件定義書テンプレートの必須項目と書き方

テンプレートの各ブロックに何をどう書くかを、具体的な記述例とともに解説します。このセクションが要件定義書作成の核心です。

プロジェクト概要・背景・目的の書き方

冒頭のブロックでは「なぜこのプロジェクトが存在するか」を明確にします。記述すべき3点セットは、背景（なぜ作るか）・目的（何を達成するか）・ターゲットユーザー（誰のためか）です。この3点が揃っていないと、後続の要件が「何のための機能か」を失い、優先度判断が困難になります。

目的の記述では、OKR や KPI との紐付けを明記することを推奨します。たとえば「月間アクティブユーザー数を現状の 1.5 倍に増やす（KPI: MAU 15,000 → 22,500）」のように数値目標を添えると、開発中に機能の優先度を判断する際の根拠として機能します。抽象的な目的文（「ユーザー体験を向上させる」）は避け、測定可能な形で記述します。

スコープ定義（対象範囲・対象外）の書き方

スコープ定義の目的は、スコープクリープ（要件の際限ない拡大）を防ぐことです。「やること」だけでなく「やらないこと」を明示的に列挙することが重要です。

記述形式は表形式が推奨されます。左列に「対象（In Scope）」、右列に「対象外（Out of Scope）」を並べると、レビュー時に抜け漏れを確認しやすくなります。フェーズ分けがある場合は、フェーズ番号と対応機能を同じ表に追加列として整理します。たとえば「フェーズ1：ユーザー登録・ログイン機能」「フェーズ2：決済機能（本リリース対象外）」のように明記します。

機能要件の書き方（ユーザーストーリー形式 vs 箇条書き形式）

機能要件の記述形式は、プロジェクトの性質と開発チームの文化によって使い分けます。代表的な2形式を比較します。

• ユーザーストーリー形式：「〇〇として（ユーザー種別）、〜したい（行動）、なぜなら〜（理由）」の構文で記述します。アジャイル開発や、ユーザー視点を重視したい場合に適しています。例：「登録ユーザーとして、パスワードを忘れた際にメールでリセットリンクを受け取りたい、なぜなら自力でアカウントを復旧できるようにしたいから」
• 機能ID付き箇条書き形式：「F-001：ユーザーはメールアドレスとパスワードで新規登録できる」のように、機能IDを付与して一覧化します。ウォーターフォール開発や、仕様書・テスト仕様書との紐付けが必要な場合に適しています。

どちらの形式でも、各機能要件に受け入れ基準（Acceptance Criteria）を付記することを強く推奨します。「パスワードリセットメールは送信後 5 分以内に届くこと」のように、完了の定義を明確にすることで、テスト工程での判断基準が明確になります。

非機能要件（性能・セキュリティ・可用性）の書き方

非機能要件は「どのくらいの品質で動くか」を定義するブロックです。定性的な表現（「高速に動作すること」）は避け、必ず数値で定義します。

• 性能要件：レスポンスタイム（例：API レスポンスは 95 パーセンタイルで 500ms 以内）、同時接続数（例：ピーク時 1,000 同時接続を処理できること）
• 可用性要件：稼働率 SLA（例：月間稼働率 99.9% 以上、計画外ダウンタイム月 43 分以内）
• セキュリティ要件：準拠すべき基準を明記します。個人情報を扱う場合は個人情報保護法・ISMS（ISO/IEC 27001）への準拠、決済機能がある場合は PCI-DSS への準拠を記載します。
• 保守性・拡張性：コードカバレッジ目標、ドキュメント更新ルール、将来的なスケールアップ要件など

非機能要件は後回しにされがちですが、インフラ設計・コスト見積もりに直結するため、機能要件と同時に定義することが重要です。

制約条件・前提条件・依存関係の書き方

このブロックでは、プロジェクトの「外から決まっている条件」を整理します。記述すべき主な項目は以下の通りです。

• 技術スタック制約：既存システムとの互換性から使用言語・フレームワークが指定されている場合
• 予算上限：開発費・インフラ費の上限金額
• リリース期日：法改正対応・マーケティングキャンペーンなど、外部要因で決まっている期日
• 外部 API・サービス依存：Stripe（決済）・SendGrid（メール）・AWS（インフラ）など、外部サービスへの依存とそのリスク

さらに重要なのが、「前提が崩れた場合の対応フロー」を記載しておくことです。たとえば「外部 API の仕様変更が発生した場合は、PdM・エンジニアリードで影響範囲を評価し、スコープ変更の要否を 3 営業日以内に判断する」のように、再合意のプロセスを明文化しておくと、変更発生時の混乱を最小化できます。

ウォーターフォール vs アジャイル｜開発手法別テンプレートの使い分け

要件定義書のテンプレート構成は同じでも、開発手法によって「粒度」「更新頻度」「運用方法」が大きく異なります。自分のチームの開発手法に合わせた使い方を選ぶことが、ドキュメントを形骸化させないための鍵です。

ウォーターフォール向け要件定義書の特徴

ウォーターフォール開発では、要件定義書は「凍結型ドキュメント」として設計します。設計フェーズ開始前に全要件を確定させ、以降の変更は原則として変更管理プロセスを経由させます。

具体的には、変更管理票（Change Request）との連携フローをドキュメントに組み込みます。「要件変更が発生した場合は CR フォームを起票 → PdM・PM・エンジニアリードで影響評価 → ステークホルダー承認 → 要件定義書のバージョンアップ」というフローを明記しておくことで、変更の追跡可能性を確保します。承認欄には初回承認だけでなく、変更承認の履歴も残せる設計にします。

アジャイル向け要件定義書（プロダクトバックログとの関係）

アジャイル開発では、要件定義書はスプリントごとに更新される「生きたドキュメント」として運用します。Scrum では要件の詳細はプロダクトバックログで管理されるため、要件定義書との二重管理が発生しないよう設計することが重要です。

推奨される運用は、要件定義書を「プロジェクトの方向性・スコープ・非機能要件の合意文書」として位置づけ、個別機能の詳細はプロダクトバックログのユーザーストーリーに委ねる分担です。要件定義書には「このプロダクトが解決する課題・目的・スコープ境界」を記述し、機能の詳細仕様はバックログアイテムの Acceptance Criteria で管理します。Confluence などの wiki ツールと Jira・Linear などのバックログ管理ツールを連携させると、変更履歴の追跡が容易になります。

要件定義書作成でよくある失敗と対策

要件定義書の作成経験が浅い段階では、同じ失敗パターンが繰り返されます。代表的な3つの失敗例と、その対策を整理します。

失敗例1：要件が曖昧で手戻りが発生する

最も頻出する失敗は、要件の定性的な記述です。「使いやすい UI にする」「高速に動作する」「セキュアな設計にする」といった表現は、書いた側と読んだ側で解釈が異なり、開発完了後に「イメージと違う」という手戻りを生みます。

対策は、定性表現を定量基準に置き換えることです。「使いやすい UI」→「主要タスクの完了率 80% 以上（ユーザビリティテスト基準）」、「高速に動作する」→「トップページの LCP（Largest Contentful Paint）2.5 秒以内」のように数値化します。さらに、各機能要件に受け入れ基準（Acceptance Criteria）を付記することで、「完了の定義」を事前に合意しておきます。

失敗例2：ステークホルダーの合意が取れていない

要件定義書を作成したものの、関係者が「見ていない」「合意した覚えがない」という状況は珍しくありません。この問題は、承認プロセスを形式化することで防げます。

承認欄には署名・日付・役職を記入する欄を設け、「合意した証跡」として機能させます。また、レビュー会議のアジェンダに要件定義書の読み合わせを組み込む運用ルールを設けることも効果的です。「メールで送って確認してください」ではなく、「会議で一緒に読む」ことで、認識齟齬をその場で解消できます。非同期レビューの場合は、Confluence のコメント機能や Google Docs の提案モードを活用し、フィードバックの記録を残します。

失敗例3：ドキュメントが陳腐化して誰も参照しなくなる

作成時は丁寧に書かれた要件定義書でも、開発が進むにつれて実態と乖離し、誰も参照しなくなるケースがあります。これはドキュメントの「更新ルール」が設計されていないことが原因です。

対策として、ドキュメント冒頭に以下の3点を明記します。更新責任者（誰が更新するか）、更新トリガー（どんな変更が発生したら更新するか）、バージョン管理ルール（バージョン番号の付け方・変更履歴の記録方法）。Confluence などの wiki ツールを使うと変更履歴が自動記録されるため、「いつ・誰が・何を変えたか」の追跡が容易になります。Notion や Google Docs でも同様の運用が可能です。

要件定義書を書けるPdMのキャリア価値と次のステップ

要件定義書の作成スキルは、PdM としての市場価値に直結します。採用面接での評価ポイントと、このスキルが特に活きるポジションの特徴を整理します。

要件定義力がPdM採用で評価される理由

要件定義書を適切に書けるということは、エンジニア・デザイナー・ビジネスサイドの橋渡し能力を持つことの証明です。PdM の採用面接では「過去に担当した要件定義の事例を教えてください」という質問が頻出します。この質問に対して、具体的なドキュメント構成・ステークホルダーとの合意プロセス・発生した課題と対処法を語れる候補者は、実務経験の深さを示せます。

特に評価されるのは、「曖昧な要件をどう定量化したか」「スコープクリープをどう防いだか」「ドキュメントをどう生きた状態に保ったか」という3点です。これらは要件定義書の品質に直結する問いであり、実務経験なしには語れない内容です。

要件定義スキルを活かせるPdMポジションの特徴

要件定義の経験が特に重視されるのは、0→1 フェーズのスタートアップや新規事業部門です。既存の仕様書がない状態からプロダクトを立ち上げる場面では、要件定義書を一から設計できる PdM の価値は高く、採用要件に明示されるケースも多くあります。

一方、大手企業の DX 推進ポジションでは、要件定義書の「標準化経験」が差別化要因になります。複数チームが同じフォーマットで要件定義書を作成できるよう、テンプレートを整備・展開した経験は、組織横断的な影響力を示す実績として評価されます。要件定義スキルを軸にしたキャリアの方向性を検討している方は、Granty の PdM 特化転職エージェントに無料でご相談いただけます。