edge-cases

エッジケース分析

PRDを体系的に分析し、エッジケース、障害モード、競合状態、実装時に見落とされる可能性のあるシナリオを特定します。

---

作業内容

1. 提供されたPRDを詳しく読みます
2. 各ユーザーストーリーと機能要件を分析します
3. 複数のカテゴリにわたって潜在的なエッジケースを特定します
4. PRDの更新案を提案します（新しい受け入れ基準、新しいストーリー、既存ストーリーの更新）

出力： エッジケースと、推奨するPRDの更新案のリスト。

---

エッジケースのカテゴリ

1. 入力のエッジケース

• 空/null値： 必須フィールドが空の場合、どうなりますか？
• 境界値： 最大長、最小値／最大値、日付範囲
• 無効な形式： データ型の誤り、不正な形式の入力
• Unicode／特殊文字： 絵文字、RTLテキスト、HTMLインジェクションの試み
• 大量のデータ： アイテムが10件ではなく10,000件ある場合、どうなりますか？

2. 状態のエッジケース

• 競合状態： 2人のユーザーが同じものを同時に編集する
• 古いデータ： 読み取りから書き込みまでの間に、別のプロセスによってデータが変更される
• 部分的な完了： 処理が途中で失敗した場合、どうなりますか？
• 同時操作： 複数のタブ、複数のセッション
• オフライン／再接続： 接続が切れたとき、どうなりますか？

3. ユーザー行動のエッジケース

• 連続クリック： ユーザーが送信ボタンを短時間に複数回クリックする
• 戻るボタン： 処理中にユーザーが前のページに戻る
• ブラウザーの更新： 複数ステップのフローの途中でユーザーがページを更新する
• 中断されたフロー： ユーザーが処理の途中で離脱する
• 予期しないナビゲーション： ユーザーがアクセス権のないURLに直接アクセスする

4. エラー処理のエッジケース

• ネットワーク障害： APIのタイムアウト、サーバーエラー
• 検証エラー： エラーをどのように表示し、復旧できるようにしますか？
• 権限エラー： 処理の途中でユーザーがアクセス権を失う
• リソース枯渇： レート制限、ストレージ制限

5. データのエッジケース

• 初回利用： まだデータが存在しない（空の状態）
• レガシーデータ： 新しいスキーマに適合しない古いデータ
• データ移行： スキーマの変更時に既存データをどう扱いますか？
• カスケード効果： 他の要素が依存しているものを削除する

6. セキュリティのエッジケース

• 認証の有効期限切れ： 処理中にセッションがタイムアウトする
• 認可の変更： ユーザーが操作中に権限が変更される
• 入力のサニタイズ： XSS、SQLインジェクション、コマンドインジェクション
• データ漏えい： エラーメッセージから機密情報が漏れる

7. パフォーマンスのエッジケース

• コールドスタート： 初回読み込み時のパフォーマンス
• 大きなペイロード： 大量のデータがある場合の応答時間
• メモリーリーク： 長時間稼働するセッション
• N+1クエリー： 規模拡大時のデータベースのパフォーマンス

---

分析プロセス

PRD内の各ユーザーストーリーについて、以下を行います。

ステップ1：ストーリーを読む

ストーリーで達成しようとしていることを理解します。

ステップ2：カテゴリのチェックリストを適用する

上記の各エッジケースのカテゴリを確認し、次の点を問いかけます。

• このストーリーにこのカテゴリは当てはまりますか？
• どのような具体的なエッジケースが起こり得ますか？

ステップ3：重大度を評価する

特定した各エッジケースについて、次のように評価します。

• 重大： データ損失、セキュリティ侵害、またはシステムクラッシュにつながる可能性がある
• 高： ユーザーに見えるエラー、または機能の破損が発生する
• 中： UXの低下、または軽微な機能上の問題が発生する
• 低： 軽微な不便、または見た目上の問題が発生する

ステップ4：PRDの更新案を提案する

各エッジケースについて、次のいずれかを提案します。

• 既存ストーリーの新しい受け入れ基準
• 範囲が大きい場合は新しいユーザーストーリー
• 機能要件の更新
• 技術的な考慮事項への追記

---

出力形式

# Edge Case Analysis for [PRD Name]

## Summary
- Total edge cases identified: X
- Critical: X | High: X | Medium: X | Low: X

## Edge Cases by Story

### US-001: [Story Title]

| Edge Case | Category | Severity | Recommended Action |
|-----------|----------|----------|-------------------|
| User submits empty form | Input | High | Add acceptance criteria: "Empty form shows validation errors" |
| User double-clicks submit | User Behavior | Medium | Add acceptance criteria: "Submit button disabled after first click" |

### US-002: [Story Title]
...

## New Stories Recommended

### US-NEW-001: Handle concurrent edits
**Description:** As a user, I want to see a warning if someone else has edited the item since I started editing.

**Acceptance Criteria:**
- [ ] System checks for updates before saving
- [ ] Warning shown if data has changed
- [ ] User can choose to overwrite or refresh

**Rationale:** Addresses race condition edge case in US-003 and US-004.

## Updated Functional Requirements

- FR-NEW-1: The system must validate all user input on both client and server side
- FR-NEW-2: All destructive operations must be idempotent

## Technical Considerations to Add

- Implement optimistic locking for concurrent edit detection
- Add retry logic with exponential backoff for network failures
- Use database transactions for multi-step operations

---

完了前のチェックリスト

• 各ユーザーストーリーをすべてのエッジケースのカテゴリに照らして分析した
• 各エッジケースの重大度を評価した
• 具体的で実行可能な推奨事項を提示した
• 重複するストーリーを避けるため、関連するエッジケースをまとめた
• 推奨事項を必要な範囲に絞った（過剰な設計を避けた）
• 重大度が重大または高の項目を優先した

---

ヒント

• やりすぎない： 理論上起こり得るすべてのエッジケースではなく、起こりそうなシナリオに焦点を当てます
• 具体的にする： 「名前欄に 255 文字を超える文字列を入力する」は「入力値の検証」より適切です
• 文脈を考慮する： 個人プロジェクトでは、銀行アプリよりエッジケースへの対応を少なくできます
• パターンを探す： レースコンディションが 1 つ見つかったら、ほかにもある可能性があります
• 攻撃者の視点で考える： システムを壊すために、どのようなことを試すでしょうか？