risk-assessment

目的

実装や行動に移る前に、自分自身に問いを投げかけ、深い思考を行う。

自問自答フレームワーク

1. 前提の検証

2. なぜなぜ分析

3. 深さの検証

4. リスクの洗い出し

5. 設計判断の評価

リスク対応戦略

リスクを特定したら、以下の4戦略から選択する：

戦略	意味	適用場面
回避	リスクを発生させる活動をやめる	影響が致命的で代替手段がある
軽減	発生確率や影響度を下げる	コストと効果のバランスが取れる
転嫁	第三者に移転する	専門性が必要、保険で対応可能
受容	認識した上で受け入れる	影響が軽微、対策コストが見合わない

ADRへの記録

プロジェクト固有の重要な意思決定は ./docs/adr にADRとして記録する。

記録すべき意思決定

• 技術選定（フレームワーク、ライブラリ、インフラ）
• アーキテクチャ変更
• リスク対応で「回避」「転嫁」を選択した場合
• トレードオフを伴う設計判断

記録しないもの

• 一時的な対応、ワークアラウンド
• 自明な選択
• 実装詳細（設計書ではない）

文体ルール

ADRは時間経過で陳腐化しないストック情報とする。現在形で記述する。

NG	OK
〜した（過去形）	〜する（現在形）
現在〜している	〜である
今後〜する予定	〜する方針である
最近〜が発生した	〜という問題がある

ステータス

採用

コンテキスト

VPC Endpoint + NLB構成はTeam Planでのみ利用可能である。

決定

Public ALBを採用する。

理由

• コスト: VPC Endpoint不要により月額コストを削減できる
• 複雑性: VPC設定が不要となる
• 要件: 内部通信の秘匿性は必須要件ではない

リスクと対応

• リスク: エンドポイントが公開される
• 対応（軽減）: WAF + IP制限を適用する

適用タイミング

タイミング	適用する問い
Plan Mode突入時	前提の検証、代替案の検討
実装開始前	深さの検証、設計判断
PR作成前	リスクの洗い出し → 対応戦略の選択
エラー発生時	なぜなぜ分析
重要な意思決定時	ADRとして ./docs/adr に記録

アンチパターン

振る舞い	問題	代わりに
言われたことをそのまま実行	前提が間違っている可能性	「本当に必要か」を問う
症状だけ治す	再発する	根本原因まで掘り下げる
一つの方法だけ提案	最適解でない可能性	代替案を検討する
「連携」「統合」で終わる	手段が目的化	具体的な価値を明示