できるPMの決め手は「リスクマネジメント」：プロジェクトマネジメントスキル 実践養成講座（8）（2/2 ページ）
リスクの洗い出しに必要なものは
それでは、リスクマネジメントの実践的な勘所について、ケーススタディを通じて解説する。当然のことであるが、われわれプロジェクトマネージャはまずプロジェクトにおけるリスクを発見する必要がある。発見なくしては未然に対処しようがない。従ってまず、「リスクの発見」の実践的な勘所について解説する。
矢見雲マネージャと出来杉マネージャのプロジェクトでは、プロジェクトスケジュールやWBS（Work Breakdown Structure）などを定めてプロジェクト計画を作成している。それぞれのプロジェクトでどのようにリスクを発見しようとしているか。その様子をのぞいてみることにしよう。
矢見雲マネージャの発言
「一通りプロジェクト計画も出来上がろうとしている。後はこの計画に対するリスクを洗い出さないといけないな」
「俺もいろいろプロジェクトマネジメントを勉強して、事前に問題を回避することの重要さがやっと分かってきた。いままで俺のプロジェクトは大火事ばかりだったが、今度は成功させるぞ」
「さて、どうやってリスクを見つけるか……」
「俺の経験からは特に問題ないと思うのだが、念のため、チームリーダーを集めてリスクを出してもらうとするか。以前ならこのまま進めていたところだが、俺も少しは成長したかな」
――――リーダーミーティングにて――――
矢見雲マネージャ 「今日は、今回のプロジェクト計画のリスクを洗い出したい」
「俺の経験からは特に問題ないと思うのだが、何かリスクはあるか？」
チームリーダー一同 （沈黙）
矢見雲マネージャ 「特にないようなので、プロジェクト計画をこれで確定して進めることにする」
「じゃあ、後はよろしく頼むよ」
このケースにも一応良かった点が含まれているので、まずその点に触れておく。「リスクを事前に把握しようとした」ことと「個人の経験だけに頼らず、リスクの発見のために各領域に精通しているチームリーダーの意見を取り入れようとした」ことである。
しかしながら、結果としてリスクを見つけることはできなかった。問題はどこにあるのだろうか。続いて、出来杉マネージャのプロジェクトの様子を見てみることにする。
出来杉マネージャの発言
「プロジェクトを円滑に進めていくためには、プロジェクトに影響の大きいリスクをどれだけ早く把握できるかが肝だからな」
「まずはチームリーダーを集めて、リスクを出してもらうとするか。その前に各リーダーに、プロジェクト計画とそのインプットとなったクライアントからの受領資料やインタビュー議事録などの成果物を再確認してもらう必要があるな。ミーティングまでに目を通して気になる点をまとめてきてもらおう」
――――リーダーミーティングにて――――
出来杉マネージャ 「今日は、今回のプロジェクト計画のリスクを洗い出したい」
「この場でブレーンストーミングを行ってプロジェクトのリスクを発見したいと考えている」
「各自、成果物を確認して気になる点を考えてきてくれたと思う。スコープ、納期、予算、品質など9つの知識エリアごとに見ていくことにしよう」
「各チームリーダーは、自分の担当領域とその周辺領域、およびプロジェクト全般にわたって気になる点を挙げてほしい」
出来杉マネージャ 「これで一通り出そろったかな（表2）。じゃあ次回のミーティングまでに、それぞれの担当領域のリスクについて、どうすれば発生しないか、あるいは発生しても影響を最小限に抑えられるか考えてきてほしい」
|
|||||||||||||||||||||||||||||||||||||||||||
| 表2 知識エリア別／影響要因別リスクマトリックス | |||||||||||||||||||||||||||||||||||||||||||
Howを示してリスクを見つける
出来杉マネージャが矢見雲マネージャと違う点は2つある。1つは、既存の成果物・ドキュメントを確認していること。もう1つは、リスクを9つの知識エリアというフレームワークを使って整理していることである。
矢見雲マネージャの問題点は、ただやみくもにリスクを発見しようとしていたことである。つまりHowの部分がないのである。一方、出来杉マネージャは、具体的に2つのHowを提示している。1つは「既存の成果物・ドキュメント」という共通の情報源を提示することで、各メンバーが頭の中で考えるだけでは気付かないリスクの発見を促進している。また、9つの知識エリアというフレームワークを示すことで、各メンバーの考える視点（ヒント）が明らかになり、網羅性を確保したリスクの発見が期待され、結果としてリスクの可視化が達成される。
リスクの可視化により、ステークホルダー間での共有が可能となり、リスク回避へつながるアクションが可能となる。また、モニタリングする際のInputとしても有効である。このHowの部分はプロジェクトや企業文化によって異なるが、参考までにいくつか紹介しておく。
・インタビュー
類似プロジェクトの経験者、ベテランのプロジェクトマネージャ、外部コンサルタントなどの専門家、有識者の経験と知識からリスクを識別する。リスクの発見は経験に左右される部分も大きいので、一般的かつ重要な方法である。
上のケースでは、プロジェクトチーム内のリーダーミーティングでアイデアを出し合っている。これもブレーンストーミングである。プロジェクト内だけではなく、ベテラン経験者、専門家、有識者などを集めた形で開催するのも有効な手段である。
・チェックリストの作成
過去のプロジェクトの経験を基にあらかじめチェックリストを作成しておくと、リスク発見の手助けとなることが多い。ただし、プロジェクトの内容や環境はそれぞれ異なるため、完ぺきなチェックリストを作ることは困難。多くのプロジェクトで汎用的に使えるポイントを網羅しておき、各プロジェクトでチェックリストに書かれていないことはないかという視点で活用することが現実的といえよう。
・前提条件の確認
プロジェクトは、何らかの前提条件の下で開始されるケースが多い。この前提が崩れると、プロジェクトマネジメント上の3大要素（品質、予算、納期）に影響を及ぼす恐れがある。従って、前提条件に変わりがないかをモニタすることはリスクを発見するうえで重要である。
見つけたリスクへの対応策
リスクを識別したら、その発生確度および現実のものとなった場合のプロジェクトへの影響度を分析し、リスクの優先順位付けを行う。その結果、アクションが必要と判明したリスクには、具体的な対応策を定める必要がある。どのようにリスクへの対応策を定めればよいのか。
矢見雲マネージャと出来杉マネージャのプロジェクトでは、共にシステムテストの準備を進めているようだ。しかし、開発中のシステムとI/F（インターフェイス）する外部システムの開発が遅れており、予定どおりにテストを実行できない恐れが出てきている。また、そのI/Fプログラムは、こちらのシステムの主要マスタデータを受信するものなので、動かないと後続のテストにも大きな影響が出るようだ。2人のマネージャの対応をのぞいてみることにしよう。
矢見雲マネージャの発言
「向こうのプロジェクトは『頑張って間に合わせます』っていっているけど、大丈夫かなあ」
「とはいえ、こちらが作ってあげるわけにもいかないしなあ。まあ、仮にそれで遅れてテストできなくてもこっちの責任じゃないし、もう少し待ってみるとするか」
出来杉マネージャの発言
「向こうのプロジェクトは『頑張って間に合わせます』っていっているけど、もし間に合わなかったらこちらのテストにも影響が大きいな。対策を考えよう」
「こちらとしてはシステム期間内にテストが終わればいいのだから、そのI/Fプログラムを使うテストを全体スケジュールの後半に実施するよう計画を見直せないかな。担当者に早速検討を依頼しよう」
「それが難しい場合は、I/Fプログラムのテストは、向こうにI/Fファイルをマニュアルで作ってもらってテストを実施しよう。環境面やネットワーク的な部分に問題がないかを検証する1次テストということにして、後でプログラムができたら再テストするしかないな」
矢見雲マネージャの対応では、リスクが現実のものとなった場合、テストができないことに変わりはない。これではまったくリスクへの対応策とはいえない。一方、出来杉マネージャは、2つの対応策を考えている。1つは、テスト実施時期を調整することで、テストができないリスクを回避する対応策であり、もう1つは、回避できない場合にも、現状で可能な範囲でテストを実行し、影響を最小限にとどめようとする対応策である。
マイナスの影響を及ぼすリスクへの対応策は、一般的に4種類に大別される。それらを以下で解説する（表3）。
| 対応 | 説明 |
|---|---|
| 回避 | ・原因を根本的に取り除き、リスク事象が現実のものとならないようにすること。 ・先述の例では、リスクとはテストができないことであり、回避とはI/Fプログラムを使ってテストできるようにすることである。 ・具体的な対応策としては、例えば先方の開発が完了してからテストを実行するようリスケジュールを行う、あるいは先方に作業の優先度を上げてもらうことで、予定どおりにテストが実施できるようにするなどが考えられる。 |
| 軽減 | ・リスクが現実化した場合に影響を小さくする、リスクの発生確度を下げるという2つの軽減策が考えられる。 ・先述の例は、マニュアルで作ったI/Fファイルを用いてテストを実行しておくことで、全体への影響を小さくする軽減策である。 |
| 移転（転嫁） | ・リスクも含めて第三者に責任の所在を移転すること。 ・実際のプロジェクトでの活用法としては、外部へのアウトソーシングや保険への加入などが挙げられる。 ・ただし、契約により責任を第三者に移転したとしても、金銭的な補償やさらなる人的支援など、契約に基づく責任の遂行にとどまることが多い。 ・いい換えれば、責任を移転してもリスク自体は依然として残っており、リスクが現実化した場合に発注者（依頼側）への影響がゼロになるわけではないことを認識する必要がある。 |
| 受容 | ・プロジェクト計画を変更しないこと。つまり、「何もしない」という決定を下すこと。 ・リスクが現実化しても影響が少ない場合や発生確度が無視できるほど小さい場合、あるいはほかの対応策を見つけることができなかった場合に、リスクを受容することになる。 ・また、リスクの現実化に備えて、コンティンジェンシープランを作成することも多い。 |
| 表3 リスクへの対応策 | |
ここまでリスクへの対応策を解説してきた。1点だけ補足しておくと、実際のプロジェクトでリスクへの対応を考えるときは、そのリスクに見合った対応策にすることが重要である。
「リスクに見合った対応策」とは、リスクの大きさ（影響と発生確度）と対策に投入する人員や予算とのバランスを取ることである。例えば、1つのリスクに必要以上に人員や予算を投入した結果、そのリスク自体は回避できたけれども、予算や納期が大幅に超過してしまったというケースは多く見られるのではないか。
予算と期間を投入すれば、プロジェクトで発生する大部分のリスクや問題は対処できる。しかし、安易に資源を投入するのではなく、ステークホルダーとの対話や折衝で、あるいは知恵を絞ってプロジェクトの進め方を工夫することなどで対処しよう。難しいことではあるが、そういうプロジェクトマネージャでありたいと筆者は心掛けている。
今回のまとめ
- プロジェクトの円滑な推進を目指すなら、「事後処置型マネジメント」から「事前予防型マネジメント」へのレベルアップが必要である。
- 「頭の中でのリスクマネジメント」から脱却し、プロジェクトのリスクを「可視化」する。
- リスクを発見するためには、Howを示すことが重要である。具体的には以下の方法がある。
インタビュー
ブレーンストーミング
チェックリスト作成
前提条件の確認 など
- リスクへの対応策とは、リスクを現実化させない方法、あるいは現実化した場合の影響を抑える方法であり、以下の4つがある。
回避
軽減
移転（転嫁）
受容
- リスクへ対応する際は、リスクの大きさ（影響と発生確度）と投入する資源とのバランスを取る。過度に資源に頼らず、対話や折衝、知恵と工夫で対処することが望ましい。
著者プロフィール
杦岡充宏（すぎおかみつひろ）
スカイライトコンサルティング シニアマネジャー。米国PMI認定PMP。関西学院大学商学部卒業後、アンダーセンコンサルティング（現アクセンチュア）を経て現職。製造業や流通業のCRM領域において、業務改革やシステム構築のPM（プロジェクトマネジメント）の実績多数。特に大規模かつ複雑な案件を得意とする。外部からの依頼に基づき、プロジェクトの困難な状況の立て直しにも従事、PMの重要性を痛感。現在は、同社においてPMの活動そのものをコンサルティングの対象とするサービスを展開している。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。