リスクマトリックス: 発生確率と影響度のスコアリング方法(テンプレート付き)

発生確率と影響度をスコアリングするリスクマトリックスのグリッド

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

リスクマトリックスは、漠然としたプロジェクトの懸念事項リストを、実際に注意すべき優先順位付きの実用的な図に変える最速の方法です。すべてのリスクを同じように緊急だと扱うのではなく、マトリックスは各リスクを2つの軸、つまり「発生する可能性の高さ」と「発生した場合の深刻さ」でスコアリングします。その結果、重大な脅威と些細な懸念を一目で切り分けられるグリッドが出来上がります。

プロジェクトマネージャー、リスク管理担当者、経営層は、製品ローンチ、システム移行、建設プロジェクト、規制対応の変更など、影響の大きい取り組みを始める前にこのツールを使います。ただし、このツールの価値はスコアリングの規律次第です。本ガイドでは、その仕組み、最も一般的なサイズの選択(3x3か5x5か)、段階的な作成手順、そしてこの手法全体を静かに損なってしまうよくある間違いを解説します。

リスクマトリックスとは

リスクマトリックス(発生確率・影響度マトリックス、またはリスク評価マトリックスとも呼ばれます)は、一方の軸に発生の可能性、もう一方の軸に影響の深刻度を配置した二次元グリッドです。グリッド内の各セルは、合計したリスクスコアを表します。スコアが高いほど、対応の緊急度も高くなります。

この考え方は、ISO 31000とPMBOKガイドの基本的な計算式に基づいています。

リスクスコア = 発生確率 x 影響度

この式は一見単純に見えますが、その真価はリストにあるすべてのリスクに一貫して適用することで発揮されます。そうすることで、性質のまったく異なる脅威同士を比較できるようになります。サプライチェーンの遅延とデータ漏洩は、どちらも並べ替えたり色分けしたり担当者を割り当てたりできる数値に変換されます。

マトリックスは判断そのものに取って代わるものではなく、判断を構造化するものです。2つのリスクが同じ数値スコアを持っていても、可逆性、規制上のリスク、戦略的な文脈によってまったく異なる対応が必要になることがあります。グリッドはどこから見るべきかを示し、そこから何をするかを決めるのはチームです。

重要なポイント

  • 国際的なリスクマネジメント規格であるISO 31000:2018は、リスクを「目的に対する不確実性の影響」と定義し、あらゆるリスク評価の基本要素として発生可能性と結果の両方を評価することを推奨しています。
  • PMBOKガイド第7版は、発生確率・影響度マトリックスを定性的リスク分析の中核ツールとして位置づけ、個々のプロジェクトリスクをさらなる分析や対応のために優先順位付けする目的で使用するとしています。
  • プロジェクトマネジメント協会(PMI)が2023年に実施した調査では、成熟したリスク管理プラクティスを持つ組織は、非公式または未整備なリスクプロセスの組織に比べて、当初のプロジェクト目標を達成する可能性が28%高いことが分かりました(PMI Pulse of the Profession 2023)。

リスクマトリックスの仕組み

マトリックスには2つの軸があります。発生確率(または可能性)は通常縦軸に、影響度(または結果)は通常横軸に配置されます。各軸はレーティングレベルに分割され、3x3マトリックスなら3段階、5x5マトリックスなら5段階になります。

発生確率スケール

レベル ラベル 定義
1 まれ 10%未満の可能性。類似プロジェクトで発生したことがない
2 起こりにくい 10~30%の可能性。まれに発生したことがある
3 起こり得る 30~50%の可能性。発生しても驚きではない
4 起こりやすい 50~75%の可能性。ほとんどの類似プロジェクトで発生している
5 ほぼ確実 75%を超える可能性。発生が見込まれる

影響度スケール

レベル ラベル 定義
1 軽微 わずかな不便。スケジュール、コスト、品質への影響なし
2 小規模な遅延やコスト超過。社内で解決可能
3 中程度 スコープ、予算、スケジュールに目に見える影響。マネジメントの注意が必要
4 重大なコスト超過やスケジュール遅延。プロジェクト目標に影響
5 壊滅的 プロジェクトの失敗、深刻な財務損失、規制違反、または安全上の事故

リスクスコアのゾーン分け(5x5グリッド)

発生確率と影響度を掛け合わせるとリスクスコア(125)が得られます。多くのチームはスコアを34段階の対応ゾーンに割り当てます。

発生確率 / 影響度 1 軽微 2 小 3 中程度 4 大 5 壊滅的
5 ほぼ確実 5 10 15 20 25
4 起こりやすい 4 8 12 16 20
3 起こり得る 3 6 9 12 15
2 起こりにくい 2 4 6 8 10
1 まれ 1 2 3 4 5

