第11章：プロジェクトリスクマネジメント(その2)
ここでは、プロジェクトリスクマネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
keywords
・リスクマネジメントプロセス
・リスクマネジメント計画
・リスク識別
・リスク区分
・情報収集のテクニック
・チェックリスト
・トリガー
リスクマネジメントプロセス(p.127)
どの順番に何をするのかを覚えること。試験にも出るし、リアルでも使える。本当にこの通りにやっていけばいい
- リスクマネジメント計画
- リスク識別
- 定性的リスク分析
- 定量的リスク分析
- リスク対応計画
- リスクの監視・コントロール
ステップ1 : リスクマネジメント計画(p.129)
…とは、プロジェクトのリスクマネジメント活動に対し、どのように取り組み、計画するかを決定するプロセスのこと。つまり、そのプロジェクトにおいて、プラスとなる事象を沢山起こさせ、マイナスとなる事象をできるだけ抑えるように(起きてもインパクトが小さくなるように)、イロイロと打つ手を計画すること。
試験よりもむしろリアルでの話題になるが、ポイントは「そのプロジェクト」というところ。プロジェクトと銘打つ限り、規模、複雑性、メンバーの経験やスキルは種種雑多なもの。似たようなものは過去にあれど、一つとして同じものはない。従って想定されるリスクも特異性を常に持つはず。大企業でよくやる「チェックリストによるリスク洗い出し」や「リスクマネジメントの標準化」はぶっちゃけありえない。上っ面だけをなでて社内様式文書を埋めることはできるかもしれないが、ホンキでリスクマネジメントをするならば、使ってはいけない。ペーパーはたくさんできあがって仕事した気にはなれるが、二度と使わない文書を作っているに過ぎないから
リスクマネジメント計画書(p.130)
…とは、プロジェクトライフサイクルを通してリスク識別、リスクの定性的・定量的分析、対応計画の策定、監視・コントロールをどのように構成し、実行するのかが書いてある。個々のリスクについてぐだぐだ書いていないことに注意。それは「リスク対応計画書」に記述する
- 方法論 : リスクマネジメントを行うために適用するやり方、ツール、データの出所を定義する。デルファイ法を使うよ～とか、バグの出具合は過去の○○プロジェクトの収束線と重ねて比較するよ～とか
- 役割と責任 : リスクマネジメントチームのリーダー・メンバーと、それぞれが何を分担するのかを書く。別組織にしたほうが良いのだが、リアルではそこまで人は割けないと一蹴される
- 予算設定 : リスクマネジメントのための予算を確定する
- タイミング : どのタイミングで、どの頻度でリスクマネジメントプロセスを実行するのかを決める。決めないと忘れ去られ、燃え盛る炎にあぶられている時に「どこかでこうなることを避けられたはずなのだが…」とつぶやくことになる。これは意思決定にかかわるため、早めに決めとく(かつ定期的に見直す)
- 重み付け : 定性的・定量的リスク分析のための方法を採用する。採点方法・採点基準を予め決めておく。例えばプログラミング言語にjavaを用いたこと、経験1年未満のプログラマが4人いることによる単体テスト時のバグ発生確率を25/KLにするとか、品質:コスト:納期の重み付けを5:3:2に割り振っておくとか
- 限界値 : 誰がドコまで対応できるのか? リスクの限界値。スポンサー・顧客によりこの値は異なってくる
- 報告書式 : リスク対応計画書の内容・書式を定める。リスクマネジメントプロセスの結果を文書化し、ステークホルダーに伝えるための報告書
- トラッキング : きちんとやったリスク活動はそのまま財産となる。個人の場合でも企業の場合でも同じ。リスク活動を記録する方法を定める。リスクプロセスを監査するかどうか、するならその方法を定める
リスクマネジメント計画書は予算とスケジュールを含んでいるため、スケジュール策定と予算策定のインプットになる
ステップ2 : リスク識別
リスク識別とは、どのリスクがプロジェクトに影響するかを判断し、その特性を文書化すること。スポンサー、シニアマネージャ、メンバー、分野の専門家を巻き込む。あるいはリスク識別プロセスそのものを定期的にくり返す
優れたマネージャはプロジェクトが発足した直後に、最初の話題として、このリスク識別をテーマにする。「このプロジェクトで一番リスクになりそうなものは何だろう? それはいつ起きる可能性が高いのだろう?」ってね。なぜなら、WBSが完成し「このプロジェクトで何をするのか?」が明らかになったとしても、リスク識別は終わらないから。リスク識別は最初から最後まで、くり返し語られ、レビューされるべきだから。
PMBOKでは「立ち上げ」および「計画」フェーズでこの作業を行うと述べているが、リスクはまさにプロジェクトがまわっているそのときに生じるもの。それぞれのフェーズを終わらせたとき、あるいはスコープの変更が発生したとき、新たにリスクが生じる場合がある。リスクは立ち上げ、計画、実行、コントロール、終結の全てのフェーズにおいて発生する可能性がある。
注意したいのは「リスクが発生する」とは「ある事象がリスクであると判断される」ということ。「あるリスクが問題化する」ことではない。
リスク区分(p.131)
リスクを分類するにあたり、様々な見方があるが、PMBOKでは「リスク区分」=「リスク源」によるカテゴリ分けを述べている
- 技術、品質、性能リスク : 実証されていない技術、工業規格の変更、非現実的な性能目標
- プロジェクトマネジメントリスク : 資源、時間の割り当てが不適切。スコープがちゃんと定まっていないのに走り出している。火が噴いてから手当てに走るなど
- 組織上のリスク : 資金不足、プロジェクト優先順位の変更
- 外部リスク : 天変地異、労働争議、オーナーによる優先順位の変更、法制度の変更といって、プロジェクトマネージャではいかんともしがたいリスク
ポイントは「外部リスクを除く3つは、なんらかの手を打つことができる」ということ。Ritaは以前のPMBOKガイドからも紹介している
- 外的リスク : 工業規格、環境起因、規制・条例、マーケットの変動
- 内的リスク : 時間、コスト、予測不能の条件、スコープの変更、メンバー・プロジェクトマネージャの経験不足、未熟なプロジェクト計画
- 技術リスク : 技術の変化
- 予見不可能なリスク : 調査によるとリスクの10％は予測不可能とのこと
情報収集のテクニック(p.132)
リスクを識別する具体的な方法。RitaはPMBOKで紹介されている以外にも沢山あるといっているが、以下のツールと技法を使いこなすだけでも充分に役立つ
- ブレインストーミング : 目的はリスクの包括的一覧を作ること。専門家集団でやるのもあるが、チームメンバーを集めて打ち合わせするのが一般的。「リスクと思われるもの」をホワイトボードに書き出す→上記のリスク源からリスクをカテゴリ分けする→リスクを定義する…これをくり返す
- デルファイ法 : いくら「ブレインストーミングでは批判しない」といっても、専門家がいたらやっぱりエンリョ心が出てくるもの。あるいは専門家が複数いたら、やっぱりお互いに遠慮するか自説を主張してしまう場になってしまうかも。それにメンバー(+専門家)を一堂に会すなんて、時間的に勿体無いかもしれない。そんなときにはコレ。目的はプロジェクト全体にかかわるリスクをハッキリさせること。匿名で参加する。質問状を使ってプロジェクトリスクに関して専門家の意見を収集する。これにより特定の意見に振り回されること無く、またデータに偏りの無い合意を得ることができる
- インタビュー : プロジェクト概要やWBSを提示して、経験あるプロジェクトマネージャや専門家へインタビューする
- SWOT分析(強み・弱み・好機・脅威) : Strengths,Weaknesses,Oppotunities,Theats analysis の頭文字をとっている
チェックリスト(p.133)
リスク識別のチェックリストは、過去の情報や似たプロジェクトから得た知識を元に作成する。チェックリストのいいところは、リスク識別が迅速で簡単なこと。リストには「○○というリスクが抜けていないか?」とか「コスト面からリスク識別を行っているか?」などと書いてあるのでMECEしているように思える…
しかし、重要なのはリストに載っていないこと。チェックリストの欠点は、全てのリスクを含んだものを作成することが不可能なため、必ずモレヌケがあるということ。あなたの会社でもあるでしょう＞標準化リスト そして、一般化するあまり使えないリストになっているハズだ。リスク識別レビューでは、チェックリストを使っても良いが、「リストに書いていないこと」を探すためのレビューでなければならない
トリガー(p.133)
リスク識別のアウトプットとして、リスクとトリガー(リスクトリガー)の一覧表ができあがる。トリガーとはリスク兆候、リスクの警鐘とも呼ばれている。引き金やね
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--
| 固定リンク
コメント