「もしシステム障害が発生した場合、誰が何をするのでしょうか？」

プロジェクトでは、事前にリスクを洗い出していても、実際に問題が発生する可能性があります。

そのような不測の事態に備え、あらかじめ対応方法を決めておく計画がコンティンジェンシープラン（Contingency Plan）です。

この記事では、コンティンジェンシープランの意味や目的、作成方法、リスク対応計画との違い、実務での活用方法について解説します。

一言でいうと

コンティンジェンシープランとは、「リスクが実際に発生した場合に備えて、あらかじめ決めておく対応計画」です。

コンティンジェンシープランとは

コンティンジェンシープランとは、特定のリスクが発生した場合に、どのような対応を行うかを事前に定めた計画です。

リスクマネジメントでは、リスクを完全になくすことはできません。

そのため、

• リスクが発生した場合に何をするか
• 誰が対応するか
• どのタイミングで対応を開始するか
• どのような判断が必要か

を事前に決めておきます。

PMBOK®︎では、リスク対応を計画する際に、リスクが発生した場合の対応策としてコンティンジェンシープランを準備します。

コンティンジェンシープランが重要な理由

問題が発生した後に対応方法を考えると、判断や対応が遅れる可能性があります。

例えば、以下のようなケースです。

• 担当者が不在になり、作業を引き継げない
• システム障害発生時に対応窓口が決まっていない
• 納期遅延が発生してから対応策を検討する

このような状況では、混乱が発生し、さらに大きな影響につながる可能性があります。

コンティンジェンシープランを準備しておくことで、発生時に迅速な対応が可能になります。

コンティンジェンシープランとリスク対応計画の違い

コンティンジェンシープランは、リスク対応計画の一部として扱われることがあります。

例えば、

リスク：重要メンバーが離脱する可能性がある

リスク対応：複数人が対応できるように知識共有を進める

コンティンジェンシープラン：離脱した場合は、予備メンバーを投入し、○日以内に引き継ぎを完了する

というように整理できます。

コンティンジェンシープランの作成方法

1. 対象となるリスクを選定する

すべてのリスクに対して詳細な計画を作成する必要はありません。

影響度が大きく、発生した場合に迅速な対応が必要なリスクを対象にします。

2. 発動条件（トリガー）を決める

コンティンジェンシープランでは、「いつ実行するか」を明確にすることが重要です。

この判断基準をリスクトリガー（Risk Trigger）と呼びます。

例：

• 予定日から3日以上遅延した場合
• 品質不良が一定数を超えた場合
• 主要メンバーが離脱した場合

3. 対応内容と担当者を決める

発生時の混乱を防ぐため、具体的な行動を決めます。

実務ではこんな場面で活用される

例えば、プロジェクトの主要メンバーが長期間参加できなくなるリスクを考えます。

事前に以下のようなコンティンジェンシープランを準備します。

• 副担当者を設定する
• 重要資料を共有フォルダへ保存する
• 定期的に知識共有を行う
• 離脱時は副担当者へ引き継ぐ
• 必要に応じて追加要員を依頼する

このように、発生後の行動を事前に決めることで、プロジェクトへの影響を抑えることができます。

よくある勘違い

コンティンジェンシープランは「悲観的な計画」ではない

コンティンジェンシープランを作成すると、「問題が起きる前提で考えている」と感じる人もいます。

しかし、目的は問題を予測して悲観することではありません。

不確実な状況でも、冷静に対応できる準備を整えることが目的です。

すべてのリスクに作成する必要はない

すべてのリスクへ詳細な計画を作成すると、管理負荷が大きくなります。

影響度や発生可能性を考慮し、重要なリスクに絞って作成することが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、リスク発生時の対応判断や危機管理が重要なテーマになります。

論文では、以下の観点を説明できることが重要です。

• どのようなリスクを想定したか
• なぜ事前に対応計画を準備したか
• どのような発動条件を設定したか
• 発生後にどのような対応を行ったか

単に「リスク対応を準備した」と書くのではなく、「発生時の混乱を防ぐために、事前に判断基準と行動を明確化した」と説明できることが重要です。

PM道場のワンポイント

コンティンジェンシープランは、問題が発生した時に慌てないための「未来への準備」です。

優れたプロジェクトマネージャは、問題が起きないようにするだけではなく、起きた場合にもプロジェクトを継続できる仕組みを作っています。

特に重要なのは、計画書を作成することではありません。

「誰が」「いつ」「どの条件で」「何をするか」を明確にしておくことです。

リスクをゼロにできないからこそ、発生後の対応力を高めることがプロジェクト成功につながります。

関連用語

• リスク（Risk）
• リスクマネジメント
• リスク対応
• リスク登録簿（Risk Register）
• リスクトリガー
• コンティンジェンシー予備
• 課題（Issue）
• エスカレーション

まとめ

コンティンジェンシープランとは、リスクが発生した場合に備えて、事前に対応方法を決めておく計画です。

重要なのは、問題発生後に慌てて対応するのではなく、あらかじめ判断基準や行動を明確にしておくことです。

プロジェクトマネージャには、不確実性をなくす力だけではなく、不確実性に備える力が求められます。

コンティンジェンシープランは、そのための重要なマネジメント手法です。

関連記事

• リスク（Risk）とは？
• リスクマネジメントとは？
• リスク分析とは？
• リスク対応とは？
• リスク登録簿（Risk Register）とは？
• エスカレーションとは？

よくある質問（FAQ）

Q. コンティンジェンシープランとは何ですか？

A. リスクが発生した場合に備えて、事前に対応方法を決めておく計画です。

Q. リスク対応計画との違いは何ですか？

A. リスク対応計画は対応方針を決めるもの、コンティンジェンシープランは発生時の具体的な行動を決めるものです。

Q. すべてのリスクにコンティンジェンシープランは必要ですか？

A. いいえ。影響度が大きく、発生時に迅速な対応が必要な重要リスクを対象に作成します。

プロジェクトの現場では、このように問題を抱え込んでしまうケースがあります。

しかし、問題への対応が遅れるほど、プロジェクトへの影響は大きくなる可能性があります。

そこで重要になるのがエスカレーション（Escalation）です。

この記事では、エスカレーションの意味や目的、適切なタイミング、プロジェクトマネージャが実践すべきポイントについて解説します。

一言でいうと

エスカレーションとは、「自分や現在のチームだけでは解決できない問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動」です。

エスカレーションとは

エスカレーションとは、問題やリスク、判断が必要な事項を、上位者や関係する意思決定者へ引き上げることです。

プロジェクトでは、プロジェクトマネージャだけでは判断できない問題が発生することがあります。

例えば、

• 予算追加が必要になる
• 納期変更の判断が必要になる
• 組織間の調整が必要になる
• 重要なリスクが顕在化する

このような場合、適切なタイミングでエスカレーションを行うことで、迅速な意思決定につなげることができます。

エスカレーションが重要な理由

プロジェクトでは、問題そのものよりも「発見後の対応の遅れ」が大きな影響を与えることがあります。

例えば、以下のようなケースです。

• 小さな遅延を報告せず、後から重大な遅延になる
• 品質問題を抱え込み、リリース直前に発覚する
• 判断待ちの事項が放置され、作業が停止する

