PRD作成スキル

このスキルは、高品質なプロダクト要求定義書(PRD)を作成するための詳細ガイドです。

前提条件

PRD作成を開始する前に、以下が完了している必要があります:

アイデアの壁打ちが完了している

プロダクトのアイデアについて、ユーザー自身がClaude Codeとの対話を通じてブラッシュアップを完了している必要があります。

docs/ideas/initial-requirements.md が作成されている

重要: 壁打ちの内容は、ユーザーが以下のファイルに保存する必要があります:

ファイルパス: docs/ideas/initial-requirements.md

このファイルには以下の内容が含まれている必要があります:

• プロダクトの基本的なアイデア
• 解決したい課題
• ターゲットユーザーの概要
• 実装したい主要機能
• MVPの範囲

PRD作成時には、このファイルの内容を参照して詳細化を行います。

既存ドキュメントの優先順位

重要: docs/product-requirements.md に既存のPRDがある場合、 以下の優先順位に従ってください:

1. 既存のPRD (docs/product-requirements.md) - 最優先
   • プロジェクト固有の要件が記載されている
   • このスキルのガイドより優先する
2. このスキルのガイド - 参考資料
   • 汎用的なテンプレートと例
   • 既存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を以下の観点でレビューします:

レビュー観点

1. プロダクトビジョンは明確か
2. ターゲットユーザーは具体的か
3. 成功指標は測定可能か
4. 機能要件は実装可能なレベルまで詳細化されているか
5. 非機能要件は網羅されているか

レビュー結果の評価基準

生成したPRDは以下の形式で評価します:

✅ 強み

• 明確なビジョンが測定可能で具体的に記述されている
• 機能仕様が実装レベルまで詳細化されている
• KPIが定量的な指標で定義されている

⚠️ 改善が必要な点

機能要件の曖昧さ:

• 問題: 具体的な実装仕様が不明確な箇所がある
• 推奨: 具体的なコマンド仕様やエラーハンドリングを明記

成功指標の測定方法:

• 問題: 測定方法が不明確
• 推奨: 測定方法とプライバシーへの配慮を明記

4. レビュー後の改善

レビューで指摘された問題を一つずつ確認し、具体化が必要な箇所を改善します:

1. 指摘された問題を一つずつ確認
2. 具体化が必要な箇所を改善
3. 改善後、再度レビューを実施
4. 問題がなくなるまで繰り返す

注意点:

• AIのレビューを鵜呑みにせず、最終的な判断は必ず人間が行う
• レビュー観点は明確に指定する
• 改善提案の妥当性を人間が検証する

PRD作成の重要なポイント

1. 具体性と測定可能性

すべての要件は具体的で測定可能でなければなりません。

悪い例:

• システムは高速である必要がある
• ユーザーは使いやすいと感じる

良い例:

• コマンド実行時間: 100ms以内(平均的なPC環境で)
• 新規ユーザーが5分以内に基本操作を習得できる(ユーザビリティテストで測定)

2. ユーザー中心設計

すべての機能は、明確なユーザーの課題を解決するものでなければなりません。

ユーザーストーリーのフォーマット:

[ユーザー]として、[目的]のために、[機能]が欲しい

例:

開発者として、ターミナルから離れずにタスクを管理するために、
CLIベースのタスク管理ツールが欲しい

3. 優先順位の明確化

すべての機能に優先度を設定します:

• P0(必須): MVP(Minimum Viable Product)に含める機能。これがないとプロダクトとして成立しない
• P1(重要): 初期リリース後すぐに追加すべき機能
• P2(できれば): 将来的に追加を検討する機能

PRDの主要セクション詳細

1. プロダクト概要

構成要素

1. 名称: プロダクト名とサブタイトル
2. プロダクトコンセプト: 3つの主要コンセプト
3. プロダクトビジョン: 目指す世界観を3-5文で
4. 目的: 具体的な目的のリスト

例

### 名称
**Devtask** - 開発者向けタスク管理CLIツール

### プロダクトコンセプト
- CLIで完結するタスク管理: ターミナルから離れずにすべての操作を完結
- 優先順位の自動推定機能: タスクの期限、作成日時、ステータス変更履歴などから優先順位を自動推定
- シンプルで高速な操作感: 最小限のキー入力で操作完了、即座のレスポンス