スコアゾーン:

  • 1~4(低): 監視のみ。即座の対応は不要
  • 5~9(中): 担当者を割り当て、対応計画を立てるが受容も可
  • 10~16(高): 積極的に管理。プロジェクトを進める前に軽減策が必要
  • 17~25(重大): 直ちにエスカレーション。プロジェクトの中断や再設計が必要な場合もある

3x3マトリックスと5x5マトリックスの違い

最もよくある疑問は、各軸を3段階にするか5段階にするかです。どちらも有効です。選択はプロジェクトの複雑さと、チームが実際に維持できるスコアリングの粒度によって決まります。

観点 3x3マトリックス 5x5マトリックス
スコア範囲 1~9 1~25
適した用途 シンプルなプロジェクト、初期段階のスコーピング、経営層向けの概要 複雑なプロジェクト、規制業界、正式なリスクレジスター
粒度 低い(大まかな区分) 高い(より細かい区別が可能)
同点スコアのリスク 高い(多くのリスクが同じセルに集中しやすい) 低い
キャリブレーションの手間 少ない 多い(5段階はより明確な定義が必要)
一般的な用途 小規模チーム、短時間のリスクワークショップ PMO主導のプログラム、建設、製薬、ITトランスフォーメーション

3x3マトリックスは記入しやすく、ステークホルダーへの説明もしやすい形式です。5x5マトリックスは、例えば発生確率20%のリスクと40%のリスクを区別したい場合に適しています。3x3では両方とも「中」帯に入ってしまうリスクでも、実際にはまったく異なる対応が求められることがあるためです。

リスクマトリックスの作成方法

ステップ1: 発生確率のレベルを定義する

各発生確率のレーティングが、自分たちのプロジェクトにとって実際に何を意味するのかを書き出します。「起こりやすい」という言葉が意味する内容は、2週間のスプリントと3年間のインフラプログラムとではまったく異なります。各レベルをパーセンテージの範囲と結びつけ、可能であればチームが認識している過去の事例とも関連付けましょう。

ステップ2: 影響度のレベルを定義する

影響度についても同様に行います。各レベルを、具体的な結果、すなわち何日分のスケジュール遅延なのか、どの程度のコスト超過なのか、どのような品質・規制上の結果になるのかにマッピングします。具体的な基準があることで、異なる人が同じリスクを評価したときの主観的なブレを減らせます。

ステップ3: リスクを洗い出してリストにする

構造化されたブレインストーミング、専門家へのインタビュー、教訓ログ、あるいはプレモーテム(事前検証)によってリスクを収集します。スコアリングの前に、それぞれをリスクレジスターに記録します。マトリックスはリスクの順位を示すもの、レジスターはそれを時系列で追跡するものです。

ステップ4: 各リスクをスコアリングする

各リスクについて、発生確率と影響度をそれぞれ独立して評価します。可能であればグループで行いましょう。評価にばらつきが出た場合、そこに議論すべき隠れた前提が浮かび上がってきます。2つの評価を掛け合わせてリスクスコアを算出し、グリッド上にリスクをプロットします。

ステップ5: 対応のしきい値を設定し、担当者を割り当てる

各スコアゾーンで何が必要になるかを事前に決めておきます。重大なリスクには、作業を続ける前に、担当者の指名、軽減策、レビュー日が必要です。高リスクには1週間以内の対応計画が必要です。中リスクはウォッチリストに載せます。低リスクは記録して監視します。あらかじめしきい値を決めておかなければ、マトリックスは意思決定ツールではなく単なる飾りになってしまいます。

メリット

共通言語ができる。 全員が同じ発生確率・影響度の定義を使うことで、リスクに関する会話が単なる印象論ではなくなります。開発者、財務責任者、経営層が同じセルを見て、その意味について合意できるようになります。

大規模な優先順位付けができる。 30~40件のリスクが洗い出されたプロジェクトでは、すべてに同じように対応することはできません。マトリックスは順位付けを強制することで、露出度が最も高い部分に時間と予算を集中させられるようにします。

早期警戒になる。 中ゾーンから始まったリスクは、プロジェクトのフェーズを通じて追跡できます。プロジェクトの途中でリスクの発生確率が「起こりにくい」から「起こり得る」に上がった場合、マトリックスはその変化を明確に示し、リスクが問題化する前に議論のきっかけを作ります。

