なぜ積み上げ式の見積もりは必ず崩壊するのか
新規プロジェクトの工数を見積もる時、多くのリーダーが以下の手法を取ります。
- システムを機能単位に分解する（WBSの作成）
- 「ユーザー登録：3日」「決済連携：5日」「ダッシュボード：4日」とタスクを積み上げる
- 合計して「12人日です！」と報告する
このやり方で作られたスケジュールは、ほぼ100%の確率で遅延します。
なぜなら、それぞれのタスク（パーツ）を組み立てて「1つの動くシステム」にし、リリースして運用に乗せるまでには、WBSには現れない**大量の「摩擦（フリクション）」**が存在するからです。
全体工数を見積もる際に、絶対に見落としてはいけない「4つの見えないコスト」を解説します。
1. 統合（インテグレーション）コスト
個々のパーツが単体で動くことと、それらが結合して動くことの間には巨大な溝があります。
フロントエンドとバックエンドのAPIを繋いだ瞬間、スキーマの解釈ミスで動かない。インフラにデプロイした瞬間、CORSエラーや権限不足で繋がらない。
積み上げ見積もりの中に**「結合テストと調整」のバッファを最低でも全体の20〜30%**確保しておかないと、実装が終わった後の「動かない調整フェーズ」でスケジュールが完全に溶けます。
2. 認識のズレを解消する「コミュニケーションコスト」
仕様書通りに作ったつもりでも、最初のデモを見せた瞬間に「思っていたのと違う」と手戻りが発生します。
また、開発メンバー間での仕様の議論、Slackでのやり取り、定例ミーティングの時間は、コードを書く時間と同じくらい工数を消費します。
見積もりは「1日8時間コードを書く」前提で作られがちですが、実質的に開発に集中できるのは1日5時間程度であると考えるのが現実的です。
3. 「知らないこと（Unknowns）」の探索コスト
「やったことがない外部APIとの連携」や「新しいライブラリの導入」がある場合、見積もりは完全にギャンブルになります。
人間は「自分が知らないことの難しさ」を過小評価する傾向があります。初めて触る技術が含まれるタスクは、見積もりを2倍〜3倍にしておくか、事前に1〜2日の「技術検証（スパイク）」期間を設けて調査を終えてから本命の見積もりを出すべきです。
4. 運用・リリース準備コスト
コードが完成してから、実際にユーザーの元に届くまでのコストです。
- 本番環境のドメイン・SSL証明書の設定
- CI/CDパイプラインの構築とデプロイテスト
- データ移行（マイグレーション）スクリプトの作成と検証
- マニュアル作成やカスタマーサポートへの共有
「金曜日までにコード書けます！」は、「金曜日にリリースできます」という意味ではありません。
結論：全体見積もりには「掛け算」が必要
タスクの積み上げで算出した日数は、あくまで「理想的な開発期間（Ideal Days）」です。
これに、チームの生産性や上記の見えないコストを加味した「オーバーヘッド係数（通常 1.5 〜 2.0）」を掛け合わせたものを、最終的な全体工数（Real Days）として提示するのが、シニアリーダーとしての正しい見積もり作法です。
全体工数 ＝ （各タスクの積み上げ合計） × オーバーヘッド係数（1.5〜2.0）
「思ったより時間がかかりました」と後から言い訳をするくらいなら、最初からこの「見えない摩擦」を数式の中に組み込んでおきましょう。