prd-master

PRD マスター

基本原則

• 常に進化するドキュメント — PRD は製品ライフサイクルを通じて進化します
• ステークホルダーとの協働 — 早期に関与することで、後からの手戻りを防ぎます
• 測定可能な目標 — あいまいな目標を定量化可能な目標に置き換えます
• 焦点を絞りつつ柔軟に — 無駄のない構成により、適応しやすくなります
• 問題を優先する — 解決策に飛びつく前に、問題を定義します
• ユーザー中心 — ユーザー調査とデータに基づいて意思決定します

---

厳守事項

これらのルールは必須です。違反した場合、このスキルは正しく機能していません。

あいまいな指標の禁止

すべての指標と要件は定量化可能でなければなりません。あいまいな記述は禁止です。

❌ FORBIDDEN:
- "The app should be fast"
- "Support many users"
- "Good user experience"
- "The system should be reliable"
- "Easy to use interface"

✅ REQUIRED:
- "Page load time < 2s on 4G, < 500ms on WiFi (P95)"
- "Support 10,000 concurrent users with 99.9% uptime"
- "NPS > 50, Task completion rate > 85%"
- "99.9% availability, MTTR < 1 hour"
- "User can complete checkout in < 3 clicks"

解決策より先に問題を定義する

問題を明確に定義せずに解決策を提案してはいけません。

❌ FORBIDDEN:
"We should add a search bar to the navigation"

✅ REQUIRED:
"Problem: Users can't find products quickly (40% exit rate on catalog).
They need a way to filter 1000+ products by attributes.
Proposed solutions: search bar, smart filters, AI recommendations."

INVEST に準拠したストーリー

すべてのユーザーストーリーは、INVEST 基準のチェックリストを満たす必要があります。

❌ FORBIDDEN:
- Dependent stories that can't be delivered independently
- Stories without acceptance criteria
- Stories too large to complete in one sprint
- Stories without clear user value

✅ REQUIRED:
- [ ] Independent — Can be delivered alone
- [ ] Negotiable — Details can be discussed
- [ ] Valuable — Clear user/business value
- [ ] Estimable — Team can estimate effort
- [ ] Small — Fits in one sprint
- [ ] Testable — Has acceptance criteria

---

クイックリファレンス

状況に応じた手法

シナリオ	アプローチ	ツール／フレームワーク
機能の優先順位付け	スコアリングモデル	RICE、ICE
リリース計画	必須／推奨／可能／対象外	MoSCoW
顧客満足度	期待を超える要素と基本要素	Kano モデル
スプリント計画	ユーザーストーリー＋BDD	Given-When-Then
複雑な要件	従来型 PRD	完全なテンプレート
アジャイルな反復	リーン要件	ユーザーストーリー＋受け入れ条件

---

PRD の構成

必須項目

## 1. Executive Summary
- Problem statement (2-3 sentences)
- Proposed solution (1-2 sentences)
- Success metrics (3-5 key metrics)

## 2. Context & Background
- Why now? Market opportunity or user pain
- Strategic alignment with company goals
- What happens if we don't build this?

## 3. Goals & Success Metrics
- Business objectives (revenue, retention, growth)
- User objectives (satisfaction, engagement)
- Success criteria (quantifiable targets)

## 4. Target Users & Personas
- Primary users (who benefits most?)
- Secondary users (indirect beneficiaries)
- User needs, pain points, motivations
- Jobs to be done

## 5. User Stories & Use Cases
- Core user flows
- Edge cases and error scenarios
- Integration with existing features

## 6. Requirements
- Functional requirements (what it does)
- Non-functional requirements (performance, security)
- Acceptance criteria (how we verify)

## 7. Out of Scope
- What we're explicitly NOT building
- Future considerations for later phases

## 8. Design & UX
- Link to design files (Figma, etc.)
- Key design decisions
- Accessibility requirements (WCAG 2.2 AA)

## 9. Technical Considerations
- Architecture overview
- Dependencies and integrations
- Data model changes
- API contracts

## 10. Rollout & Launch Plan
- Phased rollout strategy
- Feature flags and A/B tests
- Monitoring and alerts
- Rollback plan

