カテゴリー 4：ビジネス＆プロダクティビティ 5 / 6
初級 Guide 23 Business Product Requirements

プロダクト要件ドキュメント

Claudeで構造化されたPRDを作成 — ユーザーストーリー、受入基準、技術要件、成功指標。

2026年3月25日 10 min read

学べること

  • 大まかな機能のアイデアから完全で構造化されたPRDを素早く草稿するClaudeの活用方法
  • エンジニアが実装できる適切な受入基準を持つユーザーストーリーの書き方
  • スコープクリープと曖昧さを防ぐ成功指標とエッジケースの定義方法

ユースケース

プロダクト要件ドキュメント（PRD）はプロダクトマネージャーとエンジニアリングチームの間の契約です。曖昧または不完全な場合、エンジニアは間違ったものを構築し、QAは重要なケースを見落とし、明確化のサイクルのためにローンチが遅れます。徹底的で正確な場合、チームは自信を持って速く動けます。

課題は、良いPRDを書くには大きな時間がかかることです——問題の空間の調査、ステークホルダーへのインタビュー、エッジケースの考慮、プロダクトの思考をエンジニアリング対応の仕様に翻訳する作業です。ほとんどのPMは同時にロードマップ、ステークホルダーミーティング、スプリントセレモニーを管理しながらこれを行っています。

Claudeはこのプロセスを劇的に加速します。あなたはプロダクトの思考——ユーザーのインサイト、ビジネスの根拠、優先事項——を持ち込みます。Claudeは構造的な厳密さ——完全なユーザーストーリー形式、受入基準チェックリスト、答えが必要な技術的な質問、成功指標フレームワーク——を持ち込みます。結果は約30分で、シニアPMが4〜6時間かかる最初の草稿です。

これは新機能のPRD、リデザインの仕様、外部開発者向けのAPIドキュメント、内部ツールの要件に適用されます。

ステップバイステップガイド

ステップ1：解決策ではなく問題から始める

最も一般的なPRDの間違いは、問題を明確に表現する前に解決策（「Xを構築したい」）から始めることです。Claudeに最初に問題ステートメントを書くのを助けるよう依頼しましょう。これが文書全体を固定します。

プロンプト：

「新しい機能のPRDを書きたいです。私たちが解決している問題は：[2〜3文でユーザーの問題を説明]です。影響を受けるユーザーは[ペルソナを説明——役職、達成しようとしていること、現在の回避策]です。1〜2段落で「誰が、何を、なぜ」を捉えたクリスプな問題ステートメントを書くのを助けてください。」

これはまた有価値なアラインメントツールにもなります——問題ステートメントがエンジニアリングリードやデザインパートナーに共鳴しなければ、単一の要件を書く前にその不一致を解決すべきです。

ステップ2：受入基準を持つユーザーストーリーを生成する

問題が明確になったら、Claudeは適切に構造化されたユーザーストーリーに翻訳するのを助けることができます。標準形式は：「[ペルソナ]として、[アクション]したい、それにより[利益]」です。しかし本当の価値は受入基準にあります——ストーリーが完了したと見なされるために真でなければならない特定の条件です。

プロンプト：

「この問題ステートメントに基づいて、この機能のための5〜7のユーザーストーリーを書いてください。各ストーリーについて：

  • 『As a / I want / So that』形式を使う
  • Gherkin形式（Given / When / Then）の3〜5の受入基準を書く
  • 各ストーリーにmust-have、should-have、nice-to-haveのタグを付ける（MoSCoW優先順位付け）
  • 大きすぎてサブストーリーに分解すべきストーリーにフラグを立てる」

Claudeは適切な粒度レベルでストーリーを返し、分解が必要なエピックにフラグを立てます——ジュニアPMが直感的に発達させるのに年数がかかるスキルです。

ステップ3：機能的および非機能的要件を定義する

ユーザーストーリーを超えて、完全なPRDは機能的要件（システムが何をしなければならないか）と非機能的要件（どれほどうまくしなければならないか——パフォーマンス、セキュリティ、アクセシビリティ、スケーラビリティ）を捉えます。

プロンプト：

「これらのユーザーストーリーに基づいて、以下を生成してください：

  1. 機能的要件の番号付きリスト（存在しなければならないシステムの動作）
  2. 非機能的要件のリスト——パフォーマンスベンチマーク（例：X秒以内のページロード）、アクセシビリティ基準（WCAG 2.1 AA）、セキュリティ要件（認証、データ処理）、スケーラビリティの期待を含む
  3. この機能が外部システムに触れる場合のAPIまたは統合要件
  4. データ要件——何のデータを保存する必要があるか、どのくらいの期間、どのようなアクセス制御で」

このセクションはしばしば最も軽視され、実装で問題を引き起こす可能性が最も高いです。Claudeは指定しなかった要件を表面化します。

ステップ4：成功指標と測定計画を定義する

成功指標のない要件は目標ではなく希望です。構築するすべての機能について、問題を解決したかどうかをどのように測定するかを知っておくべきです。

プロンプト：