早い段階でエスカレーションすることで、選択できる対応策が増えます。

つまり、エスカレーションは「問題が大きくなってから助けを求める行為」ではなく、「問題を大きくしないための予防的な行動」です。

エスカレーションするべきタイミング

エスカレーションの判断で重要なのは、「解決策が決まってから報告する」のではなく、「問題だと認識した段階で共有する」ことです。

例えば、以下のような状況ではエスカレーションを検討します。

• プロジェクト目標へ影響する可能性がある
• 自分の権限では判断できない
• 複数チームに影響する
• 期限までに解決できない可能性がある
• 追加予算や人員が必要になる

エスカレーションで重要な報告内容

エスカレーションでは、単に「問題があります」と伝えるだけでは十分ではありません。

最低限、以下の内容を整理して共有します。

原因分析や対策案が完成していなくても、まず状況を共有することが重要です。

エスカレーションと報告の違い

エスカレーションは単なる報告ではなく、問題解決のために適切な人へ判断をつなぐ活動です。

実務ではこんな場面で活用される

例えば、システム開発プロジェクトで、重要な機能の開発が遅れる可能性が判明したとします。

プロジェクトマネージャが一人で原因分析や対策検討を続けると、対応が遅れる可能性があります。

そこで、以下のようにエスカレーションします。

• 現在判明している事実を共有する
• 納期影響の可能性を伝える
• 原因分析中であることを説明する
• 必要な支援や判断を依頼する

この段階では、完璧な解決策を提示する必要はありません。

重要なのは、問題を早期に共有し、組織として対応できる状態を作ることです。

よくある勘違い

エスカレーションは失敗報告ではない

エスカレーションを「問題を起こしたことを認める行為」と考えてしまうことがあります。

しかし、実際にはプロジェクトを成功させるためのマネジメント活動です。

原因分析が終わるまで待つ必要はない

原因分析や対策検討には時間がかかります。

その間に問題の影響が広がる可能性があります。

まず事実を共有し、その後詳細分析を進めることも重要な判断です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、問題発生時の対応や関係者調整が重要なテーマになります。

論文では、以下のような観点が評価されます。

• 問題をどのタイミングで認識したか
• 誰へどのように共有したか
• 必要な判断や支援をどのように得たか
• その結果、プロジェクトをどう改善したか

優れたPMは、問題を隠すのではなく、適切なタイミングで組織の力を活用します。

PM道場のワンポイント

エスカレーションで大切なのは、「解決してから報告する」ことではなく、「問題だと思った時点で共有する」ことです。

プロジェクトマネージャは、すべての問題を一人で解決する役割ではありません。

必要な人へ情報を届け、適切な判断を引き出すことも重要な役割です。

特に、コミュニケーションが苦手なPMほど、「原因を整理してから伝えなければならない」と考えがちです。

しかし、早期共有によって、より多くの選択肢を持って対応できます。

優れたプロジェクトマネージャは、エスカレーションによって問題解決のスピードを高めています。

関連用語

• リスク（Risk）
• 課題（Issue）
• 問題管理
• 意思決定
• ステークホルダー
• コミュニケーションマネジメント
• 報告
• プロジェクトスポンサー

まとめ

エスカレーションとは、自分やチームだけでは解決できない問題や判断事項を、適切な相手へ共有し、支援や判断を得る活動です。

重要なのは、問題が大きくなってから行うのではなく、影響が広がる前に実施することです。

プロジェクトマネージャに求められるのは、すべての問題を一人で解決する力ではありません。

組織の力を活用し、プロジェクトを成功へ導くための判断を行う力です。

関連記事

• リスク（Risk）とは？
• 課題（Issue）とは？
• ステークホルダーとは？
• コミュニケーションマネジメントとは？
• プロジェクトスポンサーとは？

よくある質問（FAQ）

Q. エスカレーションとは何ですか？

A. 解決が難しい問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動です。

Q. エスカレーションはいつ行うべきですか？

A. 問題の影響が広がる可能性があると判断した時点で、早めに実施することが重要です。

Q. 原因分析や対策案がなくてもエスカレーションしてよいですか？

A. はい。まず事実や影響を共有し、必要な支援を得ることが重要です。

プロジェクトでは、リスクを特定・分析するだけでは十分ではありません。

重要なのは、リスクが発生した場合に備えて、どのような行動を取るかを事前に決めておくことです。

この活動をリスク対応（Risk Response）と呼びます。

この記事では、リスク対応の意味や代表的な対応戦略、実務での活用方法、プロジェクトマネージャが押さえるべきポイントについて解説します。

一言でいうと

リスク対応とは、「特定・分析したリスクに対して、発生確率や影響を小さくするための具体的な行動を決める活動」です。

リスク対応とは

リスク対応とは、特定したリスクに対して、どのように向き合うかを決定する活動です。

プロジェクトでは、すべてのリスクをなくすことはできません。

そのため、リスクの種類や影響度に応じて、適切な対応方法を選択します。

PMBOK®︎では、リスク対応はリスクマネジメントの重要な活動の一つとして位置付けられています。

また、リスク対応は「悪い影響を与えるリスク（脅威）」だけではなく、「良い影響を与えるリスク（好機）」に対しても検討します。

リスク対応が重要な理由

リスクは、発生してから対応すると、プロジェクトへ大きな影響を与える可能性があります。

例えば、以下のようなケースです。

• 重要メンバーが離脱してから代替要員を探す
• 技術問題が発生してから調査を開始する
• 納期遅延が発生してからスケジュールを見直す

このような事後対応では、対応できる選択肢が限られてしまいます。

事前にリスク対応を決めておくことで、問題発生時にも迅速な判断と行動が可能になります。

リスク対応の基本的な考え方

リスク対応を検討する際には、以下の観点が重要です。

• そのリスクを発生させない方法はあるか
• 発生した場合の影響を小さくできるか
• 他者へ移転できるか
• 受け入れることが合理的か

リスクの大きさやプロジェクト状況に応じて、最適な対応方法を選択します。

脅威に対する代表的なリスク対応戦略

回避（Avoid）

回避とは、リスクの原因を取り除き、リスクが発生しない状態にする対応方法です。

例えば、

• 実績のない技術利用をやめる
• 複雑な機能を削減する
• 契約条件を変更する

などがあります。

リスクの影響が非常に大きい場合に検討されます。

軽減（Mitigate）

軽減とは、リスクの発生確率や影響度を低下させる対応方法です。

例えば、

• 事前検証を実施する
• 教育や訓練を行う
• レビュー回数を増やす

などがあります。

実務では最も多く利用される対応方法の一つです。

転嫁（Transfer）

転嫁とは、リスクへの対応責任や影響を第三者へ移す方法です。

例えば、

• 保険へ加入する
• 専門業者へ委託する
• 契約によって責任範囲を明確化する

などがあります。

ただし、リスクそのものがなくなるわけではなく、管理主体を変更する方法です。

受容（Accept）

受容とは、追加対応を行わず、リスクが発生した場合に対応する方法です。

例えば、影響が小さいリスクや、対応コストがリスク影響を上回る場合に選択します。

受容する場合でも、発生時の対応方針や担当者を決めておくことが重要です。

好機に対するリスク対応戦略

PMBOK®︎では、良い影響を与えるリスク（好機）についても対応を検討します。

