prd-authoring

PRD の作成

このスキルでは、以下を含む高品質な製品要件ドキュメント（PRD）の作成方法を包括的に案内します。

• 完全な技術仕様
• 優先度付きの実行可能なタスクリスト
• 関連するコードスニペットと例
• 明確な実装フェーズ
• 測定可能な成功基準

<quality_standards>

優れた PRD の条件

優れた PRD は、以下を満たす必要があります。

• 実行可能：各要件をそのまま実装できます
• 完全：機能要件、非機能要件、技術要件を網羅しています
• 具体的：曖昧な「すべき」「かもしれない」などの表現を避け、正確な言葉を使います
• 測定可能：定量化できる成功指標を含みます
• 実装可能：エンジニアリングチームが構築するために十分な詳細が含まれています

必須項目

すべての PRD に以下を含める必要があります。

1. 問題提起 - 解決する問題とその理由を明確に説明します
2. 目標 - 具体的で測定可能な目標
3. 要件 - 機能要件と非機能要件
4. アーキテクチャ - システム設計、コンポーネント、データフロー
5. 実装計画 - マイルストーンを含む段階的なアプローチ
6. タスクリスト - 実行可能な次のステップ（以下のテンプレートを参照）
7. 成功指標 - 定量化可能な成功の測定基準
8. コードスニペット - 関連する例（以下のガイドラインを参照）

</quality_standards>

<prd_template>

PRD テンプレート

# [Feature Name] - PRD

## Overview
[2-3 sentence summary]

