◆リスクと不確実性の違い
リスクと不確実性はしばしば同じ意味で使われているが、大きな違いがある。その違いとは、リスクはあくまでに確率事象であり、母集団における分布が過去の経験で分かっている。これに対して、不確実性の場合には母集団すらわからないことだ。
たとえば、こういうことだ。ある作業が遅れるかもしれないとする。その作業の方法がはっきりわかっている。遅れる理由は担当者のスキル不足で、十分なスキルを持つメンバーを担当させられない可能性がある。この場合の母集団はその作業に必要なスキルを持つメンバーであり、その中でスキル不足な人の割合がリスクになる。たとえば、過去の実績で判断すると、１０人の内の３人だと今の計画では予定通り作業が終わらないとすれば、遅れが発生するリスクは３０％ということになる。
ところが、別の作業はどのようにしてよいか分からないとしよう。この場合、どの範囲で遅れる確率を考えればよいか分からない。つまり、母集団が分からないのだ。これはリスクではなく、不確実性である。
◆不確実性をリスクと捉えても対応できない
この指摘は、２０世紀を代表する経済学者の一人であるフランク・ナイトの指摘であるが、プロジェクトマネジメントにおいては、この違いは極めて重要である。実は不確実性をリスクとして扱っているケースが少なくないが、不確実性をリスクとして扱うと、リスク対応策は策定できない（実際には、スキルの高い人を投入するとか、スケジュールに余裕を持たせるといった策を立てるが、実はこれでは対応策にならない）。
ここで話を進めるに当たってプロジェクトにおけるリスクの基本的な性質について言及しておきたい。リスクは意思があって初めて発生する。というか、意思があるのに現実が意思に反する可能性がリスクである。逆にいえば、意思がないところにリスクはない。まず、このことを頭に入れておいてほしい。
◆不確実性の扱い方
では、プロジェクトで不確実性はどのように扱えばよいか。プロジェクト（マネジメント）の大前提は、オペレーションに入ったプロジェクト（ＰＭＢＯＫ（Ｒ）でいえば、プロジェクト憲章が作られた後で、計画を作り、進めていく段階）には不確実性はないことだ。現実的な前提ではないと思う人も多いだろう。ところがこの前提は極めて現実的なのだ。
世紀のプロジェクトに限らず、ルーティンに近いようなプロジェクトでも不確実性は存在する。たとえば、ＩＴのプロジェクトで初めて顧客。ＲＦＰはＡ４数枚。何をしたいかもはっきり分かっていない可能性もある。このとき、顧客が要求を最終的にきちんと決定できるかどうかはリスクではなく、不確実性であることが多い。顧客の意思決定のメカニズムがはっきりしないので、顧客において何が実現できれば決定できるかがはっきりせず、母集団が決まらない。ひょっとすると、意思決定のメカニズムがないかもしれない。決定できるかどうかで、プロジェクトの進め方は変わってくるわけだが、その判断は難しいし、しばらく付き合ってみないと分からない。
このようなとき、プロジェクトマネジメントでは、「前提」を置く。この例だと、「顧客は最終的に要求を決めることができる」という前提を置くのだ。その上で、計画を作って進めていく。
◆前提とは意思決定である
前提を置くと書いたが、これは意思決定である。「顧客が要求を決めることができる」ことを前提におくかどうかでは、仕事の進め方が違ってくるし、場合によっては受注するかどうかにも影響を及ぼす。このようにプロジェクトにおいて、前提を置くことは極めて重要な意思決定であり、プロジェクトリーダーのもっとも重要な仕事である。
プロジェクトリーダーの意思決定には、前提と「制約」がある。この２つをプロジェクトのデザインという。ところが、制約は決めるのに、前提を決めていないケースが多い。つまり、プロジェクトをデザインしないままにプロジェクトの計画にかかる。
プロジェクトリーダーが前提を決めることは、前提で仮置きした不確実性に責任を持つことを意味する。ある顧客が契約後に要求を決めることができず、開発時期を延ばしてほしいと言い出すトラブルがあった。このときに、プロジェクトマネジャーが何をやっているのかと怒られていたが、これは本末転倒で、責任はプロジェクトスポンサーの立場の人にある。
前提は、常識的なところに収まることが多い。これを暗黙の前提と呼んでいるが、トラブルを起こしたプロジェクト、特にコミュニケーションの問題で云々といっているプロジェクトでは暗黙の前提が崩れていることが原因になっているケースが多い。
上に述べたようにプロジェクトでは計画通りに行かない可能性をリスクだと言っている。これは計画ができるということは母集団が分かっており、ある程度、可能性もわかっているという考えに立っているからだが、リスクはそれだけではないだろうという指摘をする人が多い。
そのとおりで、計画に対するリスク以外に、上に述べたとおり不確実性に対して、「意志決定」を行い、その意思決定が引き起こすリスクがある。実際には前提だけではなく、制約の決定も含まれるので、計画に対するリスクに対して、デザインに対するリスクと言えるものである。
◆デザインに対するリスクはプロジェクトリーダーが対応責任を持つ
デザインに対するリスクは意思決定者がリスクオーナー（対応責任者）となるべきリスクであり、このリスクオーナーをプロジェクトに押し付けるのは間違いである。押し付けるだけならともかく、前提の決定をせずに、不確実性そのものをプロジェクトに落ち着けているケースも多い。プロジェクトマネジャーが上司であるプロジェクトスポンサーに対して文句を言っているケースはこのようなケースが多い。このようなケースでは、プロジェクトでは不確実性とリスクを区別せず、不確実性もリスクとだといい、プロジェクトマネジャーがリスクオーナーになっているケースが多い。
プロジェクトスポンサー（プロジェクトリーダー）とプロジェクトマネジャーの責任の分担の中で、この点がもっとも重要である。だから、戦略ノート３０２話で述べたような予備費の権限の分担が存在するわけだ。
極論すれば制約を決めるだけではリーダーではない。制約と前提を決めるからリーダーなのだ。つまり、プロジェクトをデザインするのがプロジェクトリーダーである。この点を十分に認識しておきたい。
◆関連セミナーを開催します
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆戦略を実行するプログラムマネジメント ◆3.5PDU's
日時・場所：【Zoom】2024年 11月 26日（火）13:30-17:00（13:20入室可）
※Zoomによるオンライン開催です。
※少人数、双方向にて、演習、ディスカッションを行います
講師：鈴木道代（プロジェクトマネジメントオフィス，ＰＭＰ，ＰＭＳ）
詳細・お申込 https://pmstyle.biz/smn/program30.htm
主催 プロジェクトマネジメントオフィス、ＰＭＡＪ共催
※Youtube参考動画「プロジェクトマネジメントの基礎」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【カリキュラム】
１．プログラムマネジメントとは
２．戦略サイクルとプログラムデザイン
３．ベネフィットのマネジメント
４．ステークホルダーマネジメント
５．プログラムにおけるプロジェクト間の調整
・プロジェクト間のコンフリクトの調整
・スケジュール管理とリソース管理
・リスク管理
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
