転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。
作業時間を記録しています。
見積と実績を突き合わせて、次の見積の精度を上げるためです。
記録の集計はAIに任せていて、ルールはAIと相談して決めています。
着手の時刻は「課題票を作った時刻」としていました。
機械的に取れるからです。
今回、AIから上がってきた数字は、こうでした。
| 課題票を作った | 11:52 |
| 作業を終えた | 21:50 |
| 差 | 約10時間 |
見積は2.2時間だったので、機械的に当てると4.5倍になります。
実態は違った
自分の感覚では、その作業に10時間近くかけた覚えがありません。
そう伝えたら、AIが記録から区間を切り分けました。
間に8時間半、この作業を一度も触っていない空白がありました。
課題票は「作業を始めるために作った」ものではありませんでした。
別の作業が終わったときに、見つかった問題をまとめて置いておく場所として作ったものです。
実際に手を動かしたのは、夜に戻ってきてからの2時間ほどでした。
区間を切り分けられた理由
手がかりは、記録用のコミットが時刻つきで残っていたことです。
| 区間 | 何をしていたか |
|---|---|
| 11:52 → 12:09 | AIが手順書を書いた（17分） |
| 12:09 → 20:34 | コミットが1本も無い。この作業は動いていない |
| 20:34 → 21:50 | 自分が実装〜提出（1時間15分） |
| 21:50 → 22:57 | 提出後に残っていた作業2つ（1時間7分） |
実作業は合わせて約2.2時間で、見積の2.2時間とほぼ同じでした。
「記録が無い区間」が、そのまま「動いていない区間」の証拠になりました。
ただしこれは、たまたまこの日が細かくコミットしていた日だったから成立したことで、いつもそうとは限りません。
ルールが仮定していたこと
「着手＝課題票を作った時刻」は、こう仮定していました。
「課題票は、作業を始める直前に作られる」
| 課題票の作られ方 | ルールは成立するか |
|---|---|
| 着手直前に切る | する |
| 見つけた問題の置き場として先に作る | しない |
ルールが間違っていたわけではありません。
想定していた作られ方が、1種類だっただけです。
直したつもりが、反対側にも同じ穴があった
AIの提案で、着手を「作業用のブランチを作った時刻」に変えました。
これなら、どちらの作られ方でも正しく取れます。
その日のうちに、終わりの側でも同じことが起きました。
AIからの指摘です。
終了は「提出した時刻」で測っていました。
でも提出したあとに、まだ作業が2つ残っていました。
提出物に含まれないサーバー側の設定と、本番での実測です。
合わせて1時間強を取り落とすところでした。
| 機械的に取ろうとしたもの | 崩れる理由 | |
|---|---|---|
| 開始 | 課題票を作った時刻 | 置き場として先に作られることがある |
| 終了 | 提出した時刻 | 提出物に含まれない作業がある |
開始と終了の両方に、同じ形の穴がありました。
結論: 終了はその場で書く
機械的に復元しようとすると、必ずどこかに穴があります。
開始は、「1回だけ起きるできごと」に対応させられました。
ブランチを作るのは1回です。
終了に対応するできごとは、存在しません。
「全部終わった」は、どこにも記録されません。
だから終了は、自分がその場で言うことにしました。
そして、記録に1行足します。
「この時刻は、何の時刻か」
そう書いておけば、次に読む人が「どう測ったか」を確かめられます。
正しい数字が、知りたいことを表していなかった
約10時間という数字自体は正しく、課題票から提出まで確かにそれだけ経っています。
でも知りたかったのは、この作業に何時間かかったかでした。
正しい数字が、知りたかったことを表していませんでした。
集計を任せていると、上がってきた数字をそのまま信じたくなります。
自動で取れる数字ほど、何を測っているのかを自分で疑ったほうがいいと思いました。
今回それができたのは、「そんなにやっていない」という自分の感覚があったからです。
