# Risk Driven Development

> TDD が適さない変更系タスクを、最大リスク起点で安全に進める実行手法スキル。変更対象のリスク棚卸し、最小検証、段階適用、停止条件を定義し、主に実装系・変更系スキルの補助として使う。「リスクを見ながら実装して」「安全に段階導入したい」「まず危ないところから潰したい」「変更順序と停止条件を決めて」などで発動する。

- Skill: `ynitto/risk-driven-development` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ynitto/risk-driven-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ynitto/risk-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/risk-driven-development

---


# risk-driven-development

最大リスクを起点に、変更の順序・検証方法・停止条件を決めてから実装を進める。

このスキルは **プライマリスキルではなく補助スキル** として使うのが基本である。対象の実装・変更そのものは既存の実装系スキルに委譲し、本スキルは「何から・どの順で・どこで止まるか」を管理する。

---

## 駆動源の定義

このスキルの駆動源は **リスク** である。ここでいうリスクは、次のいずれかを指す。

- 変更失敗時の影響が大きい
- 仕様や挙動の不確実性が高い
- 巻き込み範囲が読みにくい
- 戻しにくい、あるいは観測しにくい
- 変更順序を誤ると壊れやすい

判断は「工数が大きいか」ではなく、**先に小さく潰すべき危険が何か** で行う。

---

## パス解決

このSKILL.mdが置かれているディレクトリを `SKILL_DIR`、その親ディレクトリを `SKILLS_DIR` とする。他スキルは `${SKILLS_DIR}/[skill-name]/SKILL.md` を優先して探す。

---

## Step 0: スコーピング

最初に、このスキルを本当に適用すべきかを判定する。

### 適用する

- 実装またはコード変更が発生する
- TDD を厳密に回しにくい
- 変更順序や段階投入を決めた方が安全
- 手動確認、静的チェック、限定実行などの軽量検証が可能
- UI、設定、CI、インフラ、探索実装、軽量リファクタなどで破壊範囲の管理が重要

### 適用しない

- 純粋な調査のみ
- 単純な文書更新のみ
- 影響範囲が極小で、順序設計や停止条件が不要
- API 契約や入出力境界の固定が主眼で、`contract-driven-development` の方が適切
- 異常系・回復戦略の設計が主眼で、`failure-driven-development` 相当の方が適切

### Step 0 の出力

以下を 3 行以内で明示する。

```
適用判定: APPLY / SKIP
主理由: [1文]
代替: [なし / 代替スキル名]
```

**ゲート条件:** `APPLY` と判定できた場合のみ Phase 1 へ進む。`SKIP` の場合は理由と代替を返して終了する。

---

## Phase 1: リスク棚卸し

変更対象を読み、候補リスクを列挙する。最低でも次の観点を見る。

| 観点 | 確認内容 |
|---|---|
| 影響度 | 壊れたときに何が止まるか |
| 不確実性 | 仕様・既存挙動・依存関係のどこが曖昧か |
| 可逆性 | すぐ戻せるか、フラグや分岐で逃がせるか |
| 可観測性 | 成否をどこで確認できるか |
| 波及範囲 | 何ファイル・何レイヤー・何利用者に広がるか |
| 依存順序 | 先に変えると危ない箇所はどこか |

各リスクは次の形式で整理する。

```
- R1: [リスク名]
  影響: High / Medium / Low
  不確実性: High / Medium / Low
  可逆性: High / Medium / Low
  初期対策: [1文]
```

**優先順位付けルール:**

- まず `影響 = High` かつ `不確実性 = High` を最優先にする
- 同率なら `可逆性が低い` ものを先に扱う
- それでも並ぶ場合は `最小検証で潰せるもの` を先にする

**ゲート条件:** 最大リスク 1 件を明示できること。曖昧なら追加調査を 1 回だけ行い、それでも絞れなければユーザーに相談する。

---

## Phase 2: 最小検証の設計

最大リスクを丸ごと解こうとせず、**最小変更で事実確認できる検証単位** に落とす。

以下を決める。

1. **最初に試す最小変更**
   - 1ファイル、1設定、1分岐、1コンポーネントなど、可能な限り小さくする
2. **検証方法**
   - 手動確認
   - 静的チェック
   - 限定テスト
   - 限定実行
   - ログ・差分確認
3. **成功条件**
   - 何が確認できれば次へ進んでよいか
4. **失敗条件**
   - どの兆候が出たら止めるか

出力形式:

```
最大リスク: [R番号]
最小変更: [何を最初に変えるか]
検証方法: [どう確かめるか]
成功条件: [次へ進める条件]
失敗条件: [停止条件]
```

**ゲート条件:** 実装前に「成功条件」と「失敗条件」の両方が定義されていること。片方でも欠けていたら Phase 2 をやり直す。

---

## Phase 3: 段階適用計画

Phase 2 の最小検証を起点に、変更全体を段階化する。

各段階は以下の粒度で書く。

```
Stage 1: [最小検証]
  目的: [何を確かめるか]
  実施: [主に使うプライマリスキル]
  確認: [実施後のチェック]
  失敗時: [戻し方 or 凍結条件]

Stage 2: [次の拡張]
...
```

### ルール

- いきなり本命変更を入れない
- ステージをまたいで複数の新規リスクを同時に開かない
- 各ステージの完了条件を明示する
- 戻し方がないステージは、原則として最後に置く

**ゲート条件:** すべてのステージに `確認` と `失敗時` があること。なければ計画不備として修正する。

---

## Phase 4: 実行管理

プライマリスキルに実装を委譲しつつ、各ステージの前後で以下を必ず確認する。

### ステージ開始前

- このステージで新たに開くリスクは 1 つに抑えられているか
- 失敗時の戻し方が残っているか
- 検証方法が実行可能か

### ステージ完了後

- 成功条件を満たしたか
- 想定外の副作用が出ていないか
- 次のステージへ進む価値があるか

各ステージの結果は次の形式で記録する。

```
=== Risk Stage [N] ===
対象: [ステージ名]
結果: PASS / HOLD / FAIL
確認結果: [要約]
次アクション: 次へ進む / 同ステージ再試行 / 計画見直し / ユーザー相談
```

### HOLD の扱い

`FAIL` ではないが不確実性が残る場合は `HOLD` とし、次のどちらかを選ぶ。

- 追加の最小検証を 1 回だけ挿入する
- その時点でユーザーに相談する

**ゲート条件:** `PASS` のステージだけ次へ進める。`HOLD` と `FAIL` はそのまま先送りしない。

---

## Phase 5: 完了レポート

最後に、リスク起点でどう進めたかを短くまとめる。

```
## Risk-Driven 完了レポート
最大リスク: [内容]
最初の最小検証: [内容]
実施ステージ数: [N]
停止・保留の有無: [なし / 内容]
残留リスク: [なし / 内容]
推奨次アクション: [1〜3件]
```

### verdict-json

```json
<!-- verdict-json -->
{
  "skill": "risk-driven-development",
  "verdict": "PASS | HOLD | FAIL",
  "max_risk": "[summary]",
  "stages_completed": 0,
  "blocking": false,
  "residual_risks": []
}
<!-- /verdict-json -->
```

---

## 既存スキルとの組み合わせ

### 相性が良い

- `react-frontend-coder` — UI の段階実装、影響範囲の見極め
- `ci-cd-configurator` — 設定変更の段階投入、限定検証
- `code-simplifier` — リファクタの順序設計と停止条件管理
- `systematic-debugging` — 既知バグ修正時の危険箇所の先行把握

### 使い分け

- 受け入れ条件を先にテストへ固定できるなら `test-driven-development` を優先する
- 契約や境界を先に固める案件は `contract-driven-development` を優先する
- 障害時の回復設計が主論点なら `failure-driven-development` / `error-recovery-strategist` 系を優先する

---

## エラーリカバリー

| 状況 | 対応 |
|---|---|
| 最大リスクを絞れない | 追加調査を 1 回だけ実施し、それでも曖昧ならユーザーに相談 |
| 検証方法が存在しない | 変更を分割し直す。どうしても不可なら `HOLD` として相談 |
| ステージ途中で副作用が広がった | そのステージを中断し、戻し方を実行して Phase 1 に戻る |
| 2 ステージ連続で `HOLD` | 現行計画は不適切とみなし、ユーザーに判断を仰ぐ |
| 可逆性が低い変更しか残っていない | 最終段に隔離し、明示的な承認を取ってから進む |

---

## アンチパターン

- 「全部実装してからまとめて確認する」
- 「危ないとわかっている部分を後回しにする」
- 「成功条件なしで試す」
- 「止まる条件を決めずに進める」
- 「一度 `HOLD` になったリスクを説明なく先送りする」

このスキルの目的は速度ではなく、**危険を早く小さく露出させること** である。