## 11. Open Questions & Risks
- Unknowns requiring research
- Technical risks and mitigations
- Dependencies on other teams

---

ユーザーストーリーの作成

標準形式

As a [persona/role],
I want to [action/goal],
So that [benefit/value].

3 つの C

Card          — Brief description on index card
              → Captures essence, not details
              → Placeholder for conversation

Conversation  — Discussion between team members
              → Explore edge cases
              → Clarify assumptions
              → Uncover hidden requirements

Confirmation  — Acceptance criteria
              → Defines "done"
              → Testable conditions
              → Given-When-Then format

INVEST 基準

Independent   — Story stands alone, minimal dependencies
Negotiable    — Details emerge through conversation
Valuable      — Delivers value to users or business
Estimable     — Team can estimate effort
Small         — Completable within one sprint
Testable      — Clear acceptance criteria

例

## Good User Stories

### Feature: Password Reset
As a user who forgot my password,
I want to reset it via email,
So that I can regain access to my account without contacting support.

**Acceptance Criteria:**
- Given I'm on the login page
- When I click "Forgot Password"
- Then I see a form requesting my email address

- Given I've entered my registered email
- When I submit the form
- Then I receive a password reset link within 2 minutes

- Given I click the reset link within 24 hours
- When I set a new password (min 8 chars, 1 number, 1 symbol)
- Then I'm logged in automatically

### Feature: Bulk Upload
As a content manager,
I want to upload multiple products via CSV,
So that I can save time compared to manual entry.

**Acceptance Criteria:**
- Given I'm on the products page
- When I click "Bulk Upload" and select a CSV file
- Then the system validates the file format (max 10MB, .csv only)

- Given the CSV has 1000 rows
- When I start the upload
- Then I see a progress bar showing completion percentage

- Given the upload completes
- When I view the results
- Then I see: success count, error count, downloadable error report

よくある間違い

❌ Too technical
"As a user, I want the API to return a 200 status code"
→ Focus on user benefit, not implementation

❌ Too vague
"As a user, I want the system to be fast"
→ Define measurable performance targets

❌ Missing the "so that"
"As a user, I want to filter products by price"
→ Add the value: "so that I can find items within my budget"

❌ Too large (Epic)
"As a user, I want a complete e-commerce checkout experience"
→ Break into smaller stories: cart, address, payment, confirmation

---

受け入れ条件

Given-When-Then（BDD 形式）

Given [precondition/context]
When [action/trigger]
Then [expected outcome]

And [additional context/outcome]

ベストプラクティス

✓ Keep scenarios focused (one behavior per scenario)
✓ Maintain clear separation of Given/When/Then
✓ Avoid UI-specific details (test behavior, not implementation)
✓ Make criteria testable and measurable
✓ Include both happy path and edge cases
✓ Use real user interactions, not hypothetical

例

## E-commerce Checkout

Scenario: Successful payment with saved card
  Given I have items in my cart
  And I'm logged in with a saved payment method
  When I click "Place Order"
  Then I see an order confirmation page
  And I receive a confirmation email within 2 minutes
  And my cart is emptied

Scenario: Payment declined
  Given I'm at the payment step
  When I submit payment and the card is declined
  Then I see an error message: "Payment declined. Please try another card."
  And I remain on the payment page
  And my cart items are preserved

Scenario: Session timeout during checkout
  Given I've been idle for 30 minutes
  When I attempt to place an order
  Then I'm redirected to login
  And my cart items are preserved after re-authentication

## Search Feature

Scenario: Search with results
  Given I'm on the homepage
  When I search for "laptop"
  Then I see results within 500ms
  And results are ranked by relevance
  And I see result count: "Showing 1-20 of 156 results"

Scenario: Search with no results
  Given I'm on the search page
  When I search for "xyznonexistent"
  Then I see "No results found for 'xyznonexistent'"
  And I see search suggestions or alternative queries

代替形式：チェックリスト

For simpler features, use a checklist:

## File Upload Acceptance Criteria
- [ ] Supports formats: PDF, DOCX, XLSX (max 10MB each)
- [ ] Shows upload progress bar
- [ ] Displays file name and size after upload
- [ ] Allows removal of uploaded files
- [ ] Shows error message for unsupported formats
- [ ] Shows error message for files exceeding size limit
- [ ] Scans files for malware before processing
- [ ] Works on mobile (iOS Safari, Android Chrome)

