25年エンジニアをやって気づいた、見積もりを「積分」してはいけない理由

見積もりがズレて、現場の空気がピリついている……。

リーダーを任されている方なら、一度はそんな夜を過ごしたことがあるのではないだろうか。

25年この仕事を続けてきて、ようやく見えてきたことがある。
それは、見積もりは単なる事務作業ではなく、
「数学」であり「物理」である、ということ。

どういうことか？
それは、実際に経験した現場の話で説明するけど、

ワシは数学や物理って、
包丁みたいなもんやと思うねん。

使えないやつが持つと、
普通に危ない。

でも、使えるやつが持つと、
現場が一気に変わる。

これ、三国志の軍師と同じやねん。

ただ剣を振る兵士になるな。
戦場全体を俯瞰する軍師になれ。

数学はそのための『兵法』やったんや

現場の崩壊

私がそれを実感したのは、
見積が崩壊した現場。

同じようなシステムなのに、
人によって数字が3倍～6倍もズレる。

結果どうなったか。

発注者の承認が下りない。
設計は止まる。
2ヶ月、動かない。

会議は重い。
誰も断言しない。
なぜその数字になるのか、誰も明確な根拠を説明できなかった。

誰も責任を取りたがらない。

「この見積、本当に合ってるんですか？」

その一言で、場が凍る。

ワシも、何も言えんかった。
現場は完全に迷子やった。

教科書的な方法ではうまくいかない。

最初にやったのは、
“普通に正しいやり方”やった。

タスクを細かく分けて、
1つずつ見積もる。

いわゆる、積み上げ。
数学で言うところの「積分」やな。

でも、これがハマらんかった。
むしろ、ズレが広がった。

なぜか？

不確定な条件が多すぎたからや。

情報が足りない状態で細分化すると、

・タスクの粒度がバラバラ
・1タスクの重さもバラバラ

細分化すれば、見積書の明細が増えて、
精度が上がったように見える。

ところが、実際のところ、
「タスク（仕様）の抜け漏れ」や「誤差」という『ノイズ』が
指数関数的に増えてるだけ。

これが積分の罠や

結果、

「ちゃんとやってるのにズレる」

という、
一番タチの悪い状態になる。

包丁で言えば、

目隠しして
みじん切りしようとしてる状態や。

そら危なすぎるやろ。

物理モデルがハマった

一晩中、見積資料と格闘した
でも、これという答えが見えない。

そこで一回、
発想を変えた。

細かくするのをやめた。

“まとめて見る”ことにした。
全体を型にハメる。これが「モデル化」や。

過去の案件を全部洗った。

そこで私は、過去の類似案件について
機能数（画面や帳票の数）
項目数
実工数

この関係を全部洗った。

そして、数式に落とした。

単純化して書くとこんな感じ。

「工数 ＝ a × 機能数（画面数・帳票数） ＋ b × データ項目数」

（※係数a, bは、自社の「標準工数」や過去の『実際の苦労』から導き出した秘伝のタレや）

画面や帳票の数は、要件として、割と早い段階で出てくる。
テーブルのデータ項目の数は、
業務知識があれば、それなりに正確に推測できる。
成長率・拡張性を考慮しておけばより安全。

要は、画面や帳票の数とデータの箱の数だけ数えりゃ、
あとは過去の経験則（係数）を掛けるだけでええんや、
と開き直ったわけや。

過去の案件を並べて、
『画面数・帳票数』と『DBの項目数』を軸にプロットしてみたんや。
そしたら、驚くほど綺麗な相関が見えてきた。

これは、見積もりを、
“数え上げ”から
“予測”に変えたちゅうことや。
要は、過去の似たような案件の『規模感』を数値化したんや

これがハマった。

最大で6倍ズレていた見積が、
幅があっても２倍以内に収まった。

この数式を元にEXCELでは
「工数見積算出シート」を作った。

誰がやっても
「過去の実績データ」という根拠に基づく見積
が出せるようになった。

そして、
何よりも、仕様変更での再見積もりが
めっちゃ楽になった。

細かいタスクを洗いなおす必要はない。
EXCELのシートで
画面や帳票の数を修正するだけやからな。

現場が、
やっと落ち着いた。

ここで気づいた。

ああ、これや。

細かく分けて積み上げるのは、
積分の考え方や。

でも今回は、それが使えなかった。

順番が逆やった。

まず、“全体の関係をモデル化する”

そこから必要なら、細かくしていく。

順番が逆やった。

同じ数学でも、
使い方を間違えると失敗して、
使い方が合うと成功する。

ここで、もう一歩だけ踏み込む。

なぜ、あんなに優秀な連中が集まっていて、
この簡単なことに気づけなかったのか？

理由はシンプルや。

学校では、「どう解くか」は教わる。
でも、「いつそれを使うか」は教わらない。

だから現場で、“問題の選び方”を間違える。

切り方は知ってる。
でも、切るタイミングを知らない。

これ、最初に言った話に戻る。

三国志の軍師の話や。

諸葛亮から学ぶ「知識の使いどころ」

三国志の天才軍師 諸葛亮も同じことをやっていた。

彼は、

兵法、政治、地理

といった理論を学びつつ、

戦場、組織運営、補給

といった現場で使い切った。

知識があったから強かったんじゃない。

「いつ使うか」を
選べたから強かった。

あのときのワシは、
軍師じゃなかった。
ただの兵士やった。

目の前のタスクを、
とにかく細かく切る。

でもそれは、

戦略じゃなくて、
作業やった。

軍師とは、エクセルを埋める作業員やない。
プロジェクトという現象を
『数式（モデル）』で捉え直すアーキテクトのことや。

微細なタスクに埋もれず、システムの『重心』を見極める。
それが数学を武器にするちゅうことや

一回、まな板ごと見ろ。
全体を見てから、動け。

数学や物理は、知識じゃない。
「使い方込みの道具」や。

もし今、

「これ、どう解くんや…」

って詰まってるなら、一回だけ立ち止まってほしい。

それは、細かく分ける問題なのか？
それとも、まとめて見る問題なのか？

結局、問われてるのは一つや。

「それ、いつ使うんや？」

明日の朝、デスクに座って真っ先にエクセルを開くのはやめようや。

まずはコーヒーでも飲みながら、
画面を1メートル引いて眺めてみてほしい。

細かなタスクの「行」を見るんやなくて、
プロジェクト全体の「塊」の形をぼーっと見るんや。

「これ、前のアレと似てへんか？」

その直感が、数式（モデル）の始まりや。

キーボードを叩く前に、まずは腕を組んで、
全体という名の「まな板」を眺める。

その5分が、あんたを「作業員」から「軍師」に変えるんや。

ふと気づけば、斜めに差し込んだ朝の光が、
使い古したキーボードのテカリを静かに照らしてる。
遠くで小鳥のさえずりが聞こえる、まだ誰もいないオフィス。

【関連記事】

「実務に関係ないけど、面白いから学ぶ」というモチベーション