確度の低い工程表が生み出す無駄

工程表を書いていていつもアホらしく思うのが、技術的な解決策が分かってない問題を含んでいるプロジェクトの工程。どれだけ調査すれば解決策が分かるかさえ不明で、さらに解決策が分かったとしてもその実装がどのくらいかかるかも不明なのに線を引っ張らないといけない。そして、その不明な部分に依存した別のプロジェクトまでが、確度の低い工程表に従ってリソースのアサインなどを始めてしまう。
分からないことがあるのなら、工程を立てられる程度に情報が集まるまで保留すればいいのに、なぜそうしないのかとても不思議だ。後で工程を立て直せばよいと言うが、それなら調査完了目標までの工程を作っといて、その後を未定にしとけばいいのに。
プロジェクトが完了する日が不確定だってことは、「熊とワルツを」でうまく説明されている。
「熊とワルツを」を読んだ人ならこのグラフに見覚えがあるだろう。

A は最も早くプロジェクトが完了する可能性がある日。B は開発者が「これまでには完了できそうだ」といった日。C は80%程度の確率でプロジェクトが完了していると思われる日だ。
プロジェクトにはいろんなリスクが付き物で、リスクが多いほどグラフは左右に伸びる。逆にリスクが少なければ B を基点にして左右が縮まったグラフになる。
調査が必要なんてのはかなり大きなリスクだから、そういうリスクが残っている状態では、グラフはひどく左右に伸びた状態になる。調査が終われば A・B・C の各点の位置が大きく変化し、調査前に比べてそれぞれの点が近付いてくるはずだ。
確度の低い工程を立てることは、その工程表が波及する範囲でかなりの無駄なコストが発生しているはずだ。その無駄なコストを考えれば「未定」としておくだけでかなりのコスト削減になると思うんだけどなぁ。