【PMBOK第8版】リスク対応策の実行とは?PMが「すべてを背負い込まない」ための分担術

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

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

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

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

SSAITS公式サイトはこちら

リスク対応の最大の課題は「忘れられること」

プロジェクトのリスクを洗い出し、立派な対応計画を作った。しかし、いざプロジェクトが走り出すと、日々の目の前のタスクに追われ、せっかく決めたリスク対応策が後回しにされたり、忘れ去られたりすることが少なくありません。

PMBOKにおける「リスク対応策の実行(Implement Risk Responses)」は、合意されたリスク対応計画が、予定通りに確実に実行・遂行されることを保証するためのプロセスです[1]Project Management Institute『プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)第8版』日本語版、第2部 … Continue reading。

計画を「絵に描いた餅」にしないために、私たちはどのようにして現場を動かしていけばよいのでしょうか。今回は、PMBOK第8版におけるプロセスの構成要素と、「PM一人ですべてを背負い込まない」ための実践的なマネジメント術について解説します。

プロセスのITTO(インプット・ツール・アウトプット)完全網羅

対応策を確実に実行へ移すために、PMBOKでは以下の構成要素(ITTO)が定義されています。

インプット(前提となる情報)

  • プロジェクトマネジメント計画書(リスク・マネジメント計画書)
  • プロジェクト文書(教訓登録簿、リスク登録簿[実行すべき対応策と担当者の一覧]、リスク報告書)
  • 組織のプロセス資産(OPA)

ツールと技法(実行を後押しする手段)

  • 専門家の判断
  • 人間関係とチームに関するスキル
    • 影響を与える(Influencing): なぜこの対応が不可欠なのかを説明し、協力を引き出す。(※本プロセスの核心スキル)
  • プロジェクトマネジメント情報システム(PMIS)(タスクの割り当てや進捗を追跡するツール)

アウトプット(実行した結果)

  • 変更要求(対応策の実行に伴い、コストやスケジュールの調整が必要となった場合の申請)
  • プロジェクト文書更新版(課題ログ、教訓登録簿、プロジェクト・チームの任命、リスク登録簿[ステータス更新]、リスク報告書)

PM一人で背負い込まない「リスク・オーナー」の存在

PMBOK第8版全体の特徴として、「プロジェクトマネージャー(PM)一人だけですべてを背負い込まない」という思想が随所に見られます。この「リスク対応策の実行」プロセスもその代表例です。

リスク登録簿には、各リスクの対応策を実行する責任者として「リスク・オーナー」が任命されています。
つまり、PMがすべての対応策を自分の手で直接実行して回る必要はありません。リスク・オーナーが主導してアクションを起こし、PMは彼らがスムーズに動けるように支援し、進捗をチェックして後押しする役割に徹します。リスク対応もチームで分担して実施していくことが強く推奨されているのです。

現場のリアル:他部署への依頼は「顔の広いメンバー」を頼る

さて、ツールと技法に「影響を与える(Influencing)」という人間関係スキルが挙げられています。これはなぜ必要なのでしょうか。

リスク対応策を実行する際、その担当者(リスク・オーナー)や協力を仰ぎたい相手が、「PMの直接の部下ではない(他部署の人間である)」ケースが多々あります。
進行しているプロジェクトと直接関係のない部署に対して、「このリスク対応のために動いてください」と依頼するのは、なかなか骨の折れる作業です。ましてや、PMとその部署との関係性が未構築であった場合、依頼自体が非常に難航します。

こうした時、PMが自分の権限や影響力だけでなんとかしようと背負い込む必要はありません。
現場の工夫として、「その部署と仲の良い(顔が広い)プロジェクト・メンバーをリスク・オーナーに任命し、間接的に協力を引き出してもらう」というのも立派なマネジメントの手法です。

自分に影響力が足りないなら、影響力を持っている周囲のメンバーを頼る。これも「影響を与える」スキルの実践的な活用法と言えるでしょう。

実行後に必ずチェックすべき「2つの新たなリスク」

最後に、リスク対応策を実行した後にPMが必ず確認すべき重要なポイントがあります。それは、対応策を打ったことによって生じる以下の2つのリスクです。

  1. 二次的リスク(Secondary Risk):
    対応策を実行した「結果」として新しく発生するリスクのことです。例えば、「開発の遅延リスクを回避するために海外のベンダーへ外注(転嫁)した」結果、「言語や文化の違いによるコミュニケーションの齟齬」という新しい二次的リスクが発生するといったケースです。
  2. 残存リスク(Residual Risk):
    対応策を実行したにもかかわらず、「削りきれずに残ってしまったリスク」のことです。これらは無視せず、監視リストに載せ続けるか、コンティンジェンシー予備(バッファ)で備えておく必要があります。

まとめ:計画倒れを防ぐのは「こまめな確認」と「チーム戦」

リスク対応策が実行されない最大の理由は「悪意があるから」ではなく「日々の業務に忙殺されて忘れてしまうから」です。

プロジェクトマネージャーの仕事は、すべてのリスクを自分で退治することではありません。適切なメンバー(リスク・オーナー)に対応を割り振り、「あのリスク対応、進んでいますか? 何か困っていることはありませんか?」とこまめに声をかけ、障害があれば関係性を活かして道を開くことです。
リスク管理をPMの孤独な戦いにせず、周囲を上手に頼りながら「チーム戦」で不確実性を乗り越えていきましょう。

注

注
↑1 Project Management Institute『プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)第8版』日本語版、第2部 2.7.2.5「リスク対応策の実行」(98ページ)および 図2-52より要約・引用。
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次