実務ではこんな場面で活用される

例えば、新しい技術を利用するシステム開発プロジェクトを考えます。

リスク分析の結果、

「新技術の習得不足により、開発遅延が発生する可能性が高い」

というリスクが判明しました。

そこで、以下のリスク対応を実施します。

• 事前に技術検証を実施する
• 専門家によるレビューを行う
• 経験者をプロジェクトへ参画させる
• スケジュールに余裕を持たせる

このように、リスク対応では「発生したらどうするか」ではなく、「発生する可能性をどう管理するか」を考えます。

よくある勘違い

リスク対応策を決めれば終わりではない

リスク対応は、計画を作成するだけでは十分ではありません。

実際に対応策が実行されているか、効果が出ているかを確認する必要があります。

すべてのリスクに対策する必要はない

すべてのリスクに対して詳細な対策を行うと、時間やコストが不足します。

重要なのは、リスクの大きさと対応コストを比較し、適切な判断を行うことです。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、リスクをどのように管理し、対応したかが重要なテーマになります。

午後試験では、以下の観点を説明できることが重要です。

• どのようなリスクを特定したか
• なぜその対応方法を選択したか
• 対応策をどのように実行したか
• 対応後の効果をどのように確認したか

「リスク対応を実施した」ではなく、「リスクの特徴を踏まえて最適な対応を判断した」という説明が重要です。

PM道場のワンポイント

リスク対応で重要なのは、すべてのリスクをなくすことではなく、プロジェクトとして受け入れられる状態にすることです。

実務では、リスクが発生しないようにすることばかりに注目しがちです。

しかし、プロジェクトマネージャに求められるのは、不確実性を理解したうえで適切な判断をすることです。

時には、コストや期間を考慮して「受容する」という判断も必要になります。

優れたプロジェクトマネージャは、リスク対応を通じて、チームが安心して行動できる環境を作っています。

関連用語

• リスク（Risk）
• リスクマネジメント
• リスク登録簿（Risk Register）
• リスク分析
• 定性的リスク分析
• 定量的リスク分析
• リスクトリガー
• 課題（Issue）

まとめ

リスク対応とは、特定・分析したリスクに対して、発生確率や影響を管理するための具体的な行動を決める活動です。

代表的な対応方法には、回避・軽減・転嫁・受容があります。

重要なのは、リスクを完全になくすことではありません。

プロジェクトの状況に応じて適切な対応方法を選択し、不確実性を管理することがプロジェクトマネージャの役割です。

関連記事

• リスク（Risk）とは？
• リスクマネジメントとは？
• リスク登録簿（Risk Register）とは？
• リスク分析とは？
• 定性的リスク分析とは？
• 定量的リスク分析とは？

よくある質問（FAQ）

Q. リスク対応とは何ですか？

A. 特定・分析したリスクに対して、発生確率や影響を管理するための具体的な行動を決める活動です。

Q. リスク対応にはどのような種類がありますか？

A. 脅威に対しては回避・軽減・転嫁・受容、好機に対しては活用・強化・共有・受容などがあります。

Q. リスク対応で最も重要なことは何ですか？

A. リスクの特徴を理解し、プロジェクトにとって最適な対応方法を選択することです。

プロジェクトでは、リスクの優先順位を決めるだけではなく、発生した場合の影響を具体的な数値で把握したい場合があります。

そのような場面で活用されるのが定量的リスク分析（Quantitative Risk Analysis）です。

この記事では、定量的リスク分析の意味や目的、代表的な分析手法、定性的リスク分析との違い、実務での活用方法について解説します。

一言でいうと

定量的リスク分析とは、「リスクがプロジェクト目標に与える影響を数値化し、意思決定に活用する活動」です。

定量的リスク分析とは

定量的リスク分析とは、特定したリスクについて、発生確率や影響を数値で分析する活動です。

定性的リスク分析では「高・中・低」といった相対的な評価を行いますが、定量的リスク分析では、

• 発生した場合の追加コスト
• 納期への影響日数
• プロジェクト成功確率
• 目標達成への影響

などを具体的な数値で評価します。

PMBOK®︎では、必要に応じて実施する高度なリスク分析手法として位置付けられています。

定量的リスク分析が重要な理由

プロジェクトでは、すべての判断を感覚だけで行うことはできません。

特に、大規模プロジェクトや多額の投資を伴うプロジェクトでは、リスクの影響を数値で把握することが重要になります。

例えば、以下のような判断が可能になります。

• 予備費をどの程度確保すべきか
• 納期遅延の可能性は許容できる範囲か
• 追加対策へ投資する価値があるか
• プロジェクト計画を変更すべきか

定量的リスク分析によって、経験や感覚だけではなく、データに基づいた意思決定が可能になります。

定量的リスク分析を実施するタイミング

定量的リスク分析は、すべてのプロジェクトで必ず実施するものではありません。

一般的には、以下のような場合に活用されます。

• プロジェクト規模が大きい場合
• 投資金額が大きい場合
• リスクの影響が重大な場合
• 経営層への説明が必要な場合

小規模なプロジェクトでは、定性的リスク分析だけで十分な場合もあります。

代表的な定量的リスク分析の手法

期待金額価値分析（EMV）

期待金額価値分析（Expected Monetary Value：EMV）は、リスクの発生確率と影響金額を掛け合わせ、期待される損失や利益を算出する方法です。

計算式は以下のとおりです。

期待金額価値 ＝ 発生確率 × 発生した場合の影響額

例えば、

• 発生確率：30%
• 発生時の損失：1,000万円

の場合、

0.3 × 1,000万円 = 300万円

となり、期待される損失額は300万円と判断できます。

モンテカルロ分析

モンテカルロ分析は、複数のリスクを考慮し、シミュレーションによってプロジェクトの結果を予測する方法です。

例えば、スケジュールについて、

• 予定より早く完了する可能性
• 予定通り完了する可能性
• 遅延する可能性

を多数のシミュレーションによって分析します。

大規模プロジェクトや複雑なプロジェクトで活用されます。

感度分析

感度分析とは、どのリスク要因がプロジェクトへ大きな影響を与えるかを分析する方法です。

例えば、

• 人員不足
• 材料価格上昇
• 技術的問題

の中で、どの要因がコストへ最も影響するかを判断します。

定性的リスク分析との違い

実務ではこんな場面で活用される

例えば、大規模なシステム開発プロジェクトで、納期遅延リスクを分析するとします。

定性的リスク分析では、

「納期遅延リスク：高」

という判断になります。

さらに定量的リスク分析を行うことで、

• 20日遅延する可能性がある
• 追加費用として500万円発生する可能性がある
• 納期達成確率は70%

のように具体化できます。

これにより、プロジェクトマネージャは、追加要員投入や計画変更などの判断を行いやすくなります。

よくある勘違い

すべてのリスクを数値化すればよいわけではない

定量的リスク分析は有効ですが、すべてのリスクに対して実施すると、多くの時間やコストが必要になります。

重要なのは、分析する価値があるリスクを見極めることです。

数値結果が絶対的な未来を示すわけではない

定量的リスク分析の結果は、あくまで現在の情報に基づく予測です。

前提条件が変われば、結果も変化します。

