さてさて、そろそろ何か始めないとな

さいたま市のソフトウェアエンジニアのブログ

PMBOK第7版 原理・原則⑩|リスク対応を最適化すること

📌 はじめに

「リスク」と聞いて、どんなイメージが浮かびますか。多くの日本人にとって、リスクは「避けるべき危険なもの」として映りがちです。

しかし英語の "risk" は、本来「結果がどちらに転ぶかわからない不確かさそのもの」を意味します。語源はイタリア語の "riscare"、「岩礁の間を航行する」という言葉に由来します。うまく通り抜ければ利益、失敗すれば難破という、プラスとマイナスの両方の可能性を含んだ状況が原義です。

PMBOKでも、リスクは脅威(マイナス)と好機(プラス)の両面から捉えます。

  • 脅威:コスト超過や遅延、技術的失敗など、できれば避けたい影響
  • 好機:うまく活かせれば時間短縮やコスト削減、評判向上につながる可能性

原理・原則⑩「リスク対応を最適化すること」は、この2つを同時に見据えながら、プロジェクト全体を通じて継続的にリスクと向き合うことを求めています。


リスクとは何か

リスクとは、発生するかどうかが不確実な出来事や状況のことで、もし発生した場合にプロジェクトの目標へプラスまたはマイナスの影響を与えるものです。

脅威が現実になると、スケジュール遅延・コスト超過・技術的な失敗・評判の低下といった問題につながります。一方、好機をうまく活かせれば、納期短縮・コスト削減・市場シェアの拡大・信頼向上といったベネフィットが得られます。

リスクは特定されても、必ずしもプロジェクト中に顕在化するわけではありません。だからこそ、プロジェクト・チームはライフサイクル全体を通じて、既知のリスクと新たに生まれるリスクの両方を継続的に把握し続けることが重要です。


個別リスクと全体リスクの2つの視点

リスクには、見る粒度によって2つの層があります。

個別リスクは、特定の要素や活動に関連する個々のリスクです。たとえば「特定のベンダーの納品が遅れるリスク」のように、対象が明確で対応策を立てやすいのが特徴です。

全体リスクは、プロジェクト全体への不確かさの影響です。個々のリスクを合計したものではなく、すべての不確かさが絡み合った結果として、プロジェクトの成果がどれだけ変動しうるかを表します。ステークホルダーがその影響を受ける可能性の大きさでもあります。

全体リスクのマネジメントとは、プロジェクト全体がリスクにさらされている度合いを「受け入れられる範囲」に収めることです。そのために、脅威の要因を減らし、好機の要因を増やし、目標達成の確率を高めます。


リスクの受け止め方は人によって違う

同じリスクでも、どこまで許容できるかはステークホルダーによって異なります。この違いを理解するための2つの概念があります。

リスク選好は、見返りを期待して不確かさをどこまで積極的に受け入れるかという姿勢です。リスクを取ってでも大きな成果を狙うか、安全を優先するかの違いです。

リスクしきい値は、目標に対してどの程度のズレまで許容できるかの基準です。たとえばコスト目標に対して「±5%まで」という組織は、「±10%まで」という組織よりリスク選好が低いと言えます。

プロジェクト・チームは、関係するステークホルダーのリスク選好としきい値を把握した上で、リスク対応の方針を決める必要があります。


有効なリスク対応の5つの条件

リスクへの対応策は、思いつきや過剰反応であってはなりません。PMBOKは有効なリスク対応として、次の5つの条件を挙げています。

  • リスクの重大さに見合っている:小さなリスクに大きなコストをかけない。重要なリスクには適時に手を打つ。
  • 費用対効果が高い:対応にかかるコストが、リスクが顕在化したときの損失より小さいことが前提です。
  • プロジェクトの状況に照らして現実的:理論上は正しくても、実行できない対応策に意味はありません。
  • 関連ステークホルダーの同意を得ている:対応方針はチームだけで決めず、関係者の合意を得ることが必要です。
  • 責任者が任命されている:対応策を「誰かがやる」では機能しません。担当者を明確にすることで初めて実行に移せます。

リスクはプロジェクトの外にもつながっている

リスクはプロジェクト内に閉じたものではありません。プロジェクトがプログラムやポートフォリオの一部である場合、そのリスクはより広い範囲に影響を与えます。

プログラムでは、プロジェクトのリスクがベネフィットの実現に影響し、最終的な価値の大小に関わります。ポートフォリオでは、複数のプロジェクトのリスクが組み合わさり、事業目標全体の達成度に影響します。

そのため、プロジェクト単体のリスクを管理するだけでなく、上位の目標との関係でリスクを捉える視点も必要です。

具体例として、次のようなケースが考えられます。

【脅威の例】
あるシステム開発プロジェクトで、スケジュール優先のためセキュリティ要件を一部後回しにするリスク判断をした。プロジェクト単体では納期を守れたが、その後の監査でポートフォリオ全体がコンプライアンス違反に問われた。

【好機の例①】
あるプロジェクトで新しいクラウドサービスをいち早く採用したところ、コストと納期を大幅に短縮できた。その知見がプログラム全体に共有され、他のプロジェクトでも同様の効果が得られた。プロジェクト単体の好機が、上位レベルの価値向上につながった例です。

【好機の例②】
プロジェクト進行中に競合他社の撤退という想定外の状況が生まれた。プロジェクト単体では「スコープ外」として見送ることもできたが、ポートフォリオレベルで評価したことで市場シェア拡大の戦略に組み込まれ、追加投資の決断につながった。


リスク対応を最適化するとは

リスクへの対応は、問題が起きてから慌てて動くより、事前に評価して備える方がコストを抑えられます。これはリスクマネジメントに取り組む組織が実感として気づくことです。

読む側が現場に持ち帰れる問いは、次の2つに集約できます。

  • 今のプロジェクトで、脅威だけでなく好機として捉えられるリスクはないか?
  • リスク対応の責任者と判断基準は、ステークホルダーと合意できているか?

リスクを恐れて避けるのでも、楽観的に無視するのでもなく、継続的に評価し最適な対応を選び続けること。

それが「リスク対応を最適化すること」です。

なお、脅威に対してはマイナスの影響を減らすこと、好機に対してはプラスの影響を引き出せるように働きかけること、これがリスクマネジメントの基本的な方向性です。具体的な手法や実践については、PMBOKガイド第7版「2.8 不確かさパフォーマンス領域」に詳しく記載されています。

 

▶ 次回:PMBOK第7版 原理・原則⑪|適応力と回復力を持つこと


12の原理・原則全体を整理したい方へ

本記事は、PMBOK第7版 第3章「12の原理・原則」の一部です。

原理・原則全体の構造や読み方については、以下のまとめ記事で整理しています。

PMBOK第7版 第3章|12の原理・原則をどう読むべきか


📚 参考

PMI『プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)第7版』

※本記事はPMBOKガイド第7版の学習・実践促進を目的とした解説記事です。引用・要約は学習目的の範囲で行っています。


※本ページにはアフィリエイトリンクを含みます。

PMBOK第7版の原理・原則を継続して学ぶ方は、シリーズ記事とあわせて書籍も参照すると理解が定着しやすくなります。用語の確認や、原文のニュアンスを追いたい方は以下にリンクを置いておきます。

参考書籍:PMBOKガイド第7版(Amazon)