failure-driven-development

name	failure-driven-development
description	異常系、失敗モード、検知方法、回復手段を先に定義してから安全に実装を進める実行手法スキル。障害の起こり方、検出、フォールバック、劣化運転、利用者影響を整理し、主に可用性や回復性が重要な実装系スキルの補助として使う。「失敗モードから先に考えたい」「異常系を先に固めて実装したい」「回復手段を決めてから進めたい」「障害時の振る舞いを先に設計したい」などで発動する。
metadata	{"version":"1.0.0","tier":"experimental","category":"implementation","tags":["failure-driven","resilience","fallback","failure-mode"]}

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: 検知と回復の定義

最優先の失敗モードごとに、何で気づき、どう振る舞うかを決める。

必須項目

1. 検知方法
   • エラー
   • タイムアウト
   • メトリクス閾値
   • UI 兆候
   • 監視アラート
2. 一次対応
   • 再試行
   • フォールバック
   • 劣化表示
   • 処理中断
3. 回復手段
   • 自動回復
   • 手動介入
   • 後続補償
4. 利用者影響
   • 完全停止
   • 一部機能停止
   • 遅延
   • 代替表示

出力形式

失敗モード: [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 はあるが、何を捨てるかを定義しない」
• 「監視やログなしで回復戦略を語る」

このスキルの目的は、失敗しても壊れ方を制御できる状態を先に作ること である。