PRD作成スキル
このスキルは、高品質なプロダクト要求定義書(PRD)を作成するための詳細ガイドです。
前提条件
PRD作成を開始する前に、以下が完了している必要があります:
アイデアの壁打ちが完了している
プロダクトのアイデアについて、ユーザー自身がClaude Codeとの対話を通じてブラッシュアップを完了している必要があります。
docs/ideas/initial-requirements.md が作成されている
重要: 壁打ちの内容は、ユーザーが以下のファイルに保存する必要があります:
ファイルパス: docs/ideas/initial-requirements.md
このファイルには以下の内容が含まれている必要があります:
- •プロダクトの基本的なアイデア
- •解決したい課題
- •ターゲットユーザーの概要
- •実装したい主要機能
- •MVPの範囲
PRD作成時には、このファイルの内容を参照して詳細化を行います。
既存ドキュメントの優先順位
重要: docs/product-requirements.md に既存のPRDがある場合、
以下の優先順位に従ってください:
- •
既存のPRD (
docs/product-requirements.md) - 最優先- •プロジェクト固有の要件が記載されている
- •このスキルのガイドより優先する
- •
このスキルのガイド - 参考資料
- •汎用的なテンプレートと例
- •既存PRDがない場合、または補足として使用
新規作成時: このスキルのテンプレートとガイドを参照 更新時: 既存PRDの構造と内容を維持しながら更新
出力先
作成したPRDは以下に保存してください:
docs/product-requirements.md
テンプレートの参照
PRDを作成する際は、次のテンプレートを使用してください: ./template.md
PRD作成プロセス
1. initial-requirements.md の確認
まず、ユーザーが作成した初期要求仕様を確認します:
Read('docs/ideas/initial-requirements.md')
2. PRDドラフトの生成
initial-requirements.mdの内容をもとに、テンプレートに従ってPRDを生成します。
3. PRDのレビューと改善
生成されたPRDを以下の観点でレビューします:
レビュー観点
- •プロダクトビジョンは明確か
- •ターゲットユーザーは具体的か
- •機能要件は実装可能なレベルまで詳細化されているか
- •非機能要件(パフォーマンス、ユーザビリティ、信頼性、セキュリティ、スケーラビリティ)は網羅されているか
レビュー結果の評価基準
生成したPRDは以下の形式で評価します:
✅ 強み
- •明確なビジョンが測定可能で具体的に記述されている
- •機能仕様が実装レベルまで詳細化されている
⚠️ 改善が必要な点
機能要件の曖昧さ:
- •問題: 具体的な実装仕様が不明確な箇所がある
- •推奨: 具体的なコマンド仕様やエラーハンドリングを明記
4. レビュー後の改善
レビューで指摘された問題を一つずつ確認し、具体化が必要な箇所を改善します:
- •指摘された問題を一つずつ確認
- •具体化が必要な箇所を改善
- •改善後、再度レビューを実施
- •問題がなくなるまで繰り返す
注意点:
- •AIのレビューを鵜呑みにせず、最終的な判断は必ず人間が行う
- •レビュー観点は明確に指定する
- •改善提案の妥当性を人間が検証する
PRD作成の重要なポイント
1. 具体性と測定可能性
すべての要件は具体的で測定可能でなければなりません。
悪い例:
- •システムは高速である必要がある
良い例:
- •コマンド実行時間: 100ms以内(平均的なPC環境で)
2. 優先順位の明確化
すべての機能に優先度を設定します:
- •P0(必須): MVP(Minimum Viable Product)に含める機能。これがないとプロダクトとして成立しない
- •P1(重要): 初期リリース後すぐに追加すべき機能
- •P2(できれば): 将来的に追加を検討する機能
PRDの主要セクション詳細
1. プロダクト概要
構成要素
- •名称: プロダクト名とサブタイトル
- •プロダクトコンセプト: 3つの主要コンセプト
- •プロダクトビジョン: 目指す世界観を3-5文で
- •目的: 具体的な目的のリスト
例
### 名称 **暗号鍵管理サービス** ### プロダクトコンセプト - ユーザー(クライアントシステムやマイクロサービス)が自身で暗号鍵を生成、管理する必要がなくなる - 暗号鍵はユーザー別に世代管理され、新たな世代鍵の追加や過去世代の鍵の照会を行うことができる - 本サービスで保管する暗号鍵は鍵暗号鍵によって暗号化した上で保管される - 暗号鍵管理に関する要件はPCIDSSv4.0.0以上に準拠する ### プロダクトビジョン - APIによる操作に加えて、CLIによる操作も可能にする
具体的な価値提案を含める
悪い例:
便利な暗号鍵管理ツールを作る
良い例:
クライアントが自身で暗号鍵の生成及び保管による負担から開放される 提供する価値: - ユーザー別の暗号鍵の生成と世代別の保管 - APIとCLIによる操作
2. ターゲットユーザー
クライアントの特定
以下いずれかから選択する
- •社内の別マイクロサービスからのみ利用される
- •社外の顧客システムから利用される
- •社内・社外のシステムから利用される
例
### クライアント: 社内の別マイクロサービス
3. 機能要件
コア機能(MVP)
各機能には以下を含めます:
- •ユーザーストーリー
- •受け入れ条件(チェックリスト形式)
- •優先度(P0/P1/P2)
フォーマット:
### [機能名] ユーザーストーリー: [ユーザー]として、[目的]のために、[機能]が欲しい 受け入れ条件: - [ ] 条件1(測定可能) - [ ] 条件2(測定可能) 優先度: P0(必須) / P1(重要) / P2(できれば)
4. 非機能要件
測定可能な形で記述します:
例:
### パフォーマンス - コマンド実行時間: 1000ms以内 - APIレスポンス: 1000ms以内 ### ユーザビリティ - APIのインタフェース仕様について、ユーザーが容易に把握できる - CLIの場合、ヘルプコマンドで全機能を確認できる ### 信頼性 - エラー発生時のロールバック
品質基準とチェックポイント
PRDの品質を確保するため、以下のチェックポイントを確認してください:
ビジョンと目標
- • プロダクトビジョンが明確で測定可能か
- • 提供する具体的な価値が定義されているか
ターゲットユーザー
- • クライアントの特定ができているか
- • 現在の課題と期待する解決策が明確か
機能要件
- • すべての機能がユーザーストーリー形式で記述されているか
- • 受け入れ条件が測定可能な形で定義されているか
- • 優先度(P0/P1/P2)が明確に設定されているか
非機能要件
- • パフォーマンス基準が具体的な数値で定義されているか
- • ユーザビリティ基準が測定可能か
- • 信頼性とセキュリティ要件が明確か
まとめ
PRD作成の成功のポイント:
- •initial-requirements.md をベースに作成: ユーザーが作成した壁打ち内容を参照
- •具体性と測定可能性: すべての要件を明確に
- •ユーザー中心: ユーザーの課題を解決する機能のみ
- •優先順位の明確化: P0/P1/P2で分類
- •レビューと改善: 自己レビューと人間による最終判断