はじめに
新しいプロジェクトに着手するとき、要件定義が終わったらまずスケジュールを立てることが必要です。
ですが、着手段階でスケジュールって立てづらくないですか？
（個人的には、まだまだ不確定要素が多すぎて「この日までにやれます！」と言うのがとてもこわいです。）
そこで、この記事では、
スケジュールが遅延する原因とその対策
について、設計、実装、テストの各フェーズに分けて解説します。
実際の経験を元にまとめていますので、自分と同じ初心者エンジニアの方にとって、
少しでもスケジュール管理のヒントになれば幸いです。
設計フェーズ
①要件がまだ固まっていない
▷対策
確実に固まっているところから着手するか、
結合テストのケースを先に考えておくなど、手持ち無沙汰にならないように工夫するとよいです。
予め、設計の期間を少し長めに取っておくのも一つの手かもしれません。
②レビューが遅れ、後続作業を始めている場合に手戻りが発生する
▷対策
設計完了の目途が立ち次第、早めにレビューの日程を抑えておくと安心です。
実装フェーズ
①設計ミスが発覚する
▷対策
実装フェーズで対策をするのではなく、設計段階でしっかりとソースコードに目を通しておくことで、なるべく設計ミスを少なくすることが対策です。
コメントアウト（TODOコメント）を使って作業内容をメモしておくのも有効だと思います。
②開発用ツールが上手く動かない/作業中のファイルが消えてしまう
▷対策
開発用ツール（Eclipseなど）の不具合で、ファイルの変更内容が全て消えてしまった...ということも、稀にですが起こります。
アプリの不具合なので防ぎようがないですが、
ローカルリポジトリにこまめにコミットしておくか、ときどきバックアップを取っておくと、
影響範囲を最小限にすることができます。
テストフェーズ
①インフラのトラブル（対向システムとの通信ができないなど）
▷対策
テスト工程だとこれが一番よくあるケースかと思います。
こちらも根本的には防ぎようがないです。
もし修正前のモジュールを動かせる状態であれば、早めに軽く動作確認をしておいて、
インフラチームに不具合を報告しておけば、スケジュールへの影響を抑えられるかもしれません。
また、テストデータに不備があって通信ができないなどのケースも稀にあります。
②バグが見つかり、実装（場合によっては設計）の修正が必要になる
▷対策
設計由来のバグの場合、設計と並行してテストケースの作成を行っておくことで、想定の抜け漏れを減らすことができます。
特に、機能要件だけでなく、非機能要件も満たせているかどうか（特に処理件数が増えたときの応答時間など）も念頭に入れて置く必要があります。
実装由来のバグの場合、可能であればなるべく多くの人にレビューをしてもらうことが良い対策になると思います。
特に最初のうちはレビューが怖くて避けがちですが（僕はいまだにちょっと怖いです）、後々不具合が発覚する方がもっと怖いので、レビューは色んな人に見てもらえば見てもらうほど良いです。
おわりに
今回上げた要因以外にも、
「自分はこういうことが起こってスケジュールが遅延したよ！」ということがあれば、
コメントで教えていただけると幸いです。
余談ですが、可能であればスケジュールは点ではなく線で設定できるのが望ましいと思います。
「○月○日に完成！」ではなく、「○月○日～○月×日の間に完成！」という感じです。
ただ、スケジュール作成時には既に納期なりリリースなりの日程はビタッと決まってしまっている場合が大半だと思います。
せめてマイルストーン（設計の完了や実装の完了地点）だけでも幅を持って見積もって、もし遅れた場合は早め早めに対策を打てると理想的です。