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

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

keywords
　・リスク対応計画
　・リスクオーナー
　・リスク対応戦略

ステップ5 : リスク対応計画(p.140)
リスク対応計画とは、「どんなリスクがあるかは分かった、ではどういう手はずを整えておかなければならないか?」ということ。注意したいのは、ネガティブリスクだけでなくポジティブリスク(チャンスのことね)も考慮に入れる、ということ。ネガティブリスクは発生確率を下げ、インパクトを最小化するし、ポジティブリスクは発生確率を上げ、効果を最大化する。また、全てのリスクを排除することは不可能を念頭におきつつ、以下の作業を行う。

• どのリスク対応戦略を取るか検証する
  
• 主戦略とバックアップ戦略(主戦略がダメだったときの予備)を採用する
  
• それぞれのリスクを担当者または担当グループに割りあてる
  
• リスク対応戦略は要所要所でレビューされる。戦略は計画フェーズで決められるが、決めてオシマイではない。プロジェクト進行に伴い追々分かってきた情報を元に、コントロールフェーズでレビューされる
  

リスクオーナー(p.141)
リアルで使える考え方。PMBOKから得てリアルに適用し、非常に効果をあげている概念。リーダーやってる人ならアタリマエかもしれないけれど、私には非常に役に立っているテクニック。

PMBOKには「リスク対応計画の責任者」とあるが荷が重過ぎるかも。「セキニンシャ」は責任を担う人であり、それはプロジェクトマネージャかシニアマネージャでしかありえない。リスクオーナーは「リスク担当者」と訳したほうが良いと思うぞ。

リスク一覧が出来上がり、その対応戦略が決まれば、今度は誰がそれを実行するのかを割り振る。そのリスクを「自分のリスク」として扱うわけだ(もちろん自分の責務の範囲内で)。リスク担当者は、

1. リスク対応計画の立案段階で参加しているメンバー・グループ
   
2. リスクトリガーが何であるかを知っている。即ち「リスクが問題化するのはどういうときか、どんな兆候があるか」を気にかけながらプロジェクト遂行に参加する
   
3. リスクが問題化したとき、予め決めてある「リスク対応戦略」を実施する
   
4. 上手くいけば「任務完了、寿司でも喰いにいっかー」と報告すればよいし、ダメなら人を集めてミーティングを開けばよい
   

しつこく太字を入れたのは、4の時点で「会議を2回分減らすことができる」から。仮にリスクオーナーを割り当てなかったとしよう。すると、少なくともミーティングは2回「余分に」開催される。つまり、

step1.リスクが問題化
　　　　↓
step2.問題化したリスクの報告、リスク対応方法の検討の指示(1回目の会議)
　　　　↓
step3.リスク対応方法の説明(対応策A,B,C...の解説)、対応策の決定と実施の指示(2回目の会議)
　　　　↓
step4.リスク対応策を実施した結果の報告

ほらね。酷い場合になると、step3で「対策案は分かったが、トレードオフが決められない。ちょっと検討させてくれ」とお持ち帰りになってしまう。この場合さらに会議が増えることになる。しかもstep2と3はキーマンの参加が不可欠だから、ここがボトルネックになってしまう。

しかし、リスクが問題化したとき、第一にどういう対応をすればよいかが予め分かっていれば、その対策を行うだけ。つまりstep2とstep3が省かれるわけ。例えば...

既存のパッケージを再利用した製品を開発する。より厳しい性能要件であるため、スループットにリスクがある。対策として、

1. 既存パッケージを利用するクラスを先行開発する
   
2. 性能テストを2回行った時点で、既存パッケージを使う／代替のパッケージソフトを使うを判断する
   
3. 性能要件はスループット「400トランザクション/sec」とする
   
4. 代替パッケージは次の二つを試行することとし、それでも性能要件を満たさない場合に、追加開発を行うかミーティングを行って判断する
   
5. リスクオーナーは神尾さん
   

