Solution
概要
見積もり段階で、リスク項目を洗い出しスケジュールにフィードバックする仕組みを考える。内容
- リスクは、実際に発生したときにフォローに掛かる期間と金額を提示する必要がある
- リスクの発生は、確率的である
- 初期スケジュールの出し方
- 新しいリスク項目の発生時のスケジュール見直し
- リスク項目が解消されたときのスケジュール見直し
ソフトウェア開発上で、スケジュールの遅れや必要経費の増大など、ソフトウェア開発に負の影響を与えるものを「リスク」と考える。リスクは、まだ発生していない段階の「リスク項目」と、実際に発生したときの「リスク発生」との２つに分類される。
図1 プロジェクトの終わる確率
- Nは、障害が発生せずにプロジェクトが終了するときの「楽観的」な期日を示す。
→ 成功する確率は、ほぼ０％ - Ｔは、一般的なリスクを見積もった上で、プロジェクトが終了するであろう期日を示す。
→ いわゆる、感覚的な見積もりを行って、リスク込みでこんな感じかなぁという期日 - Mは、実際にリスクが発生してスケジュールを大幅に超過したときに期日を示す。
→ 「熊とワルツを」では、プロジェクトの中止というパターンもあるのだが、受託開発の場合には「なにがなんでも」完成させるパターンが多い。
ここが落とし穴である。
図2 プロジェクト計画の妥協点
図3 最頻点と確定点
グラフのダウンロード(Excel)
指定した期日にプロジェクトが終わる度合を累積して、「期日まで」にプロジェクトが終了する確率を累積すると、このようなグラフになる。最頻点（Ｔ点）以前にプロジェクトが終わる確率は、３０％に満たない。半々でプロジェクトが終わる地点、８０％程度に確実にプロジェクトが終了する期日をみていくと、予想よりもずっと右へ（先のほうへ）ずれているのがわかる。
よく言われる、ＩＴプロジェクトの３割しか成功しない（スケジュール通りに進まない）という真実がここにあわられている。
これは「納期遅延」とは異なる。プロジェクト開始時に計画立てられた「初期計画」に対する遅延を意味する。よって、顧客の都合によるプロジェクトの長期化（主に仕様変更が理由）も、リスク項目のひとつとなる。
受託開発の場合、開発が遅れたときには長期化した分だけ追加料金をいただく、というパターンが多いが、実際には初期スケジュールから遅延することによって、２つの損失が発生している。
- システム導入効果が先延ばしになるために発生する顧客側の損失
- 前のプロジェクトが終わらないことにより、次のプロジェクトが開始できないための受託側で機会が失われる損失
たとえば、今年の４月の時点で１年間のプロジェクトを請け負ったとする。そして、来年の４月のプロジェクトを計画する。１年も先の話なんてわからないから来年のプロジェクトの計画（受注）はできない、とするか、１年先の受注を確実に取ることができるか、という分岐点になる。あなたが経営者だとしたら、これは大変な分岐点である（に違いない）。経営者でないとしても、来年の仕事があるのかないのかわからない状態よりも、来年も確実に仕事があるほう良いに決まっている。そのためには、手元にある今年の仕事が、１年間きっちりで終わる必要がある。それも、しゃにむに働いて修羅場を潜り抜けるという危うい綱渡りではなくて、確実に1年後に終わるというスケジューリングとリスク管理が必須になる。（あなたが修羅場が好きなのであれば別だが・・・私は一緒に仕事はしたくない）
１年も期間があれば、スタッフを増員して各リスク（主に顧客の仕様変更）に対処することも可能だろう。たいていの大型プロジェクトが潰れるパターンは、リスクの対処期間を含まないスケジューリングのまずさにある。リスク項目を列挙しても、リスクの対処方法（増員なり期間なり）を挙げておかなければ、リスクマネージメントをしているとは言わない。実際に発生するリスクへの対処は、プロジェクト・バッファ（「クリティカル・チェーン」を参照）でクリアする（と考えられる）。あと、４０時間勤務バッファとか。
参考文献
トム・デマルコ著 「熊とワルツを」トム・デマルコ著 「ゆとりの法則」