# Failure Driven Development

> 異常系、失敗モード、検知方法、回復手段を先に定義してから安全に実装を進める実行手法スキル。障害の起こり方、検出、フォールバック、劣化運転、利用者影響を整理し、主に可用性や回復性が重要な実装系スキルの補助として使う。「失敗モードから先に考えたい」「異常系を先に固めて実装したい」「回復手段を決めてから進めたい」「障害時の振る舞いを先に設計したい」などで発動する。

- Skill: `ynitto/failure-driven-development` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ynitto/failure-driven-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ynitto/failure-driven-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ynitto (https://skillmd.com/u/ynitto)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ynitto/failure-driven-development

---


# 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

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

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