新人エンジニアがやりがちな納期の考えかたの落とし穴
はじめに
「これ2日でできます！」
そう言った3日後、まだPRすら出ていない——。
新人の頃、納期の見積もりで何度もやらかしました。自分だけじゃなく、周りの新人エンジニアを見ていても「同じ落とし穴、みんな踏むんだな」と感じます。
この記事では、自分がハマった／見てきた納期の考え方の落とし穴と、その対処法を自戒の念を込めてまとめます。似たような悩みを抱えている人の参考になれば嬉しいです。
落とし穴1: 「コーディング時間 ＝ 全体作業時間」と思い込む
一番やりがちなのがこれ。
頭の中で「コードを書く時間」だけを見積もって「2日でいけます」と言ってしまう。でも、実際のタスクには以下が全部含まれます。
- 仕様の読み込み・確認
- 技術調査・設計
- 実装（ここだけ見積もってる）
- 動作確認・テストコード作成
- PR作成・レビュー対応・修正
- デプロイ・リリース確認
- ドキュメント更新
- Slackでの質問対応や確認のやりとり
実装時間は全体の30〜50%程度と思っておくといい感じ。「実装2日」なら、全体で4〜5日みておく。
落とし穴2: ベストケースで見積もる
「ハマらなければ2日」
……ハマります。絶対。
- ライブラリの挙動が想定と違う
- 既存コードの仕様が読み解けない
- 環境構築でトラブる
- 「あれ？これどうするんだっけ」で1時間溶ける
見積もりは ベストケース × 1.5〜2倍 でバッファを積む。慣れないうちは特に。これでも足りないことがあります。
落とし穴3: レビュー時間をゼロ扱いしている
「実装終わった＝タスク完了」じゃないのがチーム開発。
- レビュワーがすぐ見てくれるとは限らない（他の仕事してる）
- 指摘コメントへの対応
- 再レビュー待ち
- マージ前のコンフリクト解消
- 場合によっては設計レベルでの手戻り
PR出してからマージまで、平均で1〜2営業日くらい見ておく のが現実的。金曜夕方にPR出したら、マージは週明けです。
落とし穴4: 割り込みを計算に入れない
1日8時間勤務だからといって、8時間コーディングできるわけじゃない。
- 朝会・定例・1on1
- Slackの質問対応
- 急なバグ調査依頼
- メール・チケット確認
- 休憩・トイレ・集中が切れる時間
実質コーディングに使えるのは 1日3〜4時間 くらい、というのが体感。見積もりを「作業時間」でやると、カレンダー上では倍の日数かかる計算になります。
落とし穴5: 「動いた ＝ 完成」だと思う
自分のPCで1回動いたら終わり、ではない。
- ハッピーパスしか確認していない
- エラー時の挙動が未検証
- 本番環境と開発環境の差分で動かない
- 他の機能への影響を見ていない
- ブラウザ差分、端末差分
「動いた」から「リリースできる」までに、けっこう距離がある。ここを飛ばすと、リリース直前でバグが見つかって一気に納期が崩れます。
落とし穴6: 遅延を共有するのが遅すぎる
これが一番マズい落とし穴かもしれません。
「頑張ればなんとかなるかも」
「もう少し粘ってから言おう」
「怒られるのが怖い」
気持ちはわかる。でも 遅れそうだと気づいた瞬間に共有するのが一番誠実。
早く言えば、チームは対応策を打てます。
- タスクの分担
- 優先度の調整
- リリース時期の相談
ギリギリで「間に合いません」は、チームに最もダメージを与えます。遅延の報告は、早ければ早いほど評価されると思っておいていい。
落とし穴7: 依存関係（リードタイム）を無視する
自分の作業時間 ≠ タスク完了までの時間。
- レビュワーが休みだったら、そこで止まる
- バックエンドのAPIができてないと、フロント結合テストできない
- 検証環境が他の人に使われてて待ち
- 関係者の承認待ち
他人依存の時間は、自分の頑張りでは縮められない。見積もりには、依存タスクの待ち時間も含める必要があります。
落とし穴8: 学習コストを見積もりに含めない
「初めて使うライブラリだけど、まぁ調べながらやれば2日」
これが罠。
- 公式ドキュメント読む時間
- サンプル動かす時間
- 分からないことをググる時間
- 既存コードを理解する時間
未経験の技術を使うタスクは、経験済みタスクの1.5〜2倍くらいかかる と見ておくのが安全。
落とし穴9: AIが思った通りに進まない
「まあこのタスク、AIに任せれば良いっしょ」
これも罠。AIはタスクを時短で終わらせる便利なツールだが、信用しすぎていると落とし穴が待っている。
- AIのサーバーが落ちてしまった
- プロンプトが不明瞭すぎて思った通りに進まない
- AIが動かないとコーディングなんて出来ないよ
なんてことに陥ってタスクを遅延させてしまうことがあります。
※タスクが遅延してしまいそうな時はすぐに報告※
これを忘れてしまうと信用を失っていく。
じゃあ、どうすればいいのか
偉そうに書いてますが、自分も完璧にできてるわけじゃないです。ただ、意識するようになって精度は上がりました。
1. タスクを細かく分解する
「ログイン機能実装：3日」ではなく、
- フォームUI実装：0.5日
- バリデーション：0.5日
- API接続：0.5日
- エラーハンドリング：0.5日
- テストコード：0.5日
- レビュー対応バッファ：1日
くらいまで分解すると、見積もりの精度が上がります。
2. 不確実性ランクをつける
タスクごとに「これは確実」「ここは不確実」を分ける。不確実なタスクには厚めにバッファ。
3. バッファを「隠さない」
「1日の作業 + バッファ1日」と明示的に伝える。隠すと、バッファを使ったときに「遅れた」ことになってしまう。
4. 進捗を小まめに共有する
毎日1行でもいいから進捗を出す。順調なら「順調です」、詰まってるなら「ここで詰まってます」。チームが状況を把握できる状態を維持する。
5. 見積もりを振り返る
タスクが終わったら「見積もり vs 実績」を記録する。自分の見積もりのクセ（楽観的／悲観的）が見えてきて、次回から補正できます。
まとめ
納期見積もりはスキルです。最初はみんな下手くそだし、外して当然。大事なのは、
- 実装時間だけで見積もらない
- バッファを必ず積む
- 遅れそうなら早めに言う
この3つを押さえるだけで、周りからの信頼感がだいぶ変わります。
「正確に見積もれること」よりも、「見積もりと実態がズレたときに、早く周りに共有できること」のほうが、チーム開発では大事なんじゃないかと最近は思っています。
同じ失敗で悩んでる新人エンジニアの方、一緒にちょっとずつ上手くなりましょう。