Skip to content

テンプレート — リスクマトリクス

いつ使うか

ステージ4 — 検証で成果物ごとにリスク等級をつけ、等級に合った検証強度を定めるときに使う。すべての成果物に同じ強度の検証をかけるとリソースが無駄になり、逆に失敗コストが大きい領域を軽く流すと事故につながる。このマトリクスは、等級の判定基準と、等級ごとにどこまで検証すれば通過させられるかを前もって合意しておく文書だ。

使い方

下のマトリクスをプロジェクトのdocs/またはspecs/に一度コピーしておき、サイクルごとに新しく作らない。等級の判定基準(説明部分)はプロジェクトのドメインに合わせて調整してよいが、「人間レビュー必須の可否」は調整後もチームの合意を取り直す — 検証強度を下げる調整は、すなわちリスクをより引き受けるという決定だからだ。実際の検証時点では、マトリクス下の「成果物別判定」表に今サイクルで扱う成果物を埋め、どの等級か、なぜその等級かを記録する。

テンプレート

markdown
# リスクマトリクス

<!-- 記入ガイド: 等級定義はプロジェクトのドメインに合わせて調整可能だが、調整時はチームの合意を取り直す。 -->

| 等級 | 該当領域 (例) | 人間レビュー | 交差レビュー (別のエージェント) | 自動テスト水準 |
|---|---|---|---|---|
| High | 決済、認証、個人情報処理、非可逆なデータ変更(削除・マイグレーション) | 必須 — マージ前の承認なしにはデプロイ不可 | 必須 — 実装したエージェントと異なるセッションが整合性・抜けたケースを点検 | ユニットテスト + 統合テスト + 境界値/失敗ケースをカバー |
| Medium | 中核の業務ロジック(価格計算、権限分岐、通知送信の条件など) | 推奨 — リスクが高いと判断されれば昇格 | 推奨 — 余裕がなければ省略可だが理由を記録 | ユニットテスト必須、主要な分岐をカバー |
| Low | 内部ツール、プロトタイプ、文書/スタイルの変更、戻しやすい設定 | 省略可 — 自動検証の通過だけで進行 | 省略可 | 既存のテストが通れば十分、新規テストは強制しない |

## 等級の判定基準

<!-- 記入ガイド: 曖昧な境界事例をどちらに判定するかの原則を残す。 -->

- **戻せるか。** 失敗したとき即座にロールバック可能なら一段階低い等級に判定できる。データ削除・課金のように戻せないなら無条件でHighだ。
- **影響範囲がどれだけ広いか。** 全ユーザーに影響する認証・決済ロジックはHigh。特定の管理者画面にだけ影響するロジックはMedium以下に判定できる。
- **曖昧なら一段階上げる。** HighとMediumの間で判断がつかなければHighとして扱う。検証を多くするコストは、事故のコストより常に安い。

## 成果物別判定

<!-- 記入ガイド: 今サイクルで検証する成果物を実際に埋める。「なぜこの等級か」は省略しない。 -->

| 成果物 | 等級 | 判定根拠 |
|---|---|---|
| 例: 決済手段登録API | High | 決済情報を直接扱い、失敗時にロールバックが難しい外部PG連携を含む |
| 例: 割引率計算ロジックの改修 | Medium | 売上に影響するが特定のプロモーション画面に限定、デプロイ後に即座にロールバック可能 |
| 例: 内部管理ダッシュボードのフィルタUI | Low | 内部ツール、間違ってもデータ破損なし |