【PMBOK第8版】リスクと他領域の相互作用とは?「一番厄介な急所」を見極める実務の視点

目次
このサイトの運営者
SSAITS代表・山脇弘成

山脇 弘成(SSAITS(サイツ)代表)

PMP®有資格者・Webプロジェクトマネージャー。
大手メディアや官公庁のWebプロジェクト実績多数。
「技術」だけでなく「対話」を重視し、御社の「ほんとは、こうしたかった」を形にします。

Promapediaは、SSAITS(サイツ)が運営する
プロジェクトマネジメント情報サイトです。

SSAITS公式サイトはこちら

リスクはすべての領域に潜んでいる

リスク・パフォーマンス領域は、それ単体で独立して存在するものではありません。
PMBOK第8版において、リスク・パフォーマンス領域は「スコープ、スケジュール、財務、ステークホルダーの各パフォーマンス領域と密接に関連・相互作用している」と定義されています。

そもそも「リスク」とは不確実性のことです。スケジュールの遅れ、予算の超過、ステークホルダーの反発など、どの領域であっても「不確実なこと(リスク)」が存在する限り、すべてこのリスク・パフォーマンス領域での検討事項になります。

今回は、PMBOKが示す他領域との相互作用の基本を整理しつつ、実務において私たちが「どの領域のリスクに最も注力すべきか」という濃淡の見極め方について解説します[1]Project Management Institute『プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)第8版』日本語版、第2部 … Continue reading。

ステークホルダー・パフォーマンス領域との相互作用

プロジェクトに潜む不確かさ(リスク)を見つけ出す上で、最も重要な情報源となるのが「ステークホルダー(利害関係者)」です。

ステークホルダーは、現場のチームだけでは気づけない潜在的なリスクについて重要な洞察を提供してくれる存在であり、適切なリスク査定方法を提案して不確かさのマネジメントを支援してくれます。
日頃から効果的なステークホルダー・エンゲージメント(関与)と対話を行っておくことで、彼らの期待に沿ったリスク管理が可能になり、懸念事項に対して先回りして(予防的に)対処できるようになります。

スコープ・スケジュール・財務領域との連動

リスクの発生や、それに対する対応策の実行は、プロジェクトの骨格である「スコープ・スケジュール・財務(コスト)」にダイレクトに波及します。

  • スコープへの影響:
    リスクが顕在化したり対応策を実行したりすることで、作業範囲の拡大(好機の場合)や縮小(脅威の場合)が引き起こされます。そしてスコープが変化すれば、当然スケジュールや予算にも影響が波及します。
  • スケジュールとの連動:
    スコープが安定している「予測型(ウォーターフォール)」では、スケジュール予備(バッファー)を設定・活用することでリスクを吸収し、計画通りの時系列を維持します。一方、要求が進化する「適応型(アジャイル)」では、新たなリスクの発生に合わせてバックログやイテレーションの計画そのものを柔軟に調整します。
  • 財務との直接的な連動:
    リスク管理の成否は、最終的にお金(財務)に現れます。社内プロジェクトであれば「コストの増減」として跳ね返り、社外向けのビジネスであれば「収益の創出または損失」として直結します。

PMBOKでは、これら単一の分析にとどまらず、スコープの適正化、スケジュールとの同期、財務上の予備(コンティンジェンシー予備)、そしてステークホルダーとの対話を「一体として統合」し、包括的なリスク対応戦略を構築することが求められています。

現場のリアル:プロジェクトごとに「リスクの濃淡」は違う

さて、ここまでPMBOKの解説を見てきましたが、書かれている内容としては「すべての領域と関わっている」という、ある意味で当たり前のあっさりとした整理にとどまっています。

実務を預かるプロジェクトマネージャーとして私たちが意識しなければならないのは、すべての領域を均等に心配することではなく、「プロジェクトによって、リスクの『濃淡』がまったく異なる」という現実です。

たとえば、同じシステム開発のプロジェクトであっても、置かれた状況によって弱点(リスクの集中する場所)は違います。

  • プロジェクトA: 予算は潤沢で社内の承認も降りているが、特殊な技術を持つエンジニアや機材が集まるか分からない(=「資源」の調達に最大のリスクがある)。
  • プロジェクトB: 開発チームは優秀で技術的な不安はないが、社内の役員同士の派閥争いが激しく、途中で予算を削られたり仕様をひっくり返されたりする恐れがある(=「ステークホルダー」や「財務」に最大のリスクがある)。

「一番厄介なリスクはどこか?」から逆算する

このように、どの領域にリスクが潜んでいるかはプロジェクトごとに千差万別です。
だからこそ、漫然と「リスク領域と他領域の関係」を教科書通りに考えるのではなく、プロジェクトの初期段階で「このプロジェクトで発生したら、一番厄介な(致命傷になる)リスクは何か?」を突き止めることが何より大切になります。

一番厄介なのが「人手不足」なら、資源パフォーマンス領域の対策(早めの囲い込みや代替要員の確保)に全力を注ぐ。
一番厄介なのが「仕様のちゃぶ台返し」なら、ステークホルダー領域の対策(こまめな合意形成やプロトタイプの早期共有)に時間を割く。

すべての領域に100点の網を張ることは不可能です。自分たちのプロジェクトの「最大の急所(一番リスクが濃い領域)」がどこにあるのかを見極め、そこに対して重点的に対策を講じることこそが、現場で本当に機能するリスクマネジメントの要諦です。

注

注
↑1 Project Management Institute『プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)第8版』日本語版、第2部 2.7.4「他の領域との相互作用」(101ページ)より要約・引用。
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次