【2025年版】PRD×仕様書（SRS）の接続——“旗”と“地図”の役割分担／移送テンプレと実務

結論：PRDは“旗（価値の定義）”、SRSは“地図（実装の定義）”。この二つを数で結ぶのがプロの仕事です。

朝いちのレビュー。PRDでは「入口→Ahaを3クリック・3分で」と旗を掲げたのに、SRSにはUI遷移やAPI一覧がびっしり。開発は迷い、QAは「どこまでが合格かわからない」。そこで私たちは、PRDの受け入れ基準（AC）を“価値の条文”としてSRSへ移送し、トレーサビリティで固定しました。以後、実装の迷子は消え、検収は短くなる。この記事では、章立て対応→移送テンプレ→非機能の数値化→データコントラクト→テスト設計→会議運用→具体例の順で、明日から使える実務に落とします。

PRDとSRSは何が違うか——“目的の文”と“方法の文”
章立て対応表：PRD→SRSを“機械的に”写す
移送テンプレ：ACをそのままSRSへ落とす
非機能要件を“数で”運ぶ：性能・可用性・セキュリティ
データ契約（API／イベント）：破綻を先に塞ぐ
テスト設計：PRDの“価値”をテストケースに直結
変更管理：v+0.1で両文書を同期
具体例を“読ませる”：PRD→SRSの行間までたどる
会議台本：PRD→SRS接続レビュー（20分）
u-note：意思決定の順路を固定する
1. 関連記事
FAQ

PRDとSRSは何が違うか——“目的の文”と“方法の文”

PRDは「誰の、どの課題に、どんな価値を、どう測って、いつ判断するか」を一文で言い切る旗。SRSは「それを実現するUI／API／データ／制約」を地図として細密に描く文書です。両者が混ざると、価値はぼやけ、地図は厚くなるだけで遅くなります。だから、PRDに書くのは“何を達成するか”、SRSに書くのは“どうやって達成するか”です。

PRD＝価値の定義：Aha／TTV（p50/p95）／D1、AC、スコープ票
SRS＝実装の定義：UIフロー、API仕様、データモデル、非機能（性能・可用性・セキュリティ）
接続＝数で結ぶ：AC→UI要件／API契約／イベント名へ正規に移送

【要点一行】PRDは“なぜ・何を”、SRSは“どう”。接続はACと指標で数値化して行う。

まとめ：役割を分けるほど速くなる。
具体例：PRDのAC「3クリック・3分」をSRSに移すだけで、UI仕様の枝葉議論が消えました。

章立て対応表：PRD→SRSを“機械的に”写す

人の記憶に頼ると漏れます。章立ての対応を表にして、半自動で移送しましょう。こうしておくと、引継ぎや監査でも迷いません。背景説明は短く、数と用語を一致させるのがコツです。

