deliver-edge-cases

エッジケース

エッジケースのドキュメントでは、機能に関する通常とは異なる状況、境界条件、エラーシナリオを体系的にまとめます。正常系のフローは通常、十分に仕様化されていますが、エッジケースは本番環境で発覚することが多く、バグやユーザー体験の低下、サポート負荷の増加につながります。事前にエッジケースを文書化しておくことで、エンジニアリングチームは意図を持って対処でき、QA チームはテストすべき内容を把握できます。

使用する場面

• 障害の発生パターン、競合状態、タイムアウト、境界条件や上限のシナリオなど、起こりうるあらゆる問題を列挙し、それぞれの復旧方法を定義する必要がある場合
• エンジニアリングを始める前の機能仕様策定時
• QA テスト計画を準備する場合
• 本番環境のバグを発見し、類似の問題を防止する場合
• PRD やユーザーストーリーの完全性を確認する場合
• エラー状態の設計を確実にするため、ローンチ前に確認する場合

使用しない場面

• 引き継ぎ用にストーリー単位の Given／When／Then チェックが必要な場合 → deliver-acceptance-criteria を使用してください。このスキルでは機能全体の障害発生範囲を整理します
• 入力、状態、上限を列挙するには機能の仕様が不十分な場合 → まず deliver-prd を使用してください
• 本番環境でインシデントがすでに発生しており、その教訓を記録する場合 → iterate-lessons-log を使用してから、このカタログに新しいケースを追加してください
• 障害分析ではなく、ローンチに向けた準備状況の調整が必要な場合 → deliver-launch-checklist を使用してください

手順

エッジケースの文書化を依頼された場合は、次の手順に従ってください。

1. 機能の範囲を定義する 分析対象となる機能やフローを明確に説明します。エッジケースは状況によって異なるため、同じ入力でも、機能によって有効になる場合と無効になる場合があります。

2. 入力検証を確認する すべてのユーザー入力について検討します。空の場合はどうなるか、長すぎる場合はどうなるか、形式が正しくない場合はどうなるか、特殊文字を含む場合はどうなるかを確認します。有効な値の最小値と最大値も確認します。

3. 境界条件を洗い出す 許容範囲の端を確認します。あるフィールドが 1～100 を受け付ける場合は、0、1、100、101 をテストします。ページネーションの境界、タイムアウトのしきい値、レート制限も考慮します。

4. エラー状態を整理する ネットワーク障害、権限拒否、リソースが見つからない、同時変更、セッションの期限切れなど、起こりうる問題を特定します。シナリオと期待される動作の両方を文書化します。

5. 同時実行の問題を検討する 2 人のユーザーが同時に操作した場合はどうなるでしょうか。ユーザーがダブルクリックした場合はどうなるでしょうか。読み込みから保存までの間にデータが変更された場合はどうなるでしょうか。競合状態は、気付きにくいバグを引き起こすことがよくあります。

6. 復旧方法を定義する 各エラーからユーザーがどのように復旧するかを指定します。どのようなメッセージが表示されるか、再試行できるか、データが保持されるかを確認します。優れたエラー処理は、ユーザーの不満を安心感に変えます。

7. 発生可能性と影響度に基づいて優先順位を付ける すべてのエッジケースに同じ注意を払う必要はありません。発生可能性と影響度がともに高いケースには堅牢な対処が必要です。一方、まれで影響度の低いケースは、適切に失敗するだけで十分な場合があります。

出力形式

出力の構成には references/TEMPLATE.md のテンプレートを使用してください。完全なエッジケースカタログでは、テンプレートのすべてのセクション、すなわち「機能の概要」「エッジケースのカテゴリ」「エラーメッセージ」「復旧方法」「テストシナリオ」を記入します。

品質チェックリスト

最終確認の前に、次の項目を確認してください。

• すべてのユーザー入力について、入力検証に関するエッジケースが文書化されている
• 境界条件が明確に列挙されている
• ネットワークやシステムの障害シナリオが網羅されている
• 各エラー状態に、ユーザー向けのメッセージが定義されている
• 復旧方法が指定されている（エラーの検出だけではない）
• エッジケースが発生可能性と影響度に基づいて優先順位付けされている

例

完成例については references/EXAMPLE.md を参照してください。