見積に「理解する時間」が入っていなかった

転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。

制作中の自作アプリの工程管理の記録から。
Web 制作の実務では工程ごとに見積を出しているので、その感覚で立てた計画の話です。
前回の「速さを選ぶと説明できないコードが残る」と同じ数字を、今度は見積の側から見ます。

4工程連続で見積を下回っていた

順調でした。「自分の見積は保守的すぎるのかもしれない」と思っていました。

実装工程で逆転した

見積の時間を使い切ったうえで、さらに8割増しです。

最初の仮説は外れていた

「準備・設計は速い／実装は遅い」だと思いました。でも中を見ると違いました。

手順3（初めて Server Action を書く）: 4.8倍
手順4（proxy と matcher だけが新しい）: 2.2倍

同じ「実装」なのに倍率が半分以下になっています。

効いていたのは既知か未知か

手順4で新しく踏んだのは proxy と matcher だけ。
'use server' ／ Server Action ／ <form action> は
手順3で覚えたものを使い回せました。

仮説を書き換えました。「準備は速い／実装は遅い」ではなく「既知は速い／未知は遅い」。

見積が数えていなかったもの

手順書の「1.0h」はコードを書く時間の見積でした。
学習しながら実装する工程では、理解する時間が別の変数として乗ります。

実務の見積が当たっていたのは、そこが全部既知だったからだと思います。

仮説は数字で裏づけられた

工程5の残りの手順が終わりました。倍率はこうなりました。

4.8 → 2.2 → 1.5 → 0.33 → 0.25。

さらに、手順5の 2.0h の中身を見ると、新しい概念でつまずいた時間は1分もありません。
時間を使ったのは3件とも「環境と手順」でした（環境変数のキー名違い／ログを探す場所を間違えた／
コードの貼り付け位置）。

工程としては 6h の見積に対して 10.8h で大幅に超えています。
でも中を分けると、超えた分はほぼ手順3と4に集まっていました。

落としどころ

「見積が甘かった」ではなく「見積が数えていない項目があった」。
既知の作業に対する見積は当たる。未知が混ざると、混ざった分だけ伸びる。

それなら、未知の量を先に数えるほうが精度が上がるのではないか、というところまでです。
次の工程からは、手順書に「新しく踏むもの」の列を先に書くことにしました。