【PRD→SRS 対応表 v1.1】
PRD: 目的（旗） → SRS: 目的・用語集（同一文面を貼付）
PRD: Aha定義     → SRS: 受入条件(AC#A)＋UI完了トースト仕様＋イベント 'achieve_aha'
PRD: TTV定義     → SRS: 起点= view_entry / 終点= achieve_aha の計測仕様
PRD: AC          → SRS: UI要件(クリック数)／フロー図／API前後条件／テストケースID
PRD: スコープ票 → SRS: Must/Should/Won’tの機能一覧（Won’tは非対象章へ）
PRD: 体験フロー → SRS: 画面遷移（最短3ステップ＋分岐は別紙）
PRD: 計測設計   → SRS: イベント名・props・スキーマ・送信タイミング
PRD: リスク検証 → SRS: フラグ・ロールアウト・失敗時リカバリ

まとめ：対応表が“唯一の翻訳機”。
具体例：Ahaイベント名を両文書で統一し、ダッシュボードの揺れが止まりました。

移送テンプレ：ACをそのままSRSへ落とす

「ちゃんと動く」は解釈が割れます。代わりに、PRDのACをSRSに条文化します。これは、価値基準を実装基準へ写経する行為です。文章を変えず、番号を振って参照可能にします。

【AC移送テンプレ v2.0（SRS貼付用）】
AC#A（Aha到達）：入口→Ahaまで最大3クリック（モバイル=2タップ＋スクロール可）
AC#B（時間）：TTV p50 ≤ 3分 / p95 ≤ 7分（起点=view_entry, 終点=achieve_aha）
AC#C（観測）：完了トースト表示と同時に 'achieve_aha' を一意発火（1操作=1イベント）
AC#D（エラー）：同画面で自己解決（戻る遷移なし）

UI要件：
- 完了トースト：文言＿＿／表示時間＿＿／非同期更新はスナック通知で代替不可
- 入力画面：初回は必須2項目まで、詳細は次画面へ段階化

API前後条件：
- POST /teams：201返却時のみトースト表示→イベント発火
- 409/422 時は同画面で解決（AC#D）

テストケース：
- TC-A1：3クリック以内で完了（動画保存）
- TC-A2：achieve_aha 一意発火（DevTool確認）
- TC-A3：TTV p50/p95 の計測ログに記録

まとめ：AC→UI→API→TCを1ブロックにする。
具体例：このテンプレを貼るだけで、QAと計測の会話が同じ用語になりました。

非機能要件を“数で”運ぶ：性能・可用性・セキュリティ

非機能が曖昧だと、最後に事故ります。PRDで“速さ・安定・安全”の期待を示し、SRSでは閾値で締める。これは、価値の体感を守るための最低ラインです。感覚語ではなく、閾値で決めます。

性能：初回描画TTI ≤ 2.5s（4G実測）／操作応答P95 ≤ 200ms
可用性：99.9%（月間）／RPO 1h／RTO 15m
セキュリティ：OWASP Top10対策／PIIは静止時暗号化／監査ログ保持180日

【SRS 非機能セクション例】
Performance: /teams POST→成功トースト表示 ≤ 250ms(P95)
Reliability: Status 5xx 連続3回でサーキット開放（30s）
Security: JWT exp 60m／PIIはKMS暗号化

まとめ：非機能は“p95の体験”を守る装置。
具体例：P95の上限を明文化しただけで、バックエンドの優先度が揃いました。

データ契約（API／イベント）：破綻を先に塞ぐ

PRDで決めたイベント名やAhaの定義は、SRSの“契約”で守ります。なぜかというと、後からの解釈違いは復旧コストが高いからです。APIスキーマとイベントスキーマをSRSに固定し、破壊的変更はフラグ付きでしか出せない運用にします。

【イベント・スキーマ例（SRS貼付）】
event: achieve_aha
props:
  session_length: number (sec)
  steps: integer
emit_timing: UI 完了トースト表示時
idempotent_key: aha_id（1操作=1）

まとめ：名寄せと一意性が“数の信用”を作る。
具体例：idempotent_keyを導入し、Aha率の±6%揺れが消えました。

テスト設計：PRDの“価値”をテストケースに直結

テスト観点が仕様の羅列になると、価値の合否がわかりません。AC番号に結んだテストIDで、PRD→SRS→QAを一本化します。理由は、価値の不合格は実装の合格より重いからです。SRSには、ケース表とログ検証手順を記します。

【テストケース表（抜粋）】
TC-A1（AC#A）：3クリック以内で完了
TC-B1（AC#B）：TTV p95 ≤ 7分（ログ検証）
TC-C1（AC#C）：achieve_aha 一意発火（Networkタブ確認）
TC-D1（AC#D）：エラーは同画面で解決（戻り遷移なし）

まとめ：“価値が通るか”を主語にする。
具体例：ログ検証をケースに入れてから、ローンチ翌日の混乱が無くなりました。

変更管理：v+0.1で両文書を同期

PRDだけ更新、SRSは旧版——これが最悪の事故を生みます。更新は常にペアで。つまり、PRD v+0.1 → SRS v+0.1 → 通知の順で儀式化します。理由は、唯一の真実を二冊で守るためです。

【更新フロー】
PRD v1.3（AC更新）→ SRS v1.3（UI/API/TC更新）→ Slack通知（短文＋リンク）→ ダッシュボード閾値更新

まとめ：片方だけ新しい、を作らない。
具体例：ペア更新に切り替え、仕様解釈の齟齬がゼロに。

具体例を“読ませる”：PRD→SRSの行間までたどる

例1｜プロフィール入力の美化で迷子になる

PRDのAhaは「成果カードの初回表示」。しかしSRSのUI章は入力UIの美化に紙幅が割かれていた。移送後、AC#A/B/CをUI要件に結び、入力は“必須2項目”に制限。結果、p95は8.2→5.9分に短縮。

例2｜Ahaイベントの二重発火で数値が揺れる

SRSにイベントの一意性が無く、別経路でも同名発火。idempotent_keyと発火タイミング（完了トースト同時）を契約化。以後、Aha率は±1%以内で安定。

例3｜SSOを先に入れて道が長くなる

正論だが順番を間違えると遅くなる。SRSのスコープにWon’tを明記し、再審条件を設定。PRDの“3クリック・3分”が守られ、D1が+5〜+8ptで推移。

会議台本：PRD→SRS接続レビュー（20分）

移送が甘いと現場で詰みます。20分で接続だけを見る会議を定例化してください。短時間で済むのは、数字が主語だからです。

0–3分：PRDの旗・Aha・ACを音読
3–10分：対応表と移送テンプレの突合（欠落を赤入れ）
10–16分：非機能・API/イベント契約を確認
16–20分：テストケースIDとダッシュボード閾値を承認

【ひと言で締める】
「今日は“価値の条文が地図へ写っているか”だけを見ます。足りない箇所はSRS v+0.1で即修正。」

u-note：意思決定の順路を固定する

Aha→TTV→翌日活性の順で見ると意思決定が速くなります。詳しくはKPI設計と運用ガイドへ。

FAQ

Q. PRDとSRSを一つにまとめてはダメ？: A. 非推奨。旗と地図は役割が違います。PRDは価値を言い切る“短い文”、SRSは実装を詰める“長い文”。接続はACと指標で行ってください。
Q. OpenAPIや設計図の提示はどの段で？: A. SRSの契約章に置きます。PRDのAha・ACを先に接続してから、OpenAPI/ERDを貼ると迷いません。
Q. 変更が多くSRSが古くなりがち。: A. PRDとSRSをペアでv+0.1。通知は短文＋リンクで儀式化すると、同期が崩れません。

▼有料note（直リンク）