シリーズについて：「職場の暗号辞典」は、エンジニアが職場で使う言葉の「本当の意味」を翻訳するシリーズです。
- Vol.1：設計レビュー編
- Vol.2：コードレビュー編
- Vol.3：障害対応・振り返り編
- Vol.4：スプリント・スクラムイベント編
- Vol.5：1on1編
- Vol.6：採用面接編
- Vol.7：見積もり編（本記事）
- Vol.8：技術選定編
はじめに
見積もりは、エンジニアとPMの間に横たわる永遠の断絶です。
「どのくらいかかりますか？」「う〜ん、2〜3日ですかね」「わかりました、では2日で」——この会話に見覚えがある人は多いはずです。
見積もりの会話には、どちらも悪くないのにすれ違いが起きやすい構造があります。エンジニアは不確実性を知っているから曖昧に言う。PMは期日を作らないといけないから確定させたい。その結果、「2〜3日」が「2日」になり、「1週間」が「5日」になる。
この記事では、見積もりの場でよく使われるフレーズを素直な日本語に翻訳します。
翻訳辞典：見積もり編
「2〜3日あれば」（エンジニアから）
翻訳： 順調にいけば2日、何か起きれば1週間かかります
「2〜3日」は、エンジニアが最もよく使う見積もり表現の一つです。「2日」ではなく「2〜3日」と言うのは、不確実性を正直に表現しようとしているからです。
しかしPMや上司が「2〜3日」を聞いたとき、多くの場合は「2日と少し」くらいで計画を立てます。エンジニアが「3日」のつもりで言っていたとしても、スケジュールには「2日」が入ります。
見積もりに「〜」が入っているとき、それは楽観値と悲観値の両端を表しています。
対処法： 「順調に進む場合は2日、依存する〇〇の確認次第では3〜4日になる可能性があります」と条件を明示する。「〜」を「〇〇の場合は△日、××の場合は□日」に変換するだけで、認識のずれが大幅に減ります。
「仕様が固まれば」（エンジニアから）
翻訳： 今の状態では見積もれません（固まってから聞いてください）
エンジニアからの最も正当な抵抗の言葉です。曖昧な仕様で見積もりを出すと、後で必ず「聞いていた話と違う」になります。それを防ぐために「仕様が固まれば」と言います。
しかしPM側からすると「固まるまで何もしないのか」「ざっくりでいいから教えてほしい」という焦りがある。「仕様が固まれば」と「ざっくりでいいので」のすれ違いは、見積もり会議で毎回発生します。
対処法： 「現状の仕様理解で出せるざっくり見積もりは〇〇日です。ただし〇〇と〇〇が確定したら再見積もりします」という形で、条件つき見積もりを先に出す。「仕様が固まるまで出さない」より「条件つきで今出す」方が関係者全員が動きやすくなります。
「工数は調整できます」（PMや上司から）
翻訳： 期日は変えないので、クオリティか範囲を削ってください
「工数を調整する」というのは物理的に不思議な言葉です。エンジニアの稼働時間を増やす（残業）か、やることを減らす（スコープ削減）か、品質を落とす（技術的負債の積み増し）か、どれかしかありません。
「調整できます」という柔らかい表現が、実は「削ってください」という強い要求を包んでいます。この言葉が来たとき、エンジニアは「何を削るか」を具体的に提案する側に回る必要があります。
対処法（エンジニア側）： 「調整するとしたら〇〇の機能を次のリリースに回すか、△△のテストカバレッジを下げるかです。どちらがよいですか？」と選択肢を明示する。「無理です」より「どこを削るか」を一緒に考える姿勢の方が建設的です。
「ざっくりでいいので」（PMや上司から）
翻訳： ざっくりではなく、計画に使える数字をください
「ざっくりでいい」と言いながら、その後のプロジェクト計画にその数字がガチガチに組み込まれることはよくあります。
「ざっくり」を「本当にざっくり」として受け取ると後で問題になります。しかし「ざっくりなので精度は低いです」と言っても、締め切りになると「あのとき〇〇日と言っていたじゃないですか」となる。
対処法： 「ざっくり見積もりで出しますが、正式な計画には使わないという認識で良いですか？」と確認する。この一言で後から「言っていた話と違う」になるリスクが下がります。
「前回と似たようなものですよね？」（PMや上司から）
翻訳： 前回と同じ工数でできますよね？
「似たようなもの」という評価は、外側から見たときに成立します。「ユーザー一覧画面」と「商品一覧画面」は確かに似ていますが、内部の複雑さは全然違うことがある。
ページネーション、権限チェック、検索ロジック、APIの設計、既存コードとの絡み——見た目が似ていても実装コストが違う理由は山ほどあります。
対処法： 「見た目は似ていますが、〇〇の部分が新規対応になるため前回より△日程度多くなります」と差分を説明する。「違います」だけでなく「どこが違うか」を言うと、相手が納得しやすくなります。
「それって難しいですか？」（PMや上司から）
翻訳： 難しいと言わないでほしいです
「難しいですか？」という質問は、答えを求めているように見えて、「難しくない」という答えを期待していることが多い。
「難しいです」と答えると「どうすれば難しくないですか？」となり、「難しくないです」と答えると「ではやってください」となります。エンジニアにとってはどちらに転んでも仕事が増える質問です。
対処法： 「技術的な難易度ではなく、工数の観点でお答えすると〇〇日かかります」と、「難しいかどうか」を「何日かかるか」に変換して答える。感覚的な難易度の話より工数の話にした方が建設的です。
「他の作業と並行でできますか？」（PMや上司から）
翻訳： 両方やってください
「並行でできますか？」は「できますか？」という疑問形ですが、「できます」という答えを前提にしていることが多い。
人間の並行作業には限界があります。コンテキストスイッチのコスト、割り込みによる集中力の分断——「並行」は理論上可能でも、両方の品質が下がるか、両方の期日が延びるかのどちらかです。
対処法： 「並行でやるとどちらも〇〇日ほど延びます。優先度の高い方を先にやる場合、もう一方は〇〇日後着手になります。どちらがよいですか？」と選択肢を提示する。
「見積もりが外れたのはなぜですか？」（振り返りで）
翻訳： 次からもっと正確に見積もってください（責めているわけではない……かもしれない）
見積もりが外れる理由は大体決まっています。仕様変更・依存する作業のブロック・予期しない技術的な問題・自分の理解不足——のどれかです。
「見積もりが外れた」を個人の責任として処理すると、次回から見積もりにバッファを大量に積むようになります。それはそれで組織にとって非効率です。
対処法： 「外れた理由は〇〇でした。次回からは××を見積もりに含めます」と原因と対策をセットで言う。「すみません、読みが甘かったです」だけで終わると、同じことが繰り返されます。
なぜ見積もりに暗号が生まれるのか
見積もりは不確実性を確実性に変換することを求められる場です。
エンジニアは「わからない」ことを知っているから曖昧に言いたい。PMは「わからない」ままでは計画が立てられないから確定させたい。この構造的な矛盾が、見積もりの場に暗号を生み出します。
解決策は「不確実性を正直に扱える文化」を作ることです。「見積もりが外れた」ことを責めるのではなく、「どんな不確実性があったか」を学習の素材として扱うチームは、長期的に見積もり精度が上がります。
見積もりの暗号を減らすために
エンジニアとして：
- 「〇〇日」ではなく「楽観〇日・悲観〇日、理由は〇〇」という形で出す
- 「仕様が固まれば」と言う代わりに、条件つき見積もりを今出す
- 見積もりが外れたときは原因と対策をセットで報告する習慣をつける
PMや上司として：
- 「ざっくりでいい」と言ったなら、後から「あのとき〇〇日と言った」と使わない
- 見積もりが外れても責めるより「次に活かす」文化を作る
- 「工数を調整する」ときは「何を削るか」の選択肢をエンジニアと一緒に考える
おわりに
見積もりの言葉を翻訳すると、ほとんどが「不確実性への対処」から来ていることがわかります。
エンジニアが「2〜3日」と言うのは正直な不確実性の表現です。PMが「ざっくりでいい」と言うのも、本当に計画を立てたいからです。どちらも悪くないのに、言葉のすれ違いが積み重なって摩擦になります。
暗号を使わなくていい関係は、「見積もりが外れても責めない」文化から始まります。
次回はVol.8：技術選定編。「枯れた技術なので安心です」「コミュニティが活発です」「うちのチームに合っています」——技術選定の本音を全部出します。
シリーズ一覧：職場の暗号辞典
- Vol.1：設計レビュー編
- Vol.2：コードレビュー編
- Vol.3：障害対応・振り返り編
- Vol.4：スプリント・スクラムイベント編
- Vol.5：1on1編
- Vol.6：採用面接編
- Vol.7：見積もり編（本記事）
- Vol.8：技術選定編