本記事のゴール
プロジェクト管理におけるリスク管理のプロセスの内、識別と評価のステップ
リスク管理がなぜ必要か、は記述していません
前提
言葉の定義
リスクとは、以下の2つの意味を持つ。
1.将来起こりうる出来事で、イヤな結果を生むもの
2.イヤな結果そのもの
リスク管理とは、原因としてのリスクを管理すること。
すなわち、管理できるのは、①の意味でのリスクのみ。
リスクの性質について
「リスクは起きるか起きないかの2状態しかない」ととらえるのは誤りです。部分的に発生して、その分だけプロジェクトに悪影響を及ぼすリスクもあるからです。
リスクが問題として現実化すること=移行
リスクが発生した時に気づくための仕組み=移行指標
リスク管理の方法
ステップは以下の6つ。
- リスクの洗い出し
- エクスポージャー分析
- 危機対応計画の策定
- リスク軽減
- リスク図の作成
- 継続的な移行監視
1.リスクの洗い出し
- まず前提として、ありうるイヤな結果に対し「考えるとキリがない」と宣言したとしても、発生確率は0になりません。にもかかわらず、その宣言がリスク管理から目を逸らすことにつながります。リスク管理を実行するために、この点に注意した方がよいでしょう。
考えられるリスクを洗い出すには？
やることは2つあります。
- ソフトウェア開発プロジェクトに一般的なリスクを参考にする
- 組織内の過去のプロジェクトの失敗を参考にする
- プロジェクト固有のリスクを洗い出す
- ベンダーなど他人に割り当てるリスクは確実に割り当てる
1.について
一般的なリスクには以下があります。これらはプロジェクトのリスクとして登録しておくべきです。仮にそれぞれの発生確率が10%だとしても、1つも現実化しない確率は41%です。
- スケジュールに無理がある
- 要件変更
- 人員の離脱
- 仕様が詰まっていない
- 生産性が低い
2.について
遅延の原因に、計画した作業に想定以上の時間がかかったからというケースは少ない。計画になかった作業が発生したというケースが多い。そのような条件つきの作業をどう予想するか？組織が過去数年のプロジェクトで遭遇した問題の上位20件を洗い出すのがよい。
3.について
ベストな方法は、チームメイトが「もしXが起きたら、困ったことになる」とチームに共有すること。
しかし、そのように為されない場合があります。すなわち、個人的な心配にとどまってしまう場合があります。この背後には、なんらかの阻害要因が働いて、情報の流れが閉塞していることが多いです。この場合、プランBをとります。
プランBとは、リスクの洗い出しのための形式的なプロセスを設定することです。そうすることで、安心して感じているリスクを表明できるようになるからです。
4.について
ベンダーが負うべきリスクは発注者が確実に契約で負わせるなど積極的に管理をする。
そうでなければ、発注者は最低限のリスクしか負わないことになる。
特定したリスクに対し移行指標を定義しよう
- 移行指標は、できるだけ早く検知するための仕組みが望ましい
- 個々のリスクに1つ以上移行指標を定めるべき
- 移行指標は継続的に監視されるものであると認識すべきです。異常を発見したら即、危機対応計画を実行に移すためです。
- 移行指標の選択基準
- 危機対応に要する時間が長いなら、つまり早めに検知しないと手遅れになるなら、早めに検知できる指標がよい。
- 一方、指標が誤っていた時に起きる問題の大きさも加味する。リスクが現実化していないのに、現実化したと示しがちな(偽陽性)指標は、一見すると役に立たない。だが、現実化した時の問題が大きいならば、それを採用する価値はある。例：トラック運転手は、「ボールが転がってくる」ことを「子供が飛び出してくる」リスクの移行指標としている。100%当たる指標でないにせよ、守るのがよいだろう。
2.エクスポージャー分析
- 一般的にはリスク分析に近いです。
exposure = 金融の文脈で、〔投資家などが〕リスクにさらされる度合い - あるリスクが現実化する確率を求めます。
- そのリスクが現実化した際のコストを数字で求めます。(スケジュールまたは金額)
- その確率×コストを計算します。それがそのリスクのエクスポージャーです。
- 全てのリスクに対して、エクスポージャーを計算します。
- それらのエクスポージャーの総和を求め、それを予備のスケジュール(バッファ)または予算として用意します。単体の予備のスケジュールまたは予算は余ることがありますが、プロジェクト全体では丁度いい分量になるはずです。
3.危機対応計画の策定
- リスクが移行した時に取る対応策を事前に定めます。
- これを全てのリスクに対して行います。
4.リスク軽減
- 危機対応計画のコストを最小限にするために移行前にやっておくべきアクション、すなわち軽減措置を定めます。
- この軽減措置は、移行前に行うので100%実行することになります。
- 軽減措置のコストは、危機対応計画のコストの削減額よりも小さくなるべきです。(そうでなければ、軽減は無意味です。)
5.リスク図の作成
- リスク図作成とは、不確実性を数量化する作業です。
- 不確実性とは何か
- "仮にあなたがPMだったとする。プロジェクト開始前に、部長から10/30までにプロジェクトを完了できないか？と質問を受けた。大まかに考えて10/30までの完成はあり得ないと考えたとする。この時、いつ頃なら完了があり得るか、考えることはできるだろうか？"
- 横軸にプロジェクトの完了日、縦軸にその完了日が実現する確率(ただし相対的な確率)をとる実は、プロジェクトの完了日は点ではなく線で表現される
線の幅は、組織の開発プロセスにどれだけノイズ(変動因子)があるかで決まる。この時、曲線の下側にある領域の面積の合計は1となる。青色部分は、面積の半分を示す。その時の境界線が5/1を通っているということは、5/1までにプロジェクトが完了する確率が50%であることを意味する。そして、1/1までに完了する可能性は0%であることを示す。逆に、12/31までに完了する可能性は100%に近いことが分かる。ちなみに、全ての日付の中で最も完了する可能性が高いのは4/1である。しかし、この図では、4/1までに完了する確率は50%を切っている。
これが、プロジェクト完了日の不確実性を示している。これはリスク図と呼ばれる。 - このリスク図をプロダクトオーナーや管理層へのスケジュールの約束とするのがよい。ここで重要なのは、約束する納期と、チームメイト向けに示す目標の納品日を分けて定義することだ。目標日の設定は、約束する納期よりも早くなり、チームメイトのモチベーションを上げるために行う。また、線でなく点(特定の日付)でスケジュールを約束することは、完了日の不確実性を隠蔽することになる。
6.継続的な移行監視
移行していたら、定めた危機対応計画を実行に移す。
おわりに
リスク管理を行い、しくじりを未然に防止しましょう。
イベントにこじつけるためのコメント
参考書籍
トム・デマルコ (著), ティモシー・リスター (著), 伊豆原 弓 (翻訳)『熊とワルツを - リスクを愉しむプロジェクト管理』