リスクマトリクスの作り方：評価を具体的な対応につなげる

リスクマトリクスは、何を優先し、次にどう対応するかを決めるために使います。この記事では、あるリリースのリスクを例に、評価、対応責任者、対応を切り替える条件、残留リスクの見直しまでを整理します。例に使う数値は、測定した確率ではなく説明用の評価点です。

リスクの評価も、目的や担当者とのつながりを明確にすると扱いやすくなります。プロジェクト管理の用語と手法を押さえたうえで、評価の根拠と次の行動を同じ場所に残しておきましょう。

採点する前にリスクを具体化する

起こり得る事象、その原因、発生した場合の影響を分けて書きます。「リリースが遅れる」だけでは、参加者が同じ基準で評価できません。たとえば「決済プロバイダーの変更に伴う認証を予定期間内に完了できず、新しい決済機能をリリースできなくなる可能性がある」とします。まだ発生していない事象と、その結果が区別され、今回のリリースという範囲も明確になります。

チームで説明できる評価尺度を決める

具体的なリスクを話し合う前に、少数の段階からなる順序尺度を定義します。たとえば発生可能性の1は「今回の条件では起こりにくい」、5は「得られた情報から、起こる可能性が非常に高いと考えられる」とします。影響度の1はリリースの目的にほとんど影響しない状態、5は目的の達成が危ぶまれるか、計画の大幅な変更が必要になる状態です。これらはチームで合意する評価段階であり、確率のパーセントを表すものではありません。

一つのリスクをマトリクスで評価する

決済の認証に関するリスクを、発生可能性4、影響度5と評価したとします。掛け合わせた評価点は20です。この点数は優先順位を考える目安であり、損失額の予測ではありません。認証の予約がまだ確定しておらず、この例ではプロバイダーが過去に連携ルールを変更しているため、4と5を選んだと記録します。新しい情報が得られたら、評価も見直します。

評価を担当者のいる対応につなげる

マスに色を付けただけでは、リスクは軽減されません。対応内容、責任者、期限、代替案へ切り替える条件を決めます。この例では、認証の予約を依頼し、テスト用加盟店アカウントを準備します。決めた日までに予約が確定しなければ、リリース計画をどう変更するか判断できるようにしておきます。責任者は対応を調整する人であり、すべての外部依存関係を制御できる人という意味ではありません。

対応後に残留リスクを見直す

対応を実施したら、最初の色を残したままにせず、どのリスクがまだ残っているかを評価します。認証の予約が確定すれば遅延の可能性は下がるかもしれません。一方で、プロバイダー側が対応できる時期に依存する部分があれば、影響度は高いままの場合もあります。元の評価、新しい評価の根拠、次の確認日を残しましょう。対応を割り当てただけで、リスクを解消済みにしてはいけません。

Boardmixでリスクの議論を整理する

Boardmixのボード上部にリリースの目的とリスクの記述を置きます。発生可能性と影響度のマス目の横にリスク一覧を配置し、優先度の高い項目ごとに責任者、対応、行動を起こす条件を記します。評価点の近くには根拠となる情報をメモします。この進め方では、評価や対応状況をチーム自身が記入し、ボードを使って議論に必要な情報を一か所に整理します。

Boardmixのボードを開き、次のリリースで気になるリスクを同じ構成で整理してみてください。仮定と確認済みの情報を分けておくと、何を調べる必要があるかが分かります。