### プロダクトビジョン
開発者がターミナルから離れることなく、効率的にタスクを管理できるCLIツールを提供する。
コマンドラインでの操作に特化し、開発フローを中断させない軽量で高速なタスク管理を実現する。
優先順位の自動推定により、開発者は本質的な作業に集中できる。

具体的な価値提案を含める

悪い例:

便利なタスク管理ツールを作る

良い例:

開発者がターミナルから離れずにタスク管理できるCLIツール。

提供する価値:
- コンテキストスイッチの削減(GUI↔ターミナルの切り替えゼロ)
- 作業効率の向上(マウス操作不要で平均30%の時間短縮)
- 自動化との連携(シェルスクリプトに組み込み可能)

2. ターゲットユーザー(ペルソナ)

必須要素

1. 基本属性: 年齢、職業、経験年数
2. 技術スタック: 使用しているツールや言語
3. 現在の課題: 具体的な痛み点
4. 期待する解決策: どうなりたいか
5. 1日の典型的なワークフロー

例

### プライマリーペルソナ: 田中太郎(29歳、フルスタックエンジニア)
- フリーランスで3-5プロジェクトを並行
- Vim/Emacs + ターミナル環境
- タスク管理に時間をかけたくない
- Markdown、Git、CLIツールを好む

3. 成功指標(KPI)

SMART原則

• Specific(具体的): 何を測定するか明確
• Measurable(測定可能): 数値で測定できる
• Achievable(達成可能): 現実的な目標
• Relevant(関連性): ビジネス目標と関連
• Time-bound(期限): 達成期限を設定

例

### プライマリーKPI
- 日次アクティブユーザー(DAU): 100人(3ヶ月後)
- タスク完了率: 70%以上
- 1日あたりの平均コマンド実行回数: 10回以上

4. 機能要件

コア機能(MVP)

各機能には以下を含めます:

• ユーザーストーリー
• 受け入れ条件(チェックリスト形式)
• 優先度(P0/P1/P2)

フォーマット:

### [機能名]

ユーザーストーリー:
[ユーザー]として、[目的]のために、[機能]が欲しい

受け入れ条件:
- [ ] 条件1(測定可能)
- [ ] 条件2(測定可能)

優先度: P0(必須) / P1(重要) / P2(できれば)

CLIインターフェース

CLIツールの場合、具体的なコマンド例を記載します:

# 基本操作
devtask add "タスク名" --due 2025-01-15 --priority high
devtask list
devtask next  # 今やるべきタスクを表示
devtask done <task-id>
devtask show <task-id>

5. 非機能要件

測定可能な形で記述します:

例:

### パフォーマンス
- コマンド実行時間: 100ms以内(平均的なPC環境で)
- タスク一覧表示: 1000件まで1秒以内

### ユーザビリティ
- 新規ユーザーが5分以内に基本操作を習得できる
- ヘルプコマンドで全機能を確認できる

### 信頼性
- データ損失ゼロ(自動バックアップ)
- エラー発生時のロールバック

品質基準とチェックポイント

PRDの品質を確保するため、以下のチェックポイントを確認してください:

ビジョンと目標

• プロダクトビジョンが明確で測定可能か
• 提供する具体的な価値が定義されているか
• ターゲット市場が明確か

ターゲットユーザー

• ペルソナが具体的に定義されているか
• 現在の課題と期待する解決策が明確か
• 技術スタックと1日のワークフローが記述されているか

成功指標

• SMART原則に従ったKPIが定義されているか
• 測定方法が明確か
• 達成期限が設定されているか

機能要件

• すべての機能がユーザーストーリー形式で記述されているか
• 受け入れ条件が測定可能な形で定義されているか
• 優先度(P0/P1/P2)が明確に設定されているか

非機能要件

• パフォーマンス基準が具体的な数値で定義されているか
• ユーザビリティ基準が測定可能か
• 信頼性とセキュリティ要件が明確か

まとめ

PRD作成の成功のポイント:

1. initial-requirements.md をベースに作成: ユーザーが作成した壁打ち内容を参照
2. 具体性と測定可能性: すべての要件を明確に
3. ユーザー中心: ユーザーの課題を解決する機能のみ
4. 優先順位の明確化: P0/P1/P2で分類
5. レビューと改善: 自己レビューと人間による最終判断
6. SMART原則の適用: 特にKPI定義において重要