仕事の見積もり方

Japanese Translation:

記事は、ソフトウェアプロジェクトの正確な期間見積もりが本質的に不可能であると主張している。
正確に予測できるのは、非常に小さく、十分に理解されたタスク（例：Svelte ユーザーフローを約45分でデプロイする）だけである。
プロジェクト全体の労力の約90％は未知数によって支配されているため、正確な見積もりは無意味であり、しばしば政治的目的に使われる。リーダーは資金調達、スコープ、または中止を決定するためにそれらを利用しており、本来の生産性ツールとしてではない。
著者はまず政治的文脈から始めること―リーダーが何を期待しているかを理解し―その上で、どの技術的アプローチがその課せられた見積もりに合致するかを決定することを推奨している。エンジニアは単一の具体的なタイムラインではなく、複数の計画を伴うリスク評価を提示すべきである。それぞれの計画はスコープと不確実性のトレードオフを示している。
与えられた時間内に実現可能なアプローチが存在しない場合、プロジェクトは不可能と宣言され、再交渉されるべきである。見積もり提供を繰り返し拒否することは信頼性を低下させる。
一部のエンジニアは小規模タスクに対して見積もりが解決可能だと主張するが、真の課題は未知数が支配的な大規模で既存のコードベースにある。読者のコメントでは、有料プロフェッショナルでも（架空の）見積もりを提供すべきだが、本当の正確さは達成不可能であると認識しているという声が上がっている。

この改訂版は、主要なポイントをすべて保持し、新しい情報を追加せずに曖昧な表現を避けつつメインメッセージを明確に伝えている。

ソフトウェア業界には、礼儀正しいフィクションが存在します。
それは次のようなものです：

ソフトウェアプロジェクトにかかる時間を見積もることは非常に難しいですが、不可能ではありません。熟練したエンジニアリングチームなら、時間と努力を重ねれば、仕事を完了するまでにかかる期間を学び取ることができ、それによって組織は良いビジネスプランを立てられます。

実際にはこれは誤りです。経験豊富なソフトウェアエンジニアなら、ソフトウェアプロジェクトの正確な見積もりは不可能だと知っています。この礼儀正しいフィクションとその明白な虚偽との緊張関係が、テック企業では多くの奇妙な活動を引き起こします。

例えば、多くのエンジニアリングチームは時間ではなく t‑shirt サイズで作業を見積もります。これはエンジニアにとって直接的な時間見積もりが明らかに馬鹿げているように感じるためです。もちろん、管理階層へ上がる際には、これらの t‑shirt サイズはすぐに時間（時間・日）に変換されます。

あるいは、真剣に良い時間見積もりをしようとするソフトウェアエンジニアは、「初期見積もりを二倍してさらに 20 % を足せばよい」という馬鹿げたヒューリスティックを持っています。これは結局「すべてを月単位で見積もればいい」と言っているのとほぼ同じです。

テック企業は見積もりをやめるべきでしょうか？私の指針の一つに、テック企業が馬鹿げたことを行うとき、それはおそらく良い理由であるという考えがあります。言い換えると、意味不明に思える慣行は、組織内でより基本的な、見えにくい役割を果たしている場合が多いのです。では、実際の見積もりの目的は何でしょうか？ソフトウェアエンジニアとしてそれをどうやって上手く行うのでしょうか？

見積もりが不可能である理由

まず最初に、私の基本前提をもう少し正当化したいと思います。すでに多くの人がこの点について書いているので、簡潔にまとめます。

時々、非常に小規模かつ十分に理解された作業では正確な見積もりが可能です。例えば「サービスをデプロイするのに 30 分かかる」と分かっており、「リンク内のテキストを更新」するよう求められたとき、実際には約 45 分で完了できると正確に見積もれます：変更をプッシュするのに 5 分、CI を待つのに 10 分、デプロイに 30 分。

しかし私たちのほとんどはこうしたケースではありません。ほとんどのソフトウェア作業は、十分に理解されていないシステム上で行われ、事前に何をすべきか正確に予測できません。大規模システムでのプログラミングは基本的に研究です：既存技術の調査、変更の影響を把握するために十分なマッピング、新たな知見の発掘などです。小さな変更でも、実際に何が必要かは「手を伸ばしてみる」まで分からないことが多い。