そのため、分析結果を参考情報として活用し、継続的に見直すことが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、リスク分析をどのように意思決定へつなげたかが重要です。

午後試験では、以下の観点を説明できることが重要です。

• なぜ定量的分析が必要だったのか
• どのような手法を用いたのか
• 分析結果をどのように判断へ活用したのか
• 関係者へどのように説明したのか

単に「数値分析を実施した」と書くのではなく、その結果によってプロジェクトをどのように改善したかが重要です。

PM道場のワンポイント

定量的リスク分析の目的は、正確な未来予測ではなく、より良い意思決定を行うことです。

実務では、「分析結果の数字を出すこと」が目的になってしまうことがあります。

しかし、本当に重要なのは、その数字を見て、

• 追加対策を実施するのか
• 計画を変更するのか
• リスクを受け入れるのか

を判断することです。

優れたプロジェクトマネージャは、数字を目的ではなく、意思決定の材料として活用しています。

関連用語

• リスク（Risk）
• リスクマネジメント
• 定性的リスク分析
• リスク登録簿（Risk Register）
• 期待金額価値分析（EMV）
• モンテカルロ分析
• リスク対応計画
• 意思決定

まとめ

定量的リスク分析とは、リスクの影響を数値化し、プロジェクトの意思決定に活用する活動です。

期待金額価値分析やモンテカルロ分析などの手法を用いることで、リスクによる影響をより具体的に把握できます。

ただし、重要なのは分析結果そのものではありません。

数値化した情報をもとに、プロジェクトマネージャが適切な判断を行い、プロジェクト成功へつなげることが重要です。

関連記事

• リスク（Risk）とは？
• リスクマネジメントとは？
• 定性的リスク分析とは？
• リスク登録簿（Risk Register）とは？
• リスク対応計画とは？
• 課題（Issue）とは？

よくある質問（FAQ）

Q. 定量的リスク分析とは何ですか？

A. リスクがプロジェクト目標へ与える影響を、金額や期間などの数値で分析する活動です。

Q. 定性的リスク分析との違いは何ですか？

A. 定性的リスク分析は優先順位を決めるための分析、定量的リスク分析は影響を数値化するための分析です。

Q. すべてのプロジェクトで定量的リスク分析は必要ですか？

A. いいえ。大規模プロジェクトや影響が重大な場合など、必要性に応じて実施します。

プロジェクトでは、将来発生する可能性のあるリスクを完全になくすことはできません。

しかし、リスクを事前に把握し、適切に管理することで、プロジェクトへの影響を最小限に抑えることができます。

この活動全体をリスクマネジメント（Risk Management）と呼びます。

この記事では、リスクマネジメントの意味や流れ、実務での活用方法についてわかりやすく解説します。

一言でいうと

リスクマネジメントとは、「リスクを特定・分析・対応・監視し、プロジェクトへの影響を最小限に抑えるための継続的な活動」です。

リスクマネジメントとは

リスクマネジメントとは、プロジェクトで発生する可能性のある不確実な出来事を管理する活動です。

リスクが問題として顕在化する前に対応策を検討し、プロジェクト目標への影響をできるだけ小さくすることを目的としています。

PMBOK®︎では、リスクマネジメントはプロジェクト成功のための重要なマネジメント活動の一つとして位置付けられています。

なお、PMBOK®︎では、悪い影響を与える脅威（Threat）だけではなく、良い影響を与える好機（Opportunity）もリスクとして管理します。

リスクマネジメントが重要な理由

プロジェクトでは、どれだけ綿密に計画しても予期しない出来事は発生します。

例えば、次のようなリスクがあります。

• 重要メンバーが離脱する
• 新技術の導入で想定外の問題が発生する
• 顧客から大きな仕様変更がある
• 外部ベンダーの納品が遅れる

これらを問題が発生してから対応すると、スケジュールやコスト、品質へ大きな影響を与える可能性があります。

そのため、リスクマネジメントでは「問題が起きてから対応する」のではなく、「問題になる前に備える」ことを重視します。

PMBOK®︎におけるリスクマネジメントの流れ

PMBOK®︎では、リスクマネジメントは継続的に実施する活動とされています。

一般的な流れは次のとおりです。

1. リスクマネジメントを計画する
2. リスクを特定する
3. リスク分析を行う
4. リスク対応を計画する
5. リスク対応を実行する
6. リスクを監視する

これらは一度実施すれば終わりではありません。

プロジェクトの進行に合わせて、新たなリスクを追加したり、優先順位を見直したりしながら継続的に実施します。

リスクマネジメントでよく使われる成果物

リスクへの代表的な対応方法

リスクへの対応方法は、リスクの種類によって異なります。

実務ではこんな場面で活用される

例えば、新しいシステムを開発するプロジェクトを考えます。

プロジェクト開始時に、「新技術を利用するため開発が遅れる可能性がある」というリスクを特定しました。

そこで、リスクマネジメントとして次のような対応を行います。

• 事前に技術検証を実施する
• 有識者へレビューを依頼する
• 予備日程を確保する
• 定期的に進捗を確認する

このように、問題が起きる前に備えることで、プロジェクトへの影響を小さくできます。

よくある勘違い

リスク管理表を作れば終わりではない

リスク登録簿を作成しただけでは、リスクマネジメントはできていません。

重要なのは、リスクの変化を継続的に確認し、必要に応じて対応を見直すことです。

リスクマネジメントはプロジェクト開始時だけの活動ではない

プロジェクトが進むにつれて、新しいリスクが発生します。

そのため、定例会議などで継続的にリスクを確認し、管理することが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、リスクマネジメントは頻出テーマです。

午後試験では、単に「リスク管理を実施した」と書くのではなく、以下を具体的に説明できることが重要です。

• どのようにリスクを特定したか
• どのような分析を行ったか
• なぜその対応策を選択したのか
• どのように監視・見直しを行ったか

また、リスク管理がプロジェクト成功へどのように貢献したかまで説明できると、高い評価につながります。

PM道場のワンポイント

リスクマネジメントとは、「未来を予測すること」ではなく、「未来に備える仕組みを作ること」です。

実務では、「リスクを洗い出しましょう」という会議だけで終わってしまうことがあります。

しかし、本当に重要なのは、そのリスクを誰が、いつ確認し、どのタイミングで対応するのかを決めることです。

優れたプロジェクトマネージャは、リスクを一覧表で管理しているのではありません。

チーム全員がリスクを共有し、自律的に兆候へ気付ける仕組みを作っています。

関連用語

• リスク（Risk）
• リスク登録簿（Risk Register）
• リスク分析
• リスク対応計画
• リスクトリガー
• 課題（Issue）
• 根本原因分析
• 教訓（Lessons Learned）

まとめ

リスクマネジメントとは、リスクを特定・分析・対応・監視し、プロジェクトへの影響を最小限に抑えるための継続的な活動です。

リスクは完全になくすことはできません。

しかし、適切なリスクマネジメントを実施することで、問題が発生する前に備え、プロジェクト成功の可能性を高めることができます。

プロジェクトマネージャには、リスクを恐れるのではなく、不確実性を管理する力が求められます。

関連記事

• リスク（Risk）とは？
• リスク登録簿（Risk Register）とは？
• リスク分析とは？
• リスク対応計画とは？
• 課題（Issue）とは？
• 根本原因分析とは？

