プロジェクトマネジメントにおけるリスクとは

プロジェクトマネジメントにおけるリスクの理解

プロジェクトマネジメント初学者にとって、最初のハードルとなるのがこのリスク概念の理解だ。

「プロジェクトマネジメントって要するに課題管理でしょ」という認識でいるうちは、なかなかこのリスクと言う概念が理解しづらい。なぜなら、リスクとは現時点では対処できず、未来に顕在化してから課題として解決が可能となる問題だからだ。

リスクとは一体なにか

過去、人類がこの概念を見いだす以前には、漠然とした神のお告げや予期しうる事態について独占的に知識を有する占い師が闊歩する時代だった。

乱暴に言ってしまうなら、そのような神々のいたずらを、人類の手元に手繰り寄せ、利益を手にする能力が、このリスクという概念と言ってよい。

リスク〈上〉―神々への反逆 (日経ビジネス人文庫)

リスクの語源

たとえば、船乗りたちがあえて岸壁の間を通過するという危険を負ってでも、辿り着きたい場所がある、というような状況。ここには、危険を冒して、利益（ベネフィット）を取りに行く「冒険」のニュアンスが含まれる。

ここには、「きっと○○なら〜」という前提条件が必ず置かれる。リスクの本当の問題は、ベネフィットに目がくらみ、前提条件がさも絶対に存在するかのように過信し、リスクに目が行き届かなくなることなのだ。

前提条件とは

PMBOKでは前提条件を以下のように定義している。

計画を立てるにあたって、証拠や実証なしに真実、現実、あるいは確実にあると考えられた要因。

プロジェクトをマネジメントする際、プロジェクトマネジャーは、この前提条件をもとに計画を立て、課題を作成していく。

課題は前提条件を基に洗い出されるため、前提条件が変われば、当然課題も変更・追加されることになる。
前提条件の妥当性に疑いが生じた場合、前提条件ではなく、リスクとなるわけである。

前提条件の変化に対処するにはどうすればよいか

一般的には以下のような対応策が挙げられる。前提条件が変化しないように事前に手を打つ、変化した場合こうする、等の視点で課題化することがポイントだ。

リスク回避
前提条件の変化による課題に対処することが不可能と見る場合、そもそもプロジェクトやマイルストーンを選択しないという手段がある。

例：この納期（マイルストーン）の場合、全員の稼働率を150％以上にしなければならない（前提条件）。150％以上の稼働率を維持するのは難しいため、納期交渉を行う（リスク回避）。

リスク軽減
前提条件の変化をさせないよう、予め新たな課題を立てて実施する。

例：ユーザーからの要求事項は、要件定義工程開始前に全て明確となっている（前提条件）。ただし、途中成果物を見てから要件が変化する可能性があるため（前提条件の変化）、ユーザー評価のプロセスを多段階に入れる（リスク軽減）

リスク移転
前提条件が変化した場合、生じるコストを他者に移転させる。

例：保険に加入するなど資金面での対策を講じる。

リスク受容
前提条件が変化しても、変化後の課題を受け入れる。

例：前提条件変化後の課題についても、QCD（品質、コスト、納期）への影響がそれほど大きくないので何も対策を行わない。