スタッフソフトウェアエンジニアとしての作業見積もり方法

2026年1月24日原文(seangoedecke.com)

概要

ソフトウェア開発における 見積もりの難しさと虚構 について解説
見積もりは 正確に行うことが不可能 であるという現実
見積もりの本当の役割は エンジニアではなくマネージャーのため である点を強調
見積もりが 政治的なツール として機能している実態
より現実的な見積もりのアプローチとその理由を提案

ソフトウェア見積もりの虚構

ソフトウェア業界では 「見積もりは難しいが不可能ではない」 という建前が存在
実際には 正確な見積もりは不可能 であるというのが経験豊富なエンジニアの共通認識
Tシャツサイズ（S/M/L）での見積もりなど、 時間見積もりを避ける工夫 が現場で多用
- しかし結局、 マネジメント層で時間換算 されてしまう現実
「初期見積もりを2倍にしてさらに20%加算」など、 実質的に根拠のない見積もり手法 が横行
「見積もり自体をやめるべきか？」という問いの背景

見積もりが不可能な理由

小規模で 完全に理解された作業のみ は正確な見積もりが可能
大半の業務は 不明点や未知の作業 が多く、事前予測は困難
大規模システムでは 調査・既存調査・影響範囲の把握 など、研究的要素が多い
伝統的な「全作業を分解して小さくすれば見積もれる」は 実際には機能しない
未知の作業が90%を占める ため、見積もり精度は根本的に制限される

見積もりの本当の役割

見積もりは エンジニアの効率化には寄与しない
- 実際、高生産性のチームは 見積もりを行わず成果を出している 事例が多い
見積もりはエンジニアが作るものではなく、 マネージャーや経営層の意思決定材料
プロジェクトの見積もりが長い場合、 上層部から短縮の圧力 がかかる
- 逆に短すぎる場合は バッファ追加や増額要請 が発生
見積もりは 組織内の政治的交渉ツール として機能
「技術的に不可能」な場合のみ、見積もりが 現実を伝える手段 となる

見積もりが仕事の内容を決める

通常は「作業内容→見積もり」だが、実際は 「見積もり→作業内容」 が現実
- 例：6ヶ月あれば大規模なPDF機能実装、1日なら簡易なアプローチを選択
締切や見積もりに合わせて 実装方法や品質が決定
エンジニアは 多数の解決策から現実的なものを選ぶ裁量 を持つ

現実的な見積もり方法

コードを見る前に 政治的背景や期待値 を把握
- プロジェクトへの プレッシャーの有無や重要度 を確認
既にある見積もりに合う実装方法 を逆算して検討
未知の要素が多いほど見積もりは大きくなる 傾向
マネージャーには リスク評価や複数案 を提示
- 例：「X, Y, Z全てが順調なら1週間だが、どれかで遅れる可能性が高い」
- 複数プラン（機能削減、他チーム支援、リスク選択肢）を用意
「どれくらいかかるか」ではなく「この期間で何ができるか」 を提示

よくある反論とその回答

「不確実性の中で見積もるのは嫌だ」 という技術者心理
- しかし、拒否すれば より技術に疎い人が代わりに見積もる ことになる
「マネジメントと妥協するのは裏切り」 という意見
- 実際は 協調的に現実的な落とし所を探る方が価値がある
「自分はそんな圧力を感じない」 という技術者もいる
- それは 組織の目立たない部署にいる場合が多い ため、普遍的なアドバイスにはならない

まとめ：見積もりの本質

一般的な認識：「作業内容を決めてから見積もり」→ 現実は逆
見積もりは マネージャー同士の交渉や意思決定のための道具
本当に不可能な場合だけ、 見積もりが現実伝達の手段 となる
信頼関係があってこそ、現実的な見積もりやリスク共有が可能

この内容は、 ソフトウェア開発における見積もりの現実と本質 を理解するための指針を示すものです。

Hackerたちの意見

俺が思うに、タイムラインに対するトップダウンの圧力の理由が理解されてない気がするんだよね。「この機能がいつできるかわからない」って言うと、営業の人たちが無知に見えちゃうからさ。だから、根拠のない日付を自信満々に繰り返す方がいいんだよね。そうすれば、後でエンジニアリングチームに責任を押し付けられるから。

└

営業の人、これについて何か言いたいことある？

└

俺は開発者で営業じゃないけど、現実的に考えようよ。会社が「1Mドル/年で契約したいけど、この機能が必要なんだ。いつできる？」って聞いてきたら、「うーん、わからない。できたらできた時に」なんて言ったら、会社は「じゃあ、できたら連絡してくれ。そしたらまた話そう」ってなるか、「うーん、じゃあ合わないね。さよなら」ってなるよ。その間に他のところに行って契約しちゃうかもしれない。約束された日付があれば、チャンスを維持できるし、場合によってはその場で契約できることもある。機能Xが日付Yまでにアプリに入るって条件で契約するんだ。ビジネス的にはそっちの方が全然いいよね、エンジニアには厳しいけど。

└

もし家の工事を頼んで、見積もりを出さなかったら、嬉しい？締切があって、「その時までに終わる？」って聞いたら「教えない」って言われたら、その人を雇う？見積もりなしの動きは、ソフトウェアエンジニアリングにとってすごく悪影響を与えてるよ。

└

タイムラインに対するトップダウンの圧力は、オーストラリアではSDEとオーバーヘッドコストで1日1500ドルくらいかかるから、4人のエンジニアで1ヶ月だと約10万ドルになるんだ。お金は予算から割り当てられて、計画されなきゃいけない。開発の努力はプロジェクトの財務的な viability や競争力に影響する。多くの社員がこれについて盲点がある気がする。ほかの状況ではお金を考えるべきなのに、自分の労力の日数になるとお金に感じないんだよね。それに、ソフトウェア自体も影響や結果があるし、日付が重要になることも多い。特に外部の約束がある場合はね。