よくある質問（FAQ）

Q. リスクマネジメントとは何ですか？

A. リスクを特定・分析・対応・監視し、プロジェクトへの影響を最小限に抑えるための継続的な活動です。

Q. リスクマネジメントはいつ実施しますか？

A. プロジェクト開始時だけではなく、プロジェクト全体を通して継続的に実施します。

Q. リスクマネジメントで最も重要なことは何ですか？

A. リスクを一覧化することではなく、優先順位を判断し、適切な対応を継続的に実施することです。

しかし、プロジェクトではもう一つ設計しなければならないコミュニケーションがあります。

それがエスカレーションです。

私は人見知りだったこともあり、問題が起きてもすぐに相談することができませんでした。

• 「原因を整理してから報告しよう。」
• 「対策を考えてから相談しよう。」
• 「相手が納得できるように説明できる状態にしてから伝えよう。」

そう思っているうちに時間だけが過ぎ、気付けば問題が大きくなってしまうことが何度もありました。

当時の私は、「もっとコミュニケーション能力があればすぐに相談できたのに」と考えていました。

しかし今振り返ると、問題は性格ではありませんでした。

エスカレーションの仕組みを設計できていなかったのです。

人見知りほど「準備してから相談しよう」としてしまう

プロジェクトで問題が発生したとき、多くの人はすぐに相談できます。

一方、人見知りの人は違います。

• 「原因を調べてから。」
• 「対策を考えてから。」
• 「質問されたら答えられるようにしてから。」

そんなふうに、相談する前の準備に時間をかけてしまいます。

私もそうでした。

原因分析を行い、対策案を考え、相手が納得できる説明を用意してから報告しようとしていました。

しかし、その間にも時間は過ぎていきます。

プロジェクトでは、問題そのものよりも、問題への対応が遅れることの方が大きなリスクになる場合があります。

準備をしているつもりが、結果として問題を大きくしてしまっていたのです。

実は、原因より「速報」の方が価値がある

PMとして経験を積む中で、私の考え方は大きく変わりました。

今は、問題だと思った時点でエスカレーションするようにしています。

そのときに伝えることは、とてもシンプルです。

「問題だと思ったので、まずは報告します。まだ原因分析や対策案はできていません。」

これだけです。

以前の私なら、「そんな状態で報告してはいけない」と考えていたでしょう。

しかし実際には、この伝え方の方がずっと良い結果につながりました。

なぜなら、自分だけが問題だと思っていただけというケースが意外と多かったからです。

私にとっては重大な問題でも、上司や顧客からすると、

• 「それなら問題ありません。」
• 「そのまま進めて大丈夫です。」

と言われることも少なくありませんでした。

もし一人で抱え込んでいたら、必要のない不安を抱えたまま時間を使っていたことになります。

エスカレーションは、問題を報告するだけではありません。

自分一人の不安を、チームで確認するためのコミュニケーションでもあるのです。

エスカレーションは「原因」を共有するものではなく、「不安」を共有するもの

私は、エスカレーションの考え方を次のように変えました。

以前

「原因が分かったら報告する。」

現在

「問題だと思ったら報告する。」

原因分析や対策案は、その後にチームで考えれば十分です。

プロジェクトは、一人で解決するものではありません。

チームで解決するものです。

だからこそ、エスカレーションで最初に共有すべきなのは、

「私はここに不安を感じています。」

という事実なのだと思います。

エスカレーションにも「設計」が必要

PMBOK®^®︎では、コミュニケーションは計画し、管理するものとされています。

私は、エスカレーションも同じだと考えています。

「問題があれば相談してください。」

これだけでは、人によって判断が変わってしまいます。

だから私は、プロジェクトの規模に応じてエスカレーションの基準を決めるようにしていました。

小規模なプロジェクトの場合

ルールはとてもシンプルです。

「問題だと思った時点で相談してください。」

必要なのは次の2つだけです。

• 何が起きたのか
• 何を問題だと感じているのか

原因や対策は、一緒に考えます。

大規模なプロジェクトの場合

関係者が多くなるため、PMだけで全てを管理することは難しくなります。

そのため、課題管理表に必要な情報を記録し、その登録を連絡してもらう運用にしていました。

こうすることで、情報が漏れず、対応状況もチーム全体で共有できます。

もちろん、これが唯一の正解ではありません。

プロジェクトの規模や特性に応じて運用を変えることが大切です。

私はこれも、PMBOK®^®︎でいうテーラリングの考え方だと捉えています。

PMの最初の反応が、チームの文化を作る

エスカレーションしやすいチームには、一つ共通点があります。

それは、PMの最初の反応です。

私はまず、

「報告してくれてありがとう。」

と伝えるようにしています。

それだけで、相手は

「報告して良かった。」

と思えます。

逆に、

• 嫌そうな表情をする
• ため息をつく
• 責めるような質問をする

こうした反応をしてしまうと、次から相手は相談をためらうようになります。

私は人見知りだったからこそ、この影響を強く感じました。

相手の表情から「嫌だな」という感情を読み取ってしまうと、

「次はもう少し整理してから相談しよう。」

と思ってしまうのです。

その結果、エスカレーションは遅れます。

だからこそ、PMは問題の内容よりも先に、

相談しやすい空気を作れているかを意識する必要があります。

PMBOK®^®︎でも重要なのは「早く見える化すること」

PMBOK®^®︎では、リスクや課題は継続的に監視し、必要に応じて関係者へ共有することが重要だとされています。

私は、この考え方はエスカレーションにも当てはまると思っています。

大切なのは、完璧な情報を持ってから報告することではありません。

問題を早く見える化し、チームで対応を考えられる状態を作ることです。

エスカレーションとは、責任を手放すことではありません。

問題をチーム全体で管理できる状態へ変えることなのです。

おわりに

新人の頃の私は、

「原因が分かるまで相談してはいけない。」

そう思い込んでいました。

しかし今なら、当時の自分にこう伝えます。

「まずは問題だと思ったことだけ伝えよう。」

原因は、そのあとみんなで考えればいい。

プロジェクトマネジャは、一人で戦う仕事ではありません。

チームでプロジェクトを成功へ導く仕事です。

だからこそ、エスカレーションは問題を報告するための仕組みではなく、

一人で抱え込んでいた不安を、チーム全体の課題へ変えるための仕組みなのだと思います。

あなたへの問いかけ

あなたのプロジェクトでは、エスカレーションしやすい仕組みが設計されていますか。

そして、もし誰かが勇気を出して相談してきたとき、あなたは最初にどんな言葉を掛けるでしょうか。

その最初の一言が、チームのコミュニケーション文化を作るのかもしれません。

プロジェクトでは、多くのリスクが発生する可能性があります。

しかし、すべてのリスクへ同じように対応することは、時間やコストの面から現実的ではありません。

そこで重要になるのが、リスクの大きさや優先度を判断するリスク分析（Risk Analysis）です。

この記事では、リスク分析の意味や種類、実務での活用方法、プロジェクトマネージャが押さえるべきポイントについて解説します。

一言でいうと

リスク分析とは、「特定したリスクの発生確率や影響度を評価し、対応の優先順位を決める活動」です。

リスク分析とは

