｢締め切りが守れない人｣に共通する甘い考え ラストスパートでは帳尻を合わせられない

締め切りという言葉への典型的な誤った考え方は、次のようなものでしょう。

・見積もりはあくまで見積もりでしかなく、予定どおりに仕事が進むとは限らない

・締め切り目前に、徹夜でも何でもして頑張ることが大切

・それでもどうしても締め切りに間に合わなかった場合は、その段階でスケジュールを変更してもらうしかない

「ラストスパート志向」が諸悪の根源

たとえば、このような意識を持っているエンジニアに、私があるソフトウエアの作成を依頼したとしましょう。するとそのエンジニアは、今までの経験から「3カ月ぐらいでできると思います」と軽い気持ち（漠然とした見積もり）で答えます。

多くの場合、この手のエンジニアはプロジェクトを甘く見て、最初の2カ月ぐらいはのんびりとすごします。残り1カ月くらいの「お尻に火がついた」状態になって頑張るのですが、あわてて作るためにスパゲッティコード（スパゲッティのように複雑に絡み合ってしまったプログラム）になってしまいます。

残り2週間目くらいでソフトウエアはそこそこ動き始めますが、まだまだ機能は不十分だし、バグもたくさんあります。最後の1週間でプログラムに潜む誤りであるバグの修正に取り掛かりますが、最後の最後になって基本設計上の欠陥が見つかります。しかし、いまさら後戻りはできないので、バグを回避するための、その場しのぎのパッチ（修正プログラム）を当てますが、そんなことをしているとますますプログラムが汚くなっていきます。

最後は徹夜もしますが、寝不足でミスが続き、結局バグが取れずに締め切りの日になってしまいました。「申し訳ありません、できませんでした」と言うしかありません。「じゃあどのくらいで完成するの」と聞くと、「あと2週間あれば大丈夫だと思います」と答えます。しかし、2週間では根本的な変更などできるはずもなく、パッチにパッチを当て、目も当てられないようなプログラムになっていきます。

結局2週間努力しても問題は解決せず、「根本的な問題の解決のためにあと2カ月ください」と言い出します。しかたがないのでスケジュールの変更を認めると、時間に余裕があるので、また最初の1カ月はのんびりしてしまいます。

そうして最後の1カ月でラストスパートをかけようとしますが、再び同じような状況に陥り、最後は徹夜の連続。再び寝不足のためにプログラムが汚くなり、バグが多発。結局、新しく設定した締め切りも逃してしまいました……。