先に要点
- 見積もりが外れたときに一番やってはいけないのは、黙って残業で吸収しようとすること。問題が見えなくなり、傷が深くなってから露見します。
- 初動は 「早く認める・共有する」。そのうえで、終わった作業ではなく 残りの作業を再見積もり して、現実的な着地点を出し直します。
- 立て直しの基本は スコープ削減・フェーズ分割・納期延長・交渉 の組み合わせ。安易な増員は、かえって遅れることがあります。
- 外れた事実より、外れた原因を特定して残りの見積もりを引き直すこと、そして実績工数を記録して次に活かすことが、長い目では効きます。
どれだけ丁寧に見積もっても、見積もりは予測である以上、外れることはあります。問題は外れること自体ではなく、外れたあとにどう動くか です。ここを間違えると、小さなズレが炎上案件に育ちます。
この記事では、見積もりが外れて工数超過や納期遅延が見えてきたときに、何から手をつけ、どう立て直すかを実務の手順で整理します。なぜ外れるのか という原因の構造そのものは、システム開発の見積もりはなぜ外れやすい？ズレる理由と実務での防ぎ方で詳しく扱っているので、本記事は「外れたあとの対応」に絞ります。
まず最初にやること: 早く認めて共有する
見積もりが外れそうだと気づいたとき、最初にやるべきは 事実を早く共有すること です。当たり前のようでいて、これが一番できていません。
人は「あと少し頑張れば取り戻せるかも」と考え、自分の中で抱え込みがちです。しかし、隠している間も時間は進み、選べる対策はどんどん減っていきます。遅延は、早く露見するほど打ち手が多く、遅く露見するほど打ち手が少ない のが鉄則です。
「取り戻せるか分からない」段階で共有してよいです。確定するまで黙る必要はありません。早期共有は無能の証明ではなく、リスク管理ができている証拠として扱うのが健全なチームです。
立て直しの全体手順
共有したら、感情論ではなく手順で立て直します。次の流れが基本です。
肝は2番目の 「残作業の再見積もり」 です。すでに超過したぶんを嘆いても前に進みません。ここから先、何がどれだけ残っているか を冷静に出し直すことが、現実的な着地点を決める起点になります。見積もりの出し方そのものは、見積もりとは？IT開発の工数・期間・費用の出し方と代表的な見積もり方法を参照してください。
立て直しの選択肢を比較する
着地させる方法は、おおむね次の5つです。たいていは1つではなく、組み合わせて使います。
| 選択肢 | 内容 | 向いている場面 / 注意 |
|---|---|---|
| スコープ削減 | 優先度の低い機能を今回は外す、または後フェーズへ回す | 最も即効性がある。何を削るかは発注側と合意が必須 |
| フェーズ分割 | 必須機能を先にリリースし、残りを次フェーズに分ける | 納期が固い案件向き。MVPの発想に近い |
| 納期延長 | スコープを保ったまま期限を延ばす | 外部都合(イベント連動等)が無い場合。交渉が必要 |
| 増員 | 人を追加して工数を増やす | 立ち上げコストで一時的にむしろ遅くなることがある |
| 品質・費用の再交渉 | テスト範囲や費用負担を関係者と再調整する | 原因の所在(どちら都合か)を踏まえて誠実に話す |
注意したいのが 増員 です。「遅れているから人を足す」は直感的ですが、追加メンバーへの教育や引き継ぎでチームの手が一時的に取られ、遅れているプロジェクトに人を足すとさらに遅れる という古典的な経験則(ブルックスの法則)が働くことがあります。終盤での増員は特に効きにくいので、安易に選ばないことが大事です。
原因別の打ち手
立て直しの中身は、外れた原因で変わります。
要件が膨らんだ
追加要望が積み重なったケース。変更管理 に乗せ、追加分は別見積もりにする。当初範囲と追加を切り分ける。
技術で詰まった
想定より難しかったケース。設計を見直す か、難所だけ小さくPoCで検証して方針を決め直す。
見積もりが甘かった
例外処理・移行・テストを軽く見たケース。残りを正直に再見積もり し、費用負担を誠実に交渉する。
特に多いのが「要件が膨らんだ」パターンです。小さな追加要望を都度サービスで受けているうちに、当初範囲を超えていた、というのはよくあります。この切り分けは追加開発と仕様変更の違い｜受託開発で見積もり直しになる判断基準が参考になります。
やってはいけない対応
立て直しのつもりが、傷を深くする対応もあります。
- 黙って残業・休日出勤で吸収する ── 一時的に取り繕えても、原因は残り、チームが疲弊して品質が落ちる。
- こっそり品質を落として帳尻を合わせる ── テストを省く、エラー処理を雑にする。後で障害として跳ね返る。
- 「気合で間に合わせます」で押し切る ── 根拠のない精神論は、関係者を安心させて問題を先送りするだけ。
- 原因をうやむやにして次に進む ── なぜ外れたか分からないままだと、次の見積もりも同じように外れる。
プロジェクト全体が崩れていく流れを避けたいなら、なぜITプロジェクトは途中からぐだぐだになるのかも、外れた見積もりがどこに波及するかを理解するのに役立ちます。
次に活かす: 実績を記録して精度を上げる
立て直しが済んだら、必ず振り返りをします。やることはシンプルで、見積もった工数と、実際にかかった工数(実績工数)の差分を記録する だけです。
- どのタスクで、どれだけズレたか
- ズレた原因は何だったか(例外処理の見落とし、要件の追加、技術の難所など)
- 次回、同種のタスクをどう見積もるか
この記録が積み上がると、このチームは、この種の作業を◯割ほど低く見積もる傾向がある といった補正が効くようになります。見積もりが外れること自体は避けられませんが、外れ方を学習して次の精度を上げる ことはできます。これが、長期的に最も効く対策です。
見積もりが外れたときの対応に関するよくある質問
Q. 見積もりが外れそうだと気づいたら、いつ報告すべきですか？
A. 「取り戻せるか分からない」と感じた時点で報告するのが理想です。確定するまで待つ必要はありません。遅延は早く露見するほど選べる対策が多く、遅く露見するほど打ち手が減ります。早期共有はリスク管理ができている証拠であり、責められるべきものではありません。
Q. まず何から手をつければよいですか？
A. 残作業の洗い出しと再見積もりです。すでに超過したぶんを嘆いても前に進みません。「ここから先、何がどれだけ残っているか」を具体的なタスク単位で並べ直し、現実的な着地点を出すことが起点になります。「だいたい何割」という感覚値ではなく、残タスクを具体化します。
Q. 遅れているので人を増やそうと思いますが効果はありますか？
A. 時期と内容によります。終盤での増員は、教育や引き継ぎでチームの手が取られ、かえって遅くなることがあります(ブルックスの法則)。増員が効くのは、独立して進められる作業がまだ多く残っている場合です。まずはスコープ削減やフェーズ分割を先に検討する方が現実的なことが多いです。
Q. 超過したぶんの費用は誰が負担するのですか？
A. 原因の所在によります。発注側の追加要望が原因なら追加見積もりとして発注側負担、受注側の見積もりの甘さが原因なら受注側が一定の負担をすることもあります。重要なのは、原因を切り分けたうえで誠実に交渉することです。契約形態(請負か準委任か)でも負担の考え方が変わります。
Q. 品質を落としてでも納期に間に合わせるべきですか？
A. 関係者に黙って品質を落とすのは避けるべきです。テスト省略やエラー処理の手抜きは、後で障害として跳ね返り、信頼も失います。どうしても間に合わない場合は、品質を落とすのではなく、スコープを削る・フェーズを分ける・納期を延ばすといった選択肢を関係者と合意したうえで選びます。
Q. 見積もりが外れたのは自分の責任でしょうか？
A. 一人の責任に帰結させない方が建設的です。見積もりは初期の不確実な情報で出すもので、要件の粗さや想定外は構造的に起きます。大事なのは犯人捜しではなく、原因を特定して残りを引き直し、記録して次の見積もりに活かすことです。責任追及の空気は、早期共有を妨げて事態を悪化させます。
Q. 同じ失敗を繰り返さないためにできることは？
A. 実績工数の記録が最も効きます。見積もった工数と実際にかかった工数の差分を、タスク種別ごとに残しておくと、「この種の作業は低く見積もりがち」といった自チームの癖が見えてきます。それを次回の見積もりに補正として反映すれば、外れ幅を徐々に小さくできます。