prd-generator

PRD ジェネレーター

概要

業界のベストプラクティスに沿った、包括的で構成の整った製品要件定義書（PRD）を生成します。このスキルは、プロダクトマネージャーが明確で実行可能な要件定義書を作成し、関係者の足並みをそろえて開発チームを導くのに役立ちます。

基本的なワークフロー

ユーザーから PRD の作成を依頼された場合（例：「ユーザー認証機能の PRD を作成して」）、次のワークフローに従います。

ステップ 1：背景情報の収集

PRD を生成する前に、ヒアリングを通じて必要な情報を収集します。

必須情報：

• 機能／製品名：何を開発しますか？
• 問題の説明：どのような問題を解決しますか？
• 対象ユーザー：誰を対象としていますか？
• ビジネス目標：何を達成しようとしていますか？
• 成功指標：成功をどのように測定しますか？
• スケジュール／制約：期限や制限はありますか？

確認する質問：

1. What problem are you trying to solve?
2. Who is the primary user/audience for this feature?
3. What are the key business objectives?
4. Are there any technical constraints we should be aware of?
5. What does success look like? How will you measure it?
6. What's the timeline for this feature?
7. What's explicitly out of scope?

**注：**ユーザーが詳細な概要や要件をあらかじめ提示している場合は、一部の質問を省略できます。重要な情報が不足している場合は、必ず確認してください。

ステップ 2：PRD の構成を作成

references/prd_template.md の標準 PRD テンプレートを使用して、構成の整った文書を作成します。PRD には次の内容を含めます。

1. エグゼクティブサマリー - 概要（2～3 段落）
2. 問題の説明 - 問題を明確に説明
3. 目標と目的 - 達成しようとしていること
4. ユーザーペルソナ - 対象とするユーザー
5. ユーザーストーリーと要件 - 詳細な機能要件
6. 成功指標 - KPI と測定基準
7. スコープ - 対象範囲と対象外の範囲
8. 技術的な考慮事項 - アーキテクチャ、依存関係、制約
9. デザインと UX の要件 - UI／UX に関する考慮事項
10. スケジュールとマイルストーン - 主要な日程とフェーズ
11. リスクと軽減策 - 想定される問題と解決策
12. 依存関係と前提条件 - 依拠する事項
13. 未解決の質問 - 未解決の項目

ステップ 3：ユーザーストーリーの作成

主要な要件ごとに、標準形式を使用してユーザーストーリーを作成します。

As a [user type],
I want to [action],
So that [benefit/value].

Acceptance Criteria:
- [Specific, testable criterion 1]
- [Specific, testable criterion 2]
- [Specific, testable criterion 3]

一般的なパターンとベストプラクティスについては、references/user_story_examples.md を参照してください。

ステップ 4：成功指標の定義

製品の種類に応じて、適切な指標フレームワークを使用します。

• AARRR（海賊指標）：獲得、活性化、継続、収益、紹介
• HEART フレームワーク：満足度、エンゲージメント、導入、継続、タスクの成功
• ノーススターメトリック：中核的な価値を表す単一の主要指標
• OKR：目標と主要な成果

各フレームワークの詳しいガイダンスについては、references/metrics_frameworks.md を参照してください。

ステップ 5：検証とレビュー

必要に応じて検証スクリプトを実行し、PRD に不足がないことを確認します。

scripts/validate_prd.sh <prd_file.md>

次の項目を確認します。

• 必須セクションがすべて含まれている
• ユーザーストーリーが適切な形式に従っている
• 成功指標が定義されている
• スコープが明確に説明されている
• プレースホルダーテキストが残っていない

使用パターン

パターン 1：新機能の PRD

ユーザーの依頼：「モバイルアプリにダークモードを追加する PRD を作成して」

実行手順：

1. ダークモードの要件について確認する
2. テンプレートを使用して PRD を生成する
3. 次の項目についてユーザーストーリーを作成する。
   • テーマの切り替え
   • 設定の保持
   • システムレベルでの同期
   • デザイントークンの更新
4. 成功指標（導入率、ユーザー満足度）を定義する
5. 技術的な依存関係（デザインシステム、プラットフォーム API）を特定する

パターン 2：製品改善の PRD

ユーザーの依頼：「検索機能を改善するための要件を書いて」

