PRD Generator

概要

業界のベストプラクティスに従う、包括的でよく構造化された製品要件書（PRD）を生成します。このスキルは、製品マネージャーがステークホルダーを調整し、開発チームを導くための明確で実行可能な要件ドキュメントを作成するのに役立ちます。

コアワークフロー

ユーザーがPRD作成をリクエストした場合（例：「ユーザー認証機能のPRDを作成して」）、以下のワークフローに従います。

ステップ 1: コンテキスト情報の収集

PRDを生成する前に、発見型の会話を通じて重要な情報を収集します。

必要な情報：

• 機能/製品名: 何を構築しているのか？
• 問題ステートメント: これは何の問題を解決するのか？
• ターゲットユーザー: これは誰のためか？
• ビジネスゴール: 何を達成しようとしているのか？
• 成功指標: 成功をどのように測定するのか？
• タイムライン/制約: 期限や制限事項はあるか？

発見型の質問：

1. どの問題を解決しようとしていますか？
2. この機能の主なユーザー/対象者は誰ですか？
3. 主要なビジネス目標は何ですか？
4. 認識すべき技術的制約はありますか？
5. 成功とは何か？どのように測定しますか？
6. この機能のタイムラインは？
7. 明確に対象外のことは何ですか？

注記: ユーザーが詳細なブリーフまたは要件を事前に提供した場合、いくつかの質問をスキップできます。常に重要な情報の欠落について明確にするよう求めてください。

ステップ 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: ユーザーストーリーの作成

主要な要件ごとに、標準フォーマットを使用してユーザーストーリーを生成します：

[ユーザータイプ] として、
[アクション] したい。
[利益/価値] のためである。

受け入れ基準:
- [具体的でテスト可能な基準 1]
- [具体的でテスト可能な基準 2]
- [具体的でテスト可能な基準 3]

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

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

製品タイプに応じて、適切なメトリクスフレームワークを使用します：

• AARRR（海賊メトリクス）: 獲得、啓発、保持、収益、紹介
• HEARTフレームワーク: 満足度、エンゲージメント、採用、保持、タスク成功
• North Star Metric: コア価値を表す単一の重要メトリック
• 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が完了を検証できる
• タイムラインが現実的である: 見積もりがエンジニアリングで検証されている
• リスクが特定されている: 何が起こりうるかを考慮している
• ステークホルダーがアライメント済み: 主要な人物がレビューし承認している

検証スクリプトの使用

# 基本的な検証
scripts/validate_prd.sh my_prd.md

# 提案を含む詳細出力
scripts/validate_prd.sh my_prd.md --verbose

# 特定のセクションのみをチェック
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 vs. 持っていると良い
5. 早期にコラボレートする: 孤立して作業しない

PRD完了後

1. ステークホルダーとレビュー: 早期にフィードバックを取得
2. 入力に基づいて反復: PRDはリビングドキュメント
3. 提示して共有しない: PRDを説明して進める
4. 正式な承認を取得: コミットメントを確保
5. それを更新し続ける: 理解が進化するにつれて調整

例

例 1: モバイル機能PRD

# ユーザー: 「iOSアプリにバイオメトリック認証を追加するPRDを作成して」

# アシスタントが実行すること:
# 1. セキュリティ要件、ユーザーペルソナ、既存認証に関する発見型質問を実施
# 2. 以下をカバーするPRDを生成:
#    - 問題: パスワード摩擦、セキュリティ懸念
#    - ソリューション: Face ID / Touch ID統合
#    - ユーザーストーリー: バイオメトリック有効化、パスワードフォールバック、設定管理
#    - メトリクス: 採用率、ログイン成功率、サポートチケット
#    - 技術: iOS Keychain、LocalAuthentication フレームワーク
#    - リスク: デバイス互換性、ユーザープライバシー懸念
# 3. フォーマット化されたMarkdown PRDを出力

例 2: Webプラットフォーム強化

# ユーザー: 「チェックアウトフローのコンバージョンを改善するための要件を書いて」

# アシスタントが実行すること:
# 1. 現在のコンバージョン率とドロップオフポイントに関するデータを収集
# 2. 以下を含むPRDを生成:
#    - 現在の状態分析（メトリクス付き）
#    - 提案される改善（ゲストチェックアウト、保存済み支払い、進捗インジケーター）
#    - A/Bテスト計画
#    - 成功メトリクス: コンバージョン率の増加、チェックアウト時間
#    - 各改善のユーザーストーリー
# 3. フェーズ化されたロールアウトアプローチを含める

例 3: B2B製品PRD

# ユーザー: 「エンタープライズ顧客向けの管理ダッシュボードのPRDが必要です」

# アシスタントが実行すること:
# 1. B2B固有の要件を特定（マルチテナンシー、権限、報告）
# 2. 以下を含む包括的なPRDを生成:
#    - エンタープライズユーザーペルソナ（管理者、マネージャー、アナリスト）
#    - ロールベースアクセス制御要件
#    - 報告および分析ニーズ
#    - 統合要件（SSO、SCIM）
#    - 成功メトリクス: 顧客採用、管理者効率
# 3. エンタープライズ固有の考慮事項を含める（コンプライアンス、SLA）

トラブルシューティング

問題: PRDが長すぎる/詳細すぎる

解決策: 「リーンPRD」を作成し、問題、ソリューション、受け入れ基準、メトリクスに焦点を当てます。主要なイニシアティブ向けの完全なPRDを予約します。

問題: 要件が曖昧すぎる

解決策: 具体的な例を追加し、具体的な数値を使用し、ビジュアルリファレンスを含めます。「高速」を「2秒以下でロード」に置き換えます。

問題: ステークホルダーがアライメント未達

解決策: PRDをドラフトとして早期に共有し、フィードバックを組み込み、直接プレゼンし、開発前に明示的な承認を取得します。

問題: スコープが継続的に拡大している

解決策: 「スコープ外」セクションを積極的に使用し、将来のフェーズ向けに別のPRDを作成し、スコープをタイムライン制約に結びつけます。

問題: エンジニアが実現不可能と言う

解決策: プロセスの早い段階でエンジニアリングを関与させ、ソリューション方法に対して柔軟に、問題の実装ではなく「理由」に焦点を当てます。

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

1. ソリューションではなく問題から始める
2. あなたの聴衆のために書く（経営者は要約が必要、エンジニアは詳細が必要）
3. 具体的で測定可能である（曖昧な言語を避ける）
4. ビジュアルを含める（モックアップ、図、フロー）
5. 成功を事前に定義する（機能ではなくメトリクス）
6. 積極的にスコープする（MVP思考）
7. 指示ではなくコラボレートする（すべての部門から入力を取得）
8. それを更新し続ける（PRDはリビングドキュメント）
9. 「何」と「なぜ」に焦点を当て、「どのように」は焦点を当てない（エンジニアに「どのように」を解決させる）
10. スキャンできるようにする（見出し、箇条書き、要約）