リスク分析とは、洗い出したリスクについて、発生した場合の影響や発生する可能性を評価する活動です。

プロジェクトでは、すべてのリスクに対応することはできません。

そのため、リスク分析によって、

• どのリスクを優先的に管理するべきか
• どの程度の対策が必要か
• どのリスクは許容できるか

を判断します。

PMBOK®では、リスクマネジメントの重要なプロセスとして位置付けられています。

リスク分析が重要な理由

プロジェクトでは、多くのリスクが存在します。

例えば、以下のようなリスクです。

• 担当者不足によるスケジュール遅延
• 技術的な問題による品質低下
• 要求変更による追加コスト発生
• 外部企業との調整遅延

しかし、すべてのリスクを同じレベルで管理すると、重要なリスクへの対応が遅れてしまいます。

リスク分析を行うことで、影響の大きいリスクを見極め、限られたリソースを効果的に活用できます。

リスク分析の種類

リスク分析には、大きく分けて以下の2種類があります。

定性的リスク分析とは

定性的リスク分析とは、リスクの発生確率や影響度を評価し、リスクの優先順位を判断する方法です。

多くのプロジェクトで最初に実施される一般的な分析方法です。

例えば、以下のように評価します。

評価結果をもとに、優先的に対応すべきリスクを判断します。

定量的リスク分析とは

定量的リスク分析とは、リスクの影響を数値化し、プロジェクト目標への影響を分析する方法です。

例えば、以下のような分析があります。

• 追加費用が発生する可能性
• 納期遅延の日数予測
• 成功確率の算出

大規模プロジェクトや影響が大きいプロジェクトでは、定量的分析が活用されます。

定性的分析と定量的分析の違い

実務ではこんな場面で活用される

例えば、新しいシステム開発プロジェクトで、以下のリスクが洗い出されたとします。

• 新技術の利用経験が少ない
• 外部システムとの連携が必要
• 開発メンバーが不足している

これらを分析すると、以下のような判断ができます。

• 新技術リスク → 事前検証を実施する
• 外部連携リスク → 早期に接続試験を行う
• 人的リスク → 要員計画を見直す

このように、リスク分析によって「何に備えるべきか」を明確にします。

よくある勘違い

すべてのリスクをなくすことが目的ではない

リスク分析の目的は、リスクをゼロにすることではありません。

重要なリスクを見極め、適切な対応を行うことが目的です。

分析結果は一度決めたら終わりではない

プロジェクトの状況は変化します。

新しいリスクが発生したり、以前重要だったリスクの優先度が変わったりします。

そのため、リスク分析は継続的に見直す必要があります。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、リスクをどのように評価し、対応につなげたかが重要な論点になります。

午後試験では、以下の観点を説明できることが重要です。

• どのようにリスクを特定したか
• どの基準で重要度を判断したか
• 分析結果をどのような対応につなげたか
• 継続的に監視したか

単に「リスク分析を実施した」と書くのではなく、分析結果をもとにPMがどのような判断をしたかが重要です。

PM道場のワンポイント

リスク分析の目的は、リスクを分類することではなく、「PMが判断するための材料を作ること」です。

実務では、リスク一覧を作成することや、発生確率・影響度を入力することが目的になってしまう場合があります。

しかし、本当に重要なのは、その結果をもとに、

• 今すぐ対応すべきか
• 監視すべきか
• 受け入れるべきか

を判断することです。

優れたプロジェクトマネージャは、リスク分析を使って未来の不確実性に対する意思決定を行っています。

関連用語

• リスク（Risk）
• リスク登録簿（Risk Register）
• リスクマネジメント
• リスク対応計画
• リスクトリガー
• 課題（Issue）
• 根本原因分析
• 意思決定

まとめ

リスク分析とは、特定したリスクの発生確率や影響度を評価し、対応の優先順位を決める活動です。

定性的リスク分析では優先順位を判断し、定量的リスク分析では影響を数値化します。

重要なのは、分析結果を作成することではなく、プロジェクトマネージャが適切な判断を行い、問題発生を防ぐことです。

リスク分析は、未来の不確実性を管理し、プロジェクト成功の可能性を高めるための重要な活動です。

関連記事

• リスク（Risk）とは？
• リスク登録簿（Risk Register）とは？
• リスクマネジメントとは？
• 課題（Issue）とは？
• 根本原因分析とは？
• 教訓（Lessons Learned）とは？

よくある質問（FAQ）

Q. リスク分析とは何ですか？

A. 特定したリスクについて、発生確率や影響度を評価し、対応の優先順位を決める活動です。

Q. 定性的リスク分析と定量的リスク分析の違いは何ですか？

A. 定性的分析は優先順位を決めるための分析、定量的分析は数値を用いて影響を評価する分析です。

Q. リスク分析はいつ実施しますか？

A. リスクを特定した後に実施します。ただし、プロジェクト状況の変化に合わせて継続的に見直すことが重要です。

プロジェクトでは、「課題」という言葉が頻繁に使われます。

しかし、実務では「問題」「リスク」「課題」が混同されることが多く、何を管理すべきなのか分かりにくくなることがあります。

プロジェクトを成功させるためには、発生した問題を適切に管理し、解決につなげることが重要です。

この記事では、課題（Issue）の意味やリスク・問題との違い、実務での管理方法までわかりやすく解説します。

一言でいうと

課題とは、「プロジェクトの目標達成に影響を与えるため、対応や解決が必要な現在発生している事象」です。

課題（Issue）とは

課題（Issue）とは、プロジェクトの進行に影響を与えており、解決や対応が必要な事象を指します。

PMBOK®では、課題管理（Issue Management）として、発生した問題を記録・分析し、適切な担当者によって解決へ導く活動が重要視されています。

課題は、単なる「困りごと」ではありません。

プロジェクト目標（スコープ・スケジュール・コスト・品質など）へ影響する可能性があるため、計画的に管理する必要があります。

課題が重要な理由

プロジェクトでは、どれだけ計画を立てても予期しない問題は発生します。

例えば、以下のような事象です。

• 必要な人員が確保できない
• 顧客との認識が一致していない
• 設計内容に問題が見つかった
• 意思決定が遅れて作業が進まない

これらを放置すると、後工程への影響が大きくなり、納期遅延や品質低下につながります。

そのため、課題を早期に把握し、解決まで追跡することが重要です。

課題・問題・リスクの違い

実務では、問題が発生すると、それを「課題」として管理対象にすることが多くあります。

つまり、

問題は「起きた事象」、課題は「解決すべき管理対象」

と考えると理解しやすくなります。

課題管理の流れ

1. 課題を発見する
2. 課題管理表へ記録する
3. 影響度や優先度を判断する
4. 対応方針を決定する
5. 担当者・期限を設定する
6. 解決まで進捗を確認する
7. 完了後に効果を確認する

重要なのは、「課題を登録すること」ではなく、「解決まで追跡すること」です。

課題管理表に記載する主な項目

実務ではこんな場面で活用される

例えば、システム開発プロジェクトで顧客から追加要望が出た場合を考えます。

この時点では、単なる「要望」です。

しかし、追加要望によって納期やコストへ影響する場合、プロジェクトとして対応判断が必要になります。

そこで、

