要件定義書を英語で書く方法｜SRS・PRD・BRD違い・用語集・例文テンプレート

要件定義書の英語表記は1つではない：SRS・PRD・BRDの違い

「要件定義書」を英語で書こうとしたとき、最初に直面するのが「何と呼ぶか」という問題です。英語圏では要件定義書に相当するドキュメントが複数存在し、プロジェクトの性質や読者によって使い分けられています。代表的なのが SRS（Software Requirements Specification）、PRD（Product Requirements Document）、BRD（Business Requirements Document） の3種類です。それぞれ目的・読者・粒度が異なるため、まず違いを理解することが英語ドキュメント作成の第一歩になります。

SRS（Software Requirements Specification）とは

SRS は IEEE 830 規格に準拠した技術仕様書で、開発チームを主な読者として機能要件・非機能要件を網羅的に記述します。「何を作るか」を厳密に定義することを目的としており、受託開発・官公庁案件・エンタープライズシステム開発で広く使われています。仕様の曖昧さを排除するため、要件の記述には後述する RFC 2119 の shall / should / may といった規定語を用いるのが慣習です。

SRS の特徴は、機能要件だけでなくパフォーマンス・セキュリティ・可用性といった非機能要件（Non-Functional Requirements）も同一ドキュメントに含める点にあります。契約上の根拠文書として機能することも多く、変更管理（Change Management）のプロセスと組み合わせて運用されます。

PRD（Product Requirements Document）とは

PRD はプロダクトマネージャーが作成するドキュメントで、ビジネス目標・ユーザーストーリー・成功指標を中心に構成されます。エンジニアだけでなく、デザイナー・マーケター・経営層まで幅広いステークホルダーが読むことを前提としているため、技術的な詳細よりも「なぜ作るか（Why）」「何を作るか（What）」の説明に重点が置かれます。

スタートアップやアジャイル開発チームで最も普及しており、Notion・Confluence・Google Docs で管理されることが多いです。Lenny Rachitsky や Shreyas Doshi といった著名 PdM がテンプレートを公開していることもあり、PRD のフォーマットはコミュニティ内で活発に共有・進化しています。

BRD（Business Requirements Document）とは

BRD はビジネスアナリスト（BA）が作成する上位文書で、経営課題・ROI・ステークホルダー要件を記述します。SRS や PRD の前段として位置づけられ、「なぜこのプロジェクトを実施するか」という経営的な根拠を示す役割を担います。承認フロー（Approval Workflow）が必要な大企業の新規事業立ち上げや、複数部門が関与するシステム刷新プロジェクトで使われることが多いです。

BRD は技術的な詳細には踏み込まず、ビジネス側の意思決定者が読むことを想定した文書です。BRD で合意が取れた後に PRD・SRS へと詳細化していく流れが、大規模プロジェクトの標準的なアプローチとなっています。

どのドキュメントを選ぶべきか：プロジェクト別の使い分け早見表

3種類のドキュメントの違いを理解したうえで、次に重要なのは「自分のプロジェクトにどれが適切か」を判断することです。プロジェクトの規模・開発手法・読者によって最適な選択肢は変わります。以下の基準を参考にしてください。

プロジェクト規模・開発手法別の選択基準

開発手法と組織規模を軸に整理すると、選択の指針が明確になります。

• スタートアップ／アジャイル開発：PRD が最適。軽量で更新しやすく、エンジニア・デザイナー・PdM が共通言語として使える。
• 受託開発／ウォーターフォール：SRS が必須。契約上の仕様根拠として機能し、変更管理プロセスと組み合わせて使う。
• 大企業の新規事業立ち上げ：BRD → PRD → SRS の順で作成し、段階的に詳細化する。
• グローバルチームへの共有が主目的：PRD が最も汎用性が高く、非エンジニアにも読みやすい。

なお、3種類を必ずすべて作成する必要はありません。小規模なアジャイルプロジェクトでは PRD 1本で十分なケースがほとんどです。

SRS・PRD・BRD の比較表（読者・目的・粒度）

3つのドキュメントは「Why → What → How」の階層関係で理解すると整理しやすいです。

