入社して数ヶ月、そろそろ一人で機能開発を任されるようになった新卒エンジニアの皆さん。「この機能の工数どれくらい？」と聞かれて、心の中で「え、、、どうやって見積もるの？？」となっていませんか？
自社プロダクトを持つ企業で働く新卒エンジニアとして、ステークホルダーが多い環境での工数見積もりに苦労した経験を元に、リアルな悩みと対処法をまとめました。
なぜ新卒は工数見積もりで詰むのか
1. 「コードを書く時間」しか考えていない
❌ 新卒の見積もり
機能実装: 2日
合計: 2日
✅ 実際に必要な作業
- 要件整理・設計: 0.5日
- 実装: 2日
- テスト作成: 0.5日
- QAとの連携・修正対応: 1日
- ドキュメント作成: 0.5日
- カスタマーサポートへの説明: 0.5日
- レビュー対応: 1日
合計: 6日
現実は実装以外の工数が実装の2-3倍になることが多いです。
2. ステークホルダーの存在を軽視している
自社プロダクトでは様々な人が関わってきます：
- メンター：レビューや相談対応
- エンジニア：技術面でのレビュー・相談
- QA：テスト計画、バグ報告・修正依頼
- プロダクトマネージャー：要件確認、優先度調整
- カスタマーサポート：リリース後の問い合わせ対応準備
- デザイナー：UI/UX面での調整
各ステークホルダーとのやり取りで待ち時間や調整時間が発生することを見落としがちです。
3. 「うまくいくケース」しか想定していない
新卒の頭の中:
「一発でレビューが通って、バグもなくて、要件変更もない」
現実:
- レビューで2回修正指摘
- QAで3件のバグ発見
- カスタマーサポートから「これだと問い合わせが増える」指摘
- PMから「やっぱりここも変更したい」
実際にあった工数見積もり失敗談
Case 1: ユーザー一覧ページの検索機能追加
当初の見積もり: 3日
実際にかかった時間: 8日
何が起きたか：
- 実装は確かに1日で完了
- QAから「検索結果が0件の時のUIがわかりにくい」指摘 → デザイナーと相談（1日）
- 「検索履歴機能も欲しい」と追加要件（2日）
- カスタマーサポートから「検索できない場合の問い合わせ対応マニュアルが必要」（0.5日）
- 大量データでの性能問題発覚 → パフォーマンス改善（2日）
- レビュー修正で細かい調整（1.5日）
Case 2: 管理画面の新機能
当初の見積もり: 5日
実際にかかった時間: 12日
主な誤算：
- 既存コードが想像以上に複雑だった
- 他チームのAPIの仕様理解に時間がかかった
- 権限管理周りで想定外の考慮事項が発生
工数見積もりを改善する具体的な方法
1. WBS（Work Breakdown Structure）を作る
大きなタスクを小さく分解しましょう。
例：「商品レビュー機能」
├── 要件整理・設計 (0.5日)
├── DB設計・マイグレーション (0.5日)
├── モデル・API実装 (1.5日)
├── フロントエンド実装 (2日)
├── テスト作成 (1日)
├── QA対応 (1日)
├── ドキュメント作成 (0.5日)
├── ステークホルダー説明・調整 (0.5日)
└── バッファ (1.5日)
合計: 8.5日
2. 「3点見積もり」を使う
楽観値：すべてうまくいった場合 (3日)
悲観値：最悪のケースを想定 (10日)
最頻値：普通に進んだ場合 (6日)
期待値 = (楽観値 + 4×最頻値 + 悲観値) ÷ 6
= (3 + 4×6 + 10) ÷ 6
= 6.8日
3. 過去の類似タスクから学ぶ
類似タスクリスト:
- 商品一覧機能: 見積もり4日 → 実際7日 (1.75倍)
- ユーザー管理機能: 見積もり3日 → 実際5日 (1.67倍)
- 通知機能: 見積もり5日 → 実際9日 (1.8倍)
平均倍率: 約1.7倍
→ 今回の見積もりに1.7倍をかける
4. ステークホルダー別の工数を明確化
| ステークホルダー | 想定される作業 | 工数目安 |
|---|---|---|
| メンター | 相談・レビュー | 10-20% |
| QA | テスト・バグ対応 | 20-30% |
| PM | 要件調整 | 5-15% |
| カスタマーサポート | 説明・マニュアル | 5-10% |
| デザイナー | UI調整 | 0-20% |
5. 「見積もり会議」を提案する
一人で悩まず、関係者を巻き込みましょう。
参加者: メンター、PM、QA担当者
議題:
1. 要件の認識合わせ
2. 技術的な不安要素の洗い出し
3. 各工程の工数見積もり
4. リスクの特定と対策
見積もり精度を上げるチェックリスト
技術面
- 既存コードの調査時間を含めているか
- 外部API・ライブラリの学習時間を考慮しているか
- テスト作成時間を含めているか
- パフォーマンス検証時間を考慮しているか
ステークホルダー面
- QAとの連携時間を含めているか
- レビュー・修正の往復回数を想定しているか
- ドキュメント作成時間を含めているか
- リリース後の問い合わせ対応準備を考慮しているか
リスク面
- 要件変更の可能性を考慮しているか
- 技術的な難易度のブレを想定しているか
- 他チームとの依存関係を確認したか
- バッファ時間を設けているか
上司・先輩との上手な相談の仕方
❌ ダメな相談
「この機能の工数がわかりません。教えてください。」
✅ 良い相談
「この機能の工数を見積もりました。
- WBSで分解した結果、8.5日と算出
- 不安要素：既存のAPI仕様が複雑で調査に時間がかかりそう
- 質問：過去の類似機能と比べて妥当でしょうか？」
ポイント：
- 自分なりに考えた結果を示す
- 具体的な不安要素を伝える
- Yes/Noで答えられる質問にする
まとめ：見積もりは「技術力」より「想像力」
工数見積もりの精度向上は：
- コード以外の作業を想像する力
- ステークホルダーとの調整を想定する力
- 過去の経験から学ぶ力
- リスクを事前に察知する力
これらが重要です。
最初は誰でも見積もりが甘くなります。大切なのは失敗から学び、次回に活かすこと。また、一人で抱え込まず、チーム全体で見積もりの精度を上げていく文化を作ることも重要です。
見積もりが外れても世界は終わりません。むしろ「なぜ外れたのか」を分析する方が、将来のエンジニアとしての成長につながります。
新卒の皆さん、一緒に頑張りましょう！ 🚀
この記事が参考になったら、ぜひ「いいね」やコメントをお願いします。他の新卒エンジニアの方の体験談もお聞かせください！