プロ‑見積もり論では、これらの疑問は計画段階で解決されるべきだと主張します。つまり、議論される各作業項目は正確に見積もれるほど小さくスコープ化すべきだということです。この答えには私は感銘を受けません。これはかつてのソフトウェアアーキテクチャの悪い時代への逆行であり、1 人のアーキテクトが全てを前もって設計し、プログラマは単に指示に従うだけだった頃です。現在では誰もそれを行いません。なぜなら、プログラマは実際にコードに触れているため、アーキテクチャ的決定権が与えられるべきだからです。もしそれが機能したとしても、見積もり不可能な部分は計画会議へとシフトされるだけであり、そこではコードを書いたり実行したりできないため、必要な質問に正確に答えることはほぼ不可能です。

結論として：ソフトウェアエンジニアリングプロジェクトは「既知の作業」ではなく「未知の作業」に支配されます。未知の作業は時間の 90 % を占め、しかもそれは正確に見積もることができません。従って、ソフトウェアプロジェクトを事前に正確に見積もることは不可能です。

見積もりはエンジニアから来るものではない

見積もりはエンジニアリングチームが作業をより効率的に完了する手助けにはなりません。私のキャリアで最も生産的だった数年間は、まったく見積もりを行わなかったチームで過ごしました。そこでは「必ずやるべきプロジェクト」に取り組んだか、「継続的に価値を提供するプロジェクト」に取り組んだかのいずれかでしたので、見積もりはほとんど必要ありませんでした。

実際、多くの場合エンジニアが見積もりを行うことさえないのです。ある VP が「このプロジェクトをやってほしい」と強く望むと、エンジニアリングチームはその見積もりを下げるよう圧力を受けます（または別のコンプライアントなチームに仕事が割り当てられます）。逆に、不要だと思われるプロジェクトや「将来未計画作業のスペース確保」を目的としたプロジェクトで見積もりが短すぎれば、チームはそれを伸ばすよう奨励されますし、マネージャーは 30 % のバッファを追加するだけです。

例外として、技術的に不可能か、本当に極めて困難なプロジェクトがあります。マネージャーがチームに「正しい」見積もりを出させる圧力を一貫して掛けない場合、それは上層部へ「実際にはやれない」というサインとして送られることがあります。賢明な VP やディレクターは、技術的に不可能なプロジェクトを避けようとします。

もうひとつの例外は、シニアリーダーがほとんど関心を持たない組織部門です。ゆるやかなバックウォータ―では、正式な見積もりプロセスが文字通り従われます。そこには VP やディレクターが介入して見積もりを自分の目的に合わせて調整する人がいないからです。このように、テック企業内でもエンジニアリング文化は大きく異なることがあります。再編成でこれらのチームが注目を浴びると、どんな影響があるか想像してみてください。

結局見積もりは組織内の非エンジニアに対する政治的ツールです。マネージャー、VP、ディレクター、C スタッフがプロジェクトの資金調達やキャンセルを決定します。

見積もりは作業を定義し、逆ではない

見積もりに対する一般的な考え方は「提案されたソフトウェア作業から始めて、それがどれだけ時間かかるかを計算する」というものです。これは完全に逆転しています。実際にはチームはまず見積もりを決定し、その見積もり内で何のような技術的作業が可能かを考えます。

例として、LLM チャットボットを開発していて、ディレクターが「PDF と対話できる機能」を実装したいとします。6 か月ある場合は堅牢なファイルアップロードシステム、PDF をチャンク化・埋め込みし意味検索するパイプライン、PDF ページを画像として抽出してフォーマットや図を捕捉する方法などを実装できます。一方で 1 日しかない場合は、クライアント側で PDF をテキストに変換して LLM のコンテキスト全体に渡す、あるいは「PDF を grep する」単純なツールを提供するといった簡易的手法が探されるでしょう。

これはコード行単位でも当てはまります。締切まで数週間・数か月ある場合は、新機能をエレガントに統合できるようリファクタリングを空想的に考える時間が取れます。しかし、数時間しかないときは実際に動くアプローチを見つけることに集中します。ソフトウェア問題には常に多様な解決策があります。エンジニアはそれを達成する方法についてかなりの裁量権を持っています。

私が作業を見積もる方法

では、私はどうやって見積もりますか？

まずコードを見る前に、できるだけ政治的コンテキストを収集します。

このプロジェクトにはどれくらいの圧力がありますか？
これはカジュアルな要望なのか、それとも「これを実装しなければならない」状況ですか？
私のマネジメントチェーンはどんな見積もりを求めていますか？

