「スタッフエンジニアとしてどうやって見積もりしているか？」(How I estimate work as a staff software engineer)という記事。
・ソフトウェア開発の見積もりが正確にできるという考えは、業界の「丁寧な嘘」
・経験豊富なエンジニアほど、プロジェクトの正確な見積もりは不可能だと知っている
・Tシャツサイズによる見積もりは、時間に変換されることを避けるためのエンジニアの抵抗に過ぎない
・「見積もりを2倍にして20パーセント足す」といった計算式は、根拠のない気休め
・企業が非合理な見積もりを続けるのは、それが組織内で何らかの役割を果たしているから
・見積もりが可能なのは、作業が極めて小さく、内容が完全に理解されている場合に限られる
・現実のソフトウェア開発の多くは、未知の領域を調べる「研究」のようなもの
・コードを実際に調査するまで、何が必要になるかを事前に知ることはできない
・事前にすべてを設計する手法は、現代の複雑なシステムでは機能しない
・ソフトウェア開発の時間の90パーセントは、事前に予測できない未知の作業に費やされる
・見積もりは、エンジニアが効率的に開発を行うために作られるものではない
・実際には、見積もりはエンジニアではなく、上位の役職者の意向によって決定される
・エンジニアが長い見積もりを出せば短縮の圧力を受け、短すぎればバッファを積まれる
・見積もりは、マネージャーや経営層がプロジェクトの予算や継続を判断するための政治的道具である
・「作業内容から期間が決まる」のではなく、「期間から作業内容が決まる」のが実態
・期間の長短によって、エンジニアは採用する技術的なアプローチを無意識に調整している
・1週間しか時間がなければ、不完全でも動く簡略化された手法をエンジニアは選択する
・見積もりを始める前に、そのプロジェクトの背景や政治的な重要性を把握すると良い
・「どれくらいかかるか」ではなく「この期間なら何ができるか」を考えるのがプロの仕事
・既知の作業量よりも、コードベースの中にある「未知の不確実な領域」を警戒すべき
・具体的な完了日を断定せず、常にリスク評価とセットで回答を行う
・マネージャーに対しては、単一の数字ではなく、複数のプランとトレードオフを提示する
・不確実性を理由に見積もりを拒否することは、非技術者に判断を丸投げする行為
・マネージャーと協力して妥協点を見つけることは、エンジニアの背信行為ではない
・見積もりのやり取りを通じて、エンジニアは組織内での信頼を築ける
・普段から現実的な調整に応じているからこそ、本当に不可能な時に言葉の重みが増す
・プレッシャーのない環境でのみ通用する見積もり手法は、実戦では役に立たない
・既存の巨大なコードベース上での開発は、新規開発よりも見積もりが圧倒的に困難
・良い見積もりとは、ビジネス上の意思決定を支援するための実利的な情報提供ではないか
・見積もりは科学的な計算ではなく、組織内での期待値を管理するためのコミュニケーションの1つ
