プロジェクトリスク管理の鉄則｜炎上を未然に防ぐ「4つの戦略」と予兆の捉え方
「課題管理とリスク管理、何が違うのかよく分からない」
「『何かあったら考える』ではダメなの？ 事前に何をすればいいの？」
プロジェクトを円滑に進める上で、PM（プロジェクトマネージャー）の手腕が最も問われるのが「リスク管理」です。「問題が起きてから対処する」のが課題管理だとすれば、「問題が起きないように、あるいは起きても困らないように準備する」のがリスク管理です。
この「先読みの力」があるかどうかが、炎上プロジェクトになるかどうかの分かれ道となります。今回は、30年の現場経験を持つ筆者が、リスク管理の本質と、現場で機能する4つの対応戦略を解説します。
「課題」と「リスク」の決定的な違い
リスク管理を始める前に、まず「課題（Issue）」との違いを正しく理解しましょう。ここを混同すると、管理台帳が使いにくいものになってしまいます。
| 比較項目 | 課題（Issue） | リスク（Risk） |
|---|---|---|
| 発生状況 | 既に起きている（顕在化） | まだ起きていない（不確実） |
| 時間軸 | 現在・過去 | 未来 |
| 管理の目的 | 早期に解決し、正常化する | 発生を抑える、または影響を抑える |
| 主なアクション | 対策の実施、完了確認 | 予防策の実施、予備計画の策定 |
「今はまだ起きていないが、もし起きたらプロジェクトの納期・品質・予算を脅かすもの」がリスクです。
なぜリスク管理が必要なのか：3つのメリット
リスク管理は、最悪の事態を想定しておくことで、結果的にプロジェクトの成功確率を飛躍的に高めます。
- 突発的なトラブルによる「パニック」を防ぐ 何も想定していないと、問題発生時にその場しのぎの対応になり、二次災害を招きます。「もし○○が起きたら、こう動く」と決めておくことで、冷静な判断が可能になります。
- ステークホルダーの「合意」を得ておく 「新技術の採用に伴う遅延リスク」など、重大な懸念を事前に共有しておくことで、万が一の際にお客様や上層部との協力体制をスムーズに築けるようになります。
- プロジェクトの「予備（バッファ）」を戦略的に使う リスクを可視化することで、貴重なリソース（予算や人員）をどこに厚く配分すべきかが明確になります。
【実践】リスクを洗い出す「多角的なチェックリスト」
リスク特定は、PM一人の想像力では限界があります。以下の視点（カテゴリ）を使って、チーム全員で「何が心配か」を出し合いましょう。
| カテゴリ | リスク要因の例（チェックポイント） |
|---|---|
| 体制・人 | ・キーマンの退職、人事異動、体調不良 ・スキルのミスマッチ、教育コストの増大 |
| 要件・仕様 | ・お客様との認識齟齬（特に現行業務との差分） ・要件定義の漏れ、後半での大幅な仕様変更 |
| 技術・環境 | ・採用したソフトウェアの不具合や制限の露呈 ・インフラ調達の遅延、開発環境の不安定 |
| 外部・環境 | ・法改正や規制による仕様変更の強制 ・他システム連携先のスケジュール遅延や仕様変更 |
リスク分析：優先順位を決める「評価マトリクス」
洗い出した全てのリスクに全力投球はできません。「発生確率」と「影響度」の2軸で、対策の優先順位を決めます。
| 影響度 ↓ / 発生確率 → | 高（よく起きそう） | 低（滅多に起きない） |
|---|---|---|
| 大（致命的） | 【最優先】 即座に予防策を講じる | 【重点】 起きた時の備えを厚くする |
| 小（軽微） | 【軽減】 発生を抑える工夫をする | 【静観】 発生時に都度対応する |
リスクへの「4つの対応戦略」を使い分ける
リスクを「ゼロ」にすることだけが管理ではありません。コストと効果のバランスを考え、以下の4つの戦略から最適なものを選びます。
① 回避（Avoid）
リスクの原因そのものを取り除く、最も強力な戦略です。
- 具体例： 納期遅延のリスクを避けるため、難易度の高い機能の実装を次フェーズへ回す（スコープ変更）。
- 運用のポイント： 勇気がいる決断ですが、深みにはまる前に「やらない」と決めることがプロジェクトを救います。
- プロの視点： 営業的な配慮で安易に引き受けず、PMとして「断る勇気」を持つことが最大の回避策となります。
② 軽減・低減（Mitigate）
リスクの発生確率を下げる、または起きた時のダメージを最小化する戦略です。
- 具体例： 不慣れな技術を使う際、事前にプロトタイプを作成して技術検証を行う。
- 運用のポイント： システム開発で最も頻繁に使われる戦略です。早めのアクションがトラブルを未然に防ぎます。
- プロの視点： スキルの高いメンバーをレビューに据えるなど、「人」によるチェック機能を強化することも有効な軽減策です。
③ 転嫁・移転（Transfer）
第三者にリスクを引き受けてもらう戦略です。
- 具体例： 専門性の高いインフラ構築を外部の専門ベンダーに委託（アウトソーシング）する。損害保険への加入。
- 運用のポイント： リスク自体がなくなるわけではありませんが、自社のコントロール外の領域を専門家に委託する賢い選択です。
- プロの視点： 委託する場合は、契約書で「責任分担」を明確にしておくことが、転嫁を確実に成功させる鍵となります。
④ 受容（Accept）
特別な対策をせず、発生した時に対応する戦略です。
- 具体例： 対策コストが想定損害より高い場合、特に対策をせず、発生時に予備費や予備要員で対応する。
- 運用のポイント： 何もしないのではなく、「起きたらこうする」という方針（予備費の確保など）を決めておくのが「能動的受容」です。
- プロの視点： 「想定外」をゼロにすることは不可能です。あらかじめ「予備（バッファ）」を確保し、経営層に「この範囲なら吸収できる」と合意を得ておきましょう。
リスク管理を成功させる「運用」の3つのコツ
リスク管理表を「作っただけで終わり」にしないための、実践的なアドバイスです。
① 「リスクの特定」は全員参加で行う
PM一人で見える範囲には限界があります。体制図の各ユニットリーダーや現場メンバーから、「実はここが心配です」という声を吸い上げる機会（ワークショップ等）を定期的に作りましょう。現場の小さな違和感が、巨大なリスクの予兆であることは少なくありません。
② 定期的な「見直し」をルーチン化する
プロジェクトのフェーズが進むにつれて、消えるリスクもあれば、新しく現れるリスクもあります。週次や月次の進捗会議のアジェンダに「リスクの再評価」を組み込み、常に最新の「警戒リスト」を維持することが重要です。
③ 「予兆（トリガー）」を決めておく
「どのような状態になったら、どの対策を発動するか」というトリガー（引き金）を明確にします。
- 例： 「主要メンバーの残業時間が月60時間を超えたら、増員を検討する」
- 例： 「インフラ調達が○月○日までに完了しなければ、スケジュールを2週間延期する」 この基準があることで、現場の主観に頼らず、機械的にリスク対応をスタートさせることができます。
職務と役割：リスク管理は「チーム戦」
リスク管理はチーム戦です。それぞれの立場での役割を意識しましょう。
| 職務名称 | リスク管理における役割 |
|---|---|
| PM（両社） | リスク管理計画の策定、全体リスクの監視、経営層へのエスカレーション。 |
| PL / リーダー | 現場レベルのリスク特定、軽減策（予防策）の実行と進捗確認。 |
| ユニットリーダー | 専門領域（技術・業務）の懸念事項の起票、トリガーの監視。 |
| 品質保証（QA） | 客観的な視点での評価。PMが見落としているリスクへのアラート。 |
現場を動かす「リスク管理表」の必須項目
そのままエクセルやスプレッドシートに転用できるよう、記録すべき項目を整理しました。これらを横に並べて一覧表形式で利用してもよいでしょう。
| 分類 | 記録項目 | 項目内容 |
| リスク | 記入日 | リスクを記入した日 |
| 記入者 | リスクを記入した担当者 | |
| リスク内容 | リスクの内容 | |
| リスク影響 | リスクの影響（リスクが発生した場合の状態や結果） | |
| リスク判断基準 | リスクが発生したと判断する基準 | |
| 影響度 | 発生した場合の影響度を「大・中・小」等で記載 | |
| 発生確率 | リスクが発生する確率を「高・中・低」等で記載 | |
| リスク優先度 | 発生確率と影響度から前述の表より優先度1～5を記載 | |
| リスク対策 | 予防対策 | リスクを未然に防ぐための対策 |
| リスク対策 | リスクの対策（前述の4つの観点でリスクを検討） | |
| 監視サイクル | 日時、週次、月次、工程完了時など | |
| 監視記録 | リスク状況 | 発生したリスクの状況、対策後のリスクの状況 |
| 監視日 | 監視を行った日 | |
| 監視者 | 監視をした担当者 | |
| 状況 | 「対策検討中」「監視中」「完了」などの状態 | |
| 完了日 | リスクを回避して完了した日 |
まとめ：リスク管理は「想像力」の筋トレである
リスク管理は、まだ起きていないことを想像する活動です。経験を積むほど「このパターンは危ない」という感覚が鋭くなります。
- 課題（今）とリスク（未来）を分けて管理台帳を分ける。
- 「予兆（トリガー）」を決め、対策発動の基準を自動化する。
- 定期的な見直し（見守り）をルーチン化し、情報の鮮度を保つ。
リスクを恐れるのではなく、正しく「管理下」に置くことで、プロジェクトの成功確率は飛躍的に高まります。
