失敗する場面を具体的に書く
顧客が集まらない、外部サービスが止まる、情報が漏れる、担当者が不在になるなど、事象として表現します。「技術リスク」のような分類名だけでは対処できません。原因と結果を分けると、予防と復旧を考えやすくなります。
影響と発生可能性を比較する
数値の精密さより、チームで同じ基準を使うことを優先します。発生しにくくても重大な影響があるものは別途判断します。評価の根拠がない場合は、その不確実さ自体を残してください。
対応を四つに分ける
その活動を避ける、起きにくくする、契約や保険などで負担の分担を検討する、残る影響を理解して受け入れる、という選択肢を考えます。何もしない場合でも、誰が判断したかと監視条件を記録します。
運用へつなげる
兆候、対応者、連絡先、期限を管理表に付けます。障害対応の訓練や公開判定と結び付け、状況が変わったら評価を更新します。リスク管理を別会議だけの仕事にせず、通常の意思決定へ組み込みます。
参考資料と編集について
新規事業.com の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。
編集：Otsumu株式会社 ／ 編集日