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

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

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

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

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

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

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

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

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

すべては営業とマーケティングが、競合の機能について聞いたことのある噂や機能を、6ヶ月のプロジェクト期限に詰め込むところから始まるんだ。6ヶ月って長いよね？ そんなに難しいことなのかな？ 失礼だけど、終わるときには終わるんだよ。

これは本当だけど、問題はエンジニアが証拠に基づいて過剰に推測するよう求められて、その推測を責任持ってやらなきゃいけないってことだよね。見積もりを立てるのが大嫌いなんだ、なんか不公平に感じるから。スプリントの見積もりは喜んでやるけど。

機能している組織では、正確な見積もりに依存しているプロフェッショナルがたくさんいるんだ。副作用として、実際にはそうじゃない。ちょっと皮肉な発言を許してほしい。経験豊富なプロたちは、自分たちの仕事を整理して、ソフトウェアの納品がどうでもよくなるようにしている、つまり他の誰かの問題になっている。ソフトウェアは届くか、届かないかのどちらかだよ。例えば、私の仕事は「ハードウェア」の技術開発で、複雑なサポートソフトウェアに依存している。私が取り組んでいるハードウェアには、テストを実行するためのAPIがあることを確認している。私の部署は、雰囲気コーディングに全力投球してる。顧客は待ってないよ、すべてのユーザーのマントラは「何も変えない」だから、古いソフトウェアの継続的なサポートを要求できる。新しいハードウェアに古いソフトウェアが組み合わさると「収益」としてカウントされるから、マネージャーたちは満足してる。

そうだね、見積もりの重要な部分は、プロジェクトを収めるためにどれくらいの（時間）ボックスが必要かではなく、ビジネスが耐えられる範囲内でどれくらいのプロジェクトを詰め込めるかってことなんだ。だから、必須、非常に望ましい、あったらいいな、に分ける必要がある。モジュール性と拡張性が必要なのはそのためだよ。すべてを一度に作ることができないし、どの部分がスコープ外になるかを予測することもできないから、レゴのような構造になるんだ。ちなみに、もしプロジェクトがどれくらいの作業になるかという丁寧な嘘を振り払って、異なる時間枠内での可能な納品物について考え始めたら、会話がもっと健全になるかもしれないね。

その通り。見積もりの原則は、時間・スコープ・コストのバランスを見つけることで、どの要素がどの次元に影響を与えるかを理解することが第一歩だね。

記事読んだ？ 実際にどうやってやるかを、すごく理にかなった方法で説明してるよ。

でも、もっと正確に見積もれるものもたくさんあるよ。複雑なソフトウェアプロジェクトに正確な見積もりをしたことがない私としては、ちょっと懐疑的になっちゃう。著者は見積もりが可能な例を挙げてたけど、すごく短い時間枠（数日以内）で簡単なプロジェクトのことだったと思う。もっと複雑なソフトウェアプロジェクトで、合理的なバリエーション内で見積もりができる例を聞いてみたいな。ただ、この記事のポイントは違う方向にあるようにも思う。良い時間見積もりを持っていることはあまり重要じゃないってこと。見積もりを求めるのは、管理層があなたに接近して、納期を伝えるためのちょっと変わった方法だから。

1時間/1日などが好きだけど、そうだね、これが私が見つけた唯一の方法だよ。どんな結果を出したいのかをはっきりさせて、アイデアを詳細に仕様化して、仕様を論理的なステップに分解して、各ステップをオーダーオブマグニチュードで分けてみて。それが見積もりになるよ。もし1日/1週間の範囲に分けられないなら、実際には計画がないし、現実的な見積もりを出せないってことだよ。

「どういう意味？」って感じだね。レベルって、橋を作るみたいな科学じゃなくて、ただの恣意的なもんだよ。お金だって恣意的だし、ビットコインの億万長者もいるしね。読書に関しては… https://thecodelesscode.com/case/215?topic=documentation