novel-jp/learn-se-risk

/learn-se-risk — リスク識別と管理（04-03）

実装中のリスクを洗い出し、mitigation を定義して管理する演習です。

所要時間: 約 45 分 前提: /learn-se-workflow（04-02）完了済み スキル対応: Specification Engineering（自律実行できる仕様）

---

Step 1: 導入

「リスクとは『まだ起きていない問題』です。
Issue は『既に起きた問題』。この区別が重要です。

リスク管理は問題を予防する技術:
- 事前に洗い出し → mitigation（緩和策）を定義
- probability（発生確率）× impact（影響度）で優先度を決定
- ステータスを更新し続ける: identified → planned → resolved

『リスクを登録して終わり』ではなく、計画し、対処し、結果を記録するサイクルを回します。」

---

Step 2: リスクの洗い出し

まず list_deliverables(projectId) で、04-01 で定義した自分の成果物を確認する。

「まず、あなたの成果物を確認しましょう。」

list_deliverables(projectId) を実行し、成果物の一覧を表示する。

成果物を確認したら、それに関連するリスクを 3 件考えてもらう。

| カテゴリ | 例 | | -------------- | --------------------------------------------------- | | technical | 「外部 API の仕様変更でデータ取得が失敗する」 | | schedule | 「認証ライブラリの学習コストが想定以上にかかる」 | | dependency | 「バックエンドの API が未完成で結合テストが遅れる」 | | external | 「サードパーティサービスの障害で機能が停止する」 |

「あなたの成果物について、3 つのリスクを考えてください。

ヒント:
- 技術的な不確実性はないか？（未経験の技術、複雑なロジック）
  例: 初めて使うライブラリで想定外のエラーが出るかもしれない
- スケジュールに影響する要因はないか？（学習コスト、レビュー待ち）
  例: 公式ドキュメントが英語のみで、読解に予想以上の時間がかかるかもしれない
- 外部への依存はないか？（API、ライブラリ、チームメンバー）
  例: 使おうとしているOSSライブラリのメンテナンスが停滞していて、バグ修正が得られないかもしれない」

---

Step 3: upsert_risk で登録

各リスクを upsert_risk で ProjSight に登録する。

以下のフィールドを記入するよう誘導:

| フィールド | 説明 | 値の範囲 | | --------------- | ------------------------ | -------------------------------------------- | | probability | 発生確率 | 1〜5（下記ルーブリック参照） | | impact | 影響度 | 1〜5（下記ルーブリック参照） | | category | リスク分類 | technical / schedule / dependency / external | | description | リスクの詳細（Markdown） | 状況・影響範囲・根拠を含める | | mitigation | 緩和策 | 具体的な対策を記述 |

probability（発生確率）の判断基準

| 値 | レベル | 目安 | | --- | ------------ | -------------------------------------------------------- | | 1 | ほぼ起きない | 過去に前例がなく、条件も揃いにくい | | 2 | 起きにくい | 可能性はあるが、通常の状況では発生しない | | 3 | 五分五分 | 条件次第では十分に起こりうる | | 4 | 起きやすい | 過去に類似の問題が発生している、または条件が揃いつつある | | 5 | ほぼ確実 | 既に兆候がある、または時間の問題で発生する |

impact（影響度）の判断基準

| 値 | レベル | 目安 | | --- | ------ | ---------------------------------------------- | | 1 | 軽微 | 軽微な手戻り。数時間で対処可能 | | 2 | 小さい | 一部の機能に影響。1〜2日の遅延 | | 3 | 中程度 | 主要機能に影響。スケジュール調整が必要 | | 4 | 大きい | 複数の成果物に波及。マイルストーンに影響 | | 5 | 致命的 | プロジェクト停止レベル。根本的な方針変更が必要 |

description の書き方

良い例:

## 状況

外部決済APIの仕様がv2からv3へのマイグレーション期間中で、
v2の廃止日が未確定。

## 影響範囲

決済モジュール全体（3画面 + 2 APIエンドポイント）

## 根拠

公式ブログで「年内にv2廃止予定」と発表済み。
過去にも予告なしでフィールドが変更された実績がある。

悪い例:

外部APIが変わるかもしれない

→ 何のAPI？ どう変わる？ 影響はどこに？ が分からず、対策が立てられない。

mitigation（緩和策）の書き方

「mitigation（緩和策）は具体的に書いてください。
『注意する』『気をつける』は緩和策ではありません。
『〜の場合は〜を実行する』のように、アクションを明確にしましょう。」

良い mitigation の例:

• 「外部API仕様変更リスク → レスポンスの JSON スキーマバリデーションを追加し、スキーマ不一致を検知したらアラート通知する。v3 移行ガイドを事前に確認し、互換レイヤーを設計する」
• 「学習コスト超過リスク → 最初の2日間でプロトタイプを作成し、想定工数との乖離が20%以上なら代替ライブラリに切り替える。判断基準と代替候補を事前に決めておく」

2段階登録で体験する

ここでは ステータス遷移を体験するために2段階 で登録を行います。実運用では1回の upsert_risk 呼び出しで全フィールドを渡して完了できます。

1. upsert_risk(projectId, title, description, probability, impact, category) でリスクを作成（status は自動的に identified）
2. upsert_risk(riskId, status: 'planned', mitigation: '...') で緩和策を設定し status を更新

---

Step 4: リスクの severity 確認

list_risks で登録したリスクの一覧を確認し、severity の順位を確認する。

「登録したリスクを確認しましょう。

severity = probability × impact のスコアで優先度が決まります:
- 15〜25: 高（即座に対応が必要）
- 8〜14: 中（計画的に対応）
- 1〜7: 低（モニタリング）

スコアが高いリスクから優先的に対応します。
あなたの 3 件のリスクで、最もスコアが高いものはどれですか？」

list_risks の出力で各リスクの severity を確認する。Web UI ではヒートマップ（確率 × 影響マトリクス）として視覚的に確認することもできます。

---

Step 5: 振り返り

「リスク管理のポイント:
- リスクは登録して終わりではなく、ステータスを更新し続ける
- planned → resolved（対策を実施して解決）or closed（リスクが消滅）
- リスクが顕在化したら → Issue を起票し、create_link(caused_by) で紐づける
- 緩和策は『アクション』で書く — 抽象的な方針ではなく具体的な手順

AI にリスク情報を渡すことで、実装時に『ここは慎重に』という判断ができます。
具体的には、start_work(taskId) を実行すると、プロジェクトの alerts にリスク情報が含まれて返却されます。
また、list_risks で明示的にリスク一覧を取得し、タスクの description や notes に関連リスクを記載しておくことで、AI が実装時にリスクを考慮した判断を行えます。
仕様にリスクと制約を組み込むことが、Specification Engineering の本質です。

次の /learn-se-dependency では、タスク間の依存関係を管理する方法を学びます。」

受講者のタスクを complete_work(taskId) で完了にする。