見積もりについて

原因を理解する

見積もりの失敗は単なる計算ミスではなく、ソフトウェア開発という行為に内在する 「不確実性」 という避けられない現実に根差している。

ソフトウェア開発における不確実性を理解するための最も強力なモデルが「不確実性のコーン（Cone of Uncertainty）」である 。これは単なるグラフではなく、プロジェクトの進行に伴う知識獲得のプロセスを可視化したものである。

プロジェクトの初期段階、すなわちコンセプト形成や要求定義が始まったばかりの時点では、見積もりのばらつきが非常に大きい。

プロジェクトが進行し、要求定義、UI設計、詳細設計といったフェーズを経るにつれて、未知の要素が既知の要素へと変化し、知識が蓄積されていく 。見積もりとは測定の問題ではなく、本質的には知識獲得の問題なのである。

したがって、初期段階におけるプロジェクトチームの主たる目標は、不正確な情報に基づいて完璧な数値を算出することではなく、プロトタイピングや技術調査といった活動を通じて不確実性を積極的に削減することにある 。

不確実性を分解する

「不確実性」という抽象的な概念をより具体的に理解するためには、その構成要素を分解する必要がある。主に以下の四つの側面に分類できる。

要求の不確実性 : プロジェクト開始時点において、クライアントやユーザーが本当に何を必要としているかは、しばしば曖昧で不明確である 。ソフトウェアは完成するまで目に見えないため、関係者は完成形を想像しながら要件を定義せざるを得ない 。その結果、開発途中で仕様変更が頻繁に発生し、当初の見積もりを無効化する。これは「何を創るべきか」という問題である。

技術的な不確実性 : プロジェクトで採用する技術が新しいものであったり、馴染みのないフレームワークを使用したりする場合、その技術が期待通りに機能するか、あるいは習得にどれほどの時間がかかるか予測が困難である 。また、外部システムとの連携や、既存コードに潜む技術的負債も、予期せぬ問題を引き起こす要因となる 。これは「どうやって創るか」という問題である。

工数の不確実性 : たとえ要求が明確で、使用技術が既知のものであっても、予期せぬバグの発生、特定の問題で長時間停滞してしまう、隠れた複雑性など日常的に発生する事象もある 。

外部環境の不確実性 : 市場の動向変化、競合の出現、ビジネス上の優先順位の変更など、プロジェクトチームの管理外にある要因も不確実性を増大させる 。また、外部ベンダーやAPIへの依存も、相手方の都合による遅延リスクを内包している 。

これらの不確実性は相互に関連し合っており、プロジェクト全体のリスクを増幅させる。見積もりとは我々が知らないことすら知らない領域を予測しようとする試みである。

アンチパターン

不確実性という理論的な背景を理解した上で、次に、それが現場でどのような具体的な失敗として現れるのかを分析する。

不適切なタスク分解: 見積もり失敗の最も一般的なプロセス上の原因は、作業の分解が不十分なことである。例えば「ユーザー認証機能」といった大きな単位で見積もるのは、ほとんど当てずっぽうに等しい。これを「ログイン画面UI作成」「APIエンドポイント設計」「パスワードハッシュ化処理実装」といった具体的で小さなタスクにまで分解することで、初めて論理的な見積もりが可能になる 。タスクの粒度が小さいほど、予測の精度は向上する 。

「隠れた作業」の無視: 見積もりは、プログラミングの時間だけを計上しがちである。しかし、実際にはプロジェクト管理、定例会議、コミュニケーション、コードレビュー、テスト、デプロイ、ドキュメント作成といった、直接的ではないが付随的な作業が総工数のかなりの部分を占める 。これらの「管理工数」や「調査・分析工数」を見落とすことが、計画と実績の間に大きな乖離を生む原因となる 。

スコープクリープ: プロジェクト開始時の見積もりが承認された後に、管理されることなく要件が追加・変更されていく現象である。これは予算やスケジュール超過の主要な原因となる 。問題は要件変更そのものではなく、変更が発生した際に、見積もりと計画を再評価・再合意するプロセスが機能していないことにある 。

精度をあげる

フィードバックループ

個人の経験を組織的な能力へと転換させるための具体的な仕組みが「学習ループ」である。これは、以下の4つのステップからなる継続的な改善サイクルである。

見積もる（Estimate）: 作業を開始する前に、一貫した手法を用いてタスクの工数や規模を見積もる。

追跡する（Track）: そのタスクに実際に費やされた時間や労力を正確に記録する。

分析する（Analyze）: プロジェクトの区切りやスプリントの終了時に、見積もりと実績値を比較する。ここでの最も重要な問いは「なぜ差異が生じたのか？」である 。予期せぬ技術的課題が原因か、要求が曖昧だったからか、あるいは頻繁な割り込みが影響したのか。この根本原因の分析が、次の改善につながる。

調整する（Calibrate）: 分析から得られた洞察を基に、将来の見積もりプロセスや基準を調整する。例えば、「この種のAPI連携タスクは、当初の想定より平均で30%多く時間がかかる」という知見が得られれば、次回の見積もりではその傾向を反映させることができる。

このフィードバックループを回し続けることで、見積もり能力は、経験則に基づいた漠然としたものから、データに裏打ちされた洗練されたスキルへと進化していく 。

分解の優位性

作業分解は、不確実性を削減するための最も強力な手段である。大きなタスクを見積もることは本質的に困難であり、誤差も大きくなる 。タスクを数時間から数日程度で完了できる単位まで細分化することで、見積もりの精度は飛躍的に向上する 。さらに、詳細なタスク分解は、リスクの早期発見、進捗の正確な追跡、そして作業の抜け漏れ防止にも寄与する 。

再見積もりの規律

見積もりは、プロジェクト開始時に一度だけ行われる静的なイベントではない。それは、プロジェクトの進行と共に進化し続ける、動的なドキュメントである 。プロジェクトが進み、不確実性のコーンが狭まるにつれて、新たな情報が手に入る。その情報を基に、定期的に見積もりを見直し、計画を更新する規律を持つことが不可欠である 。

next action

• 毎issueで以下のことをしてみよう

  • タスクを分解する

    • タスクを数時間から数日程度で完了できる単位まで細分化する

  • 見積もる: 作業を開始する前にタスクの工数や規模を見積もる。

  • 追跡する: そのタスクに実際に費やされた時間や労力を正確に記録する。

  • 分析する: プロジェクトの区切りやスプリントの終了時に、見積もりと実績値を比較する。ここでの最も重要な問いは「なぜ差異が生じたのか？」である 。

  • 調整する: 分析から得られた洞察を基に、将来の見積もりプロセスや基準を調整する。

  • 再見積もりの規律

    • 毎日新しい要素が増えたか確認する。