「なぜかズレる」を放置していないか。見積もりの違和感を構造で分解する

見積もりは当たっているのに、プロジェクトはなぜかズレる。この違和感、放置したまま進めていないだろうか。

見積もりは合っているのに、なぜかズレる

見積もりは出している。数字も出している。根拠も、一応は説明できる。それでも、終わる頃にはズレている。納期が伸びる、工数が足りなくなる、途中で説明が変わる。この現象、珍しくない。むしろ「毎回起きている」と感じている人のほうが多いはずだ。

ここで一つ、違和感を言語化する。見積もりは“外している”のではなく、“ズレやすい構造の上で作られている”のではないか。

たとえば、見積もり時点では「3日」と置いた機能が、実装フェーズで「実は設計が複雑だった」と判明する。このとき、現場の感覚としては「想定外だった」となる。だが実態は違う。想定外なのではなく、想定できないものを、想定できる前提で数字にしている。ここに最初の歪みがある。

なぜズレるのか（3つに分解すると見える）

このズレは偶然ではない。構造的に発生している。分解すると、原因はこの3つに集約される。

① 不確定なものを、確定値として扱っている

開発初期は、仕様が固まっていない。UIは仮、API仕様は未確定、例外ケースは未整理。それでも見積もりは必要になる。ここで起きていることはシンプルだ。「未確定なもの」に対して「確定した数字」を置いている。

たとえば「検索機能」と一言で言っても、単純な一覧表示なのか、複雑な条件分岐があるのか、レスポンス要件が厳しいのか、これだけで難易度は倍以上変わる。それでも見積もりでは「検索：3日」と置く。この時点で、ズレる可能性は高い。

② 「時間」という不安定な単位で測っている

「この機能は3日くらい」。この表現は自然に見えるが、構造的には不安定。なぜか。時間は作業の本質ではなく、状況の結果だからだ。担当者のスキル、割り込みタスク、設計の完成度、レビューの質、これらすべてに影響される。同じ機能でも、ベテランは1日、中堅は2〜3日、新人は4日以上、こうなる。つまり時間見積もりは、機能だけでなく「人と状況」の影響を強く受ける。これは実務上は避けられないが、そのまま使うとズレの原因になる。

③ 見積もりが“説明可能な状態”になっていない

「なんとなくこのくらい」。この状態で見積もりが通ることはある。だが、その後が崩れる。なぜか。説明できない見積もりは、再現できないからだ。チーム内で認識が揃わない、顧客に納得されない、変更時に再計算できない。結果、ズレたときにこうなる。「想定より難しかったです」。これは説明ではない。後付けの言い訳になる。

見積もりの正体は「翻訳ミス」

ここで視点を変える。見積もりとは何か。作業の“難しさ”を、“数字”に翻訳する行為だ。この定義に立つと、見えてくるものがある。作業は正しい、でも数字がズレる。この状態は何か。翻訳がズレているだけだ。

たとえば日本語を英語に訳すとき、文脈を無視する、単語だけで訳す、こうすると意味がズレる。見積もりも同じだ。時間という単語で訳す、文脈（複雑さ・不確実性）を無視する、するとズレやすくなる。つまり問題は、作業の精度だけでなく、翻訳ルールにもある。

ポイント換算は「翻訳ルールの変更」

ここで出てくるのがポイント換算。これは単なる見積もり手法ではない。翻訳のルールを変えるアプローチだ。やっていることはシンプル。「時間だけで訳す」のをやめる。代わりに、相対的な重さで訳す。

ここでいう“重さ”は、単純な作業量ではない。複雑さ、不確実性、依存関係、失敗リスク、これらを含めた総量だ。

具体例で分解する。文言修正は1ポイント（影響範囲が小さい）、単純入力フォームは2ポイント（ロジックが単純）、CRUD処理は3ポイント（基本構造あり）、検索機能は5ポイント（条件・パフォーマンス考慮）、外部API連携は8ポイント（依存・エラー対応）、決済処理は13ポイント（失敗コストが高い）。ここで重要なのは、「何日か」ではなく「どれだけ不確実か」を測っていること。

なぜポイントにするとズレをコントロールしやすくなるのか

ここで初めて、「なぜ効くのか」を整理する。

① 個人差を排除できる
時間は人に依存する。ポイントは機能に依存する。これで基準が安定する。

② 比較が可能になる
「前回の検索機能と同じ5ポイント」。これが言えるようになると、過去と比較できる、判断が再利用できる、見積もりがブレにくくなる。

③ 不確実性を含めて表現できる
時間は確定値。ポイントは“幅”を持つ。例えば13ポイントは「大きい・読みにくい・ズレやすい」という意味を含む。

④ チームで合意できる
ポイントは議論できる。時間は議論しにくい。「3日です」よりも「これは5か8か」で話す方が差分が見える。

結果として、見積もりが「個人の感覚」から「チームの共通認識」に変わる。ここまでで見えてくるはずだ。見積もりの精度は「当てにいく」ことで上げるのではなく、「ズレを管理できる構造」にすることで結果的に上がる。

ポイントの決め方（ここで精度が決まる）

ポイント換算は、考え方だけでは機能しない。基準が曖昧なまま運用すると、ただの“別の感覚見積もり”になる。ここで精度が決まる。

まず前提。ポイントは「正確に当てるもの」ではない。チーム内で一貫していることが最優先。

なぜフィボナッチを使うのか。一般的に使われるのがフィボナッチ数列。1,2,3,5,8,13…理由は一つ。大きくなるほど不確実性が増えるから。1と2の差は細かく見積もれるが、8と9の差はほぼ判断できない。だから小さい領域は細かく、大きい領域は粗く扱う。

実務で使える基準の作り方。ここを曖昧にすると破綻する。やることは3ステップ。

① 基準となるタスクを決める（アンカー）。1ポイント＝文言修正、3ポイント＝CRUD一式、5ポイント＝検索機能など、まず基準となる重さを固定する。
② 各ポイントの意味を言語化する。3ポイント＝構造が既知でリスク低、5ポイント＝分岐あり検証が必要、8ポイント＝外部依存あり、13ポイント＝仕様の揺れが大きい、など。
③ 過去案件で補正する。「実績とズレを比較する」。3ポイントが0.5日で終わった、8ポイントが倍かかった、こうした差分を次に反映する。

ここでやっと「チーム固有の物差し」になる。
ここまで読んで、「なるほど」と思った人ほど危ない。

ここから先を外すと、結局また同じズレに戻る。
問題は「理解したか」ではなく、「現場で再現できるか」だ。
・どう分解するのか
・どう合意を取るのか
・どうズレを扱うのか
ここができない限り、見積もりは変わらない。

この先は、実際に現場で回すための具体的な手順に入る。