ステークホルダーへの伝達に役立つ。 色分けされたグリッドは、生の数値を並べた表よりも、ステアリングコミッティ向けの資料でははるかに読みやすくなります。赤・黄・緑のゾーンは、複雑な分析を即座に理解できる視覚的なシグナルに変換します。

監査証跡になる。 日付とバージョンが記録されたマトリックスは、リスクが正式に評価され、積極的に管理されていたことを示す証拠として、規制当局、監査人、スポンサーに提示できます。製薬、建設、金融といった業界では、この記録がしばしば義務付けられています。

よくある間違い

基準のない主観的なスコアリング。 発生確率のレベルが「低」「中」「高」としか定義されておらず、裏付けとなる基準がない場合、5人が同じリスクを評価すれば5通りのスコアが出てしまいます。各レベルをパーセンテージの範囲と具体的な事例で定義しましょう。

スコアゾーンのしきい値を無視すること。 チームによっては、美しいマトリックスを作り、正しく色分けしたにもかかわらず、すべてのリスクに同じ対応をしてしまうことがあります。ゾーンを分ける目的は、それぞれ異なる対応を引き起こすことにあります。赤ゾーンに入った重大リスクは必ずエスカレーションされなければなりません。代わりにウォッチリストに載せてしまえば、マトリックスは機能していないことになります。

マトリックスを一度きりの成果物として扱うこと。 プロジェクトが進むにつれて、リスクプロファイルは変化します。キックオフ時には発生確率が低かったリスクが、3か月後にはほぼ確実になっていることもあります。要件確定後、調達後、稼働開始後といった主要なマイルストーンで、リスクを再スコアリングしましょう。静的なマトリックスは誤った安心感を生みます。

影響度のカテゴリを混同すること。 スケジュールへの影響と財務への影響は同じものではありません。2週間の遅延を引き起こすリスクは、社内チームであればほとんどコストがかからないかもしれませんが、違約金付きの固定価格契約では同じ遅延が壊滅的になり得ます。リスクの大きいプログラムでは、影響度の次元を分けて管理するか、加重した複合スコアの利用を検討しましょう。

マトリックスの過密化。 すべてのリスクが中ゾーンに集中している場合、スコアリングの定義がおそらく緩すぎます。実際のリスクプロファイルを反映するよう再調整しましょう。右上のセルはまばらであるべきです。そこが埋まっているなら、本当に危険なプロジェクトであるか、基準を厳格にする必要があります。

リスクマトリックスの実例

あるSaaS企業が、顧客データベースを新しいクラウドプロバイダーに移行しようとしています。プロジェクトマネージャーがリスクワークショップを実施し、5つの主要なリスクを洗い出しました。

リスク 発生確率 影響度 スコア ゾーン
移行中のデータ損失 2(起こりにくい) 5(壊滅的) 10
サードパーティベンダーの遅延 4(起こりやすい) 3(中程度) 12
チームの稼働可否の競合(休暇の重複) 3(起こり得る) 2(小) 6
規制当局のレビューが予定より長引く 2(起こりにくい) 4(大) 8
移行後のパフォーマンス低下 3(起こり得る) 3(中程度) 9

データ損失のリスクは、発生確率は低いもののスコアが10となっています。影響が壊滅的だからです。このリスクには担当者(エンジニアリングリード)が指名され、移行開始前にロールバック計画が文書化され、切り替え期間中は毎日の状況確認が行われます。ベンダー遅延のリスクはスコア12で、契約条項の追加とバックアップベンダーの選定が行われます。残る3件はウォッチリストに載せられ、2週間ごとに確認されます。

これはマトリックスが本来の役割を果たしている例です。性質の異なる2つのリスク(偶発的なデータ損失とベンダーのスケジュール問題)が、いずれも「高」まで引き上げられ、どちらも積極的な管理の対象になっています。

ベストプラクティス

過去のデータでキャリブレーションする。 組織が過去に類似のプロジェクトを実施している場合は、実際の過去のリスク発生頻度を発生確率の定義の基準として使いましょう。勘は揺らぎますが、インシデントの記録は揺らぎません。

固有リスクと残存リスクを分けて考える。 対策を講じる前(固有リスク)と対策を講じた後(残存リスク)の両方でリスクをスコアリングします。この2つの差が、現在の対策が実際にどれだけの価値を提供しているかを示します。対策後も残存スコアが依然として「高」であれば、対策が不十分であり、強化が必要ということです。

マトリックスと合わせてRAIDログを使う。 マトリックスはリスクの順位を示し、RAIDログは前提条件、課題、依存関係といった文脈の中でリスクを追跡します。この2つのツールは代替するものではなく、補い合うものです。

