risk-driven-development

name	risk-driven-development
description	TDD が適さない変更系タスクを、最大リスク起点で安全に進める実行手法スキル。変更対象のリスク棚卸し、最小検証、段階適用、停止条件を定義し、主に実装系・変更系スキルの補助として使う。「リスクを見ながら実装して」「安全に段階導入したい」「まず危ないところから潰したい」「変更順序と停止条件を決めて」などで発動する。
metadata	{"version":"1.0.0","tier":"experimental","category":"implementation","tags":["risk-driven","incremental-change","safety-gate","implementation-method"]}

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

<!-- 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 になったリスクを説明なく先送りする」

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