発生日：2026年1月24日。 ソフトウェアエンジニアのショーン・ゲーデッケは、従来のプロジェクト見積もりを批判する論考を発表し、見積もりは予測としてよりも、スコープ、資金配分、優先順位を選択するための組織的な手段として有用であることが多いと主張した。

ゲーデッケの中心的な主張は、重要なソフトウェアプロジェクトの大半は、作業の多くが発見のプロセスであるため、事前に正確に予測できないというものだ。エンジニアは、不慣れなシステムを調査し、過去の手法を見つけ、提案された変更が既存のコードにどのような影響を与えるかを判断しなければならない。そうした未知の要素がプロジェクトの労力の多くを費やす一方、確信を持って見積もれるのは、すでに理解されている作業だけである。

彼はそうした作業を、小規模で反復可能な変更と区別している。デプロイ手順に習熟しており、要求された修正が限定的であれば、エンジニアはコーディング、継続的インテグレーション、リリースに必要な既知の時間を合理的に合算できる。大規模システムの開発は異なる。事前に調査と実装を事実上行わない限り、計画によって不確実性を排除することはできない。

この論考は、見積もりをより厳密に見せるための一般的な試みにも疑問を投げかけている。チームが期間の代わりにTシャツのサイズで作業量を分類しても、経営側がその分類を時間や日数に換算するだけかもしれない。エンジニアは、最初の推測に余裕を持たせたり、経験則を適用したりすることもある。ゲーデッケの見方では、こうした慣行は根底にある知識不足を解消しない。

しかし彼は、企業が見積もりを単に放棄すべきだとは結論付けていない。代わりに、見積もりを事業上の意思決定へのインプットとして説明している。管理職や経営幹部はスケジュールを使い、どのプロジェクトに資金を投じるべきか、どれを中止すべきか、どの構想を縮小すべきかを決める。組織内の圧力も数値に影響を与え得る。優遇されている提案は、より短い見積もりへと誘導されるかもしれず、余力を確保することを意図した作業には、より大きな余裕が与えられるかもしれない。

この解釈は通常の順序を逆転させる。プロジェクトを完全に定義してから所要期間を把握するのではなく、チームは利用可能な時間予算から始め、それに収まる実装を選べる。ゲーデッケは、利用者がPDFと対話できる仮想的な機能を例に挙げる。数カ月あれば、チームはアップロード、セマンティック検索、画像抽出を構築できるかもしれない。1日しかなければ、抽出したテキストを言語モデルのコンテキストに直接入れるか、基本的なテキスト検索を提供するかもしれない。

実務上の教訓は、締め切りによって固定された解決策にかかる時間が判明するということではない。締め切りが、どの解決策を実現可能にするかを決めるのである。この枠組みによって不確実性が明示され、見積もりはスコープの交渉へと変わる。同時に、組織上の理由で選ばれたスケジュールを、エンジニアリング上の複雑さを正確に測定したものと取り違えてはならない、という警告も維持される。

ゲーデッケの論考は、実証研究ではなく実務家による主張である。その価値は、不確実な予測を客観的事実として提示するのではなく、制約を話し合い、未知の要素を明らかにし、作業を適応させるという、チーム向けのモデルを提示している点にある。