【テンプレあり】英語PRD（プロダクト要求仕様書）の書き方｜ITプロジェクトで使える日英フォーマット付き

英語でPRD（プロダクト要求仕様書）を書くよう求められたとき、何をどこまで書けばいいか迷った経験はないだろうか。

PRDは「何を・誰のために・なぜ作るか」を定義するプロダクト開発の中核文書だ。グローバルチームでは英語が基本になるが、7つのセクション構成さえ押さえれば英語でも問題なく書ける。

この記事では、PRDに必要な7つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに実務で活用できる。

PRDに必要な7つの構成要素

PRD（Product Requirements Document）は開発する機能の目的・要件・成功指標を定義するドキュメントだ。以下の7つが標準的な構成要素になる。

基本情報（Document Info）
背景・課題（Problem Statement）
目的・成功指標（Goals & Success Metrics）
ユーザーストーリー（User Stories）
要求事項（Requirements)
スコープ外・前提条件（Out of Scope & Assumptions）
リリース計画（Release Plan）

PRDとBRDの違い

BRD（ビジネス要件定義書）は「ビジネス上なぜ必要か」を経営・業務視点で定義する文書だ。一方、PRDは「プロダクトとして何を作るか」を開発チーム向けに具体化する文書になる。BRD→PRD→技術仕様書という流れで詳細化されるのが標準的だ。

BRDの書き方は英語要件定義書の書き方でも確認してほしい。

なぜ英語で書くのか

グローバルチームではPRDがエンジニア・デザイナー・QAの共通言語になる。英語で書くことで、海外メンバーも同じ理解で開発を進められ、仕様の認識齟齬による手戻りを防げる。

「読んだ人が同じものを思い浮かべられる」ことが、PRDの最大の目的だ。

テンプレートをダウンロード（Word）

以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。

📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)

日本語版テンプレート（コピペOK）

基本情報

項目	内容
機能・プロダクト名	（例：ダークモード対応）
バージョン	v1.0
作成者（PM）	（名前・役職）
レビュアー	（例：エンジニアリングリード・デザインリード）
作成日	YYYY-MM-DD
最終更新日	YYYY-MM-DD
ステータス	Draft / In Review / Approved

背景・課題

項目	内容
課題	（例：夜間利用ユーザーから「画面が眩しい」という要望が月50件以上寄せられている）
根拠データ	（例：ユーザーの38%が21時以降に利用。アンケートでダークモード希望が72%）
放置した場合の影響	（例：競合3社はすでに対応済みで、解約理由の上位に「目の疲れ」が入っている）

目的・成功指標

項目	内容
目的	（例：夜間利用時の体験を改善し、継続率を向上させる）
成功指標1（KPI）	（例：ダークモード利用率：リリース3か月で30%以上）
成功指標2（KPI）	（例：夜間帯（21時〜2時）の平均セッション時間：10%向上）
ガードレール指標	（例：画面表示速度・クラッシュ率を悪化させないこと）

ユーザーストーリー

#	ストーリー	優先度
1	ユーザーとして、設定画面からダークモードに切り替えたい。夜間に目の負担を減らすためだ	Must
2	ユーザーとして、OSの設定に自動で追従してほしい。手動で切り替える手間を省くためだ	Should
3	ユーザーとして、時間帯で自動切り替えしたい。日中と夜間で最適な表示にするためだ	Could

要求事項

#	要求	種別	優先度
1	設定画面に「ライト／ダーク／OS設定に従う」の3択を追加する	機能要求	Must
2	全画面・全コンポーネントがダークモードに対応する	機能要求	Must
3	モード切り替えは即時反映され、再起動を必要としない	非機能要求	Must
4	切り替え時の画面ちらつきを発生させない	非機能要求	Should
5	WCAG AAのコントラスト比を維持する	非機能要求	Must

スコープ外・前提条件

区分	内容
スコープ外1	（例：Webブラウザ版の対応は本PRDに含まない（モバイルアプリのみ））
スコープ外2	（例：ユーザー定義のカスタムテーマ機能は対象外とする）
前提条件1	（例：デザインシステムのカラートークン化が完了していること）
依存関係	（例：デザインチームのダークモード用パレット納品（6月末）に依存する）

リリース計画

フェーズ	内容	時期
フェーズ1	社内ベータ（全社員対象）	2026年8月上旬
フェーズ2	段階的リリース（ユーザーの10%→50%）	2026年8月下旬
フェーズ3	全体リリース＋効果測定開始	2026年9月上旬

英語版テンプレート（コピペOK）

Document Info

