LTSコラム

リスクの分解
2011.8.4

「リスクマネジメント」という分野は経営レベルのリスクからプロジェクトレベルでのリスクにいたるまで多くの手法が語られています。
リスクを受容・回避・軽減・転化の4つに分類する基礎的なレベルから、発生確率と損害想定額(時間)を掛け合わせてリスク対応コスト(バッファ)を算出する方法まで様々です。
もちろんこれらの分析手法は有効なリスク管理手法ですが、どんなリスクを想定したとしても、リスクが顕在化した際の影響が具体的に想起でき、かつ対応策が具体的に実行可能なレベルまで策定可能なレベルに分解されていなければ意味がありません。
以下は実際にプロジェクトのリスク管理表に記載されていたリスクです。
「要求仕様書(RFP)の品質が想定より低い恐れ」
不安な事項はとても良くわかりますが、実際にリスク対応を行うにはあまりに漠然としていています。
そもそも品質とは何なのか?想定とは何なのか?という話もあります。これを少し分解してみましょう。
「要求仕様書の策定にあたってユーザー部署へのヒアリング時間が確保できず要求事項を網羅的に収集できない恐れ」
これくらいならだと多少は具体的と言えるかもしれません。少なくとも何がリスクなのかは良くわかります。プロジェクトに汎用的に適用するチェックリストならこのレベルの記述が適切かもしれません。でもこのレベルでは実際のプロジェクトではまだ分解が足りません。対策を立てるにはもう一段階の分解が必要なのです。
「(3つの調整先ユーザー部署の中で)A部署の業務現場リーダーであるBさんのヒアリング時間が繁忙期と重なるため期間内に確保できない恐れ」
これくらいに分解されていれば対策を具体的に立てることができます。
営業のようにある程度自立的に時間を確保できそうな職種と違って、コールセンターやシェアドサービスセンターのように業務時間が区切られている部署では繁忙期になると担当者が全く現場を離れられないということがあります。
しかもこういうところに限って上長(本社などから出向者だったりする)は現場を把握していないためヒアリング者としては不適切だったりします。
考えられる対応としては以下のような事項が考えられます。
  「上長に依頼してこの時期の部署の体制を予め増強しておいてもらう」
  「現任のリーダーではなく他部署に移った前任者に事前にヒアリングを行いポイントを整理しておく」
  「始業前、終業後の時間をヒアリング時間として確保してもらう(つまり残業を依頼する)」
  「プロジェクト側で想定していたヒアリングスケジュールを繁忙期に合わせて調整する」
考えれば他にもあると思います。重要なのは「具体的で実行可能な対応策を可能な限り多く」考えることです。
個々の対応策が「回避」なのか「軽減」なのかは本質ではありません。リスクを定量的に評価することもプロジェクト全体に影響を与える重大リスクはともかくとして、日常の作業で頻発する雑多なリスクに対してはいちいち、定量評価をする手間があったらすぐに対応することの方が重要です。
ここでも具体的に分解することが効果的なリスク対応を行う上でのポイントとなります。