• BRD：読者＝経営・ビジネス側 ／ 目的＝Why（なぜやるか） ／ 粒度＝粗い（ビジネス課題・ROI）
• PRD：読者＝PdM・デザイナー・エンジニア ／ 目的＝What（何を作るか） ／ 粒度＝中程度（ユーザーストーリー・成功指標）
• SRS：読者＝エンジニア・QA ／ 目的＝How（どう作るか） ／ 粒度＝細かい（機能仕様・非機能要件）

グローバルチームで英語ドキュメントを初めて整備する場合は、まず PRD から着手し、必要に応じて SRS を追加するアプローチが現実的です。

英語で要件定義書を書くスキルを活かせる求人をお探しの方は、Granty の PdM 特化転職エージェントに無料でご相談いただけます。

英語 PRD の標準構成と各セクションの書き方

PRD を英語で書く際、構成が標準化されていると読者の理解が早まり、レビューサイクルも短縮されます。業界で広く参照されている構成は、Overview・Problem Statement・Goals & Non-Goals・User Stories・Requirements・Success Metrics の6セクションです。以下では各セクションの役割と英語例文を解説します。

PRD 必須セクション一覧（Overview〜Success Metrics）

• Overview：プロダクト・機能の概要を2〜3文で説明。読者が全体像を把握するための導入部。
• Problem Statement：解決すべき課題を具体的に記述。ユーザーの痛点と現状の問題を定量・定性で示す。
• Goals & Non-Goals：このドキュメントのスコープを明確化。「やること」と「やらないこと」を明示することで手戻りを防ぐ。
• User Stories：「As a [user type], I want to [action] so that [benefit]」形式で要件をユーザー視点で記述。
• Requirements：機能要件を箇条書きで列挙。優先度（Must Have / Should Have / Nice to Have）を付けると実装判断が容易になる。
• Success Metrics：成功の定義を数値・計測方法・期間のセットで記述。曖昧な目標設定を防ぐ最重要セクション。

各セクションの英語例文（コピペ可）

Problem Statement の例文：

Users currently struggle to track their task completion status across multiple projects, resulting in missed deadlines and duplicated work. Our goal is to provide a unified dashboard that surfaces the most critical tasks in real time.

Goals & Non-Goals の例文：

Goals: Enable users to view all active tasks in a single view; send automated reminders 24 hours before due dates.
Non-Goals: This release does not include time-tracking functionality or integration with third-party calendars.

User Stories の例文：

As a project manager, I want to filter tasks by assignee so that I can quickly identify bottlenecks in my team's workflow.

Success Metrics の例文：

Increase DAU by 20% within 90 days of launch, as measured by daily active sessions in our analytics platform. Reduce average task overdue rate from 35% to under 15% within 60 days.

各セクションの記述量の目安は、Overview が3〜5文、Problem Statement が5〜8文、Requirements が10〜30項目程度です。プロジェクトの複雑さに応じて調整してください。

英語 SRS の標準構成（IEEE 830 準拠）

受託開発やエンタープライズ案件では、IEEE 830（現在は IEEE 29148 に統合）に準拠した SRS が求められることがあります。SRS は PRD より技術的な詳細度が高く、エンジニアと QA エンジニアが実装・テストの根拠として参照するドキュメントです。

SRS の必須セクション（Introduction〜Appendix）

IEEE 830 に基づく基本構成は以下の通りです。

1. Introduction：Purpose（文書の目的）/ Scope（システムの範囲）/ Definitions & Acronyms（用語定義）/ References（参照文書）
2. Overall Description：Product Perspective（既存システムとの関係）/ Product Functions（主要機能の概要）/ User Classes（ユーザー種別）/ Constraints（制約条件）
3. Specific Requirements：Functional Requirements（機能要件）と Non-Functional Requirements（非機能要件）を詳細に記述。Use Case または User Story 形式で記述するのが現代的なアプローチ。
4. Appendix：用語集・図表・参考資料を補足として添付。

Functional Requirements の各項目には一意の ID（例：FR-001、FR-002）を付与し、テストケースとのトレーサビリティを確保するのがベストプラクティスです。

非機能要件（Non-Functional Requirements）の英語表現

非機能要件は曖昧になりやすいため、測定可能な形で記述することが重要です。以下に典型的な英語表現を示します。

