アプリを作るとき、工程ごとに作業時間を記録しています。
見積が12時間の工程で、実際に何時間かかったかを残す。あとで見積の精度を
確かめるためです。
今日その記録で、時刻が9分ずれました。
体感と実測が9分ずれました
自分の体感では、午前は9時15分から11時20分まででした。
実装を手伝っているAIのほうが、実際の時刻を測っていて、
中断は11時11分と出ました。
誤差の範囲です。ただ以前、合計は合っているのに内訳が違っていたことがあったので、
そのまま流さずに確かめました。
ログのタイムスタンプで照合できました
AIとの対話は、やりとりが全部ファイルに残っています。
そこに時刻が入っているので、今日のぶんを抜き出しました。
- 今日の最初のやりとり：9時22分59秒
- 午前の最後：11時11分16秒
- 午後：14時26分から15時20分
11時11分は一致しました。 体感の11時20分が9分長いほうでした。
ここで止めなくてよかったです
数字が出たので、そのまま採用しようとしました。
9時23分が最初のやりとりなら、開始は9時15分ではなく9時23分では？
そうではありませんでした。
ログに残るのはAIに話しかけた時刻だけです。エディタを開いて前日書いたコードを
読んでいた時間は、1行も残りません。
9時15分を否定する材料になっていませんでした。
もっと危なかったのは、途中の空白でした
ログを見ると、9時53分から10時7分まで14分の空白がありました。
これを「休憩」と読んで引くと、作業時間が14分短くなります。
でもこの14分は、たぶん自分が黙々とコードを書いていた時間です。
いまの進め方は、AIに手順書を書いてもらって、実装は自分でやるという形です。
自分で書いている間は、AIに話しかけません。
つまり手を動かしている時間ほど、ログには残らないということでした。
対話ログは下限しか示さない
数え方を並べてみました。
| 数え方 | 合計 |
|---|---|
| 体感のまま | 2時間54分 |
| 終わりだけ直す | 2時間51分 |
| ログの最初から最後まで | 2時間41分 |
| ログの空白を引く | 2時間27分 |
いちばん下を採ると、24分ぶんの実装が消えます。
採用したのは上から2番目です。終わりの時刻だけ直して、始まりは体感のまま。
その計算も、1回間違えました
上の「2時間51分」は、最初に出した数字ではありません。
最初は2時間45分と出しました。6分足りませんでした。
作業の終わりを「コードをコミットしたところ」で切ったからです。
そのあと6分かけて作業ログを書いていたのを、数に入れていませんでした。
実装側から指摘が来ました。記録を書く時間は作業の一部です。しかも
記録は省略しないルールにしているので、数えないのはルールと矛盾していました。
この記事でここまで書いてきたことを、その照合作業で自分がやりました。
「何を含めるか」を決めずに、範囲を勘で切りました。
気づいたこと
AIとの対話ログは、作業時間の代理指標になりません。
しかも歪み方に方向があります。
- AIと相談しながら進める工程は、長く見える
- 自分で書く工程は、短く見える
同じ1時間でも、ログの濃さが全然違いました。
使えるのは「その時刻に作業していた」ことだけです。
「その時刻に作業していなかった」の証明には使えません。
やっていること
数字を突き合わせる前に、何を含めるかを決めるようにしました。
以前も同じことをやっています。合計が合っているのに内訳が違ったときも、
原因は「何を含めるかを決めていなかった」ことでした。
同じ場所に3回来ました。 しかも3回目は、それを書いている最中でした。
分かったのは、書くときには落ちないということです。会話から拾って残す部分は
漏れませんでした。落ちたのは2回とも、複数の情報を1つにまとめる瞬間でした。
そして2回とも、見つけたのは自分ではなく、もう一方のセッションでした。
記録を取るのは、あとで見積の精度を確かめるためです。
測り方が工程によって歪むなら、その歪みも一緒に残しておかないと使えません。
