ynitto failure-driven-development
失敗モード、検知方法、回復手段を先に定義し、その失敗に耐える形で実装を進める。
このスキルは プライマリスキルではなく補助スキル として使うのが基本である。実装そのものは既存の実装系スキルに委譲し、本スキルは「何が壊れうるか」「どう検知するか」「どこまで劣化を許容するか」「どう回復するか」を先に固定する。
駆動源の定義
このスキルの駆動源は 失敗モード である。ここでいう失敗モードは、次のいずれかを含む。
- 外部依存の失敗（API、DB、キュー、ファイル、ネットワーク）
- 入力異常やデータ不整合
- タイムアウト、再試行、重複実行
- 部分失敗、片系停止、非同期遅延
- 劣化運転やフォールバックが必要な状態
判断は「正常系が通るか」ではなく、失敗したときにどこまで壊れずに済むか で行う。
パス解決
このSKILL.mdが置かれているディレクトリを SKILL_DIR、その親ディレクトリを SKILLS_DIR とする。他スキルは ${SKILLS_DIR}/[skill-name]/SKILL.md を優先して探す。
Step 0: スコーピング
最初に、このスキルを本当に適用すべきかを判定する。
適用する
- 外部依存や非同期処理があり、失敗時の挙動が重要
- 可用性、回復性、劣化運転が論点に含まれる
- 異常系を先に詰めないと実装のやり直しが増える
- フォールバック、再試行、タイムアウト、冪等性の設計が必要
- 利用者影響や運用影響を事前に定義した方が安全
適用しない
- 純粋な内部ロジックで異常系がほぼ自明
- API / I/O 境界の固定が主眼で、
contract-driven-developmentの方が適切 - 変更順序や停止条件の管理が主眼で、
risk-driven-developmentの方が適切 - すでに発生した障害の原因調査と修正が主眼で、
systematic-debuggingの方が適切 - 文書更新のみで失敗時挙動の設計が不要
Step 0 の出力
適用判定: APPLY / SKIP
主な失敗領域: [依存先 / 入力 / 非同期 / 可用性 / その他]
代替: [なし / 代替スキル名]
ゲート条件: APPLY の場合のみ Phase 1 へ進む。SKIP の場合は理由と代替を返して終了する。
Phase 1: 失敗モード列挙
最初に、正常系ではなく 先に壊れ方 を列挙する。最低でも次の観点を見る。
| 観点 | 確認内容 |
|---|---|
| 起点 | 何が失敗を引き起こすか |
| 影響範囲 | 誰に・どこに影響するか |
| 検知 | どの信号で気づくか |
| 回復 | 自動回復 / 手動回復 / フォールバックのどれか |
| 許容劣化 | 何を捨ててよいか |
| 再発性 | 一時的か、継続的か、再試行で直るか |
各失敗モードは次の形式で整理する。
- F1: [失敗モード名]
起点: [原因]
影響: High / Medium / Low
検知: [ログ / メトリクス / 画面 / 例外]
回復候補: [再試行 / フォールバック / 劣化運転 / 停止]
優先順位付けルール:
- まず
影響 = Highの失敗モードを先に扱う - 同率なら
検知しづらいものを優先する - それでも並ぶ場合は
回復手段が未定のものを先にする
ゲート条件: 最優先の失敗モードを 1 件以上明示できること。失敗モードを挙げられない場合は、依存先と利用者影響の理解が不足しているので追加確認する。
Phase 2: 検知と回復の定義
最優先の失敗モードごとに、何で気づき、どう振る舞うかを決める。
必須項目
- 検知方法
- エラー
- タイムアウト
- メトリクス閾値
- UI 兆候
- 監視アラート
- 一次対応
- 再試行
- フォールバック
- 劣化表示
- 処理中断
- 回復手段
- 自動回復
- 手動介入
- 後続補償
- 利用者影響
- 完全停止
- 一部機能停止
- 遅延
- 代替表示
出力形式
失敗モード: [F番号]
検知方法: [どう気づくか]
一次対応: [最初にどう振る舞うか]
回復手段: [どう戻すか]
許容劣化: [何を維持し何を落とすか]
ゲート条件: 検知方法と回復手段の両方が定義されていること。どちらかが欠けた失敗モードは未設計とみなす。
Phase 3: 実装ルールへの変換
定義した失敗モードを、実装時のガードレールへ落とす。
最低でも次を定義する。
- どの依存呼び出しに timeout を置くか
- どこで retry を許可し、どこで禁止するか
- どこで fallback を返すか
- どこで fail-fast するか
- どこで利用者向けに劣化を見せるか
出力形式:
実装ルール:
- R1: [timeout / retry / fallback / fail-fast / degraded mode]
- R2: ...
ゲート条件: 少なくとも 3 個の具体的な実装ルールに変換されていること。抽象的な「気をつける」では不十分。
Phase 4: 検証観点の定義
正常系テストだけで終わらないよう、異常系観点を先に定義する。
最低でも次を含める。
- 依存先が失敗したときに期待どおり劣化する
- timeout 時にハングせず終了する
- retry の上限で止まる
- fallback 時に利用者影響が定義どおりになる
- ログ / メトリクス / エラー通知が残る
出力形式:
異常系テスト観点:
- FT1: [依存失敗]
- FT2: [timeout]
- FT3: [retry 上限]
- FT4: [fallback / degraded mode]
- FT5: [observability]
ゲート条件: 失敗モードに対応する検証観点が 1 つ以上紐づいていること。検証不能な設計は再設計する。
Phase 5: 完了レポート
最後に、先に定義した失敗モードと回復戦略を短くまとめる。
## Failure-Driven 完了レポート
最重要失敗モード: [内容]
検知方法: [要約]
回復手段: [要約]
許容劣化: [要約]
異常系テスト観点数: [N]
残留リスク: [なし / 内容]
推奨次アクション: [1〜3件]
verdict-json
<!-- verdict-json -->
{
"skill": "failure-driven-development",
"verdict": "PASS | HOLD | FAIL",
"primary_failure_mode": "[summary]",
"blocking": false,
"residual_risks": [],
"degraded_modes": []
}
<!-- /verdict-json -->
既存スキルとの組み合わせ
相性が良い
api-designer— 異常系レスポンスと fallback 契約の設計react-frontend-coder— 依存失敗時の UI 劣化表示や再試行設計ci-cd-configurator— ジョブ失敗、再試行、fail-fast 方針の設計systematic-debugging— 事前に設計した失敗モードを、実障害時の仮説に接続する
使い分け
- すでに発生した障害の原因調査は
systematic-debuggingを優先する - 変更順序や停止条件が主眼なら
risk-driven-developmentを優先する - 契約や境界固定が主眼なら
contract-driven-developmentを優先する
エラーリカバリー
| 状況 | 対応 |
|---|---|
| 失敗モードが列挙できない | 依存先、入力、非同期処理、利用者影響を追加確認する |
| 検知方法がない | 実装前に observability を足す方針を決める |
| 回復手段が決まらない | fail-fast と degraded mode のどちらかを明示的に選ぶ |
| 許容劣化が決まらない | 利用者影響を優先して、何を守るかをユーザーに確認する |
| 検証観点が作れない | 失敗モード定義が抽象的すぎるため、Phase 1 に戻る |
アンチパターン
- 「正常系が通ったので異常系は後で考える」
- 「失敗時は generic error でよいとして詳細を詰めない」
- 「retry すれば何とかなる」とだけ書く
- 「fallback はあるが、何を捨てるかを定義しない」
- 「監視やログなしで回復戦略を語る」
このスキルの目的は、失敗しても壊れ方を制御できる状態を先に作ること である。