フレームワーク活用ガイドひとことで言うと#
横軸に「発生確率」、縦軸に「影響度」を取った2次元マトリクスにリスクを配置し、赤・黄・緑で優先度を色分けするツール。どのリスクに優先的に手を打つべきか、一目で判断できる。
押さえておきたい用語#
- 発生確率（Probability）
- リスクが実際に起こる可能性の高さのこと。低・中・高の3段階または5段階で評価する。
- 影響度（Impact）
- リスクが顕在化した場合のプロジェクトへのダメージの大きさのこと。コスト・スケジュール・品質への影響で評価する。
- リスクスコア（Risk Score）
- 発生確率と影響度を掛け合わせた数値のこと。スコアが高いリスクから優先的に対処する。
- リスク対応戦略（Risk Response Strategy）
- リスクに対する回避・軽減・転嫁・受容の4つの対応方針のこと。赤・黄のリスクに具体策を設定する。
リスクマトリクスの全体像#
こんな悩みに効く#
- リスクは洗い出したものの、どれから対処すればいいかわからない
- 「全部重要」になってしまい、結局何も対処できない
- チーム内でリスクの認識がバラバラで、議論がかみ合わない
基本の使い方#
プロジェクトに潜むリスクをチームで網羅的に洗い出す。
- ブレインストーミングやチェックリストを使ってリスクを列挙する
- 過去の類似プロジェクトの教訓も参照する
- 技術リスク、人的リスク、外部リスク、スケジュールリスクなどカテゴリ別に考える
ポイント: この段階では取捨選択せず、思いつくものを全部出す。
各リスクの「起きやすさ」と「起きたときの影響の大きさ」を評価する。
- 発生確率: 低（1）・中（2）・高（3）の3段階、または5段階で評価
- 影響度: 低（1）・中（2）・高（3）の3段階、または5段階で評価
- チームで合意を取りながら評価する（個人の感覚に頼らない）
ポイント: 定量データがあれば活用する。なければチームの経験に基づく定性評価でOK。
評価結果をもとに、各リスクをマトリクス上に配置する。
- 右上（高確率×高影響）＝赤：最優先で対処
- 中間エリア＝黄：監視対象として計画的に対処
- 左下（低確率×低影響）＝緑：受容（許容）するか、簡易な対策で十分
ポイント: 全リスクを一枚の図に並べることで、チーム全体の共通認識ができる。
赤・黄のリスクに対して、具体的な対応策を決める。
- 回避: リスクの原因を除去する
- 軽減: 発生確率や影響度を下げる施策を打つ
- 転嫁: 保険や外注で第三者に移す
- 受容: 小さなリスクは受け入れて、発生時に対応する
ポイント: 対応策には担当者と期限を必ず設定する。「誰かがそのうちやる」では実行されない。
具体例#
リスク洗い出し: チーム全員でブレスト。15件のリスクを特定。
評価結果（上位5件）:
| リスク | 確率 | 影響度 | スコア | 色 |
|---|---|---|---|---|
| (A) 主要開発者の離職 | 中(2) | 高(3) | 6 | 黄 |
| (B) 外部APIの仕様変更 | 高(3) | 高(3) | 9 | 赤 |
| (C) サーバー障害 | 低(1) | 高(3) | 3 | 黄 |
| (D) 競合の先行リリース | 高(3) | 中(2) | 6 | 黄 |
| (E) 法規制の変更 | 低(1) | 低(1) | 1 | 緑 |
対応計画:
- (B) 外部APIリスク【回避+軽減】: API変更の監視体制構築 + 抽象化レイヤーの実装（担当: CTO、2週間以内）
- (A) 離職リスク【軽減】: ナレッジ共有とペアプロでの属人化解消（担当: TL、即日開始）
- (D) 競合リスク【軽減】: MVPの範囲を最小化し、リリースを2週間前倒し
結果: 実際に外部APIの仕様変更が発生したが、抽象化レイヤーにより対応工数が想定40時間→8時間で完了。リスクマトリクスによる事前対策が奏功した。
背景: 大手製造業のERP導入。50名体制、18ヶ月。過去の類似プロジェクトで「データ移行」と「ユーザー教育」が頻出リスクだったことを教訓DBから確認。
5×5マトリクスでの評価: 20件のリスクを5段階（1〜5）で評価。
| リスク | 確率 | 影響度 | スコア | 対応戦略 |
|---|---|---|---|---|
| データ移行の不整合 | 4 | 5 | 20 | 軽減：本番データサンプルでのテストを3回実施 |
| カスタマイズ範囲の膨張 | 4 | 4 | 16 | 回避：カスタマイズ上限を契約で明記 |
| ユーザーの抵抗 | 3 | 4 | 12 | 軽減：チェンジマネジメント担当者を配置 |
| ベンダーの要員不足 | 3 | 3 | 9 | 転嫁：SLA契約で要員補充義務を明記 |
| 為替変動（ライセンス費） | 2 | 2 | 4 | 受容：予備費10%で対応 |
月次リスクレビューの推移:
| 時点 | 赤リスク数 | 黄リスク数 | 緑リスク数 |
|---|---|---|---|
| 開始時 | 3 | 8 | 9 |
| 6ヶ月後 | 1 | 6 | 13 |
| 12ヶ月後 | 0 | 4 | 16 |
結果: 月次レビューで赤リスクを段階的に解消。データ移行テスト3回実施により、本番移行でのエラーは0.02%（業界平均1〜3%）に抑制。予算内・ほぼ計画通りのリリースを達成。
背景: 県の防災情報システム更新。3ベンダーが参画、24ヶ月。住民の安全に直結するためリスク管理が特に重要。
リスクマトリクスの工夫: 影響度を「コスト」「スケジュール」「安全性」の3軸で評価し、安全性に2倍の重みをつけた独自スコアリングを採用。
| リスク | 確率 | コスト影響 | スケジュール影響 | 安全性影響 | 加重スコア |
|---|---|---|---|---|---|
| 災害時の切替失敗 | 中(2) | 低(1) | 中(2) | 高(3) | 14 |
| ベンダー間の連携不備 | 高(3) | 中(2) | 高(3) | 中(2) | 19 |
| 旧システムのデータ損失 | 低(1) | 中(2) | 中(2) | 高(3) | 11 |
対応策:
- ベンダー間連携：合同レビュー会議を隔週で実施 + インターフェース仕様書の早期確定
- 災害時切替：切替訓練を四半期ごとに実施 + フェイルオーバーの自動化
- データ損失：3重バックアップ体制の構築
結果: プロジェクト期間中に実際の台風警報で切替テストが必要になったが、事前訓練の成果で15分以内に完了。リスクマトリクスの安全性重み付けが住民サービスの継続性を確保した。
やりがちな失敗パターン#
- 全リスクを「高」にしてしまう — 不安からすべてを高リスクに評価すると、優先順位がつかない。客観的な基準を先に定義し、チームで合意してから評価する
- 一度作って更新しない — リスクは状況によって変化する。新たなリスクが出てきたり、対策の効果で確率が下がったりする。月次や各フェーズで見直すこと
- 対応策を決めずに終わる — マトリクスを作って満足してしまう。リスクマトリクスは対応策につなげてこそ価値がある
- 定性評価だけに頼る — チームの「感覚」だけで評価すると、声の大きい人の意見に引っ張られる。過去のデータや類似事例を参照し、客観性を高める
まとめ#
リスクマトリクスは、プロジェクトのリスクを「発生確率×影響度」で評価し、優先順位を可視化するシンプルかつ強力なツール。大事なのはマトリクスを作ることではなく、赤・黄のリスクに具体的な対応策を打つこと。定期的に見直して、リスクの変化に対応し続けよう。