## Problem Statement
[What problem are we solving? Why now? What's the impact of not solving it?]

## Goals
- [ ] [Primary goal 1 - specific and measurable]
- [ ] [Primary goal 2 - specific and measurable]
- [ ] [Secondary goal 3]

## Non-Goals
[What we explicitly will NOT do in this iteration - sets scope boundaries]

## Requirements

### Functional Requirements
- [FR-1] [User stories/use cases as specific requirements]
- [FR-2] [Acceptance criteria for each requirement]

### Non-Functional Requirements
- [NFR-1] **Performance**: [specific metrics, e.g., "API responds in <200ms at p95"]
- [NFR-2] **Security**: [e.g., "All data encrypted at rest and in transit"]
- [NFR-3] **Scalability**: [e.g., "System handles 10k concurrent users"]
- [NFR-4] **Reliability**: [e.g., "99.9% uptime SLA"]

### Technical Requirements
- [TR-1] [Technology stack constraints]
- [TR-2] [Integration requirements]
- [TR-3] [Data retention/compliance requirements]

## Proposed Architecture

### System Design
[High-level architecture - use text diagrams or mermaid]

[Component A] ←→ [Component B] ←→ [Component C] ↓ ↓ ↓ [Database] [Cache Layer] [External API]

### Component Breakdown
- **Component A**: [Responsibility, technology choice, scaling approach]
- **Component B**: [Responsibility, technology choice, scaling approach]
- **Component C**: [Responsibility, technology choice, scaling approach]

### Data Flow
1. [Step-by-step description of how data moves through the system]
2. [Include error handling, retries, fallbacks]
3. [Describe async/sync boundaries]

### API Design (if applicable)
[Include endpoint specifications, request/response schemas]

## Technical Considerations

### Technology Choices
| Technology | Justification | Alternatives Considered |
|------------|---------------|-------------------------|
| [Tech 1]   | [Why this choice] | [Alternative 1, Alternative 2] |
| [Tech 2]   | [Why this choice] | [Alternative 1, Alternative 2] |

### Trade-offs Analyzed
| Option | Pros | Cons | Decision |
|--------|------|------|----------|
| [Option A] | ... | ... | ✅/❌ |
| [Option B] | ... | ... | ✅/❌ |

### Risks and Mitigations
| Risk | Impact | Probability | Mitigation Strategy |
|------|--------|-------------|---------------------|
| [Risk 1] | High/Med/Low | High/Med/Low | [How to address] |
| [Risk 2] | High/Med/Low | High/Med/Low | [How to address] |

## Implementation Strategy

### Phase 1: Foundation
- [ ] [Task 1.1]
- [ ] [Task 1.2]
- [ ] [Task 1.3]

**Definition of Done**: [Specific criteria for phase completion]

### Phase 2: Core Features
- [ ] [Task 2.1]
- [ ] [Task 2.2]
- [ ] [Task 2.3]

**Definition of Done**: [Specific criteria for phase completion]

### Phase 3: Polish & Launch
- [ ] [Task 3.1]
- [ ] [Task 3.2]
- [ ] [Task 3.3]

**Definition of Done**: [Specific criteria for phase completion]

## Task Breakdown

<task_list_template>
### High Priority (P0) - Blockers for launch
- [ ] **[TASK-1]**: [Actionable task title]
  - Complexity: [Simple/Medium/Complex]
  - Dependencies: [Task IDs or components that must exist first]
  - Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
  - Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
  - Acceptance criteria: [Specific, testable criteria]

### Medium Priority (P1) - Important but not blocking
- [ ] **[TASK-2]**: [Actionable task title]
  - Complexity: [Simple/Medium/Complex]
  - Dependencies: [Task IDs or components that must exist first]
  - Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
  - Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
  - Acceptance criteria: [Specific, testable criteria]

### Low Priority (P2) - Nice to have
- [ ] **[TASK-3]**: [Actionable task title]
  - Complexity: [Simple/Medium/Complex]
  - Dependencies: [Task IDs or components that must exist first]
  - Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
  - Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
  - Acceptance criteria: [Specific, testable criteria]
</task_list_template>

<parallelization_guidance>

### Task Parallelization

Mark tasks as **Parallelizable: Yes** when:
- Task is independent of other in-progress tasks
- Multiple developers/subagents can work on different aspects simultaneously
- Task can be split into independent sub-tasks

**Examples:**

✅ **Parallelizable**
- "Design REST API endpoints" and "Design database schema" - can be done simultaneously with coordination
- "Write frontend user profile component" and "Write frontend settings component" - independent components
- "Set up CI/CD pipeline" and "Set up monitoring infrastructure" - separate infrastructure tasks

❌ **Not Parallelizable**
- "Implement authentication" - blocks on "Design database schema" (dependency)
- "Write API tests" - requires API endpoints to exist first (dependency)

**Format for parallelizable tasks:**
```markdown
- Parallelizable: Yes - Can run concurrently with [TASK-X], [TASK-Y]

</parallelization_guidance>

<complexity_guidance>

タスクの複雑さのレベル

シンプル

• 範囲が明確に定義されている
• 想定外の未知要素がない
• 確立されたパターンに従う
• 単一のシステム／コンポーネント
• 例：「登録フォームにメールアドレスの検証を追加する」

中程度

• 調査や検討がある程度必要
• 複数のコンポーネントを統合する
• 意思決定が必要
• 解消すべき曖昧さがある
• 例：「Google と GitHub による OAuth 2.0 ログインを実装する」

複雑

• 重要なアーキテクチャ上の意思決定が必要
• システム間の依存関係がある
• 曖昧さが大きい、または広範な調査が必要
• パフォーマンスやセキュリティ上の懸念がある
• プロトタイプ作成や技術検証が必要
• 例：「WebSocket のスケーリングに対応したリアルタイム通知システムを設計・実装する」

</complexity_guidance>

<testing_guidance>

テスト要件

各タスクでは、テストの必要性を明記する必要があります。

必須 - 重要な機能。マージ前にテストが必須です

• ユーザー認証／認可
• 決済処理
• データ永続化操作
• 外部 API との連携

推奨 - テストを実施すべきですが、ブロック要因にはなりません

• UI コンポーネント
• ビジネスロジックの検証
• エッジケースへの対応
• エラーシナリオ

不要 - テストの対象外です

• 設定変更
• ドキュメントの更新
• インフラストラクチャのセットアップ
• デザイン／モックアップのタスク

テストの種類：

• unit - 個々の関数／コンポーネントを分離してテスト
• integration - 複数のコンポーネントが連携するテスト
• e2e - 最初から最後までのユーザーフローのテスト
• performance - 負荷テスト、ベンチマーク
• security - 侵入テスト、脆弱性スキャン

</testing_guidance>

成功指標

• [Metric 1]：[Current value] → [Target value]
• [Metric 2]：[Current value] → [Target value]
• [Metric 3]：[Current value] → [Target value]

未解決の質問

• [Q1] [解決が必要な質問]
  • 選択肢：[Option A, Option B, Option C]
  • 決定者：[決定する担当者]

付録

コードスニペット

[関連するコード例を記載してください。以下のガイドラインを参照]

データスキーマ

[データベーススキーマ、型定義などを記載してください]

モックアップ

[UI モックアップまたはワイヤーフレームへのリンク]

</prd_template>

<code_snippet_guidelines>

## When to Include Code Snippets

PRDs SHOULD include code snippets when they clarify technical details. Use for:

### 1. API Design
**Include when**: Defining endpoints, request/response formats

```typescript
// POST /api/users
interface CreateUserRequest {
  email: string;
  password: string; // Hashed with bcrypt
  name: string;
}

interface CreateUserResponse {
  id: string;
  email: string;
  createdAt: Date;
}

2. データスキーマ

記載する場合：データベースモデルや型定義を定義するとき

// User schema
interface User {
  id: string; // UUID
  email: string; // Unique, indexed
  passwordHash: string; // bcrypt
  createdAt: Date;
  updatedAt: Date;
}

// Indexes
db.users.createIndex({ email: 1 }, { unique: true });

3. 設定例

記載する場合：機能フラグや環境変数を定義するとき

# Environment variables
DATABASE_URL=postgresql://...
JWT_SECRET=your-secret-key
RATE_LIMIT_ENABLED=true
RATE_LIMIT_REQUESTS_PER_MINUTE=100

4. アルゴリズムの例

記載する場合：複雑なロジックを説明するとき

// Rate limiting algorithm
function rateLimit(userId: string): boolean {
  const requests = redis.get(`ratelimit:${userId}`) || 0;
  if (requests >= LIMIT) {
    return false; // Rate limited
  }
  redis.incr(`ratelimit:${userId}`);
  redis.expire(`ratelimit:${userId}`, 60);
  return true; // Allowed
}

5. 統合例

記載する場合：コンポーネント間の連携方法を示すとき

// Example: Service A calling Service B
const response = await fetch('http://service-b/api/process', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ data: payload })
});

