リスクアセスメント支援

アセスメント結果の正当性をプロジェクトマネジャーに理解してもらうには、プロジェ クトマネジャー判断の妥当性検証と同様にアセスメント結果を導き出したアセッサーの 根拠が必要である。

そこで、アセスメント結果の正当性を示す情報として過去の失敗事例を利用する。過去 プロジェクトと進行中プロジェクトにおいて背景・特性等が全く同じであることは稀であ る。そのため、過去のプロジェクトと同じ施策が同じ結果を導くとは言えないが、類似プ ロジェクトと同じ結果を導く確率は高い。類似プロジェクトの失敗事例を提示すること で、プロジェクトマネジャーに現在進行中のプロジェクトにおいて同じ失敗を起こさない ための回避策を熟慮させることが可能となる。この考え方に基づきアセスメントプロセス を提案する。

(1) プロジェクトの状態や，進行過程で行ったイベント (2) プロジェクトの特性や，背景

(3) 進行過程で把握しているプロジェクトのリスク (4) リスクに対するプロジェクト判断

「判断」＝「計画」＋「根拠」

計画の内容だけでなく，リスクをどのように捉えてプロジェクトとしての計画 を導き出したかという根拠を記載する．ここでは，PM が判断した”PM 判断”

とプロジェクトを支援する立場であるアセッサーを含む定期的会議出席者の”

アセスメント結果”も記述するとともに，PM判断・アセスメント結果を踏まえ てプロジェクトとして決定したものを「判断」として記載する．

(5) 判断にもとづいた施策の為の具体的な行動

「行動」＝「実施」＋「やり取り・工夫」

計画を実践する際に、どのようなやり取りや工夫を記載する．

(6) 行動に対して表れた結果

リスクに対する施策が失敗した場合でも対応できるよう，リスクに対する施策 がどのような「結果」になったかまで，監視する．

7.4.1 失敗知識の活用方法

失敗知識を利用したアセスメントプロセスについて説明する。アセスメントプロセスは 以下の4ステップからなる。

[Step1]プロジェクトマネジャーがプロジェクトの状況を定期的に報告

プロジェクトマネジャーは、週報のような定期報告において、リスク対応プロセス情報 の形式でアセッサーにプロジェクトの状況を報告する。

[Step2]アセッサーが過去の失敗事例を提示

プロジェクトマネジャーの報告内容に対して、アセスメントを実施する。アセスメント 結果には根拠を示すものとして過去事例（失敗知識データベース）の中から類似と判断し た過去の失敗事例を添える。特に、プロジェクトマネジャーが過去に失敗した事例と同様 な判断・実施を行ったものについてはその根拠を質問する。

[Step3]プロジェクトマネジャーが過去事例との違いを回答

アセスメント結果やアセッサーからの質問に対する回答を行う。特に、過去と類似の施 策については、過去と同じ結果に陥らないと判断する根拠を明確にする。

[Step4]アセッサーが検証し定期報告を受理

プロジェクトマネジャーの回答内容を検証する。回答に問題があるようなら、その旨を 示し再度[Step3]に差し戻す。最終的に、アセッサーが問題なしと判断したら定期報告を受 理する。プロジェクトマネジャーとアセッサーの中で折り合いがつかない場合は定期的会 議内で幹部を交えて議論することとする。

アセスメントプロセスの流れを図7.3に示す。

図 7.3 アセスメントプロセス

上記のプロセスを実現するには、アセスメント結果に対しアセッサーが責任を負う仕組 みも必要となる。

7.4.2 リスク対応プロセス情報の拡張

プロジェクトマネジャーは施策を決定する際に過去事例と進行中プロジェクトと対比 して施策を熟慮し易くする必要がある。そのため、過去事例においても、進行プロジェク

トと同形式の情報が必要となる。そこで、過去事例として蓄積する形式も、表7.2で提案 したプロジェクトマネジャーの妥当性検証の際に用いるリスク対応プロセス情報と同様 の形式とする。

ここで、アセスメント結果の根拠として過去の失敗事例を提示する場合には、なぜ失敗 に繋がったか原因を検討した「反省」、失敗を通して得られた「教訓」、どのような対策 を行えばよかったかという「対策案」もプロジェクトマネジャーにとって有益な情報と成 り得る。上記を踏まえ、リスク対応プロセス情報を拡張し再定義する。再定義したリスク 対応プロセス情報を表7.3に示す。

表 7.3 リスク対応プロセス（再定義）

なお、(7)は結果に陥らないためにはどのようにすれば良かったかという項目である。

