【PMBOK第8版対応】リスク・マネジメントの計画とは何か?

目次
このサイトの運営者
SSAITS代表・山脇弘成

山脇 弘成(SSAITS(サイツ)代表)

PMP®有資格者・Webプロジェクトマネージャー。
大手メディアや官公庁のWebプロジェクト実績多数。
「技術」だけでなく「対話」を重視し、御社の「ほんとは、こうしたかった」を形にします。

Promapediaは、SSAITS(サイツ)が運営する
プロジェクトマネジメント情報サイトです。

SSAITS公式サイトはこちら

リスク・マネジメントの計画とは

リスク・マネジメントの計画とは

「リスク・マネジメントの計画」とは、プロジェクトのリスク・マネジメント活動を「どのようなアプローチやルールで実行するか」をあらかじめ定義するプロセスのことです[1]Project Management Institute『プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)第8版』日本語版、第2部 … Continue reading。

リスク・マネジメントの手法を考えるだけでなく、 リスクをグループ化(区分)したり、リスクの発生確率と影響度の物差し(評価尺度)を定義したり、リスクに対するプロジェクトメンバーの役割と責任を明確にする活動も含まれます。
PMBOK第8版においても、このプロセスはプロジェクトが構想された初期段階で開始され、プロジェクトの早期に完了する必要があるとされています。

リスク・マネジメントの計画はなぜ必要なのか?

リスク・マネジメントの計画はなぜ必要なのか?

プロジェクトが失敗する原因は様々ですが、「悪運にみまわれた」「想定外のトラブルが起きた」というのは、失敗したプロジェクトのプロジェクト・マネジャー(以下、プロマネ)の誰もが口にする言い訳のように思われます。

しかし、ソフトウェア開発の人類学者であるジェラルド・ワインバーグは、計算機センターに火災が発生した2つのプロジェクトを比較し、以下のような結論を導いています[2]G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 … Continue reading。

(成功と失敗の)差異をもたらすのは事象ではなく、事象に対する反応である。成功プロジェクトは中断を認め、それに反応し、そして回復の責任をとり、災難を逆手にとる機会もつかんだ。一方、失敗プロジェクトでは、犠牲者を演じる機会をつかんだのだった。

つまり、「計算機センターの火災」という同じトラブルに見舞われても、成功したプロジェクトのプロマネは発生したトラブルを受け止め、プロジェクトを正常に戻す活動を行ったのに対し、失敗したプロジェクトのプロマネは発生したトラブルを嘆くばかりだったとワインバーグは指摘しています。

ワインバーグが見た成功したプロジェクトのプロマネのように、トラブルが発生しても動じずに対処するには、あらかじめトラブル発生のリスクを把握し、その対処法を講じておくことです。
その活動の土台を作るのが「リスク・マネジメントの計画」プロセスです。プロジェクトをトラブル(および一か八かの不確実性)から守るための、極めて重要な防衛線と言えます。

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉

リスク・マネジメント計画書の8つの構成要素

このプロセスのアウトプット(成果物)は「リスク・マネジメント計画書」です。
PMBOK第8版では、この計画書にはプロジェクトの規模やニーズに応じて、主に以下の8つの要素が含まれると定義されています。

  1. リスク戦略: プロジェクトのリスク・マネジメントに対する全体的なアプローチ。
  2. 方法論: 使用する特定のツールやデータソースの定義。
  3. 役割と責任: 各活動におけるリード、サポートなどメンバーの配置。
  4. 資金調達: リスク管理活動に必要な資金や、予備(バッファー)の適用手続きの確立。
  5. タイミング: リスク・プロセスを実行する時期と頻度(スケジュールへの組み込み)。
  6. リスク区分: リスク源を階層構造で分けた「リスク・ブレークダウン・ストラクチャー(RBS)」などの整理枠組み。
  7. ステークホルダーのリスク選好: 主要な関係者が「どこまでリスクを許容できるか」のしきい値の設定。
  8. リスクの発生確率・影響度の定義: 「高い・低い」といった曖昧な言葉ではなく、プロジェクトに合わせた発生確率(例:3〜5段階)と影響度の具体的な定義尺度。

リスク・マネジメントの計画のインプット

PMBOK第8版において、この計画を作成するためのインプットとして以下のようなものが紹介されています。

  • プロジェクト憲章
  • プロジェクトマネジメント計画書
  • プロジェクト文書(ステークホルダー登録簿など)
  • 組織体の環境要因(EEF) / 組織のプロセス資産(OPA)

他のプロセスと比べてリスク・マネジメントの計画が難しいのは、「これを確認すれば、完璧に対策を立てられる」という魔法の文書が明確にあるわけではないことです。
そのため、これまでに作った文書を改めて読み返し、組織のプロセス資産(過去の類似プロジェクトの教訓やテンプレート)を参考にしながら、ゼロから枠組みを作っていく必要があります。

リスク・マネジメントの計画のツールと技法

計画を作成するためのツールと技法として、以下が挙げられます。

  • 専門家の判断
  • データ収集(インタビュー)
  • データ分析(ステークホルダー分析など)
  • 会議

ステークホルダー分析で「彼らがどれくらいのリスクを許容できるか(リスク選好)」を探りつつ、中心となるのはやはり「会議」です。キックオフミーティング等で多くの参加者をまとめながら、特定のステークホルダーだけが不利にならないよう、客観的なリスクの評価尺度を作っていく必要があります。

実践のヒント:リスクを洗い出す「事前検死」

この後のプロセスである「リスクの特定」に進む際、会議において「どんなリスクがありますか?」と漠然と聞いても、なかなか意見は出にくいものです。
そこで非常に有効なのが「事前検死(Pre-mortem)」という手法です。これは「プロジェクトが完全に失敗した未来」をあらかじめ想像し、その原因を逆算して洗い出すという強力なアプローチです。詳しくは以下の記事で解説していますので、ぜひ参考にしてみてください。

注

注
↑1 Project Management Institute『プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)第8版』日本語版、第2部 2.7.2.1「リスク・マネジメントの計画」(95〜96ページ)、第4章(134〜136ページ)より要約・引用。
↑2 G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年、129頁。( )内は投稿者による補足。
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次