---

優先順位付けのフレームワーク

RICE スコアリング

RICE Score = (Reach × Impact × Confidence) / Effort

Reach      — How many users affected per time period?
             (users/quarter, transactions/month)
Impact     — How much does it improve their experience?
             3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal
Confidence — How certain are we?
             100% = High data, 80% = Medium, 50% = Low
Effort     — Person-months required
             (engineering + design + PM time)

例：

機能	リーチ	インパクト	確信度	工数	RICE スコア
パスワードのリセット	5000/月	3	100%	1	15,000
ダークモード	10000/月	0.5	80%	2	2,000
PDF へのエクスポート	500/月	2	50%	0.5	1,000

使用する場面： 多数のアイデアを管理し、定量的な比較が必要で、ユーザーデータがある場合。

---

ICE スコアリング

ICE Score = (Impact + Confidence + Ease) / 3

Impact     — 1-10: How much business/user value?
Confidence — 1-10: How certain are we?
Ease       — 1-10: How easy to implement? (10 = very easy)

例：

機能	インパクト	確信度	容易さ	ICE スコア
ワンクリックログイン	9	8	6	7.7
AI によるレコメンデーション	10	5	3	6.0
メール通知	6	9	9	8.0

使用する場面： 迅速な優先順位付け、週次のバックログ整理、成長実験、精度よりスピードを重視する場合。

---

MoSCoW メソッド

Must Have      — Critical for launch, non-negotiable
                 Without this, the product fails

Should Have    — Important but not vital
                 Painful to omit, but workarounds exist

Could Have     — Nice to have, "vitamins not painkillers"
                 Include if time/resources allow

Won't Have     — Explicitly out of scope
                 Defer to future releases

例：MVP の EC サイト

必須	推奨	あればよい	対象外
商品一覧	商品レビュー	ウィッシュリスト	AR 試着
ショッピングカート	関連商品	ギフト包装	ライブチャット
購入手続き	注文追跡	割引コード	ロイヤルティプログラム
決済（Stripe）	メール領収書	ソーシャル共有	モバイルアプリ
ユーザーアカウント	ゲスト購入	商品比較	サブスクリプション

使用する場面： スプリント計画、MVP の範囲設定、リリース境界の決定、ステークホルダー間の認識合わせ。

---

Kano モデル

Basic Needs       — Must-haves, assumed by users
                    Absence = dissatisfaction, presence = neutral
                    Example: Website loads, checkout works

Performance       — More is better, linear satisfaction
                    Example: Faster page load, more payment options

Delighters        — Unexpected features that wow
                    Absence = neutral, presence = delight
                    Example: Free shipping, personalized recommendations

Indifferent       — Users don't care either way
                    Example: Animated logo, theme customization

使用する場面： 顧客主導の意思決定、基本要素とイノベーションのバランス調整、UX の改善。

プロセス：

1. ユーザーに次の対になった質問をします。
   • 「機能 X があったら、どのように感じますか？」
   • 「機能 X がなかったら、どのように感じますか？」
2. 回答を分類します：基本品質、性能品質、魅力品質、無関心
3. 優先順位を付けます：まず基本品質を満たし、次に性能品質、最後に魅力品質に対応します

---

ハイブリッドアプローチ

Best practice: Combine frameworks

1. Use MoSCoW to define release scope
   → Separate must-haves from nice-to-haves

2. Use RICE to rank must-haves
   → Sequence within release based on impact

3. Use Kano to ensure balance
   → Don't over-invest in basics, under-invest in delight

Example:
- All "Must Have" items → Score with RICE → Build in RICE order
- Validate with Kano → Ensure we have delighters, not just basics

---

拡張リファレンス

## Agile Requirements Management から始まる詳細な資料は、このスキルを簡潔に保つため、reference/extended.md に移動しました。移動した例、コマンド一覧、チェックリスト、プラットフォームの詳細、実装テンプレートが必要なタスクでは、このリファレンスを読み込んでください。