- ソフトウェアプロジェクトの正確な期間見積もりは不可能であり、ほとんどの作業は予測不能な「未知の仕事」に支配される
- 見積もりはエンジニアではなく経営陣の政治的ツールとして使われ、プロジェクトの優先順位や資金配分を決める役割を担う
- 実際には 見積もりが作業を定義しており、チームは与えられた期間内で可能な技術的アプローチを見つける形で働く
- 効果的な見積もりのために、エンジニアは 政治的文脈の把握、未知のリスク評価、複数の実行シナリオの提示に集中すべき
- このアプローチは 正確さよりも信頼と現実的な協業を重視し、組織内の意思決定構造を理解するエンジニアリング能力を強調する
ソフトウェア見積もりの虚構
- 業界には、熟練したチームが十分な努力を払えば 正確なスケジュール予測が可能だという「礼儀正しい虚構」 が存在する
- 実際には、ほとんどのエンジニアが 正確な予測は不可能だと認識している
- 一部のチームは Tシャツサイズ方式で見積もるが、これは結局時間単位に換算されて管理層に伝えられる
- 「初期見積もりの2倍に20%を足せ」のような 非現実的なヒューリスティックが使われることもある
なぜ見積もりは不可能なのか
- 小さく明確な作業は予測可能だが、ほとんどのプロジェクトは 不確実で複雑なシステムの中で行われる
- 例: 単純なリンクテキストの変更は45分と予測できても、大規模なシステム変更は不可能
- プログラミングの大半は 探索的な研究行為であり、事前計画だけでは必要な作業を把握できない
- 過去の 中央集権的なアーキテクチャ設計方式は失敗しており、実際のコードを扱う開発者が意思決定すべき
- 結果として 既知の作業は全体の10%にすぎず、残り90%は未知の領域のため見積もれない
見積もりはエンジニアではなく経営陣の道具
- 見積もりは チームの生産性向上とは無関係であり、多くの効率的なチームは見積もりなしでも働いている
- 経営陣は 望む結果に合わせて見積もりを調整しようとし、長いスケジュールには短縮圧力が、短いスケジュールにはバッファ追加が求められる
- 技術的に不可能なプロジェクトだけが、例外的に現実的な判断を引き出せる
- 組織内で関心の低い領域では、形式的な手続きがそのまま維持されることもある
- したがって見積もりは 非エンジニアがプロジェクトを選択・中止するための政治的手段として機能する
見積もりが作業を定義する
- 一般的な認識とは異なり、作業ではなく見積もりが先に決まり、それに合わせて技術的アプローチが決まる
- 例: 「PDFと会話する」機能を6か月で実装する場合と1日で実装する場合では、アプローチはまったく異なる
- 時間的制約がコード設計の深さと品質を決め、エンジニアは与えられた期間内で可能な解法を選ぶ
実際の見積もり方法
- まず 政治的文脈を把握し、プロジェクトの重要度と期待されるスケジュールを理解する
- その後 すでに決まっている期間を基準に可能なアプローチを探る
- 未知の領域 (unknowns) が多いほど見積もりは大きくなり、アプローチの範囲を狭める必要がある
- 最終的には 正確な期間ではなく、リスク評価と複数の実行シナリオを提示する
- 例: すべての要素を自力で解決する、一部を迂回する、別チームに支援を求める、など
- エンジニアの役割は「どれくらいかかるか」ではなく 「与えられた期間で可能な方法は何か」 を見つけること
反論と対応
- 一部のエンジニアは 不確実な条件下での見積もりを避けるが、それは非技術者が代わりに見積もることを招く
- 経営陣と協力せず 常に対立する姿勢は非生産的であり、信頼を弱める
- 圧力を感じないチームは、単に 組織内で関心の外にある領域にいる可能性が高い
結論
- 実際には 管理者がすでに念頭に置いている期間を持ってチームに接し、チームはその中で可能な技術的解法を探す
- 見積もりは 経営陣同士の交渉ツールであり、不可能なプロジェクトだけが例外的に現実を伝える手段となる
- 正しい見積もりは 正確な数値ではなく、リスクと選択肢の提示を含むべき
- ソフトウェア作業の正確な見積もりは不可能であり、成功する見積もりは未知のリスクを認識し、それを管理する能力にかかっている
2件のコメント
> まず政治的な文脈を把握して、プロジェクトの重要度と期待されるスケジュールを理解する
> その後、すでに決まっている期間を基準に、可能なアプローチを探る
おお
Hacker Newsのコメント
少し冗談交じりの自分のプロジェクト見積もり基準表を共有する
社内プロジェクト（例: ベンダー移行などユーザー影響なし）は、上司を納得させられるだけの期間を取る
ユーザーに影響するプロジェクト（例: 新機能追加）は、ROIがプラスである限り進める
外部パートナーとの協業が必要なプロジェクトは営業チームが納期を決め、エンジニアリングチームはその日程に合わせてMVPの定義を少し調整する
なぜ誰もplanning pokerやstory pointの話をしないのか不思議だった
完璧ではないが、かなり良い方法だ。すべての作業はスプリント内で終わるべきで、大きければ分割しなければならない
チーム全員がポイントに合意する必要があり、その過程で本当の議論の価値が生まれる
数か月たつとチームの速度が安定し、±10%程度の精度で予測できるようになる
魔法ではないが、継続的に価値を届け、毎スプリントごとに費用対効果を見直せるようにしてくれる
新しく加わった人は、同じチケットでも2倍以上かかることがある
そのうえ組織はPRレビューを24時間以内に終えろ、のようなルールを作って現実との乖離が生まれる
開発者とQAが一緒に複雑さを比較しながら見積もり、QAはテスト難易度や自動化可能性を評価する
そのおかげで開発速度指標が安定し、バージョンごとの見積もりもかなり正確だ
チーム全体が最小単位について共通理解を持ち、それを時間に変換できるときだけ意味がある
結局その時点では単に時間を使えばよいので、ポイント自体が不要だ
私は「2時間、2日、2週間、2か月、2年」の単位で問いかける信頼区間ベースの見積もりをする
幅が広すぎるならさらに分割し、それが無理なら情報収集に時間を使う価値があるか判断する
そうでなければプロジェクトを破棄する
結果を明確に定義し、アイデアを詳細なステップに分けると現実的な見積もりが可能になる
1日や1週間単位に分解できないなら、まだ計画が不足している状態だ
こういう場合は、別のアプローチを試しながら学び続ける過程なので見積もりは難しいと思う
単純な長さの見積もりより、行動中心で考えられるようになる
以前、単純にパスワードを平文からハッシュへ移行する作業を1スプリントで見積もったが、実際には6か月かかった
顧客がパスワードを大文字小文字を区別せず使っていたことを動画で見せてくれて初めて分かった
そのうえPHPイメージが削除されてビルド失敗まで重なった
見積もりはいつだって楽しい冒険だ
実際のプロジェクトデータに基づいて予算超過率の統計を示している
ITプロジェクトは平均73%超過で、原子力貯蔵施設・オリンピック・水力発電に次いで悪い
ITプロジェクトの18%が50%以上超過し、それらの平均超過率は447%だ
結局、ほとんどの産業で見積もりは構造的に楽観的にならざるを得ないことを示している
多くのエンジニアやマネージャーが過去プロジェクトのメトリクスを基に見積もっていないのが不思議だ
チームのスループットデータを見れば、おおよその期間と**信頼区間（例: 90%、70%、50%）**を計算できる
こうすれば外部ステークホルダーにも確率的な文脈を提供できる
だが多くのエンジニアはこれを事務的負担だと感じる
良い実践は区間見積もりを使うことで、PERT方式のように最良・予想・最悪の3つをモデル化する
優秀な技術者ほど自分の時間見積もりに過信する傾向がある
各自で見積もった後に20%補正する方法がかなりうまく合っていた
経営陣が日程を押しつけてくるなら、その時間内で可能な範囲を説明するか、スコープ明確化後の再見積もりを提案すべきだ
参考: PMI PMP、PMBOKの Lessons Learned Repository
予測は誤差を通じて学ぶが、指示はむしろ生産性への圧力につながる
私は見積もりを交渉プロセスとして見ている
自動車のトリムのように、Economy、Mid-tier、Luxuryの3つの選択肢を提示する
ビジネス側はいつも3番の機能性と1番の予算を欲しがるので、結局は私が状況に合わせて調整する
#1プランを用意しておけば危機時にすばやく切り替えられ、交渉中に近道の代償を可視化できる
そのおかげで、動揺したPMや役員の非合理的な判断を何度も避けられた
私はFAANG級の大規模分散システムを扱っているが、ここでは正確な見積もりはほぼ不可能だ
unknown-unknownsが多すぎて、プロトタイプだけでも膨大なデータと時間が必要になる
だから見積もりよりも不確実性の管理に焦点を当てる
最も信頼できる方法は類似プロジェクトとの比較だ
「これはプロジェクトXより20%複雑だから20%長くかかる」といった具合に
ただし、そのためには過去プロジェクトの実際の所要データを継続的に記録しておく必要がある
最初は「見積もりは不可能だ」という主張に反対しようと思ったが、実際には組織内での役割のほうが重要だと気づいた
チームが見積もり対比のキャパシティを見て不可能だと言っても、日程は変わらない
結局はスコープ縮小や品質の妥協で合わせることになる
だから「見積もりは無意味だ」という言い方のほうが正確かもしれない
見積もりの核心は曖昧さ（ambiguity）だと感じる
UIの微調整のように小さく見えても、実際にはやりながら学ぶ作業が多い
逆に大きな変更でも、明確に定義されていればすぐ終わる
LLM時代には、変化の大きさよりも不確実性の度合いが所要時間を決める要素になるだろう