勝つためにいちいち賭けをしていると、負けた時にとても許容できない重大な影響が出るかもしれない。
ソフトウェア・プロジェクトでは概して、勝つために特別なことをするより、負けの程度を抑えるほうが大事なのだ。
部下に向かって、精一杯力を尽くして（たとえ無茶なスケジュールでも）プロジェクトを期日に間に合わせてみろとたきつけることは、NASCARのレーサーに大事な仕事を任せるのと同じことだと理解する必要がある。その人はあらゆるチャンスに賭け、思いつく限りの悪い可能性を無視し、はかない勝利の望みをできるだけ長くつなごうとするだろう。それを何と呼ぼうと、リスク管理ではないことは確かだ。
「我々は予想することは下手ではない。ほんとうに下手なのは、その予想の裏にある仮定をすべて挙げることである」ポール・ルック
ソフトウェア・プロジェクト・マネジャーのほとんどは、やらなければならない作業についてはほぼ正確に予想できるが、やらなければならないかもしれない作業は正しく予想できない。
この業界は、早く終わるという第三の結果を事実上不当なものとみなすことで、期日どおりに完成する確率をほぼゼロにしているのだ。いい加減なスケジュールを許さないがために、むしろいい加減なスケジュールが例外ではなく当然になっている。
約束した納期への信頼を高めるには、早く完成することの正当性を取り戻さなければならない。そのためにも、企業文化を本気で改革する必要がある。プロジェクトが予定より早く完成することが安全になれば、発注者も、予定どおりに納品されることを期待できるようになってくる。納期とは別に現実的な目標を設定し、約束を守れることを周囲に示すという、長年先延ばしにしてきた仕事を始めることができる。
阻害要因
- マイナス思考をするな。
- 解決策が見つからない問題を持ち出すな。
- 問題だと証明できないことを問題だと言うな。
- 水をさすな。
- すぐに自分で解決を引き受けるつもりのない問題を口に出すな。
リスクを口に出すことをチームの利益に反すると見るべきではないが、そう見られることが多いのは事実である。これらの不文律は特にめずらしいものではない。責任ある発言と泣き言の区別ができていないのだ。
誰もが「やればできる」聖心で仕事をするよう強いられる。それが問題なのだ。リスクを口にだすことは「だきない」聖心のあらわれである。リスク発見は、組織のこのような基本姿勢とまったく相容れないものである。
阻害要因は強力なので、リスクについて話せるようにするには、明確に定められた理解しやすいプロセスが必要である。全員がプロセスに参加し、なおかつ安全でいられるための儀式が必要である。
我々の経験では、デスマーチ・プロジェクトに共通する性質として、予想される価値が低いことがある。どうしようもなくつまらない製品を世に送り出すためのプロジェクトなのだ。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが効果を上回ることがあきらかだからだ。英雄的な献身がなければ、奇跡を期待することすらできない。
もっといい方法とは、予想される価値を基準に、どれだけリスクをとるかを決める方法である。今思えば、以前からそうしなかった最大の理由は、発注者に価値の数量化を求める厳しさが欠けていたことだ。特に価値の低いプロジェクトの場合、価値の数量化をかたくなに拒否する相手を黙って見守っていた。拒否する以外に、プロジェクトの体裁を保つ手段がないのだ。価値予想を宣言しなければ、開発コストの削減だけでプロジェクトを正当化できる。・・・「コストをこれだけ抑えれば、得られる価値がいくらだろうと、コストのほうが低くなるにきまっている」