• Performance（パフォーマンス）：The system shall respond within 200ms for the 95th percentile of API requests under a load of 1,000 concurrent users.
• Availability（可用性）：The system shall maintain 99.9% uptime measured on a monthly basis, excluding scheduled maintenance windows.
• Security（セキュリティ）：All data in transit shall be encrypted using TLS 1.2 or higher. User passwords shall be hashed using bcrypt with a minimum cost factor of 12.
• Scalability（スケーラビリティ）：The system shall support horizontal scaling to handle a 10x increase in traffic without architectural changes.
• Maintainability（保守性）：The codebase shall maintain a test coverage of at least 80% for all critical business logic modules.

SLA（Service Level Agreement）・RTO（Recovery Time Objective）・RPO（Recovery Point Objective）といった略語を使う場合は、Definitions セクションで正式名称と定義を明記しておくと、読者間の認識齟齬を防げます。

日英対訳用語集50選：要件定義書でよく使う単語・フレーズ

英語で要件定義書を書く際に詰まりやすいのが、日本語固有の概念や業務用語の英訳です。直訳すると意味が通じないケースも多いため、実務で通用する英語表現を用語集としてまとめました。

基本概念・ドキュメント用語（20語）

• 要件定義 ＝ Requirements Definition / Requirements Engineering
• 機能要件 ＝ Functional Requirements
• 非機能要件 ＝ Non-Functional Requirements
• 受け入れ基準 ＝ Acceptance Criteria
• 仕様書 ＝ Specification Document / Spec
• 仕様凍結 ＝ Specification Freeze / Feature Freeze
• 手戻り ＝ Rework / Revision（「手戻りを防ぐ」は prevent rework または avoid late-stage revisions）
• スコープ外 ＝ Out of Scope
• スコープクリープ ＝ Scope Creep
• 要件漏れ ＝ Missing Requirements / Requirements Gap
• トレーサビリティ ＝ Traceability
• ユースケース ＝ Use Case
• ユーザーストーリー ＝ User Story
• エピック ＝ Epic
• バックログ ＝ Backlog
• 優先度付け ＝ Prioritization
• 依存関係 ＝ Dependencies
• 前提条件 ＝ Assumptions / Preconditions
• 制約条件 ＝ Constraints
• 変更管理 ＝ Change Management

プロセス・ステークホルダー用語（15語）

• 承認フロー ＝ Approval Workflow
• 関係者 ＝ Stakeholders
• 優先度 ＝ Priority（MoSCoW 法では Must Have / Should Have / Could Have / Won't Have に対応）
• エスカレーション ＝ Escalation
• 確認待ち ＝ Pending Review / Awaiting Approval
• 調整中 ＝ Under Discussion / In Progress
• 合意形成 ＝ Consensus Building / Alignment（「関係者との合意形成」は stakeholder alignment）
• レビュー依頼 ＝ Review Request
• フィードバック反映 ＝ Incorporating Feedback
• キックオフ ＝ Kickoff Meeting
• マイルストーン ＝ Milestone
• デッドライン ＝ Deadline / Due Date
• リリース判定 ＝ Release Decision / Go/No-Go Decision
• 品質保証 ＝ Quality Assurance（QA）
• 受け入れテスト ＝ User Acceptance Testing（UAT）

技術・品質用語（15語）

• 画面遷移 ＝ Screen Transition / Navigation Flow
• 例外処理 ＝ Exception Handling / Error Handling
• 冪等性 ＝ Idempotency（「冪等な操作」は idempotent operation）
• レイテンシ ＝ Latency
• スループット ＝ Throughput
• 可用性 ＝ Availability
• 耐障害性 ＝ Fault Tolerance / Resilience
• バックアップ・復旧 ＝ Backup and Recovery
• SLA（サービスレベル合意）＝ Service Level Agreement
• RTO（目標復旧時間）＝ Recovery Time Objective
• RPO（目標復旧時点）＝ Recovery Point Objective
• API 仕様 ＝ API Specification / API Contract
• データ整合性 ＝ Data Integrity / Data Consistency
• ログ出力 ＝ Logging / Audit Logging
• テストカバレッジ ＝ Test Coverage

