リスク管理の実践



プロジェクト管理において、リスク管理は重要だ!といつも言われますが、考えてみたら、プロジェクトの現場できちんとリスク管理を行なったことなんて、今までなかった気がします。
これまでリスク管理については、自分なりにいろいろ勉強してきたつもりですが、説明はいまいちピンとこないし、何よりも教科書通りやると、手間がかかる(敷居が高い)割には、嬉しいことが少ない気がして、自然に避けていたのが、正直なところです。

そこで今回、プロジェクトメンバーとも相談しながら、実際のプロジェクトで実践してみることにしました。

以下は、今回実践したことならびにこれからやろうとしていることのメモです。
PMBOK等をベースに自分達にとって実践しやすい、リスク管理のやり方を考えてみることにしました。)

リスクの明確化と対応準備

見積り作成時やプロジェクト計画作成時に、リスクの明確化と対応のための事前準備を行ないます。

リスクの洗い出し

まず、各リーダに、見積り作成時に一緒にリスクも洗い出してもらうようにお願いしました。
「見積り作成時に一緒に」というのがポイントで、例えばAPチームにある機能開発の見積りをお願いしたとすると、通常何もなければ、1.0人月で終わる作業に対して、「ここ、技術的に新しい機能のところだな。何かあったら困るから、PMには1.5人月と報告しておこう。」と、0.5人月分のサバが追加されて、APチームからの見積りは1.5人月と報告されてくることが多々あります。
実は、この「ここ、技術的に新しい機能のところだな。何かあったら・・・」がリスクであり、追加された0.5人月(のコスト)こそ、そのリスクの対応コストになると思うのです。
すなわち彼らは、見積り作成時に開発作業をシミュレーションしながら、無意識のうち(?)に並行してリスクの洗い出しと、ご丁寧にもその対応コストの見積りまでやってくれているのです。
従って今回は、ある機能について、

  • 見積り→1.0人月(何もなければ、普通にやって終わる工数
  • リスク→「技術的に新しい機能のところなので、実際開発してみると不明な点などが出てきて調査や検証で余計な工数を使う可能性がある。」
  • それが発生した場合、必要となるコスト→0.5人月くらい

とそれぞれ分けて報告してもらうようにしました。
(余談ですが...これでおのずとCCPMでいうところの「サバとり」ができます。*1

各リスクの検証

各リーダーが持ち寄ったリスク一つ一つについて、全員で以下の観点で検証しました。

  • そもそもリスクとして載せておくべきか。

場合によっては、契約書見積り前提に記載しておけば済むリスクもあります。例えば、「顧客からのユーザI/F要望書の提示が1ヶ月遅れる」というリスクは、見積り前提として、「ユーザI/F要望書は○月○日に提示いただけるものとします。お客様の都合で提示が遅延する際は、リスケジュールと追加コストでの対応を前提に別途協議させて頂きます」と書いてしまえば済む話で、これは契約書もしくは見積り前提の更新/追記で対応とします。

  • リスクが顕在化した際何を犠牲にするか。

コスト:そのリスクが顕在化した際にスケジュール、品質を守るためにコストをかけて対応する。ここで想定されるコストは事前に算出(後述)し、コンティジェンシー予備として予め見積りに含めておく。
スケジュールマイルストーン、納期やサービスイン予定日等の変更。通常は顧客承認が必要。
品質:例えば性能目標値の変更等。通常は顧客承認が必要。

  • リスクが顕在化する確立(10%〜50%)

パーセンテージは予め、ある程度の基準を設けると良いと思います。
また、ある程度確立が高いもの(例えば50%超のもの)は、リスクという扱いではなく、発生することを前提に対応タスクを予め計画し(スケジュール)に盛り込むべきと思います。

  • 軽減策、回避策、転嫁策の検討

事前にリスクが顕在化する確立やリスクが顕在化した際の影響を低減もしくは転嫁できる対策があれば、予めプロジェクトタスクとして盛り込んでおく。

リスクコストの見積り

以下ののコストを見積り、プロジェクト全体の見積りに含めておきます。
コンティンジェンシー予備:リスク対応コスト×発生確立で算出
マネージメント予備:目安としてコンティンジェンシー予備と同額をマネージメント予備として積んでおくと更に安心。実際にプロジェクトを遂行している中で想定していなかったリスクが追加もしくは顕在化したり、リスク対応コストが予想よりも増えそうな場合、マネージメント予備を取り崩して、コンティンジェンシー予備を補てんすることが可能。

プロジェクト開始後

上記で整理したリスク管理表をマスターとして、プロジェクト開始後はいよいよリスク管理を実践していきます。

リスクの追跡

定例進捗会議等の場で、リスクの顕在化や追加リスクの有無、各リスクの発生頻度やリスク対応コストの見直しを行う形で継続的にリスク管理表をメンテナンスしていきながら、リスクコントロールをしていきます。

フィードバック

また、自分達が最初に洗い出したリスクが実際はどうなるのか(本当に顕在化したのか、対応コストは十分だったか、実際には想定外のリスクの発生が多かったか)等をフィードバックし、次回のリスク洗い出しに活かすことで、リスク管理そのものの精度も高められるのでは?と期待しています。d(^_^)

*1:CCPMについては、別な機会にまた記述したいと思います。