私たちは、たまたまうまくいったプロジェクトを実践して来ており、それは結果として正しいだけであり、そこに潜むリスクを無視していたことに気づかされる。
まったく考えていなかった発想だった。
あと、新しい知恵と認識した事柄は、
１）リスクのないプロジェクトは手を付けるな＞（チャンスからの逃避）
２）エクスポージャー分析＝リスクが実現する確率×その影響の定量化
３）ショートストッパー＝容易にコストを決められず、発生すると何もかもが犠牲になるリスク。プロジェクトを位置から考え直すか、完全にやめるしかないリスク。
⇒対策は「プロジェクトの前提条件」によって管理するしかない。
４）「間違えるのは構わないが、不確実かなのはだめだ。」というルールがある会社はダメな会社。
⇒つまり、記述には間に合わなくても「事前に失敗するかもしれない」ことを認めるという大罪を犯さなければ、失敗は容認される。
５）ソフトウェア・プロジェクトの古典的なリスク
１．スケジュールの欠陥＞原因：開発サイズの見誤り、対応：予備期間の確保
２．要求の増大＞原因：カウンター・インプリメンテーション＝不満分子が要求を詰め込む事。対策：要件定義をデータ要素レベルまで定義する。
３．人員の離脱＞原因：協力することになっている。対策：余裕を見ておく
４．仕様の崩壊＞原因：合意することになっている。仕様はあいまいに作ることができる。（ソフトはあいまいに作ることができない。）
５．生産性の低迷＞対策：人が多ければ個人差はならされる。
■リスク発見の阻害要因
１．マイナス思考をするな。
２．解決策が見つからない問題を持ち出すな
３．問題だと証明できない問題を問題だというな
４．水をさすな
５．すぐに自分で解決を引き受けるつもりのない問題を口に出すな。
＞チームプレイヤーとして利益に反する。
＞泣き言との区別が難しい。
よって、状況は改善されない。
＞やればできるの精神で失敗を招く。