Field	Value
Feature / Product Name	(e.g., Dark Mode Support)
Version	v1.0
Author (PM)	(Name / Role)
Reviewers	(e.g., Engineering Lead, Design Lead)
Created Date	YYYY-MM-DD
Last Updated	YYYY-MM-DD
Status	Draft / In Review / Approved

Problem Statement

Item	Details
Problem	(e.g., We receive 50+ requests per month from nighttime users saying the screen is too bright.)
Supporting Data	(e.g., 38% of users are active after 9 PM. 72% requested dark mode in our survey.)
Cost of Inaction	(e.g., Three competitors already support dark mode, and “eye strain” ranks high among churn reasons.)

Goals & Success Metrics

Item	Details
Goal	(e.g., Improve the nighttime experience and increase retention.)
Success Metric 1 (KPI)	(e.g., Dark mode adoption: 30%+ within 3 months of release.)
Success Metric 2 (KPI)	(e.g., Average session length during 9 PM–2 AM: +10%.)
Guardrail Metrics	(e.g., No regression in rendering speed or crash rate.)

User Stories

#	Story	Priority
1	As a user, I want to switch to dark mode in settings, so that I can reduce eye strain at night.	Must
2	As a user, I want the app to follow my OS theme automatically, so that I don’t have to switch manually.	Should
3	As a user, I want scheduled switching by time of day, so that I get the best display day and night.	Could

Requirements

#	Requirement	Type	Priority
1	Add a three-option setting: Light / Dark / Follow OS.	Functional	Must
2	All screens and components must support dark mode.	Functional	Must
3	Theme changes apply instantly without requiring a restart.	Non-functional	Must
4	No screen flicker during theme switching.	Non-functional	Should
5	Maintain WCAG AA contrast ratios.	Non-functional	Must

Out of Scope & Assumptions

Category	Details
Out of Scope 1	(e.g., Web browser version is not covered by this PRD (mobile apps only).)
Out of Scope 2	(e.g., User-defined custom themes are out of scope.)
Assumption 1	(e.g., Design system color tokens are already in place.)
Dependency	(e.g., Depends on the design team delivering the dark palette by end of June.)

Release Plan

Phase	Details	Timing
Phase 1	Internal beta (all employees).	Early August 2026
Phase 2	Gradual rollout (10% → 50% of users).	Late August 2026
Phase 3	Full release + impact measurement.	Early September 2026

各セクションの書き方と例文

テンプレートを埋めるときに悩みやすいセクションを解説する。

Problem Statement（課題）の書き方

課題は「データ＋ユーザーの声」で裏付ける。解決策を先に書かず、課題の深刻さを事実で示すことで、関係者の合意形成がスムーズになる。

日本語	英語
ユーザーから月50件以上の要望があります	We receive 50+ user requests per month.
データによると〇〇です	The data shows that [fact].
この課題を放置すると〇〇のリスクがあります	If left unaddressed, we risk [consequence].
競合はすでに対応済みです	Competitors already support this.
解約理由の上位に入っています	This ranks high among churn reasons.

成功指標の書き方

指標は「何を・いつまでに・どのレベルまで」をセットで定義する。さらにガードレール指標（悪化させてはいけない指標）を添えると、リリース判断の基準が明確になる。

日本語	英語
利用率30%以上を目標とします	We target an adoption rate of 30% or higher.
リリース3か月後に効果測定します	We will measure impact 3 months after release.
〇〇を悪化させないことを条件とします	[Metric] must not regress.
この指標で成功と判断します	We will consider this successful if [criteria].
指標が未達の場合はロールバックします	We will roll back if the metrics fall short.

プロダクトの方向性を示すロードマップは英語技術ロードマップの書き方でも確認してほしい。

PRDでよく使う英語表現

実務でよく使う英語表現を場面別にまとめた。

PRD・プロダクト開発の基本用語

日本語	英語
プロダクト要求仕様書	Product Requirements Document (PRD)
ビジネス要件定義書	Business Requirements Document (BRD)
ユーザーストーリー	User Story
受け入れ基準	Acceptance Criteria
成功指標	Success Metrics
ガードレール指標	Guardrail Metrics
段階的リリース	Gradual Rollout / Phased Release
機能フラグ	Feature Flag
優先度（必須／推奨／任意）	Priority (Must / Should / Could)

レビュー・合意形成のフレーズ

日本語	英語
PRDのレビューをお願いします	Could you review the PRD?
この要求の優先度を確認させてください	Let me confirm the priority of this requirement.
スコープ外として明記しました	I’ve explicitly marked this as out of scope.
エンジニアリングの観点で実現可能ですか	Is this feasible from an engineering perspective?
この仕様で開発を開始できます	We can start development with this spec.