実行手順：

1. 現在の検索機能の制約について背景情報を収集する
2. ユーザーの課題と望まれる改善点を特定する
3. 次の項目を重視して PRD を生成する。
   • 現状分析
   • 提案する改善内容
   • 影響評価
4. 優先順位を付けたユーザーストーリーを作成する
5. 改善前と改善後の指標を定義する

パターン 3：新製品の PRD

ユーザーのリクエスト：「新しい分析ダッシュボード製品の PRD が必要です」

実行内容：

1. 包括的なディスカバリー（市場分析、ユーザー調査）
2. 以下を含む完全な PRD を作成します：
   • 市場機会
   • 競合分析
   • 製品ビジョン
   • MVP の範囲
   • 市場投入に関する考慮事項
3. 主要機能の詳細なユーザーストーリー
4. 段階的なロールアウト計画
5. ビジネス目標に沿った成功指標

パターン 4：簡易 PRD／ワンページャー

ユーザーのリクエスト：「小規模なバグ修正機能の簡潔な PRD を作成してください」

実行内容：

1. 以下に焦点を当てた簡易 PRD を作成します：
   • 問題の説明
   • 解決策のアプローチ
   • 受け入れ基準
   • 成功指標
2. 小規模な範囲に関係のないセクションは省略します
3. ドキュメントを簡潔にまとめます（1～2 ページ）

PRD 作成のベストプラクティス

要件の品質基準

優れた要件の条件：

• 具体的であること：明確で曖昧さがない
• 測定可能であること：検証またはテストが可能
• 達成可能であること：技術的に実現可能
• 関連性があること：ユーザーまたはビジネスの価値に結び付いている
• 期限が明確であること：明確なスケジュールがある

避けるべきこと：

• 曖昧な表現（「速い」「簡単」「直感的」）
• 実装の詳細（実現方法はエンジニアに委ねます）
• 機能の肥大化（主要な要件に絞ります）
• 検証されていない前提

ユーザーストーリー作成のベストプラクティス

すべきこと：

• 機能ではなく、ユーザーの価値に焦点を当てる
• ユーザーの視点から書く
• 明確な受け入れ基準を含める
• ストーリーを独立した小さな単位にする
• 一貫した形式を使う

すべきでないこと：

• 技術的な実装の詳細を書く
• ストーリー間に依存関係を作る
• ストーリーを大きくしすぎる（エピックにする）
• 内部向けの専門用語を使う
• 受け入れ基準を省略する

スコープ管理

対象範囲セクション：

• 含まれる具体的な機能や能力を列挙します
• 明示的かつ詳細に記述します
• ユーザーストーリーへのリンクを記載します

対象外範囲セクション：

• 含まれない項目を明示します
• スコープの肥大化を防ぎます
• ステークホルダーの期待を管理します
• 「将来の検討事項」を含めることもできます

成功指標のガイドライン

次の条件を満たす指標を選びます：

• ビジネス目標に沿っている
• 測定および追跡できる
• 明確な目標値やしきい値がある
• 先行指標と遅行指標の両方を含む
• ユーザーとビジネスの価値を考慮している

一般的な指標のカテゴリ：

• 導入：その機能を利用するユーザーは何人か？
• エンゲージメント：どのくらいの頻度で利用されるか？
• 満足度：ユーザーはその機能を気に入っているか？
• パフォーマンス：適切に動作するか？
• ビジネスへの影響：ビジネス目標の達成につながるか？

高度な機能

コンテキスト別の PRD テンプレート

このスキルは、さまざまな形式の PRD に対応しています：

標準 PRD - 包括的な完全版ドキュメント
リーン PRD - アジャイルチーム向けに簡潔化
ワンページャー - エグゼクティブサマリー形式
技術 PRD - エンジニアリングに重点を置いた要件
デザイン PRD - UX/UI に重点を置いた要件

リクエスト時に形式を指定します：「リーン PRD を作成してください……」または「技術 PRD を生成してください……」

デザインとの連携

デザイン要件セクションに含める項目：

• ビジュアルデザインの要件
• インタラクションパターン
• アクセシビリティ要件（WCAG 準拠）
• レスポンシブデザインに関する考慮事項
• 使用するデザインシステムのコンポーネント
• ユーザーフロー図
• ワイヤーフレームやモックアップへの参照

