第11章：プロジェクトリスクマネジメント(その5)

ここでは、プロジェクトリスクマネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

keywords
　・リスク対応計画のアウトプット
　・残存リスク
　・二次リスク
　・コンティンジェンシー計画
　・引当金
　・リスクの監視・コントロール
　・リスク対応の監査
　・定期的なリスクの見直し
　・リスクの監視・コントロールのアウトプット

ステップ5(承前) : リスク対応計画のアウトプット(p.143)
リスク対応計画には次のものが含まれている。

• 識別されたリスクの一覧。一覧には原因・可能性・影響度が記述されている
  
• それぞれのリスクへの対策(回避、転嫁、軽減、受容の具体的対策)とリスクオーナーの名前
  
• 対策をとったとしても残るリスク→残存リスク
  
• 対策を実施した結果発生するリスク→二次リスク
  
• コンティンジェンシー計画
  

残存リスク(p.143)
残存リスクとは、「回避、転嫁、軽減」を実施した後でも残るリスクのこと(「受容」がないことに注意)。残存リスクは通常「受容」される。

二次リスク(p.143)
二次リスクとは、リスク対応を行ったことで直接生ずる別のリスクのこと。火事のリスクを転嫁するため、火災保険に入ったまではいいが、保険費はキャッシュフローを圧迫するリスクとなる。

コンティンジェンシー計画(p.143)
コンティンジェンシー(contingency)は臨時出費だが、コンティンジェンシー計画とは、識別したリスクが問題化するときに実行する一連の対策のこと。「部品Aで基準値をクリアできなかったらすぐに部品Bを試すこと」といった、予め決めてある対策のこと。リスクオーナーは部品Bを試行するために会議を開かなくて済む。コンティンジェンシー計画でダメな場合、代替計画も予め練っておく。

引当金(p.144)
引当金とは、コンティンジェンシー予備費のこと。「バッファー」「リザーブ」というやつだね。PMIでは10％を推奨しているが、ホントの意味で予備とするには少なすぎるし、「誤差」を埋める費用と考えると多すぎる。次の場合、どれぐらいのリザーブが必要か? (回答はドラッグ反転で表示)

30％の可能性でプロジェクトが遅延する。コストは9000万
→0.3×9000=2700万円増

30％の可能性で4000万円安くなる技術を適用する
→0.3×4000=1200万円減

5％の可能性で手戻りが発生する。その影響は5000万円
→0.5×5000=250万円増

トータルで、2700-1200+250=1750万円の予備が必要

他に出るものとして、一問一答(答えはドラッグ反転で表示)

• クリティカルでないリスクはどうするのか? →ドキュメント化して定期的に見直す
  
• リスク対応戦略は一つのリスクに一つだけか? →複数の戦略を複合して取ることも可能
  
• 実行フェーズでリスクマネジメントとして取るべきことは? →クリティカルでないリスクが重要なリスクとなるか監視する
  
• ミーティングで最も注視するべき要素はどれか? →リスク
  
• ミーティングでリスクを洗い出すにはどうすればよいか? →「このリスクのステータスはどうなっているのか?」「新たなリスクはないか?」「重要な変化はないか?」といった質問により出てくる場合が多い
  

step6：リスクの監視・コントロール(p.144)
リスクコントロールとは、コントロールフェーズにおいて以下のことを実行する。

• 識別されたリスクの状態を追跡する(問題化していないか?)
  
• リスク対応計画を実行する
  
• 新たなリスクが発生していないか監視する
  
• リスクの状態、新たなリスクを報告する
  
• 問題化するリスクに対し是正措置を実施する
  
• プロジェクトがベースラインから変更するとき、リスク識別、定性的リスク分析、定量的リスク分析の観点でリスクを再評価する
  

リスク対応の監査(p.145)
「リスクを予め識別し、対策を練り、担当へ割り振る」…ここまではリアルでもなんとかできているんだが、この「リスク対応の監査」までは手がまわらない。ホントウはここまでやって合格なんだろうが… リスク対応の監査とは、リスク対応の有効性を調べ、文書化すること。他の監査物と同様、次の(他の)プロジェクトのための教訓となる。どんなリスクがあるかは経験積めば見えてくるが、とった対策がどれぐらい有効／無効だったかは残さないと忘れ去られてゆく。これこそが真のノウハウなんだろう。

定期的なリスクの見直し(p.145)
これも重要だがリアルでできていないorz… リスクの格付け、優先順位は実行フェーズにおいて変動する。従って定期的にプロジェクトリスクのレビューを行う必要がある。見直した結果、変更する場合は定性的・定量的の双方からのリスク分析を行う。

リスクの監視・コントロールのアウトプット(p.146)
リスクコントロールのアウトプットとして、以下のものがある。

• 迂回策(p.146)：事前に識別していないリスクや、リスクの発生に対し計画していない対応をとること。キチンと文書化してプロジェクト計画やリスク対応計画に取り込む
  
• 是正措置：是正措置とは、コンティンジェンシー計画や迂回策を実施すること
  
• プロジェクト変更要求：リスクに対応するために採用したコンティンジェンシー計画や迂回策が、結果的にプロジェクト計画を変更せざるを得ない状況になる。トレードオフやね。これは変更管理プロセスの中で扱われる「変更要求」となる
  
• リスク対応計画更新版
  

Rita曰く「リスクマネジメントについて系統立てたトレーニングがされていない結果、リスクマネジメントで共通的に誤解されている部分がある」… 実際そうかもしれない。思い返すと、コスト・品質・スケジュール・スコープ・人材・コミュニケートについてはOJTで身につけることができる。しかし、リスクマネジメントについてはなかった。「経験がモノを言う」ところであることは承知しているが、その結果、キーマンにリスクマネジメントを集中させるというリスクが発生しているのも事実。簡単にいうと、キーマンが倒れるとプロジェクトが死ぬ。誰も引き継げない仕事と化す。

リスクマネジメントでつまづきやすいところは以下の通り。試験に出るのは考え方。覚えるのではなく「これがリスクマネジメントなんだ」と理解して欲しい。

• プロジェクトをよく理解していない人がリスク識別をする。結果モレヌケが出て「こんなはずじゃなかった」となる。リスク識別はチームメンバーの参加、専門家の意見が必要
  
• 専門家へのアンケートやインタビュー、モンテカルロ技法だけでリスクを評価する。「このタスクにはどんなリスクがあるのだろう」という視点が欠けていると、思わぬモレが出てくる
  
• リスク識別とリスク分析を同時に行う。分析しながらリスクを洗い出しているため、出るべきリスクが出てこなくなる
  
• 一般的すぎるリスク。「プログラム品質のリスクがあり、品質向上が必要」ではダメ。「経験半年プログラマの割合が過半のため、品質リスクがある。チーフプログラマに経験豊富な神尾さんを招き、コーディング規約・ネーミング規約を充実・徹底させる」がマル
  
• リスクには不確実性が伴う。間違いなく起こりうることは「リスク」と呼ばない
  
• 技術リスク、文化的リスク、市場リスクといったリスクは、そのカテゴリごと忘れられている場合が多い
  
• 実行フェーズでは、リスクは顧みられてない。問題化して初めて目が向けられる
  
• 充分なリスクの検討がされる前に契約してしまうという愚←とRitaは言うが、いろんな政治的思惑があるのよ。PMレベルじゃどうしようもないのよ
  

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る