これより、リスク～結果の全体と関係付けることが出来る。再定義したリスク対応プロ セス情報の各項目の関係性を図7.4に示す。

図 7.4リスク対応プロセス情報の各項目の関係性

7.4.3 リスク対応プロセス情報の利用方法

図7.3のアセスメントプロセスにおいて、プロジェクトマネジャーの施策決定にリスク 対応プロセス情報を利用してもらうには、情報の見せ方も重要である。プロジェクトマネ ジャーが施策を熟慮する際には、施策に対する結果を常に考えながら進めていくことか ら、リスク対応プロセス情報の各項目を独立させて見せるのではなく、イベント～反省の 流れとして見せることが有効であると考える。

アセスメントプロセスの[Step2][Step 3]の具体的な処理である、リスク対応プロセス情 報を用いた失敗事例の提示方法について図7.5を用いて説明する。

イベント リスク 判断 行動 結果

特性 背景

反省 教訓 対策 計画

根拠

やり取り 工夫

(1) プロジェクトの状態や，進行過程で行ったイベント(顧客折衝等) (2) プロジェクトの特性や，背景

(3) 進行過程で把握しているプロジェクトのリスク (4) リスクに対するプロジェクト判断

「判断」＝「計画」＋「根拠」

(5) 判断にもとづいた施策の為の具体的な行動

「行動」＝「実施」＋「やり取り・工夫」

(6) 行動に対して表れた結果

(7) リスク～行動での反省や，得られた教訓，同様な状況での対策案

図 7.5 失敗事例の提示

リスク Aに対して、プロジェクトマネジャーが判断 Aを行ったとする。アセッサーは 進行中プロジェクトと同じ背景・特性等を持つ類似プロジェクトから過去の失敗事例を検 索する。同じリスクに対し同様の判断（判断A）を行った事例を検索し、そのリスクが陥 った失敗(結果 A)および反省（反省 A）、教訓（教訓 A）、対策（対策 A）を抽出する。

進行中プロジェクトに対して、陥る可能性のある失敗（失敗A）と、過去プロジェクトで 検討された再発防止策（対策A）を提示することで、進行中プロジェクトのリスクの回避 策をプロジェクトマネジャーに熟慮させられる。

7.4.4 失敗知識の収集

リスク対応プロセス情報の概念でリスクへの対応過程を整理しておくことは、プロジェ クト完了時のリスク知識の収集を容易に実現することにも繋がる。

失敗知識は、アセスメントプロセスにおいて作成する定期報告から収集することとす

る。 7.2.3.1 のアセスメントプロセスにおける[Step1]の”プロジェクトマネジャーの定期

報告”から「(1)イベント～(3)リスク、(5)行動」の項目が取得可能である。「(4)判断」は、

プロジェクトマネジャー判断とアセスメント結果をもとに決定したものである。[Step1]

で取られるプロジェクトマネジャー判断と[Step2]で得られるアセスメント結果を踏まえ

て、[Step3、4]を経てプロジェクトとしての判断が決定される。

このようにして得られた「(1)イベント～ (5)行動」の項目に加え、リスクへの対策に対 し発生した事象・現象を「(6)結果」として定期報告に書き記す。また、プロジェクト終了 後に、ヒアリング等でイベント～結果に対する「(7)反省、教訓、対策」を収集・追加すれ ば、リスク対応プロセス情報は収集できる。

項目(7)はプロジェクト終了後に追加するものの、項目(1)～(6)についてはプロジェクト 進行過程で収集可能である。特に、プロジェクトの原因分析において、プロジェクトの進 行過程の情報を収集するのは困難であり、様々なドキュメントやヒアリングなどによりプ ロジェクト経緯を明らかにしなければならないが、リスク対応プロセス情報の概念で情報 を収集しておけば、組織的分析手法におけるプロジェクト経緯の整理が容易に行える⁸⁷。

ここで、任意のリスクに対する項目(1)～(6)が一つの定期報告内で完結することはほと んど無い。また、一つの定期報告には複数のリスク対応プロセス情報に関する項目が存在

87 さらに言うと、リスク対応プロセス情報を整理しておけば、常に客観的なプロジェクト認識を行うこと ができるとも考えられる。

する。そこで、定期報告を跨って記載している、任意のリスク対応プロセス情報の項目間 の関連性を把握できるようにする必要がある。

定期報告とリスク対応プロセス情報の項目(1)～(6)の関係を図 7.6 に示す。このリスク 対応プロセス情報を管理し、特にプロジェクトの失敗に繋がったものを失敗知識とする。

図 7.6 定期報告とリスク対応プロセス情報の関係