ここまで決めておけば神尾さんは困らないでしょう。実際に会議をするハメになったとしても、一次対策まで実施した後にミーティングが始まるのだ。ミーティングには「既存・代替パッケージの性能試験の結果」と「追加開発に必要な機能一覧」が資料として出てくる。この差は大きい。

リスク対応戦略(p.141)
リスク対応戦略とは、リスクの脅威を減らし、チャンスを増大させること。これもネガティブリスクだけでなく、ポジティブもあることに注意。別名「リスク軽減策」とも言う。

まさにトレードオフなのだが、リスク対応戦略にはプロジェクト計画の変更も含まれる。つまり、WBS、品質計画、スケジュール、予算の変更も含まれる。

• 回避：リスク回避とは、原因を取り除くことで、リスクの脅威を避けること。機能を盛り込みすぎて納期が間に合わない。じゃぁ納期をずらすか機能を削減したものをリリースする
• 転嫁：リスク転嫁とは、リスクの結果と責任を第三者へ移すこと
• 軽減：リスク軽減とは、問題があるリスクを受容可能なレベルまで減らす試み。減らすのは影響度と可能性の両方
• 受容：リスク受容とは、プロジェクト計画を変更しないこと。「何もしない」決定を下す消極的受容と、コンティンジェンシー計画を立てる、という積極的受容がある。

「転嫁」は特に試験に出るところ。ちょっと前に流行った「アウトソーシング」がそれやね。なんでも自社開発するのではなく、一部を外注で作る。瑕疵担保や保証制度を使って、リスクが顕在化したときに納入者へ責任転嫁できる調達マネジメントでも説明するが、「定額契約」を使えば納入者にリスクを転嫁できる。定額契約は「お値段固定」契約のため、見積もり誤算した分、全て納入者持ちとなる。「実費償還契約」だと顧客・スポンサーにリスクが行く。いわゆる「出来高」のお値段だから。一方、途中で変更したとしても「変更した分の費用追加」で済むというメリットもある。

「転嫁」でもう一つ。転嫁したとしてもそのリスクは消えてなくならないということを強調したい。リスクを負う人が代わっただけでリスクは「とりあえずその人が考えてくれる」になっただけ。ある機能を外注して開発することでリスク転嫁はできるが、「その機能が予定通りに出来上がらなかった場合」のリスクは依然残る。納入者は、契約に反する場合の責任を取るだろうが、あくまで「契約書の範囲での責任のみ」。その機能を取り込んだ上での全体としての製品を作り上げる責任(とリスク)は、微塵も動いていないワケ。

ピンとこない人は、「納期に間に合わない外注業者に激昂して無限責任を押し付けようとするﾄﾞｷｭｿ」を見たことがないんだろうなぁ…

「受容」について補足。コンティンジェンシー(contingency)とは、偶発事件や不測の事態、あるいは臨時出費のこと。例えば中間のマイルストーンを達成できなかった場合に発動し、代替計画を立てておくこと。元のプロジェクト計画はそのままで、もうひとつ代替計画を進める。並行して走る別作業工程やね。でもってそれ分の予算を予備として確保しておくこと。

戦略を選ぶポイントについて、Ritaはものすごくいいことを言っている→「リスクの深刻さに合った努力をはらうべき───つまり、リスクが引き起こすコスト以上の金をつぎ込むことなかれ」。くだらない取り繕いや際限もなく資源を投入するマネージャがなんと多いことか…
（つД｀）

練習問題：次の判断は回避、転嫁、軽減、受容のどれに相当するか? (答えはドラッグ反転)

状況説明	戦略
そのタスクをプロジェクトから外した	回避
問題をできるだけ早く把握するために、製造部門へ人をアサインした	軽減
このリスクが問題化してもコスト増につながらないため、対策しないことを報告した	受容
新技術に慣れないメンバーに研修を行った	軽減
○○機能部分を外注に出した	転嫁
プロトタイピングによる開発手法を採用した	軽減

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