「CTO が一週間でやってほしい」と「あなたのチームに適した作業を探していた」という差異は大きいものです。

理想的には、すでに見積もりを手元に持った状態でコードへ入ります。「これを行うのにどれくらいかかるだろう」と自問する代わりに、「1 週間で実装できるアプローチは何があるか？」と質問します。

既知より未知への不安定さに多く時間を割きます。前述したように、ソフトウェアプロジェクトの大部分は未知です。この機能が触れるコードベースの「ダークフォレスト」が多いほど見積もりは高くなります（あるいはより具体的には、既知作業への制限を厳しくする必要があります）。

最後にマネージャーへリスク評価を持って戻ります。具体的な「4 週間プロジェクト」と言うことはありません。代わりに次のように説明します：

「X・Y・Z がすべて順調に進むと仮定すると、1 週間で完了できるかもしれませんが、少なくとも 1 つは予想以上に時間がかかります。」

理想的には複数の計画を提示します：

X・Y・Z を直接攻める。スムーズに進む可能性もあるが、膨張すれば 1 ヶ月かかる。
Y と Z をバイパスし、他のリスクを受け入れることで締切に間に合う可能性がある。
X・Y に精通した別チームから助力を得て、Z のみを担当する。

言い換えれば「作業を分解して時間を決める」ではなく、「マネジメントチェーンが求める見積もりに合致する技術的アプローチのセットを特定する」ことです。

そのセットが空の場合、つまりプロジェクト自体が不可能であれば、マネジメントは要件を変更する方法を検討すべきです。ただし「常に不可能だ」と言い続けると、マネージャーは別の人に見積もりを任せてしまいます。私は実際には多くの場合現実的な推定を行うことで信頼関係を築いているため、そうした状況は稀です。

いくつかの反論への対応

このアプローチを嫌がるエンジニアもいます。主な理由は、不確実性の中で見積もりを行うことを好まないからです。そのため、すべての未知の質問に事前に答えるよう求めます。「不安だ」と私が書いた Engineers who won’t commit や How I provide technical clarity to non‑technical leaders で言った通り、それは臆病な行為です。見積もりを拒否すると、非技術者に代わって誰かが見積もりを行うことになります。

また、エンジニアの中には「管理層に常に反論し続けるべきだ」と考える人もいます。私は Software engineers should be a little bit cynical で書いたように、それはある種の神聖な信頼を裏切る行為です。もしその道を歩みたいならそれは構いませんが、私個人としてはマネージャーと協力し合う方がやりがいがあります。

さらに、ディレクターや VP から見積もりの変更圧力をほとんど感じないエンジニアもいます。これは実際に機能不全な組織のサインかもしれません。しかし私が経験した組織では、そのようなエンジニアは「注目されていない」環境で働いており、圧力がほとんどなく自由にプロセスを採用できるケースです。問題はありません。ただしそのような環境の人々には、上層部からプレッシャーを受けている他のエンジニアへ役立つ助言をする資格はあまりないと考えます。

まとめ

ソフトウェアエンジニアリングにおける見積もりは一般的に誤解されています。

一般的なイメージ：マネージャーが技術プロジェクトを提案し、チームが「どれくらいかかるか」を算出、その情報で人員配置や計画を決定する。
実際には逆転している：マネージャーは既に見積もりを持ってチームへ渡し、チームはその見積もり内で実現可能な技術プロジェクトを検討する。

これは見積もりがエンジニアリングチームのためではなく、管理層同士の交渉ツールだからです。まれに「本当に不可能」なプロジェクトの場合、見積もりはその事実を上層部へ伝える手段となりますが、そのためには信頼関係が必要です。常に見積もりに反論するチームは、本当に不可能な提案に直面したときに信用されません。

私が見積もる際は、マネージャーが求める範囲を抽出し、その後コードを解析してその時間内で何ができるかを判断します。私は「2 週間」などのフラットな数値では戻りません。代わりにリスクごとに複数の選択肢を提示し、マネージャーにトレードオフを委ねます。

ソフトウェア作業を正確に見積もることは不可能です。プロジェクトはほぼ全て未知の問題に取り組むため、定義された時間で予測することができません。良い見積もりを行うには、実際には「既知」の要素をほぼ無視し、「未知」がどれだけあるか、そしてそれぞれの未知がどれほど怖いかを推測していく必要があります。