熊とワルツを

第1部 なぜリスク管理をするのか
まったくリスクのないプロジェクトに手を出すのは負け組みだ。かならずといっていいほど、何も得るものはない。そうでなければ、とっくの昔に誰かが片づけているはずだ。時間と労力を節約して、もっと価値のあることに使ったほうがいい。
リスク管理の反対を「危機管理」といい、問題が発生した後に何をするべきかを考えることを意味する。

リスク管理を構成する主な活動
・リスク発見・・・ブレーンストーミングによるリスク選別と、新しいリスクを発見するための継続的なプロセスの導入
・エクスポージャー分析・・・それぞれのリスクが実現する確立と、その影響を数量化する。例えばリスクの発生確率が20パーセントで、発生した場合に100万ドルのコストがかかるとしたら、リスク・エクスポージャーは20万ドルである。
・危機対応計画・・・リスクが実現した場合に何をするべきかを計画する。これのみをリスク管理と誤解されることが多い。
・軽減・・・リスクの発生を検出する指標を考え、発生までにとる処置を計画する。例えば火災のリスクに対し、消火器、火災報知機の設置避難訓練など。
継続的な移行監視・・・管理するリスクを追跡し、実現しないかどうかを監視する。

デンバー国際空港 この失敗は、言われているようなソフトウェアの開発プロセスの問題ではなく、リスク管理がなされなかったことが問題である。

第3章 リスク管理の方法

「測定していないものはコントロールできない」のデマルコの言葉通り、数量化し、リスク図で考える方法が示される。
リスク図とは縦軸に確率、横軸にスケジュール、あるいはコストをあらわしたグラフである。
例えばプロジェクトの完了を、「プロジェクトは年内に完了します。」という代わりに「年明けまでに完了する確率は０です。完了する確率が最も高いのは来年4月の始めです。少なくとも5月以降でしたら５分以上です。」などと説明する。

いくつかの原因リスクおよび、開発規模のパラメータと技術要因が合成されて、結果としての全体リスクの図ができる。
例として、ソフトウェア・プロジェクトのスケジュールのリスク図を作成するExcelのマクロで作られたRISKOLOGYの使い方が示される。（無償で使える）
RISKOLOGYでの原因リスク（コア・リスク）としているのは、
(1)スケジュールの欠陥
(2)要求の増大
(3)人員の離脱
(4)仕様の崩壊
(5)生産性の低迷
の５つである。

リスク発生の検出における、進捗メトリック、特にEVR（稼得価値）の重要性。
さらにリスク軽滅のためのインクリメンタル手法の説明。
究極のリスク軽滅戦略は「早くスタートすること」。

第4章 数量化の方法

プロジェクトのスケジュールとコストをリスク図を使って考えるのと同時に、発注者は、プロジェクトの利益をリスク図を使って同じ精度であらわさなければいけない。


本書は会社の中でのソフトウェア・プロジェクトのリスク管理の方法を述べていますが、SOHO事業者の立場から、リスク管理を考えるきっかけになりました。
SOHOとしては、いいニュースは、リスク管理に反対する人は誰もいないこと、悪いニュースは、人員の離脱（健康の問題でしょうか）等に対応するすべをもたないことです。
この辺の弱点を、パートナーとのコラボレーションで補うというのが、今後のあり方かなと考えさせられました。
内容はソフトウェア･プロジェクトに特化されていますが、業種、業態を問わず、全ての方にお勧めです。