リスクとコンティンジェンシー予備

プロジェクトにリスクはつきものです。というよりリスク対策を実施することが非常に重要です。

そこでリスク発生時の対策費として、コンティンジェンシー予備というものが出てきます。

どうでしょう「コンティンジェンシー予備」の呼称は、最近は一般化していると言えるでしょうか?

管理人は「使う人が少し出てきたかな」という感じがしています。今回はコンティンジェンシー予備について考えて見たいと思います。

コンティンジェンシーとは?

そもそも「コンティンジェンシー」とはどういう意味でしょうか?

それが曖昧だと、先に進めません。PMBOKガイドから引用します。

プロジェクトの実行に影響を及ぼすイベントまたは出来事。予備の適用が可能な場合がある。

リスクとはちょっと意味が違うようですが「リスクが顕在化したとき」と、考えてよさそうです。

リスクとは「機知の未知」と説明されていることもあるので、予測していた事態(普通は悪い方)が発生した場合と考えてよいでしょう。

コンティンジェンシー予備とは?

コンティンジェンシーの意味がわかれば、その「予備」ということなので、もうおわかりになると思います。

リスクが顕在化した場合の対策費ということです。「〜予備」で終わっていますが、リスク対策費とでも言いましょうか、予備費の意味を含んでいると考えてください。

どのような場合に使うのか?

リスクは「プロジェクトに対して悪い影響を与えるもの」として考えることが多いと思います。

リスクが顕在した場合に「どのような対応を想定しておくか」という「リスク対応策」については、「リスク対応の計画」プロセスで計画済みです。

そのリスク対応計画を立てる時点で「どの程度のリスク対策費が発生するか」を、あらかじめ見積もっておきます。

その見積られた費用が、「コンティンジェンシー予備」と呼ばれているのです。

あくまでも「既知の未知」に対する対応なので、リスク対応策で想定されたものです。

PMBOKでは、このコンティンジェンシー予備は「コストの一部として管理されるもの」として扱っています。

「管理される」とはどういうことか?

「管理される」とは一体どういうことなのでしょうか?

それは「コンティンジェンシー予備はベースラインに含めて管理される」ということを意味しています。

ベースラインとは、計画時に「スコープ、コスト、スケジュール」について、ステークホルダーと合意したものです。

そのためベースラインを変更する場合は、ステークホルダーの許可が必要です。

しかしコンティンジェンシー予備はベースラインに含まれているため、実際にリスク対応策を実施しなければならない場合でも、ベースラインの変更を伴わない範囲であれば、プロジェクトマネージャの権限で使用できます。

予測ができなかった場合はどうなるのか?

今まで説明してきたのは「既知の未知」であるコンティンジェンシー予備のことで、あくまでもリスク計画で想定している内容の話です。

そうではない場合、すなわち「予測していない事態」に陥った場合はどうするのでしょうか?

「未知の未知」に備える

PMBOKでは、そのような事態を想定して、さらにコストを積むよう説明しています。このような状態は「未知の未知」と呼ばれています。

「未知の未知」に対応するべく準備しておくのが「マネジメント予備」というものです。プロジェクトに対して、想定していない事象に対する予備費とでも言いましょうか。

自然災害であったり、国際問題の発生であったりと、予測が不可能な事象に対する予備費です。

当然、どれくらい積んでおくか? はスポンサーの資金力や、プロジェクトの重大性などで千差万別ですし、そもそもそんな予備費は設定しない、というケースもあるでしょう。

PMBOKとしては理想論として「そのような準備もしておくと、想定外の問題が発生したとき軽減されますよ」といっているようです。

ちなみにこのマネジメント予備は、プロジェクトマネージャの権限で使うことはできません。スポンサーの承認を得てはじめて使えます。

その場合、マネジメント予備はベースラインに組み込まれて管理されます。

現実はどうなのか?

予備費を確保することは難しい

プロジェクトに無限にコストをかけられれば何もいうことなしなのですが、厳しいプロジェクト予算の中で、湯水のように予備費を取ることはできません。

そこで各リスクに対する優先度と、影響度をシミュレーションして、予備費を算出します。

PMBOKでは「発生確率・影響度マトリックス」と呼んでいます。みなさんの会社でも似たようなものや、アレンジしたものを使われていることでしょう。

発生確率・影響度マトリックスを使用する

この「発生確率・影響度マトリックス」を使用して、リスク対応策の優先度を決めていきます。

PMBOKでは「好機」に対する分析も推奨していますが、現実として管理人は行ったことがありません。「脅威」に対する分析のみです。

この発生確率も影響度も定性的です。また社内で過去のプロジェクトの資産として、すでに対応策のパターンが決められていたりしますよね。

管理人もあえて逆らうことはせず、そのパターンをベースに、今回のプロジェクトの特性を当てはめて、対応策の取捨選択をしています。

利用できるものは十分に利用しましょう。先人方の英知が積み重なっているものですから。

説明できるリスク対応計画であること

リスク対応計画を立てる場合、プロジェクトマネージャが説明できる内容であることが重要です。

根拠が明確であれば、プロジェクトマネジメント計画書レビューも通ることでしょう。また顧客に対しても納得のいく説明もできると思います。

そこでリスク対応策の優先度が決定したあと、実際にどの程度のコストがかかるかをシミュレーションします。ここが難しいところです。

工数の一律何パーセントと決めるのもよいのですが、根拠を問われた場合に弱くなります。ある程度の意思を持って決めたいところです。

管理人はどのようにしているか?

管理人はどのようにしているか? を書いてみますが、次のとおりにしている場合がほとんどです。

  • まず組織で決められたパターンを使ってコストを計算する。●●リスクの場合は△△%など。
  • そこで計算した結果を、プロジェクト特性を念頭に入れて、微調整を行う。
    今回は、お客がうるさいようなので、◯◯リスクは、+◇◇%上乗せするなど。
    (ここが「意思を持って」行うところです)
  • 微調整後、全体として工数の何%になっているかを計算する。そして過去プロジェクトの事例と比較して、妥当かどうか判断する。

内容としては一般的かもしれませんが、参考にしてみてください。

まとめ

予備費の算出は頭が痛いところです。

少ないと、リスク顕在化したときに首が回らなくなりますし、多すぎると構築費用が跳ね上がり、顧客ともめる原因になってしまいます。

ひどいときには、予備費を全部削って価格交渉をしなければならないこともあり(政治的な圧力で)、実際に構築する側としては、どうすればよいかわからなくなる場合もあります。

ここはプロジェクトマネージャの腕の見せ所かもしれません。知恵を絞って取り組んでください。

管理人も知恵が回らず、いつも苦しんでいます。なんとかしたいですね。

PM

Posted by wpmaster