技術的な考慮事項セクション

次の項目を扱います：

• アーキテクチャ：技術的なアプローチの概要
• 依存関係：外部サービス、ライブラリ、API
• セキュリティ：認証、認可、データ保護
• パフォーマンス：読み込み時間、スケーラビリティ要件
• 互換性：ブラウザー、デバイス、プラットフォームのサポート
• データ：ストレージ、移行、プライバシーに関する考慮事項
• 統合：既存システムとの連携方法

ステークホルダーとの合意形成

PRD が果たす役割：

• 部門横断チームの足並みをそろえる
• 明確な期待値を設定する
• 並行する作業ストリームを可能にする
• 意思決定を促進する
• 信頼できる唯一の情報源を提供する

配布チェックリスト：

• エンジニアリングチームが技術的な実現可能性を確認した
• デザインチームが UX 要件を確認した
• プロダクト部門のリーダーがスコープを承認した
• ステークホルダーがスケジュールを理解している
• 成功指標について合意した

よくある PRD のシナリオ

シナリオ 1：顧客からの機能リクエスト

顧客からのフィードバックをもとに PRD を作成する場合：

1. 顧客のリクエストをそのまま記録する
2. 根底にある課題を分析する
3. すべてのユーザーに向けた解決策として一般化する
4. プロダクト戦略との整合性を確認する
5. 適切なスコープにする（リクエストより小さく、または大きくなる場合があります）

シナリオ 2：戦略的な取り組み

会社の戦略的な取り組みに関する PRD を作成する場合：

1. 会社の OKR／目標に関連付ける
2. 市場分析を含める
3. 競争環境を考慮する
4. 複数段階での展開を検討する
5. 戦略に沿った成功基準を含める

シナリオ 3：技術的負債／インフラストラクチャ

技術的な改善に関する PRD を作成する場合：

1. （間接的な影響であっても）ユーザーへの影響を説明する
2. 現在の制約を記録する
3. メリット（速度、信頼性、保守性）を明確にする
4. エンジニアリングチームから十分に意見を取り入れる
5. 測定可能な改善を定義する

シナリオ 4：コンプライアンス／規制

コンプライアンス要件に関する PRD を作成する場合：

1. 関連する規制（GDPR、HIPAA など）を参照する
2. 法務／コンプライアンス部門によるレビューを含める
3. 通常、期限の変更はできません
4. 最小限の実用的なコンプライアンスに重点を置く
5. 監査証跡の要件を記録する

検証と品質チェック

自己レビュー用チェックリスト

PRD を完成させる前に、以下を確認してください。

• 課題が明確である：誰でも解決しようとしていることを理解できる
• ユーザーが特定されている：誰を対象としているかがわかっている
• 成功を測定できる：うまくいったかどうかを判断できる
• スコープが明確に定められている：対象範囲と対象外が明確である
• 要件をテストできる：QA が完了を検証できる
• スケジュールが現実的である：見積もりをエンジニアリングチームと確認している
• リスクが特定されている：起こりうる問題を検討している
• ステークホルダーの認識がそろっている：主要な関係者がレビューし、承認している

検証スクリプトの使用

# Basic validation
scripts/validate_prd.sh my_prd.md

# Verbose output with suggestions
scripts/validate_prd.sh my_prd.md --verbose

# Check specific sections only
scripts/validate_prd.sh my_prd.md --sections "user-stories,metrics"

リソース

このスキルには、以下のリソースが含まれています。

scripts/

• generate_prd.sh - 対話形式で PRD を生成するワークフロー
• validate_prd.sh - PRD の完全性と品質を検証します

references/

• prd_template.md - 標準的な PRD テンプレートの構成
• user_story_examples.md - ユーザーストーリーのパターンと例
• metrics_frameworks.md - PM 指標（AARRR、HEART、OKR）のガイド

プロダクトマネージャー向けのヒント

PRD の作成前

1. 調査する：ユーザーインタビュー、データ分析、競合分析を行う
2. 課題を検証する：解決する価値があることを確認する
3. 戦略との整合性を確認する：ロードマップに合っているか
4. 工数を見積もる：エンジニアリングチームと大まかな T シャツサイズを見積もる
5. 代替案を検討する：これが最善の解決策か