└

これは営業に対して不公平だと思う。前にも君の主張をしたことがあるけど、現実的には多くのことがタイムラインに依存してるから、そうじゃない期待をするのは無理だよ。いつ怪我から回復してワールドカップに出られるの？子供の誕生日に必要なこの商品はいつ届くの？旅行に必要な車はいつ修理されるの？競合よりも早くこの機能を提供できるのはいつ？「できたらできた時に」っていうのは、多くの状況で満足できないし、場合によっては受け入れられないよね。

俺のちょっと皮肉を込めた基準を教えるね。- 内部プロジェクト（ユーザーに影響がないベンダー移行とか）なら、上司が納得するまで時間をかける。- ユーザーに影響があるプロジェクト（新機能追加とか）なら、見積もりのROIがプラスの間だけ時間をかける。- 外部との調整が必要なプロジェクト（クライアントやパートナーとの関係）なら、営業チームが納期を決めて、エンジニアリングチームがその日付に合わせてMVPの定義を変える。

製品を持ってみて、エンジニアリング以外の人たちに対してすごく同情するようになった。エンジニアは見積もりに対して反発するのが好きで、「できたらできた時に」っていうのがビジネスが機能するために受け入れられると思ってる。でも、機能している組織では、正しい見積もりに依存しているプロフェッショナルがたくさんいるんだ。俺たちにとって、6ヶ月のプロジェクトの正確な納期は必須だった。CXは優先度の高い顧客のオンボーディングを始めるためにそれが必要だった。マーケティングは広告資料を計画するために、それが必要だったし、展示会での約束もあった。プロダクトはQ3のロードマップに何を含めるべきかを理解するためにそれが必要だった。営業は契約を締結するためにそれが必要だった。俺は、これらの部門の責任者を尊敬できるビジネスで働けてラッキーだったけど、信じられないかもしれないけど、それが普通であるべきなんだ。課題は見積もりじゃなくて、大きなプロジェクトを一連のスプリントに分解するのは全然できることなんだ（基本的にはスプリントとウォーターフォールのハイブリッド）。遅延は通常、必須の中断やクリティカルバグに反応することから来る。そういうのは見積もりできないけど、解決策を協力して考えることはできる。機能を削減したり、日付を延ばしたり、追加の助けを呼んだり、頑張ったり。どんな決定でも、他の部門と協力して作業することが常に有益だった。

└

未来を知ることができたら便利だって言ってるけど、俺もそう思うよ。でも、もし過去に似たような仕事をしていなかったら、どれくらい時間がかかるか正確にはわからないと思う。実際、開発者は厳しい締め切りを求めてくる人たちを「扱わなきゃ」いけないし、予期しないことに備えて見積もりに余裕を持たせる必要がある。達成すべきマイルストーンを具体的に設定して、無理な期待を避けることが大事だね。マイルストーンを逃したら、積極的にコミュニケーションを取るべきだし、逃すことはあるからね。安心感を持たせるために日付を設定されるけど、そのために無駄な残業を引き起こすこともある。時には何を削るか交渉しなきゃいけないこともある。でも、プロジェクトの正確な内訳は、そのプロジェクトを実行することに繋がるんだ。他のことは大体が見積もりで、誤差が生じやすい。

└

半導体業界で社内ツールを作ってたことがあるんだけど、ハードウェアは締め切りを逃すことがほとんどなかったし、ソフトウェアも同じように運用されてた。計画通りに進むことは少なかったけど、何か問題が起きるとすぐにスコープを縮小したり、残業したり、数ヶ月前に日付を延ばす計画が立てられたりしてた。それから初めてのウェブSaaSスタートアップに入ったけど、そこでの間に締め切りを一度も守れなかったと思う。みんなそれが普通だと思ってたみたい。興味深いことに、それが失敗の理由だとは思わないけど、すごいカルチャーショックだった。

└

同意するよ。ソフトウェアエンジニアリングは、これがプロとして受け入れられている唯一の業界だと思う。もし政府の職員が橋が完成するのはいつか、いくらかかるのかを尋ねて、主導エンジニアが「正確に見積もるのは不可能だから、やらないよ。大きなプロジェクトだけど」と言ったらどうなるだろう。ソフトウェアの見積もりは非常に難しいけど、それが上達するのを諦める理由にはならないよ。

└

機能を削減し、日付を延ばし、追加の助けを呼び込むか、残業する。これらにはそれぞれ問題がある。会社は、製品をX個売れることを知っていて、その価格は$Yだ（Xは悪い推測の場合もあるけど、時には統計的な範囲がある - スペースの都合で無視するけど、これは重要だ！）。XかけるYは粗利益になる。機能を作るための総コストが高すぎると、全体をやるべきではない。機能を削減すると、売れる数や売れる価格に影響が出る（時には両方）。日付を延ばすことも影響がある - 競合他社から買う人が出てくるかもしれない（可能なら - 後ろに日付が延びるほど、競合がその機能をリリースする可能性が高くなる）。追加の助けを呼ぶと、総コストが上がる。さらに、彼らを呼び込むのが遅すぎると、納品が遅れることになる。残業は一番簡単だけど、従業員を疲弊させるから、長期的には悪い解決策になりがちだ。だから、企業は正確な見積もりが必要なんだ。これは会社を運営するためにオプションではない。正確な見積もりが不可能だとしても、その必要性は変わらない。私たちはそれが可能だと装っているけど、会社を運営するには必要で、なんとかやっている。でも、これは基本的な要件なんだ。

Hacker Newsで議論の続きを見る

ハクソク