• 影響範囲を確認する
• 対応するか判断する
• 必要な変更手続きを行う
• 関係者へ共有する

という形で課題として管理します。

よくある勘違い

課題管理表を作れば課題管理ができているわけではない

課題管理表に大量の項目を登録しても、解決されなければ意味がありません。

重要なのは、課題ごとに「誰が」「いつまでに」「何をするか」を明確にすることです。

すべての問題をPMだけが解決するわけではない

プロジェクトマネージャの役割は、すべての問題を自分で解決することではありません。

適切な担当者を設定し、必要な意思決定を支援しながら、解決へ導くことが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、課題が発生した際に、どのように管理し解決したかが重要な論点になります。

午後試験では、以下のような観点を説明できることが重要です。

• 課題をどのように把握したか
• 影響度をどのように評価したか
• 誰を巻き込み解決したか
• 再発防止につなげたか

優れたプロジェクトマネージャは、課題を単なる問題処理ではなく、プロジェクト改善の機会として活用します。

PM道場のワンポイント

課題管理で重要なのは、「課題をなくすこと」ではなく、「課題が放置されない仕組みを作ること」です。

実務では、課題が発生すること自体を悪いことと考えてしまう場合があります。

しかし、複雑なプロジェクトでは、課題が発生することは自然なことです。

重要なのは、問題を早期に発見し、適切な人へ共有し、解決へ進められる環境を作ることです。

優れたプロジェクトマネージャは、問題がないプロジェクトを作るのではなく、問題を早く解決できるプロジェクトを作っています。

関連用語

• リスク（Risk）
• リスクマネジメント
• 変更要求
• 課題管理
• 根本原因分析
• 教訓（Lessons Learned）
• ステークホルダー
• 意思決定

まとめ

課題（Issue）とは、プロジェクトの目標達成に影響するため、対応や解決が必要な事象です。

リスクが「将来発生する可能性があるもの」であるのに対し、課題は「現在対応が必要なもの」です。

プロジェクトマネージャは、課題を適切に管理し、関係者と協力しながら解決へ導く役割を担っています。

関連記事

• リスク（Risk）とは？
• リスクマネジメントとは？
• 変更要求とは？
• 根本原因分析とは？
• 教訓（Lessons Learned）とは？

よくある質問（FAQ）

Q. 課題（Issue）とは何ですか？

A. プロジェクトの目標達成に影響するため、対応や解決が必要な現在発生している事象です。

Q. リスクと課題の違いは何ですか？

A. リスクは未来の不確実な出来事、課題は現在発生しており対応が必要な事象です。

Q. 課題管理で重要なことは何ですか？

A. 課題を記録するだけではなく、担当者・期限・対応方針を明確にし、解決まで追跡することです。

「この仕様変更が発生すると、納期に影響するかもしれません。」

プロジェクトでは、将来発生する可能性のある不確実な出来事が数多く存在します。

これらの不確実性を適切に把握し、対応策を準備することが、プロジェクトマネージャの重要な役割です。

この管理対象となるものがリスク（Risk）です。

この記事では、リスクの意味や問題との違い、プロジェクトでの管理方法までわかりやすく解説します。

一言でいうと

リスクとは、「将来発生する可能性があり、発生した場合にプロジェクトへ影響を与える不確実な出来事」です。

リスクとは

リスクとは、将来起こる可能性がある出来事であり、その発生によってプロジェクトの目標（スコープ・スケジュール・コスト・品質など）へ影響を与えるものです。

PMBOK®では、リスクを「プロジェクト目標に影響を与える可能性のある不確実な事象」として扱います。

重要なのは、リスクは必ずしも悪いものだけではないという点です。

プロジェクトに悪影響を与えるリスクを脅威（Threat）、良い影響を与える可能性があるものを好機（Opportunity）として扱います。

リスクが重要な理由

プロジェクトには、未来を完全に予測できないという不確実性があります。

例えば、以下のような出来事です。

• 重要メンバーが急に離脱する
• 技術的な問題が発生する
• 顧客から追加要求が発生する
• 外部サービスの提供が遅れる

これらを事前に把握せず、問題が発生してから対応すると、大きな影響につながる可能性があります。

そのため、プロジェクトでは「起こってから対応する」のではなく、「起こる前に準備する」ことが重要です。

リスクと問題（Issue）の違い

簡単に言うと、

リスクは「未来の不確実な出来事」、問題は「現在発生している課題」です。

リスクの種類

リスクマネジメントの流れ

1. リスクを特定する
2. 発生確率や影響度を評価する
3. 対応方針を決定する
4. 対応策を実施する
5. 継続的に監視する

リスク管理は、一度計画すれば終わりではありません。

プロジェクトの状況変化に合わせて、継続的に見直すことが重要です。

実務ではこんな場面で活用される

例えば、新しい技術を利用したシステム開発プロジェクトを考えます。

リスクとして、

• 技術検証が不足している
• 開発メンバーが経験不足である
• 想定より開発期間が長くなる

といったことが考えられます。

そこで、事前に技術検証を実施したり、有識者を参画させたりすることで、リスクが問題化する可能性を低減できます。

よくある勘違い

リスク管理とは、リスクをゼロにすることではない

すべてのリスクをなくすことは現実的ではありません。

重要なのは、影響の大きいリスクを優先的に管理し、発生した場合でもプロジェクトへの影響を最小限にすることです。

悪いことだけがリスクではない

リスクというと「問題になる可能性」と考えがちですが、PMBOK®では好機もリスクとして扱います。

例えば、新技術の活用によって開発期間を短縮できる可能性もリスクです。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、リスクをどのように特定し、評価し、対応したかが重要な論点になります。

午後試験では、単に「リスク管理を実施した」と書くのではなく、

• どのようなリスクを予測したか
• 発生確率や影響度をどう判断したか
• どのような予防策・対応策を実施したか

を具体的に説明できることが重要です。

優れたプロジェクトマネージャは、問題対応能力だけではなく、問題になる前に兆候を捉える力が求められます。

PM道場のワンポイント

リスク管理とは、「未来を予測する活動」ではなく、「未来の不確実性に備える活動」です。

実務では、リスク管理表を作成すること自体が目的になってしまうことがあります。

しかし、本当に重要なのは、リスクを登録することではありません。

「このリスクが発生すると何が起こるのか」
「どのタイミングで対応すべきなのか」
「どんな兆候を見逃してはいけないのか」

をチームで共有することです。

優れたプロジェクトマネージャは、問題が起きてから対応するのではなく、問題になる前の兆候を管理しています。

関連用語

• リスクマネジメント
• リスク登録簿（リスクレジスター）
• リスク対応計画
• リスク評価
• 課題（Issue）
• 変更要求
• 根本原因分析
• 教訓（Lessons Learned）

まとめ

リスクとは、将来発生する可能性があり、発生した場合にプロジェクトへ影響を与える不確実な出来事です。

重要なのは、リスクを完全になくすことではなく、事前に把握し、適切な対応策を準備することです。

プロジェクトマネージャは、問題が発生した後に対応するだけではなく、未来の不確実性を管理する役割を担っています。

関連記事

• リスクマネジメントとは？
• リスク登録簿（リスクレジスター）とは？
• 課題（Issue）とは？
• 根本原因分析とは？
• 教訓（Lessons Learned）とは？