グローバルチームで通じる英語要件定義書を書く5つのコツ

英語が母語でない書き手が陥りやすい落とし穴は、曖昧な表現・受動態の多用・測定不可能な目標設定の3点に集約されます。以下のコツを意識するだけで、ドキュメントの品質は大きく向上します。

コツ1：曖昧表現を避ける — shall / should / may の使い分け

RFC 2119（IETF が定める要件記述の規定語）に従い、要件の強度を明確に区別します。

• shall（MUST）：絶対的な必須要件。「The system shall encrypt all passwords.」
• should（RECOMMENDED）：推奨事項。特別な理由がない限り従うべき。「The system should display error messages in the user's preferred language.」
• may（OPTIONAL）：任意の機能。「Users may export data in CSV format.」

「できる限り」「なるべく」「適切に」といった日本語的な曖昧表現を英語に直訳するのは禁物です。これらは shall / should / may のいずれかに置き換えて、要件の強度を明示してください。

コツ2：能動態・測定可能な表現で書く

要件文は「The system shall allow users to [action]」の形式で主語を明確にします。受動態（「It is required that…」）は責任の所在が曖昧になるため避けてください。また、Success Metrics は必ず数値・計測方法・期間をセットで記述します。「Improve user satisfaction」のような定性的な目標は、「Increase NPS score from 30 to 50 within 6 months of launch, as measured by quarterly in-app surveys」のように具体化します。

コツ3：定義セクションで用語を統一する

同じ概念を「user」「customer」「end user」と混在させると、読者の混乱を招きます。SRS の Definitions セクション、PRD の Glossary セクションで用語を定義し、ドキュメント全体で一貫した表記を使うことが重要です。特に日本語固有の概念（例：「担当者」を owner / assignee / responsible party のどれにするか）は冒頭で定義しておきましょう。

コツ4：Non-Goals を明示する

英語の PRD で日本語ドキュメントと最も異なる点の一つが、Non-Goals（やらないこと）セクションの存在です。スコープ外を明示することで、スコープクリープ（Scope Creep）を防ぎ、レビュー時の議論を効率化できます。「This release does not include…」「Out of scope for this version:…」の形式で箇条書きにするのが一般的です。

コツ5：レビュー・バージョン管理の英語慣習を守る

ドキュメントの冒頭または末尾に Change Log セクションを設け、Author / Date / Version / Summary of Changes を記録します。バージョン番号は「v1.0」「v1.1」「v2.0」のようにセマンティックバージョニングに準じた形式が一般的です。レビュー依頼メールの定型文としては、「Please review the attached PRD by [date] and leave your comments directly in the document. If you have major concerns, please flag them by [date] so we can discuss in the next sync.」が実務でよく使われます。

コピペで使える英語要件定義書テンプレート（PRD・SRS）

以下のテンプレートは Notion・Confluence・Google Docs に貼り付けてすぐに使えます。プレースホルダー（[ ]内）を実際の内容に置き換えてください。

PRD テンプレート（Markdown 形式）

# Product Requirements Document

**Product Name:** [Product / Feature Name]
**Author:** [Your Name]
**Date:** [YYYY-MM-DD]
**Version:** v1.0
**Status:** [Draft / In Review / Approved]

---

## Overview
[2-3 sentences describing what this product/feature is and who it is for.]

## Problem Statement
[Describe the user problem or business pain point this feature addresses.
Include data or evidence where possible.]

## Goals & Non-Goals

### Goals
- [Goal 1: measurable outcome]
- [Goal 2: measurable outcome]

### Non-Goals
- [What this release explicitly does NOT include]
- [Functionality deferred to a future release]

## User Stories
- As a [user type], I want to [action] so that [benefit].
- As a [user type], I want to [action] so that [benefit].

## Requirements

### Must Have
- REQ-001: The system shall [requirement].
- REQ-002: The system shall [requirement].

### Should Have
- REQ-003: The system should [requirement].

### Nice to Have
- REQ-004: The system may [requirement].

## Success Metrics
- [Metric 1]: Increase [KPI] by [X%] within [timeframe], as measured by [tool/method].
- [Metric 2]: Reduce [KPI] from [current value] to [target value] by [date].

## Open Questions
- [Question 1 — Owner: Name, Due: Date]

