遅れの原因を解明する

　たとえ遅れを「量」的に把握できているとしても、ただ、スケジュールが２日遅れたというだけでは済みません。それが起きてしまった原因を考えなければなりません。そうでなければ、また同じ過ちを犯してしまうでしょう。いや、既に来週以降の予定の中に同じ過ちを犯した部分があるかも知れません。

　したがって、遅れの原因を正しく掌握することは、遅れをこれ以上拡大させないことでもあり、見積もりのスキルを上げることでもあり、「分かる範囲」を広げることでもあるのです。

　たとえばレビューに手間取ったのなら、なぜ手間取ったのかを究明しなければなりません。それが設計書の書き方に原因があると判断される場合は、ソースの品質に影響が出ている可能性があります。そうなると、単体テストや統合テストに影響を与えるかも知れません。

　あるいはテスト工程の遅れの原因が、バグの発生が予想より多く、その対応に手間取っているためだとしたら、バグの発生傾向を調べることで今後の収束の予測が出来るかも知れません。逆に開発・設計の品質の悪さが原因だとすれば、時にはテスト工程を中止させることも必要です。そのような物を製品として市場に出す意味はないからです。

　中には、着手が遅れただけで、その作業の実体としては見積もり通りの時間で進んでいることもあります。作業の実績時間を詳細なスケジュール表にきちんと記入していれば、別の理由で予定を外してしまった作業とはっきりと区別できます。

　遅れの原因として、単に「量」的見積もりの失敗ということもあります。量を見ようとしていなかったために、２時間と予定した作業が４時間になったりします。この場合、来週以降の作業も「量」が見積もれていない可能性があり、明日以降の類似の作業を見直す必要があります。詳細スケジュール表には「時間」の形で表現されるため、どうしても、その前情報としての「量」が曖昧にされてしまいます。したがって、もし原因がここにあるなら、「時間」の根拠になった「量」を何処かに書き残しておくとよいでしょう。

　もっとも、言語に不慣れなために「量」を上手く見積もれなかったのなら、それほど問題にはならないでしょうが、それが原因であったという認識は必要です。

　また、作業のイメージが不十分であったために、当日になってその作業に入る前に準備が必要であることに気付き、急遽手配したが間に合わず、さらに悪いことに次々と段取りが狂ってしまい、結局のところ３日で終わるものが１週間かかってしまったというケースもあります。

　このような場合はもっと深刻かも知れません。それは“イメージする能力”に関わるからです。言い換えれば、そこで求められていることは１ヶ月後、２ヶ月後の作業を、「今」からその作業を行うような錯覚をすることでもあります。もしかしたら、誰にでも出来ることではないのかも知れません。でも、このスキルは、訓練である程度耐えられるレベルに到達すると思っていますし、そのような人の場合は、別の工夫を考えることも必要でしょう。