PRD の作成中

1. 巧みさより明確さを優先する：シンプルな表現が効果的です
2. 説明するより見せる：例、モックアップ、図を使う
3. エッジケースを考える：何が問題になる可能性があるか
4. 徹底的に優先順位を付ける：MVP に含めるものと、あれば望ましいものは何か
5. 早い段階から協力する：一人で進めない

PRD の完成後

1. ステークホルダーとレビューする：早い段階でフィードバックを得る
2. 意見をもとに改善する：PRD は更新し続けるドキュメントです
3. 共有するだけでなく説明する：PRD の内容を順に説明する
4. 正式な承認を得る：コミットメントを確実にする
5. 最新の状態に保つ：理解が深まるにつれて内容を調整する

例

例 1：モバイル機能の PRD

# User: "Create a PRD for adding biometric authentication to our iOS app"

# Assistant will:
# 1. Ask discovery questions about security requirements, user personas, existing auth
# 2. Generate PRD covering:
#    - Problem: Password friction, security concerns
#    - Solution: Face ID / Touch ID integration
#    - User stories: Enable biometric, fallback to password, settings management
#    - Metrics: Adoption rate, login success rate, support tickets
#    - Technical: iOS Keychain, LocalAuthentication framework
#    - Risks: Device compatibility, user privacy concerns
# 3. Output formatted markdown PRD

例 2：ウェブプラットフォームの機能強化

# User: "Write requirements for improving our checkout flow conversion"

# Assistant will:
# 1. Gather data on current conversion rates and drop-off points
# 2. Generate PRD including:
#    - Current state analysis with metrics
#    - Proposed improvements (guest checkout, saved payment, progress indicator)
#    - A/B test plan
#    - Success metrics: Conversion rate increase, time to checkout
#    - User stories for each improvement
# 3. Include phased rollout approach

例 3：B2B プロダクトの PRD

# User: "I need a PRD for an admin dashboard for enterprise customers"

# Assistant will:
# 1. Identify B2B-specific requirements (multi-tenancy, permissions, reporting)
# 2. Generate comprehensive PRD with:
#    - Enterprise user personas (admin, manager, analyst)
#    - Role-based access control requirements
#    - Reporting and analytics needs
#    - Integration requirements (SSO, SCIM)
#    - Success metrics: Customer adoption, admin efficiency
# 3. Include enterprise-specific considerations (compliance, SLAs)

トラブルシューティング

問題：PRDが長すぎる、または詳細すぎる

解決策：「簡潔なPRD」を作成し、課題、解決策、受け入れ基準、指標に焦点を当てます。完全版のPRDは、大規模な取り組みのために用意します。

問題：要件が曖昧すぎる

解決策：具体例を追加し、具体的な数値を使い、視覚的な参照資料を含めます。「高速」ではなく、「2秒未満で読み込まれる」とします。

問題：ステークホルダー間で認識が揃っていない

解決策：PRDを早い段階でドラフトとして共有し、フィードバックを取り入れ、対面で説明し、開発開始前に明確な承認を得ます。

問題：スコープが拡大し続ける

解決策：「対象外」セクションを積極的に活用し、今後のフェーズについては個別のPRDを作成し、スコープをスケジュールの制約に合わせます。

問題：エンジニアから実現不可能だと言われる

解決策：プロセスの早い段階でエンジニアを巻き込み、解決策の進め方には柔軟性を持たせ、実装ではなく課題に焦点を当てます。

ベストプラクティスのまとめ

1. 解決策ではなく、課題から始める
2. 対象読者に合わせて書く（経営陣には要約、エンジニアには詳細が必要です）
3. 具体的かつ測定可能にする（曖昧な表現を避けます）
4. 視覚資料を含める（モックアップ、図、フロー）
5. 成功の基準をあらかじめ定める（機能ではなく指標）
6. スコープを厳しく絞る（MVPの考え方）
7. 一方的に指示するのではなく、協力する（すべての部門から意見を集めます）
8. 常に最新の状態に保つ（PRDは継続的に更新するドキュメントです）
9. 「どのように」ではなく、「なぜ」と「何を」に焦点を当てる（「どのように」はエンジニアに任せます）
10. ざっと読めるようにする（見出し、箇条書き、要約を使います）