## Change Log
| Version | Date | Author | Summary |
|---------|------|--------|---------|
| v1.0 | [Date] | [Name] | Initial draft |

SRS テンプレート（IEEE 830 簡易版）

# Software Requirements Specification

**System Name:** [System Name]
**Author:** [Your Name]
**Date:** [YYYY-MM-DD]
**Version:** v1.0

---

## 1. Introduction

### 1.1 Purpose
[State the purpose of this SRS and its intended audience.]

### 1.2 Scope
[Describe the software system being specified. What does it do and what does it not do?]

### 1.3 Definitions, Acronyms, and Abbreviations
| Term | Definition |
|------|------------|
| [Term] | [Definition] |

### 1.4 References
- [Reference document 1]
- [Reference document 2]

---

## 2. Overall Description

### 2.1 Product Perspective
[Describe how this system fits into the larger product ecosystem.]

### 2.2 User Classes
- **[User Class 1]:** [Description and characteristics]
- **[User Class 2]:** [Description and characteristics]

### 2.3 Constraints
- [Technical constraint 1]
- [Regulatory or compliance constraint]

---

## 3. Functional Requirements

### FR-001: [Feature Name]
**Description:** The system shall [description].
**Priority:** High / Medium / Low
**Acceptance Criteria:**
- [Criterion 1]
- [Criterion 2]

### FR-002: [Feature Name]
**Description:** The system shall [description].
**Priority:** High / Medium / Low
**Acceptance Criteria:**
- [Criterion 1]

---

## 4. Non-Functional Requirements

### 4.1 Performance
- The system shall respond within [X]ms for the [N]th percentile of requests under [Y] concurrent users.

### 4.2 Availability
- The system shall maintain [X]% uptime measured on a monthly basis.

### 4.3 Security
- All data in transit shall be encrypted using TLS 1.2 or higher.

### 4.4 Scalability
- The system shall support [X]x traffic increase without architectural changes.

---

## Appendix
[Supplementary diagrams, data models, or reference materials.]

Notion への貼り付け方のヒント：Notion では「/code」ブロックを作成し、言語を「Markdown」に設定してから貼り付けると、コードブロックとして整形されます。Confluence では「Insert」→「Markup」→「Markdown」から貼り付けが可能です。Google Docs の場合は、Docs to Markdown アドオンを使うと Markdown と Google Docs 形式を相互変換できます。

英語で要件定義を書けるPdMへのキャリアパス

英語で要件定義書を書けるスキルは、グローバルな開発環境で働く PdM にとって大きな差別化要因になります。外資系企業やグローバルスタートアップの PM 求人では、PRD 作成経験が必須要件として明記されるケースが増えており、英語ドキュメントの実務経験はキャリアの選択肢を広げる重要なスキルセットです。

グローバル PdM に求められる英語ドキュメントスキルの実態

外資系テック企業や海外展開を進めるスタートアップでは、PRD・SRS を英語で作成・共有する能力が採用要件に含まれることが一般的です。特に、ユーザーストーリーの記述・成功指標の設定・Non-Goals の明示といった PRD の基本スキルは、グローバルチームでの協働において即戦力として評価されます。

英語要件定義の実務経験は、ポートフォリオとして活用することも可能です。実際に作成した PRD や SRS を GitHub（README として公開）や Notion の公開ページとして整備しておくと、転職活動時の具体的な成果物として提示できます。個人情報や機密情報を含む場合はサンプルデータに置き換えたうえで公開するのが一般的な慣習です。

PdM としてのキャリアアップに向けた次のステップ

英語ドキュメント作成スキルを磨きながら、グローバルな環境で PdM としてのキャリアを築きたい方は、まず自分のプロジェクトで PRD テンプレートを実際に使ってみることをお勧めします。小さな機能改善でも英語で PRD を書く習慣をつけることで、実務レベルのドキュメントスキルが身につきます。

英語ドキュメント経験を活かせるグローバル PdM 求人をお探しの方は、Granty の PdM 特化転職エージェントに無料でご相談いただけます。外資系・グローバルスタートアップの求人紹介から、英語 PRD のポートフォリオ活用方法まで、PdM 専門のエージェントがサポートします。