「2週間くらいでできると思います」と聞いていた機能が、3週間たっても終わらない。確認すると「想定外の作業が出てきて、あと2週間ほど」。結局リリースは1か月半後になり、顧客や営業に伝えていた時期をずらすことになった。こうしたことが一度ではなく、毎回のように起きている、というプロダクトは少なくありません。
見積もりがずれるたびに、「もっと正確に見積もってほしい」とエンジニアに伝えたくなるかもしれません。しかし、見積もりのずれの多くは、エンジニアの見積もる力よりも、依頼の仕方と、見積もりを受け取った後の計画の持ち方に原因があります。そしてその2つは、プロダクトの責任者として依頼する側が変えられる部分です。
本記事では、見積もりがずれる5つの原因を依頼する側から整理したうえで、それぞれへの対策と、ずれることを前提にしたリリース計画の立て方を解説します。
そもそも、見積もりは「ずれるもの」
対策に入る前に、前提をそろえておきます。ソフトウェア開発の見積もりは、どれほど経験のあるエンジニアでも、ある程度ずれます。
理由は、開発が「まだ誰も作ったことのないもの」を作る仕事だからです。同じ家を何棟も建てる工事とは違い、機能ごとに作るものが異なり、既存のコードとの組み合わせ方も毎回違います。作り始めてから分かることが、必ず出てきます。
一般に、見積もりの精度は、作るものの中身が決まるほど上がっていきます。アイデアの段階で出した見積もりと、画面や仕様が固まった段階で出した見積もりとでは、同じ機能でも確からしさがまったく違います。
したがって、目指すべきは「ずれない見積もり」ではありません。
- ずれ幅を小さくする（依頼の仕方を変える）
- ずれても計画が崩れないようにする（計画の持ち方を変える）
- ずれが分かった時点で、早く手を打てるようにする（進め方を変える）
この3つを組み合わせることが、現実的な対策になります。
見積もりがずれる5つの原因
見積もりがずれる原因は、依頼する側から見ると、次の5つに整理できます。
原因1：何を作るかが曖昧なまま見積もっている
もっとも多い原因です。「顧客の一覧をCSVで出せるようにしたい」という一文だけで見積もりを依頼すると、エンジニアは自分の想像で中身を補って見積もります。
ところが、実際に作り始めると、「出力する項目はどれか」「絞り込み条件は必要か」「1万件を超えたらどうするか」「権限によって出せる範囲を変えるか」といった判断が次々に出てきます。そのたびに確認が入り、答えによっては作業が増えます。
見積もりの時点でエンジニアが想像していたものと、依頼した側が頭の中で考えていたものが違っていれば、ずれるのは当然です。これは見積もりの誤りではなく、そもそも同じものを見ていなかったということです。
原因2：見積もりに含まれていない作業がある
エンジニアが「2週間」と答えるとき、多くの場合それはコードを書く作業にかかる時間を指しています。一方、機能をリリースするまでには、次のような作業もかかります。
- 仕様の確認や相談のやりとり
- テスト、不具合の修正
- コードのレビュー、リリースの準備
- 既存の似た機能への影響の確認
さらに、少人数のチームでは、エンジニアが見積もり対象の開発だけに時間を使えることはまずありません。顧客からの問い合わせ調査、本番の障害対応、別の機能の小さな修正、採用面接への同席など、割り込みの仕事が入ります。
「2週間分の作業」が「2週間後に終わる」とは限らないのは、このためです。見積もりが「作業量」を指しているのか、「完了日」を指しているのかを分けて話さないと、ずれが生まれます。
原因3：開発の途中で、やることが増えていく
開発が始まってから、「ついでにこれも」「顧客からこういう声もあったので」と追加の依頼が入るケースです。1つひとつは小さな追加でも、積み重なると当初の見積もりとは別物になります。
経営者がプロダクトの責任者を兼務していると、商談や顧客対応の中で新しい要望を聞く機会が多く、その場で開発チームに伝えたくなります。ところが追加の依頼をするときに、見積もりも一緒に見直すという手順が抜けがちです。結果として、作るものは増えたのに期限は元のまま、という状態になります。
原因4：大きすぎる単位で見積もっている
「新しい請求機能」「管理画面のリニューアル」のように、大きな単位のまま見積もると、ずれ幅も大きくなります。中身の見通しが立たない部分が多く含まれるためです。
大きな単位の見積もりは、足し算の抜け漏れも起きやすくなります。10個の作業のうち1つを見落としていても、全体の見積もりを見ただけでは気づけません。
また、長いコードの書き換えが必要な古い部分や、仕組みがよく分かっていない部分に手を入れる開発は、見積もりが特にずれやすくなります。こうした部分が多いプロダクトでは、見積もりの問題と、技術的負債の問題が重なっていることもあります。
原因5：見積もりが「約束」として扱われている
最後の原因は、数字そのものではなく、見積もりをめぐるやりとりにあります。
一度出した見積もりが、そのまま「約束した期限」として扱われる。ずれたときに「なぜずれたのか」を問われる。こうしたことが続くと、エンジニアは次の2つのどちらかの行動をとるようになります。
- 責められないよう、見積もりを大きめに言う
- 期待に応えようと、根拠のない短い見積もりを言う
どちらの場合も、見積もりは実態から離れていきます。特に後者は、依頼する側が「もう少し早くならない?」と聞いたときに起きやすいものです。経営者から直接そう聞かれると、エンジニアは「頑張ればできるかもしれません」と答えてしまいがちです。
さらに、途中でずれそうだと気づいても、それを言い出しにくくなります。ずれの報告が遅れることは、ずれそのものより計画に大きな影響を与えます。
原因ごとの対策
5つの原因に対して、依頼する側がとれる対策を整理します。
対策1：見積もりを依頼する前に、「完成した状態」を言葉にする
原因1への対策です。見積もりを依頼する前に、少なくとも次の3点を書き出して渡します。
- 誰の、どんな状況を良くするための機能か（目的）
- 何ができれば完成といえるか（完成の条件）
- 今回はやらないこと（範囲の外）
特に大切なのは、「完成の条件」と「やらないこと」です。「CSVで出力できる」だけでなく、「絞り込み後の一覧をそのまま出力できる」「出力できるのは管理者権限のユーザーのみ」「1万件を超える場合は今回は考慮しない」のように書くと、エンジニアが想像で補う部分が減ります。
すべてを最初から決める必要はありません。決まっていないことは「未定」と書いておけば、エンジニアはその部分の不確かさを見積もりに織り込めます。
対策2：「作業量」と「完了日」を分けて話す
原因2への対策です。見積もりを聞くときは、「作業としては何日分か」と「いつ頃終わりそうか」を分けて聞きます。
完了日を考えるときは、エンジニアが開発に使える時間が週のうちどのくらいあるかを一緒に確認します。問い合わせ対応や障害対応に毎週一定の時間がとられているなら、その分を差し引いて考えます。
見積もりに含まれている作業の範囲も確認しておきます。「この見積もりには、テストとリリース準備も入っていますか」と聞くだけで、後から「テストは別です」となる事態を防げます。
対策3：追加の依頼は、必ず「何かと入れ替える」
原因3への対策です。開発の途中で追加の依頼をするときは、次のどちらかを必ずセットで決めます。
- 期限を延ばす
- 他の何かを今回の範囲から外す
「ついでに」の追加を、期限を変えずに受け入れてもらうことは避けます。追加したいものがあるなら、その場で「これを入れるなら、何を外すか」「どのくらい延びるか」をエンジニアと話します。
少人数のチームでは、この入れ替えの判断を経営者がその場で下せることが強みです。追加の要望を聞いたら、まず顧客や営業には「検討します」と伝えて持ち帰り、開発チームと入れ替えを話してから答える流れをつくっておくと、途中で膨らむことを防げます。
対策4：数日単位まで分けてから見積もる
原因4への対策です。大きな機能は、1つの作業が数日程度に収まる単位まで分けてから見積もります。分ける作業そのものはエンジニアに任せてよいですが、「分けてから見積もってほしい」と依頼することは、依頼する側がはっきり伝えます。
分けていく途中で、「ここは調べてみないと分からない」という部分が見つかることがあります。その場合は、先に1〜2日だけ調べる時間をとり、その結果を見てから残りを見積もるという進め方が有効です。分からない部分を含んだまま全体の見積もりを出すより、ずれ幅を大きく減らせます。
分けておくと、途中で「今どこまで進んでいるか」も分かりやすくなります。全体の見積もりだけでは、ずれに気づくのが期限の直前になりがちですが、細かく分けていれば、最初の数日で「想定より時間がかかっている」ことが見えてきます。
対策5：見積もりを「約束」から「予測」に戻す
原因5への対策です。見積もりは、現時点での予測であって、約束ではないという前提を、チームの中で言葉にして共有します。
具体的には、次のような振る舞いを依頼する側が意識します。
- 見積もりを聞いたときに、その場で「もっと早くならないか」と聞き返さない。早めたい場合は、範囲を減らす相談をする
- ずれたときは、「なぜずれたか」ではなく「次に同じずれを防ぐには何を変えるか」を一緒に考える
- ずれそうだと早めに報告してくれたことを、はっきり歓迎する
経営者がプロダクトの責任者を兼務している場合、エンジニアにとっては「プロダクトの相談相手」であると同時に「評価者」でもあります。その立場から出る一言は、想像以上に重く受け取られることを意識しておくとよいでしょう。
ずれを前提にした、リリース計画の立て方
原因への対策でずれ幅は小さくなりますが、ゼロにはなりません。そこで、ずれても計画が崩れにくい持ち方をしておきます。
1点ではなく、幅で持つ
「2週間」という1点ではなく、「早ければ2週間、遅くとも4週間」のように幅で見積もってもらいます。エンジニアにとっても、1点で答えるより答えやすい聞き方です。
社外に伝える時期は、この幅の遅いほうを基準にします。顧客や営業に伝えるときは「〇月中旬から下旬」のように幅を持たせるか、遅いほうの時期で伝えます。早く終わった場合に前倒しで案内するのは問題になりませんが、遅れた場合の説明は信頼に響きます。
「必ず出すもの」と「間に合えば出すもの」を分ける
リリースの中身を、「これがないと出す意味がない」ものと、「あると良いが、なくても出せる」ものに分けておきます。
期限が近づいて間に合わないと分かったときに、期限を延ばすか、「間に合えば出すもの」を次回に回すかを選べるようになります。期限と範囲のどちらで調整するかを、事前に決めておくことで、直前の判断に迷わずに済みます。
見積もりと実績を記録し、次の見積もりに使う
見積もりと、実際にかかった期間を簡単に記録しておきます。表計算ソフトに「機能名・見積もり・実績・ずれた理由」を1行ずつ残すだけで十分です。
数か月分たまると、「このチームは見積もりのおよそ1.5倍かかることが多い」「外部サービスとの連携が入ると倍になる」といった傾向が見えてきます。その傾向を、次の計画に反映させます。見積もりを責める材料ではなく、計画の精度を上げる材料として使うことが大切です。
途中で見直すタイミングを決めておく
開発期間の3分の1ほどが過ぎた時点で、「当初の見積もりどおりに進みそうか」を確認するタイミングを決めておきます。2週間の見積もりであれば、数日たった時点で一度確認します。
この時点でずれが分かれば、範囲を調整する、期限を見直して関係者に伝え直す、といった手を打つ余裕があります。期限の直前に分かった場合と比べて、選べる手段が大きく違います。
よくある失敗
- 見積もりの数字だけを見て、前提を確認しない：同じ「2週間」でも、何を含んでいて何を含んでいないかで意味が変わります。数字と一緒に、前提を聞く習慣をつけます。
- ずれるたびに見積もりを細かく管理しようとする：毎日の進捗報告を求めたり、作業を時間単位で見積もらせたりすると、エンジニアの時間が報告に使われ、かえって開発が遅れます。確認は、決めたタイミングで行えば十分です。
- バッファを隠して上乗せする：エンジニアに伝えずに、社外向けの期限だけ長めに設定していると、チームの中で「本当の期限」が分からなくなります。幅を持たせる場合は、チームと共有したうえで行います。
- 見積もりの精度を個人の評価に結びつける：見積もりがずれたことを評価に反映させると、見積もりが大きめになり、計画全体がゆるくなります。
具体例：毎回ずれていた見積もりが、ずれにくくなったケース
従業員15名、BtoB SaaSを提供する創業5年目のスタートアップを想定した例です。経営者がプロダクトの責任者を兼務しており、エンジニアは4名でした。機能開発の見積もりは毎回のように1.5〜2倍に延びており、営業が顧客に伝えたリリース時期を何度もずらしていました。
直近3件の開発を振り返ったところ、次のことが分かりました。
- 見積もりの依頼は、Slackでの一言か、商談メモの転送がほとんどだった
- 3件とも、開発の途中で経営者から追加の依頼が入っていた
- エンジニアの時間のうち、毎週2割ほどが顧客の問い合わせ調査に使われていたが、見積もりには反映されていなかった
そこで、次の3つを変えました。
- 見積もりの依頼は、「目的・完成の条件・やらないこと」を書いた1枚のメモで行う
- 途中で追加したい要望が出たら、その場で開発チームに伝えず、週1回の開発定例で「入れ替え」として相談する
- 完了日は、作業量に「開発に使える時間は週の8割」を前提にして考え、社外には幅で伝える
最初の1か月は、メモを書く手間がかかると感じたそうです。しかし、メモを書く過程で「まだ決めていなかったこと」に経営者自身が気づくようになり、見積もりの前の質問のやりとりも減りました。3か月後には、見積もりと実績の差がおおむね2割以内に収まるようになり、営業が顧客にリリース時期を伝え直すことはほとんどなくなりました。
よくある質問（FAQ）
Q1. エンジニアの見積もりが毎回甘いのは、経験不足が原因ではないのですか。
経験による差は確かにあります。ただ、経験のあるエンジニアでも、依頼の中身が曖昧なままでは正確に見積もれません。まずは本記事の5つの原因のうち、依頼する側で変えられるものから見直し、それでもずれが大きい場合に、見積もりの進め方そのものをエンジニアと一緒に見直すのがよいでしょう。
Q2. ストーリーポイントなどの見積もり手法を導入したほうがよいですか。
チームが一定の人数になり、開発の進み具合を継続的に見たい段階では有効です。ただし、少人数のチームでいきなり手法を導入すると、手法の運用そのものが負担になることがあります。まずは「分けてから見積もる」「見積もりと実績を記録する」の2つから始め、必要を感じたら手法を検討する順序をおすすめします。
Q3. 受託開発会社や業務委託のエンジニアに依頼している場合も同じですか。
基本的な考え方は同じです。社外に依頼する場合は、見積もりがそのまま費用に直結するため、原因1の「何を作るかを決めてから見積もる」ことが、より重要になります。依頼の範囲を文書で合意しておき、途中の追加は「入れ替え」か「追加の見積もり」かを必ず確認します。
Q4. 1人目のPdMを採用したら、見積もりのやりとりは任せてよいですか。
任せる方向で進めるのがよいでしょう。依頼の中身を言葉にしてエンジニアに渡すことは、PdMの中心的な仕事の一つです。ただし、社外に伝えるリリース時期や、期限と範囲のどちらで調整するかといった判断は、しばらくは経営者とPdMで一緒に決めることをおすすめします。
まとめ
開発の見積もりがずれるのは、エンジニアの見積もる力だけの問題ではありません。依頼する側から見ると、(1)何を作るかが曖昧なまま見積もっている、(2)見積もりに含まれていない作業がある、(3)途中でやることが増えていく、(4)大きすぎる単位で見積もっている、(5)見積もりが「約束」として扱われている、の5つが主な原因です。
対策は、完成の状態を言葉にしてから依頼する、作業量と完了日を分ける、追加は入れ替えで行う、分けてから見積もる、見積もりを予測として扱う、の5つです。あわせて、計画を幅で持ち、「必ず出すもの」と「間に合えば出すもの」を分け、見積もりと実績を記録していくことで、ずれても崩れにくい計画になります。
まずは次に見積もりを依頼する機能について、「目的・完成の条件・やらないこと」の3点を書き出すところから始めてみてください。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
