目次
はじめに
プロジェクトを進めていると、「昨日まで順調だったのに、急に予定が狂ってしまった…」と戸惑う場面はありませんか。担当者が突然異動になったり、外部ベンダーの納期が遅れたり、打ち合わせの中で思いがけない仕様変更が決まったりすると、それまで組んでいたスケジュールはあっという間に崩れてしまいます。
「トラブルが起きたとき、何から手をつければいいのか分からない」「慌てて対応しているうちに、さらに混乱してしまう」――そんな不安を感じたことがある方も多いのではないでしょうか。
こうした予期せぬ出来事に振り回されないために大切なのが、あらかじめ起こり得ることを思い描き、実際に起きたときにどう動くかを決めておくことです。問題が起きてから慌てて考えるのではなく、「もし納期が遅れたらどうするか」「担当者が不在になったら誰が引き継ぐか」と、先に手当てを用意しておくことで、現場の混乱を最小限に抑えられます。これがリスクマネジメントの基本的な考え方です。
この記事では、プロジェクトにおけるリスク管理の全体像を順番に整理しながら、実際の現場でどのように備え、どのように行動すればよいのかを具体的な場面に落とし込んでお伝えしていきます。読み進める中で、「自分のプロジェクトならどう準備しておくか」を思い浮かべながら、一緒に確認していきましょう。
プロジェクトのリスクマネジメントとは？
プロジェクトを計画どおりに進めるためには、発生してから対処するのではなく、起こり得る問題を事前に想定し、備えておく視点が欠かせません。その考え方がリスクマネジメントです。ここでは、そもそもリスクマネジメントとは何をする活動なのか、リスクと課題（イシュー）の違いは何か、なぜプロジェクトにおいて管理が必要なのか、さらにPMBOKではどのように位置づけられているのかを順に整理します。
リスクマネジメントとは何をすること？
リスクマネジメントとは、プロジェクト中に起こりそうなトラブルを事前に洗い出し、それぞれに具体的な対応手順を決めておくことです。例えば「外部の承認に通常より1週間以上かかる可能性がある」と想定したら、承認待ちの間に進められる別作業を用意しておく、といった行動まで決めておきます。さらに、発生確率を％で見積もり、発生した場合に日程が何日遅れるのかを数値で整理します。こうした準備があれば、実際に遅延が起きても、決めておいた手順どおりに対応できます。
リスクと課題（イシュー）の違いは？
すでに納期を3日過ぎている、リリース後に不具合が確認されている、といった状態は、実際に発生している問題です。これは課題（イシュー）として扱い、原因を特定して修正作業をすぐに開始します。一方で「これから実施する結合テストで不具合が大量に見つかる可能性がある」といった段階は、まだ現実には起きていません。このように、発生前で将来起きるかもしれないものがリスクであり、発生後に対処する課題とは管理方法が異なります。
なぜプロジェクトでリスク管理が必要なの？
プロジェクトは、決められた納期と予算の範囲で進めます。担当者が急に退職する、取引先の回答が予定より1週間遅れるといった出来事が重なると、後続の作業開始日がずれ込み、全体の工程が順番に遅れていきます。こうした遅延や追加作業を想定していないと、その場で代替要員の確保や日程の再調整を考えることになります。あらかじめ起こり得る事態と対応手順を決めておけば、工程全体を大きく崩さずに立て直せます。
PMBOKではリスクマネジメントをどう扱っている？
プロジェクトマネジメントの標準である A Guide to the Project Management Body of Knowledge では、リスクはコストやスケジュールと同じ管理対象として定義されています。計画段階で、想定される出来事をリスクリストに書き出し、それぞれに発生確率と影響度を数値で評価します。そのうえで、回避・軽減・受容などの対応方針と具体的な行動を決めます。このように、リスク管理は補足ではなく、計画書に組み込んで実行する手順として示されています。
PMBOKで示されているプロジェクトのリスクマネジメントの全体の流れ
PMBOKでは、リスクマネジメントは思いつきで対処する活動ではなく、一定の手順に沿って進める体系的なプロセスとして整理されています。まず管理の進め方を決め、そのうえでリスクを洗い出し、重要度を評価し、具体的な対策を計画し、最後まで継続的に監視していきます。ここでは、その全体の流れを6つのステップに分けて順番に確認します。
① リスクマネジメント計画を策定する（管理の進め方を決める）
キックオフ直後の会議で、リスクをどのファイルに記録するか、更新担当を誰にするかを決めます。共有フォルダにリスク管理表を作成し、発生確率は「10％未満・30％・50％以上」など数値で区分し、影響度は「納期が3日遅延・1週間遅延」といった具体的な基準で統一します。評価基準が人ごとに違うと、同じ事象でも重要度が変わってしまうため、最初に尺度を数値と定義文でそろえてから運用を開始します。
② リスクを特定する（起こりそうな出来事を洗い出す）
要件定義書やWBSを確認しながら、各作業で起こり得るトラブルを一つずつ書き出します。たとえば「外部ベンダーの回答が遅れる」「テスト工程で不具合が集中する」「担当者が他案件と重なり作業時間を確保できない」といった具体的な事象を挙げます。過去に障害が出た工程では、そのときの原因と結果を思い出し、付箋に記入して洗い出します。まだ発生していない出来事を、実際の場面が想像できる言葉に置き換えて一覧にします。
③ 定性リスク分析を行う（発生確率と影響度を評価する）
洗い出した各リスクについて、発生確率を「50％以上・30％前後・10％未満」などの数値で評価し、影響度も「納期が1週間以上遅れる・3日遅れる・影響なし」といった基準で判定します。たとえば「主要メンバーの離脱」は発生確率30％、納期1週間遅延と評価されれば、一覧表の上位に置きます。逆に、発生確率10％未満で影響も軽微なものは下位に配置します。数値と基準で並べ替えることで、優先して対処すべき項目が明確になります。
④ 定量リスク分析を行う（遅延やコストを数値で見積もる）
大規模案件では、各リスクが発生した場合の遅延日数や追加費用を具体的な数字で見積もります。たとえば「外部承認が2週間遅れた場合は人件費が150万円増える」といった形で算出します。さらに、複数の発生パターンを入力し、予算を超える確率が何％になるかをシミュレーションします。分析ツールに数値を入れて算出結果を確認すると、想定損失額や遅延日数が明確になります。数字で示すことで、対策に必要な予備費や余裕日数を具体的に判断できます。
⑤ リスク対応を計画する（回避・軽減などの対策を決める）
優先度が高いリスクについては、実行する対策を具体的に決めます。たとえば外部ベンダーの遅延リスクがある工程では、事前に第2候補のベンダーを選定し、見積もりと連絡先を確保しておきます。新技術の採用で不具合が出る可能性がある場合は、本番前に小規模な試作を行い、動作確認と性能測定を実施します。あわせて、担当者名と実施期限をリスク管理表に記載し、いつ誰が動くのかを明確にします。
⑥ リスクを監視・コントロールする（状況を継続的に確認する）
週1回の定例会議でリスク管理表を画面に表示し、各項目の発生確率と影響度を再確認します。たとえば発生確率が30％から50％に上がった場合はセルを赤色に変更し、担当者が理由と対応状況を報告します。すでに発生した項目は課題管理表へ移し、対応期限を設定します。新たに見つかった懸念はその場で一覧に追加し、評価を行います。進捗に合わせて内容と数値を更新し続けます。
プロジェクトのリスクマネジメントでリスクを洗い出す方法
リスクを管理するためには、まず「何が起こり得るのか」を具体的に洗い出すことが出発点になります。漠然と不安を挙げるのではなく、作業内容や過去の事例、外部環境などを手がかりにして、できるだけ具体的な出来事として整理することが重要です。ここでは、実務で使われる代表的な洗い出しの方法を順に確認します。
ブレインストーミングで起こり得る出来事を具体的に書き出す
会議室にメンバーを集め、付箋や共有ドキュメントに起こり得る出来事を一つずつ書き出します。たとえば「担当者がインフルエンザで1週間出社できない」「取引先の承認が予定日より5日遅れる」といった具体的な状況まで記入します。あいまいな表現が出た場合は、「いつ・誰が・どの工程で起きるか」を補足して文章を具体化します。過去案件のリスク一覧やチェックリストを横に置き、同じ工程で発生したトラブルがないかを確認しながら洗い出します。
WBSやスケジュール表を見ながら工程ごとにリスクを探す
WBSを上から順に確認し、作業時間が長い工程や外部ベンダーに依頼している工程に印を付けます。たとえば「API連携開発」「外部審査申請」など、担当者だけでは完結しない作業を具体的に確認します。ガントチャートで開始日と終了日が連続して並び、予備日が入っていない区間では、1日の遅れがそのまま後続工程の開始遅延につながります。各工程ごとに「誰の遅れで止まるか」「何日遅れると全体に影響するか」を書き出すことで、具体的なリスクを特定します。
過去プロジェクトの失敗事例から同じパターンを探す
以前の案件で納期が2週間延びた原因を確認すると、「仕様変更が3回発生し、その分テスト期間が5日短縮された」といった具体的な経緯が分かります。同じように今回も要件が確定していない場合は、仕様変更が重なりテスト工程が圧迫される可能性があります。過去の報告書や振り返り資料を開き、発生したトラブルと影響日数を一覧にします。その内容を現在のWBSと照らし合わせ、同じ条件がそろっていないかを確認してリスクとして記載します。
技術・外部環境・組織体制などのカテゴリごとに漏れがないか確認する
洗い出したリスクを一覧に並べたあと、「技術」「外部環境」「組織体制」などの分類ごとに振り分けます。たとえば「新フレームワークの不具合」は技術、「取引先の承認遅延」は外部環境、「担当者不足」は組織体制に分類します。異なる種類の項目が同じ欄に混在していると、どの分野に問題が集中しているのか判断しづらくなります。分類して件数を数えると、特定のカテゴリだけ極端に少ない場合が分かり、その分野でまだ洗い出せていないリスクがないかを確認できます。
プロジェクトのリスクマネジメントにおける定性リスク分析の進め方
リスクを洗い出したあとは、それぞれの重要度を見極める段階に進みます。すべてのリスクに同じ労力をかけることは現実的ではないため、発生しやすさや影響の大きさを基準に優先順位をつける必要があります。ここでは、定性リスク分析の基本的な進め方を順番に整理します。
① 発生確率と影響度の評価基準を決める
まず、発生確率を数値で区分します。たとえば「10％未満」「30％前後」「50％以上」の3段階に分け、それぞれを具体的な頻度で定義します。影響度も「納期が3日遅れる」「1週間以上遅れる」「追加費用が100万円発生する」など、工程や予算に直結する基準で決めます。あらかじめ数値と条件を明記しておくことで、誰が評価しても同じ尺度で判定できます。
② 各リスクを確率×影響度で評価する
洗い出したリスクを1件ずつ確認し、決めた基準に沿って発生確率と影響度を数値で入力します。たとえば「外部承認が遅れる」は、過去5案件中2回発生していれば発生確率を40％とします。影響度は「承認が1週間遅れると設計工程の開始が7日後ろ倒しになる」など、止まる工程と遅延日数を具体的に算出します。会議では、その確率や日数を選んだ根拠を説明し、メンバー間で数値の妥当性を確認します。
③ マトリクスに配置して優先度を可視化する
発生確率を縦軸、影響度を横軸にした表を用意し、各リスクを数値に応じた位置に配置します。たとえば「確率50％・納期1週間遅延」の項目は右上に置きます。逆に「確率10％未満・遅延なし」の項目は左下に配置します。表の右上に集まったリスクから順に対策を検討する、といった優先順位が一目で分かるようになります。
④ 評価のばらつきがないかを確認する
一覧表を確認し、発生確率や影響度が特定の区分に偏っていないかを見直します。たとえば20件中15件が「確率50％以上」となっている場合は、30％と50％の判断基準が曖昧になっている可能性があります。逆に、すべてが「10％未満・遅延なし」と評価されていれば、過去の発生実績と合っているかを再確認します。各数値について根拠となる事例やデータを示し、評価が基準どおりに付けられているかをチェックします。
プロジェクトのリスクマネジメントにおける定量リスク分析とは？
定性分析で優先度を整理したあと、より精度の高い判断が求められる場合には、数値を用いた定量的な分析を行います。リスクが発生したときにどれだけのコスト増加やスケジュール遅延につながるのかを具体的な数字で見積もることで、経営判断や予備費の設定に活かすことができます。ここでは、定量リスク分析の考え方と代表的な手法、そしてどの規模のプロジェクトで活用されるのかを整理します。
数値を使ってリスクの影響を見積もる分析方法
定量リスク分析では、各リスクが発生した場合の追加費用や遅延日数を具体的な数値で算出します。たとえば「1週間遅れると人件費が50万円増える」と設定し、その金額を基に影響額を計算します。発生確率も「20％」「30％」のように割合で入力し、期待損失額（例：50万円×20％＝10万円）を求めます。数値に置き換えることで、予備費や予備日をいくら確保すべきか判断できます。
期待値分析（EMV）で金額や損失を計算する
期待値分析（EMV）では、発生確率と損失額を掛け合わせて金額を算出します。たとえば、追加費用が50万円発生する確率が20％の場合、50万円×0.2＝10万円が期待損失額です。別のリスクで「100万円の損失が10％」なら、100万円×0.1＝10万円となります。各リスクの期待損失額を合計すると、予備費として確保すべき金額の目安が計算できます。会議では、この合計金額を共有し、予算に組み込むかを判断します。
モンテカルロ法で完了時期のばらつきを予測する
モンテカルロ法では、各工程の所要日数を「最短30日・最長45日」のように幅で設定し、1万回など多数の試行をコンピュータで実行します。試行ごとに合計日数を計算し、その結果から完了日の分布を算出します。たとえば「60日以内に完了する確率70％、65日を超える確率30％」といった数値が得られます。分布グラフと確率を確認することで、余裕日を何日確保するかを具体的に判断できます。
どの規模のプロジェクトで活用されるのか
総予算が数億円規模で、社外ベンダーや複数部門が関わるプロジェクトでは、1週間の遅延が数百万円の損失につながるため、モンテカルロ法や期待値計算を使った定量分析が行われます。一方、予算が数百万円程度の社内システム改修では、専用ツールを使わずに発生確率と影響日数を簡易計算するだけで済ませることもあります。ただし、外部審査や法令対応が含まれる案件では、規模が小さくても遅延による違約金や追加費用を数値で見積もる必要があります。プロジェクトの予算規模と影響範囲に応じて、分析の深さを決めます。
プロジェクトのリスクマネジメントにおけるリスク対応の選び方
リスクの重要度を評価したあとは、実際にどのように対応するかを決める段階に進みます。すべてのリスクを同じ方法で処理するのではなく、影響の大きさや発生確率、そしてそのリスクが脅威なのか機会なのかを踏まえて、適切な対応方針を選ぶことが重要です。ここでは、リスク対応を選択する際の基本的な考え方と判断のポイントを整理します。
① リスクを回避・軽減・転嫁・受容のどれで扱うかを整理する
各リスクについて、回避・軽減・転嫁・受容のどれで対応するかを決めます。たとえば、新しい開発言語の不具合が懸念される場合、実績のある既存言語に変更してリスク要因をなくす方法が回避です。完全に排除できないが確率を下げたい場合は、本番前に試作と負荷テストを実施する軽減を選びます。外部ベンダーの遅延リスクに対して、契約書で遅延時の違約金条項を定めるのは転嫁です。発生確率が低く影響も小さい場合は、追加対策を取らずに受容すると決めます。まずは4区分のどれに該当するかを明確にします。
② 発生確率と影響度をもとに対応の強さを決める
発生確率が50％以上で、発生すると納期が1週間以上遅れるリスクには、回避や強い軽減策を選びます。たとえば主要機能の遅延が想定される場合、代替機能の開発や追加要員の確保を事前に準備します。逆に、発生確率が10％未満で影響も3日以内の遅延にとどまる場合は、特別な対策を取らず受容とする判断もあります。確率と影響日数を基準に、どこまで手間や費用をかけるかを決めます。
③ 機会リスクか脅威リスクかを切り分ける
リスクは「損失が出る可能性」だけではなく、「利益が増える可能性」も含みます。たとえば、新機能が想定より早く完成すれば、予定より1か月早く販売を開始でき、売上が前倒しで計上できます。これは機会リスクです。この場合は、追加広告予算を事前に確保して販売を強化するといった対応を取ります。一方、「主要メンバーが離脱して納期が2週間遅れる」といった損失の可能性は脅威リスクです。まず、各リスクが利益増加につながるのか、損失につながるのかを明確に分け、その性質に応じた対策を決めます。
④ 対応にかかるコストと得られる効果を比較する
追加要員を1名確保すれば遅延リスクは下がりますが、人件費として月80万円が発生します。高額な保険に加入すれば最大1,000万円の損失は補填されますが、保険料として年間200万円を支払う必要があります。発生確率が10％未満のリスクに対して同額の対策費をかけると、他の重要工程の予算が不足します。対策費用と、削減できる損失額や遅延日数を並べて比較し、費用に見合うかを判断します。
プロジェクトのリスクマネジメントで使う「リスクレジスター」の作り方【テンプレ例】
リスクを洗い出し、評価し、対応方針を決めたら、それらを一元管理できる形に整理する必要があります。その役割を担うのが「リスクレジスター」です。属人的なメモで終わらせず、チーム全体で共有・更新できる管理表として整備することで、リスク管理は実務として機能します。ここでは、リスクレジスターの基本的な作り方と運用の流れを順に確認します。
① 記載する項目（列）を先に決める
最初に、リスク管理表に入れる列名を決めます。たとえば「リスク内容」「発生原因」「発生確率（％）」「影響日数または損失額」「優先度」「対応策」「担当者名」「ステータス（未対応・対応中・完了）」を設定します。Excelやスプレッドシートを開き、1行目にこれらの項目を入力します。先に列を固定しておくことで、後からリスクが増えても同じ形式で記録できます。
② 洗い出したリスクを一覧に書き出す
ブレインストーミングやWBS確認で挙がったリスクを、管理表の1行ごとに入力します。このとき、「納期遅延」とだけ書くのではなく、「外部ベンダーの納品が5日遅れ、その結果、設計工程の開始が1週間後ろ倒しになる可能性」と具体的に記載します。誰の遅れで、どの工程が、何日止まるのかまで書いておくことで、後の確率や影響日数の評価がぶれにくくなります。
③ 確率・影響度・優先度を記入する
各リスクについて、発生確率を「10％・30％・50％以上」などの数値で入力し、影響度も「遅延3日・1週間・2週間」や「損失50万円・100万円」など具体的な基準で記入します。そのうえで、確率（例：0.3）×影響額（例：100万円）＝30万円のように計算し、優先度の目安を出します。数値まで入力すると、影響額や遅延日数の大きい順に並べ替えられ、対応すべきリスクが一覧で確認できます。
④ 定期的に更新・見直しする
リスク管理表は作成後も定期的に更新します。たとえば毎週の定例会議で管理表を開き、各リスクの発生確率や影響日数を再確認します。対応が完了した項目はステータスを「完了」に変更し、発生したものは課題管理表へ移します。新しく見つかった懸念はその場で1行追加します。更新を止めると、実際の状況と管理表の内容が一致しなくなります。
⑤ 対応策と担当者を明確にする
各リスクに対して、実行する対応内容と担当者名を管理表に記載します。「検討する」と書くのではなく、「5月15日までに代替ベンダー2社の見積もりを取得する」のように期限と行動を明記します。あわせて、「担当：山田」など実行責任者を名前で登録します。対応内容と担当者を具体的に記載して初めて、管理表が実行計画として機能します。
プロジェクトのリスクマネジメントでよくある失敗パターン
リスクマネジメントは手順どおりに進めているつもりでも、運用の段階で形骸化してしまうことが少なくありません。計画や分析までは行っても、その後の管理や見直しが徹底されず、結果的にトラブルを未然に防げなかったというケースも多く見られます。ここでは、実務で陥りやすい代表的な失敗パターンを整理します。
① リスクを洗い出しただけで管理しなくなるパターン
キックオフで付箋に20件のリスクを書き出して共有フォルダに保存したものの、その後の定例会議で管理表を開かないまま進行するケースがあります。新たに「外部承認が3日遅れた」「担当者が別案件にアサインされた」といった変化が起きているのに、管理表の発生確率やステータスが更新されません。最初に作成した一覧がそのまま放置されると、実際の状況と記録内容が一致しなくなります。
② リスク対応の担当者が決まらず放置されるパターン
管理表に「代替案を検討する」「追加要員を調整する」と書かれていても、担当者名が空欄のままになっているケースがあります。「チームで対応」とだけ記載されていると、誰が資料を作成し、いつ報告するのかが決まりません。定例会議で項目が読み上げられても、実行責任者がいないため進捗報告が出ず、次回も同じ内容が残ります。担当者名と期限が記載されていないリスクは、対応が進まないまま一覧に残り続けます。
③ 定例会でリスクを確認せず形だけの管理になるパターン
定例会で進捗表やガントチャートは毎週確認しているのに、リスク管理表を画面に表示しないケースがあります。会議時間が60分しかない場合、遅延中の作業や不具合対応の報告が優先され、未発生のリスクは議題から外されます。その結果、「外部承認の遅れ確率が30％から50％に上がっている」といった変化に気づかないまま日程が進みます。定期的に確認しないと、発生直前まで対策を打てません。
④ リスクと課題を混同して後手に回るパターン
すでに発生している不具合をリスク管理表に残したままにし、課題管理表へ移さないケースがあります。たとえば「テストで重大バグが発生した」という事象は、発生後は課題として修正期限と担当者を設定すべき内容です。逆に、「外部承認が遅れる可能性がある」といった未発生の項目を課題として最優先で扱うと、緊急度の判断がずれます。リスク管理表と課題管理表を分けずに混在させると、どの項目を先に処理するか判断できなくなります。
⑤ リスクレジスターが更新されなくなるパターン
キックオフ時に作成したリスク管理表を、その後の会議で一度も開かないケースがあります。新たに「外部審査が1週間遅れた」といった事象が発生しても追記せず、すでに対策完了した項目も「対応中」のまま残ります。管理表の発生確率や影響日数が実態と合わなくなると、会議で参照しても信用されなくなります。毎週の定例会で管理表を開き、追加・修正・削除を行う時間を確保しないと、形式だけの資料になります。
⑥ 楽観的な確率評価で優先順位を誤るパターン
発生確率を「たぶん起きない」と10％未満に設定し、本来は優先度が高いリスクを下位に置いてしまうケースがあります。たとえば過去にトラブルがなかったという理由だけで、外部承認遅延の確率を低く見積もると、対策準備を行わないまま進行します。結果として実際に1週間の遅延が発生し、後から対処に追われます。発生確率や影響日数の基準を数値で定め、過去の発生件数などのデータに基づいて評価しないと、優先順位を誤ります。
プロジェクトのリスクマネジメントで迷ったときのチェックポイント
リスクマネジメントを実践していると、どのリスクを優先すべきか、どこまで対応すべきかで判断に迷う場面が出てきます。そのときは感覚や経験だけに頼るのではなく、一定の基準に立ち返って整理することが重要です。ここでは、迷ったときに立ち止まって確認すべき基本的なチェックポイントを整理します。
① それがリスクなのか課題なのかを切り分ける
サーバーが現在停止しており、利用者がアクセスできない状態なら、復旧作業をすぐに開始する必要があります。これはすでに発生している課題です。一方、「アクセス数が通常の2倍に増えた場合、サーバーが停止する可能性がある」という段階は、まだ発生していないリスクです。今この瞬間に障害が起きているのか、将来の発生可能性なのかを確認すると、課題管理に回すのか、リスク管理として評価するのかが判断できます。
② 発生確率と影響度のどちらが高いかを整理する
発生確率が60％だが遅延は1日だけのリスクと、発生確率は10％だが納期が2週間遅れるリスクが並ぶことがあります。どちらを先に対策するかで判断が分かれます。納期まで残り3日の段階であれば、2週間遅延する可能性のあるリスクを優先します。逆に、開始直後で余裕がある段階なら、頻繁に起きる1日遅延のリスクを先に減らす選択もあります。現在の工程状況と残り日数を確認し、確率と影響のどちらを重く見るかを決めます。
③ 対応にかかるコストと影響の大きさを比較する
リスクを完全に防ぐために、追加要員を2名投入し月160万円の人件費をかける案が出ることがあります。しかし、その費用を確保すると他の機能開発の予算が削られます。対策に必要な作業日数や追加費用を具体的に算出し、発生した場合の損失額や遅延日数と並べて比較します。対策費用が想定損失を上回る場合は、軽減策や受容を選ぶ判断も検討します。
まとめ
プロジェクトでは、納期遅延や追加費用につながる出来事が常に発生する可能性があります。だからこそ、キックオフの段階でリスク管理の進め方を決め、WBSやスケジュール表をもとに具体的な事象を書き出し、発生確率と影響日数・損失額を数値で評価します。確率×影響度で優先順位を整理し、回避・軽減・転嫁・受容のどれで対応するかを決め、担当者名と期限まで明記して初めて実行可能な計画になります。
また、リスクと課題を分けて管理し、定例会で管理表を更新し続けることが重要です。発生したものは課題として即時対応し、未発生のものは確率と影響を見直しながら優先順位を調整します。楽観的な見積もりや担当者未設定のままでは、管理は機能しません。
リスクマネジメントは、トラブルをゼロにする仕組みではありません。起こり得る出来事を具体的な言葉と数字に置き換え、対応手順を事前に決めておく技術です。不確実性を見える形にして管理することで、納期と予算のブレを最小限に抑えられます。