よくある質問（FAQ）

Q. リスクとは何ですか？

A. 将来発生する可能性があり、発生した場合にプロジェクトへ影響を与える不確実な出来事です。

Q. リスクと問題の違いは何ですか？

A. リスクはまだ発生していない未来の不確実性であり、問題はすでに発生している事象です。

Q. リスクは悪いことだけを指しますか？

A. いいえ。PMBOK®では、プロジェクトに良い影響を与える可能性がある好機もリスクとして扱います。

プロジェクトマネージャについて学ぶと、必ずと言っていいほど耳にする言葉です。

そのため、「話すのが得意な人」「誰とでもすぐに打ち解けられる人」がPMに向いていると思われがちです。

しかし、PMBOK®を読むと少し違った景色が見えてきます。

PMBOK®では、コミュニケーション・マネジメントについて、「必要な情報を、必要な人へ、適切なタイミングで届けるための計画・実行・監視」を重視しています。

一方で、「社交的になりましょう」「話し上手になりましょう」とは書かれていません。

私はこの違いに救われました。

なぜなら、私は人見知りだったからです。

私は「コミュニケーション能力を身に付けなければPMは務まらない」と思っていました。

しかし10年以上PMとして仕事を続ける中で気付いたのは、PMに本当に必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力だったということです。

私が一番苦手だったのは「初対面の人」と話すこと

人見知りにもさまざまなタイプがありますが、私が特に苦手だったのは初対面の人との会話でした。

プロジェクトが立ち上がると、多くのメンバーやステークホルダーとは初めて仕事をします。

本来であれば、自分から積極的に声を掛けて関係を築いた方が良いのでしょう。

しかし私は、

• 何と話しかければいいんだろう。
• 今話しかけても迷惑ではないかな。

そんなことばかり考えてしまい、自分から声を掛けることができませんでした。

「そのうち話す機会があるだろう。」

そう思って先延ばしにしていたのです。

ところが、その「話す機会」は決まってトラブルが起きたときでした。

トラブルのときに初めて話すのでは遅い

問題が発生すると、PMは多くの人と連携しながら状況を整理し、対応方針を決めなければなりません。

しかし、お互いに十分な関係性ができていない状態では、

• 相談しづらい
• 本音を引き出しにくい
• お願いもしづらい

という状況になります。

私は何度も、

「もっと早く話しておけば良かった。」

と後悔しました。

当時は「コミュニケーション能力が足りないからだ」と思っていましたが、今振り返ると違います。

コミュニケーションが生まれる場を設計できていなかったのです。

私を変えたのは「キックオフミーティング」だった

転機になったのは、キックオフミーティングの目的を変えたことでした。

以前の私は、キックオフはプロジェクトの目的やスケジュールを説明する場だと考えていました。

しかし今は違います。

私にとってキックオフの最大の目的は、

「最初のコミュニケーションを設計すること」

です。

自己紹介をする。

挨拶をする。

顔と名前を一致させる。

ほんの数分の会話でも構いません。

一度でも会話していると、その後のコミュニケーションは驚くほど楽になります。

チャットを送る心理的なハードルが下がります。

電話を掛けるときも、

「相手は自分の顔を思い出しながら話してくれている。」

そんな安心感があります。

私は社交的になったわけではありません。

社交的でなくても話せる環境を作っただけだったのです。

振り返ってみると、私は無意識のうちに「コミュニケーション・マネジメント計画」を見直していたのだと思います。

「誰と、いつ、どのようにコミュニケーションを取るか」を計画することは、情報共有だけではありません。

コミュニケーションが自然に生まれるきっかけを設計することでもあるのです。

PMBOK®の「テーラリング」を、自分自身にも適用してみた

PMBOK®では、プロジェクトの特性に合わせてプロセスや手法を調整することをテーラリングと呼びます。

私はこの考え方を、プロジェクトだけでなく自分自身にも当てはめるようになりました。

以前は、

• もっと話せるようになろう。
• 人見知りを克服しよう。

と考えていました。

しかし、それでは長続きしませんでした。

そこで発想を変えました。

「人見知りでも成果を出せるプロジェクト運営を設計しよう。」

そう考えるようになったのです。

キックオフを実施する。

定例会を設ける。

レビューの場を作る。

相談しやすいルールを決める。

これらはプロジェクトを管理するためだけではありません。

自分の苦手を補うための仕組みでもありました。

PMは「人を変える」のではなく、「行動しやすい環境」を設計する

この考え方は、プロジェクトメンバーにも当てはまります。

PMは、

「もっと相談してください。」

「もっと報告してください。」

と言うだけでは十分ではありません。

相談しやすいタイミングを決める。

報告する基準を決める。

定例会や1on1を設ける。

つまり、行動しやすい環境を設計することが重要です。

これは、PMBOK®のステークホルダー・エンゲージメントの考え方にも通じます。

ステークホルダーを動かすために必要なのは、「相手の性格を変えること」ではありません。

相手が行動しやすい環境を整えることです。

そして、この考え方は自分自身にも使えます。

人見知りという性格を変えようとするのではなく、

人見知りでも行動できる環境を設計する。

その方が、ずっと現実的で、再現性があります。

私が考えるPMのコミュニケーション能力

私は昔、コミュニケーション能力とは、

• 話すのが上手なこと
• 誰とでも仲良くなれること

だと思っていました。

しかし、今は違います。

私にとってPMのコミュニケーション能力とは、

「必要な情報が、必要な人へ、必要なタイミングで届く状態を設計する力」

です。

話すことが目的ではありません。

プロジェクトを前に進めることが目的です。

だからこそ、PMに必要なのは社交性ではなく、

必要なコミュニケーションが自然に生まれる仕組みを作る力なのだと思います。

おわりに

私は今でも人見知りです。

初対面の人と話すことが得意になったわけではありません。

それでもPMとして仕事を続けられているのは、自分を変えたからではありません。

自分に合った環境を設計するようになったからです。

これは、プロジェクトマネジャという仕事の本質にも通じています。

PMは、プロジェクトを成功へ導くために、計画を立て、仕組みを作り、人が動きやすい環境を整えます。

それなら、自分自身に対しても同じことができるはずです。

苦手なことを無理に克服しようとするのではなく、

苦手でも成果を出せる環境を設計する。

私は、それこそがプロジェクトマネジメントの考え方を、自分自身に活かすことなのだと思っています。

あなたへの問いかけ

あなたは、苦手なことに出会ったとき、自分を変えようとしていませんか。

それとも、苦手でも成果を出せる環境を設計しようとしていますか。

プロジェクトマネジメントは、プロジェクトを管理するための知識だけではありません。

自分自身をマネジメントするための考え方でもあるのではないでしょうか。

まずは一つだけ、環境を変えてみる

もしあなたが私と同じように人見知りで悩んでいるなら、性格を変えようとする必要はありません。

まずは一つだけ、コミュニケーションが自然に生まれる仕組みを作ってみてください。

例えば、キックオフで必ず全員と自己紹介をする、定例会を設ける、1on1の時間を確保するなど、小さな工夫で十分です。

自分を変えることは難しくても、環境を変えることはできます。

その小さな仕組みが、プロジェクトだけでなく、あなた自身をきっと助けてくれるはずです。