リスク管理より大事なことは - 室長のひとりごち

プロジェクトの条件
プロジェクトの定義のように知られているとおり、有限の期限でアウトプットを出す作業だ。
プロジェクトの目的、期間、顧客、場所、人、予算など、プロジェクトを構成する部品がすべてのプロジェクトで違い、同じプロジェクトは存在しない。
例えば、同じSIerが同じサービスを提供するとしても、顧客が違えば同じように進められることはありえない。
顧客の業界の風土や顧客の責任者が経験してきたことがSIerに強く影響するためだ。
SIer自身、プロジェクトメンバがいつも同じことはありえない。
たとえ同じメンバであっても、初期のプロジェクトといくつもプロジェクトを経験したときでは、技術の習得という条件が違う。

プロジェクトマネージャは、そのようなプロジェクトの諸条件を前提にプロジェクト計画を立て、推進するが、近年のプロジェクト計画の中には“リスク管理”が含まれていることが多い。
では、その“リスク管理”は何をするのだろうか。

リスク管理はリスク“項目”だけの管理
リスク管理の定義にある様に、

リスクを把握・特定することから始まり、把握・特定したリスクを発生頻度（発生確率、possibility）と影響度（酷さ、severity）の観点から評価した後、発生頻度と影響度の積を評価の尺度とした、リスクの種類に応じて対策を講じる

という管理をする。
この観点に立って考えれば、リスクとは原因なる“リスク自体を管理”する、ということになる。
実際、それで十分なのだが、リスク管理をしているのにプロジェクトがいわゆる“炎上”してしまうケースが後を絶たない。
なぜだろうか。

管理できることは、リスクだけ
リスク管理は、、識別、定量化したあと、どのように対応するか意思決定する。
対応の選択肢はいくつかあって、

回避策　起きないように避ける

転嫁策　リスクを自分以外に回す

軽減策　起きても損害が大きくならないように対策する

受容策　起きても仕方がないねと腹を括っておく

意思決定して“どうするか”を決めておく。
この意思決定した後にリスクとして識別した望まないリスクが発生したときの対応に問題があることが多い。

リスクの定義には、続きの文章があって、

また、仮にリスクが実際に発生した際には、リスクによる被害を最小限に抑えるという一連のプロセスをいう。

というものがある。
この“リスクによる被害を最小限に抑えるという一連のプロセス”こそが大事で、これがきちんとして回っていれば、リスク何て“もう怖くない”はずだ。
リスク管理の対応の選択肢にある“回避策”が取れるリスクなら、本来、リスクを発生しないようにコントロールできるはずだからだ。
つまり、実際発生する前の通常の作業管理の仕組みの中で識別したリスクが発生する兆候がないか知ることができ、兆候を発見した段階で通常の課題としてコントロールすればよい。

まあ、それができないので炎上するのだけれど。