含めてはいけないもの

❌ 実装コード全体 - PRD は要件を定めるものであり、実装を記述するものではありません ❌ ビジネスロジックの詳細 - 実際の開発時に扱います ❌ 定型コード - 設定に関するものを除きます

✅ 含めるもの：インターフェース、スキーマ、アーキテクチャの例 ✅ 含めるもの：設定、API コントラクト、データモデル

</code_snippet_guidelines>

<task_list_guidelines>

実行可能なタスクリストの作成

PRD のタスクは、以下を満たす必要があります。

具体的であること

❌ 「ユーザー認証を実装する」 ✅ 「Google と GitHub のプロバイダーを使った OAuth 2.0 ログインを実装する」

テスト可能であること

❌ 「高速にする」 ✅ 「1000 RPS の負荷時に、API の応答時間を p95 で 200ms 未満にする」

個別に完結していること

❌ 「チェックアウトフロー全体を構築する」 ✅ 「カート概要エンドポイントを構築する」（多数あるタスクのうちの 1 つ）

テスト可能であること

各タスクには、テスト要件（必須／推奨／なし）を必ず指定してください。

タスクのテンプレート（AI エージェント向けに最適化）

- [ ] **[TASK-ID]** [Actionable title]
  - **Complexity**: [Simple/Medium/Complex]
  - **Dependencies**: [Task IDs or components that must exist first]
  - **Parallelizable**: [Yes/No - if Yes, specify which tasks]
  - **Testing**: [Required/Recommended/None - specify type: unit, integration, e2e]
  - **Acceptance Criteria**:
    - [ ] [Criterion 1 - must be testable]
    - [ ] [Criterion 2 - must be testable]

</task_list_guidelines>

<anti_patterns>

よくある PRD のアンチパターン

曖昧な表現

❌ 「システムはスケーラブルであるべき」 ✅ 「システムは、応答時間 500ms 未満で 10,000 人の同時ユーザーに対応しなければならない」

受け入れ基準の不足

❌ 「検索機能を実装する」 ✅ 「フィルター付きの全文検索を実装し、100 件以上の同時検索をサポートしながら、100ms 未満で結果を返す」

成功指標がない

❌ 「ユーザーエンゲージメントを向上させる」 ✅ 「90 日以内に、日次アクティブユーザーを 1,000 人から 2,000 人に増やす」

スコープが無限に広い

❌ 「最高の e コマースプラットフォームを構築する」 ✅ 「商品カタログ、カート、チェックアウトを備えた MVP を構築する（決済には Stripe を使用）」

技術的な詳細が不足

❌ 「データベースを使用する」 ✅ 「リレーショナルデータには PostgreSQL、キャッシュには Redis を使用し、email と product_id に適切なインデックスを設定する」

リスク評価がない

❌ [リスクに関するセクションがない] ✅ [軽減策を含むリスク表を記載する]

</anti_patterns>

PRD 作成ワークフロー

1. 問題を理解する

   • 必要に応じて関係者にインタビューする
   • 現行のソリューションにおける課題を特定する
   • 機会を定量化する

2. 要件の草案を作成する

   • ユーザーストーリーから始める
   • 機能要件（FR-1、FR-2 など）に変換する
   • 非機能要件（NFR-1、NFR-2 など）を追加する

3. アーキテクチャを設計する

   • システム図を作成する
   • コンポーネントとその責務を定義する
   • コンポーネント間のデータフローを図示する

4. 技術的な詳細を追加する

   • 根拠とともに技術を選定する
   • トレードオフを記録する
   • 関連するコードスニペットを含める

5. タスクの内訳を作成する

   • フェーズに分ける
   • 具体的で実行可能なタスクを作成する
   • 依存関係を特定する

6. 成功の定義を決める

   • 測定可能な指標を設定する
   • ベースラインと目標を定義する

7. レビューして改善する

   • 品質基準に照らして確認する
   • アンチパターンがないことを確認する
   • 関係者に確認する

完全な PRD の例については、references/examples.md を参照してください。