「この機能の成功指標を定義するのを助けてください。ビジネス目標は[リテンションの増加 / 解約の削減 / エンゲージメントの増加 / サポート量の削減など]です。追跡すべき主要、二次、ガードレール指標は何ですか？採用をどのように測定しますか？ローンチ後30日、90日、6ヶ月で成功はどのように見えますか？測定フレームワーク表としてフォーマットしてください。」

Claudeは階層化された指標構造を提案します——主要指標（ビジネス目標を動かしたか）、二次指標（成功の先行指標）、ガードレール指標（これを出荷したときに悪化してはならないもの）。

ステップ5：エッジケースとオープンクエスチョンを表面化する

PRD作成におけるClaudeの最も価値ある用途の一つは、エンジニアリングが開始する前に解決が必要なエッジケースとオープンクエスチョンを体系的に表面化することです。

プロンプト：

「このPRDの草稿をレビューして、以下を特定してください：

  1. 受入基準でカバーされていないエッジケースとエラー状態
  2. 開発が始まる前にステークホルダーの入力が必要なオープンクエスチョン
  3. 他のチームまたはシステムへの依存関係（データ、プラットフォーム、デザイン、法務、セキュリティ）
  4. 間違っていて要件を変更するかもしれない前提 未解決のままにした場合に問題を引き起こす可能性の高さで優先度順にリストしてください。」

これはシニアエンジニアの「…したときに何が起きるかを考えましたか？」という会話に相当します——しかしスプリントの途中ではなく、スプリントが始まる前に起きます。

プロンプトテンプレート

以下の機能/プロダクトのPRDを書く必要があります：

機能名：[名前]
問題ステートメント：[これはどのユーザーの問題を解決するか？誰が経験するか？現在の回避策は何か？]
ビジネス目標：[何の成果をドライブするか？リテンション、収益、効率などか？]
ターゲットユーザー：[主要なペルソナを説明]
スコープ：[何がスコープ内か？何がスコープ外か？]
既知の制約：[技術的制限、タイムライン、予算、プラットフォーム、コンプライアンス要件]
依存関係：[他のチーム、システム、またはこれが依存する外部要因]

以下を含む完全なPRDを作成してください：
1. 問題ステートメント（2段落）
2. 目標と非目標
3. As a / I want / So that形式の5〜8のユーザーストーリー、各々に：
   - Given / When / Then形式の3〜5の受入基準
   - MoSCoW優先順位付けタグ
4. 機能的要件（番号付きリスト）
5. 非機能的要件（パフォーマンス、アクセシビリティ、セキュリティ、スケーラビリティ）
6. 成功指標表（主要、二次、ガードレール）と測定タイムライン
7. オープンクエスチョンと依存関係
8. 開発が始まる前に定義が必要なエッジケース

NotionまたはConfluenceに貼り付けられる構造化Markdownドキュメントとしてフォーマットしてください。

ヒントとベストプラクティス

  1. Claudeを使って却下する機能のPRDを書く — 機能リクエストを却下するとき、Claudeで1ページの「アンチPRD」を書きましょう：解決する問題、今がなぜ適切な時期ではないか、何の証拠が決定を変えるか。これにより6ヶ月後に同じ会話をすることを防ぎます。

  2. Claudeに各ストーリーの「完了の定義」を書かせる — 受入基準を超えて、ストーリーが閉じる前に確認しなければならない条件のチェックリストを草稿するようClaudeに依頼しましょう：ユニットテストが書かれた、ドキュメントが更新された、アナリティクスイベントが計装された、デザインQAが完了。これがスプリントの品質ゲートになります。

  3. 受入基準からテストケースを生成する — 受入基準を書いた後、Claudeに共有してください：「これらの受入基準をQAテストケースに変換してください、ハッピーパス、ネガティブテスト、エッジケーステストを含む。」QAチームに喜ばれます。

  4. Claudeを使ってリアルタイムでスコープクリープを見つける — 誰かがスプリントの途中で機能に追加することを提案するとき、PRDと新しいリクエストをClaudeに貼り付けて尋ねましょう：「この新しいリクエストは現在のスコープ内に収まりますか？収まる場合、どの受入基準の下に入りますか？収まらない場合、バックログに延期するために使える1段落のメモを草稿してください。」

  5. 「何が間違えるか」セッションを実施する — PRDが完成したら、Claudeに依頼しましょう：「この機能が出荷されて問題を解決できなかった場合、最も可能性の高い3つの理由は何ですか？これらのリスクを減らすためにPRDに今追加できるものは何ですか？」この敵対的なレビューはポストモーテムになる前に問題を見つけます。

試してみよう

現在作業しているまたは計画している機能を取りましょう——フォームの改善やフィルターの追加などの小さなものでも大丈夫です。解決するユーザーの問題の1段落の説明を書きましょう。次にそれを上のプロンプトテンプレートを使ってClaudeに与えて完全なPRDを依頼しましょう。草稿が届いたら、特に「オープンクエスチョン」セクションを見てください。これらの質問のうち、すでに解決したものはいくつありますか？実際の曖昧さを表すものはいくつですか？その比率は実際に構築を開始する準備ができているかどうかを示します。