マトリックスをプロジェクトリスクマネジメント計画と連携させる。 マトリックスはあくまでスナップショットです。より広範なリスクマネジメント計画は、再スコアリングの頻度、リスクレビューへの参加者、リスクのエスカレーション方法、クローズしたリスクの文書化方法を定めます。この計画がなければ、マトリックスは宙に浮いたままになります。

スケジュールやコストのリスクにはモンテカルロシミュレーションの活用を検討する。 マトリックスは定性的なツールであり、複数のリスクが同時に発生した場合の複合的な影響をモデル化することはできません。スケジュールや予算の変動が重要になる大規模なプログラムでは、モンテカルロ法がマトリックスでは捉えられない定量的な層を提供します。

リスク対応をステークホルダー分析マトリックスと連携させる。 重大・高リスクは、ステークホルダーごとに個別のコミュニケーション計画が必要になることがよくあります。誰がどのリスクを気にかけていて、軽減策を承認する権限をどれだけ持っているかを把握することで、対応計画の実行可能性は大きく高まります。

対応のバックログにはMoSCoW優先順位付けを適用する。 チームが同時に軽減できる以上の高リスクを抱えている場合は、優先順位付けのフレームワークを使って、どの対応を他より先に行うべきかを判断しましょう。

よくある質問

リスクマトリックスとリスクレジスターの違いは何ですか?

リスクレジスターは、識別されたすべてのリスクの完全なカタログであり、プロジェクトのライフサイクル全体を通じて、その説明、担当者、ステータス、対応計画を追跡します。一方、リスクマトリックスは、ある時点における発生確率と影響度でリスクを順位付けするスコアリング・可視化ツールです。レジスターが記録であり、マトリックスが順位付けです。多くのプロジェクトチームはこの2つを併用し、レジスターで詳細を保持しつつ、マトリックスで優先順位に関する議論を進めます。

リスクマトリックスはどのくらいの頻度で更新すべきですか?

最低限、キックオフ後、要件承認後、主要な調達の意思決定後、そして各主要な納品フェーズの前といった、プロジェクトの主要なマイルストーンごとにマトリックスを再スコアリングしましょう。複雑度が高い、あるいは変化の速いプロジェクトでは、月次あるいは2週間ごとのレビューが有効です。リスクは静的なものではなく、更新なしではプロジェクト開始時には正確だったマトリックスも、6週間後には危険なほど実態とかけ離れたものになりかねません。

1つのリスクがマトリックス上の複数のセルに現れることはありますか?

いいえ。各リスクは、評価サイクルごとに、現時点で最も妥当と考えられる発生確率と影響度に基づいて、1つのスコアだけを持ちます。あるリスクが、他に何が先に起こるかによって発生確率や影響度が大きく変わる場合は、依存関係を明記した上で2つの別々のリスクとして扱うか、異なるプロジェクト条件下で評価するシナリオベースのスコアリングを使いましょう。

マトリックス上での固有リスクと残存リスクの違いは何ですか?

固有リスクとは、対策や軽減策を一切講じる前のスコア、つまり何もしなかった場合に何が起こるかを示すものです。残存リスクとは、計画した対策を実施した後のスコアです。どちらも追跡する価値があります。対策後も残存スコアが依然として「高」であれば、それは対策が不十分であり、追加や強化が必要であることを示しています。

規制対応や安全性が重要なプロジェクトでは、リスクマトリックスだけで十分ですか?

マトリックスは有用な出発点ですが、製薬、建設、航空、金融サービスといった規制業界では、通常、定量的リスク分析、正式なハザード特定手法、文書化されたレビュー記録といった、より高い厳密性が求められます。ISO 31000や業界固有の規格が、より広範な枠組みを提供します。マトリックスは、その枠組みの中で、完全なリスクマネジメントプロセスとしてではなく、定性的な一次トリアージツールとして位置づけられます。

リスクマトリックスは、すべてのリスクを同じように緊急だと扱うのをやめるための、構造化された手段を与えてくれます。一度スコアリングし、各ゾーンに適切な対応を割り当て、プロジェクトの進行に合わせて見直しましょう。しっかりとしたリスクレジスターと明確なエスカレーションの道筋を組み合わせれば、あらゆるプロジェクトマネージャーのツールキットの中でも、最も実用的なツールの一つになります。

About the author

Tara Minh

Tara Minh

Senior Operations & Growth Strategist

Tara Minh is Senior Operations & Growth Strategist at Rework, helping B2B SaaS leaders scale without breaking their teams. With 8+ years in revenue operations and process optimization, Tara turns messy workflows into systems people actually follow. Readers get practical frameworks they can use to cut waste, align teams, and grow on purpose.