自分の発信を1か所に集めるハブサイト「Hubpin」を、個人で作りました。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
Claude Code を取り入れながら、設計から実装まで一人で進めています。
紹介ページに、工程ごとの実績時間をまとめた表を置いています。
見積が何時間で、実際は何時間かかったか。
転職の面接で見せる想定なので、作業の記録から転記して作っています。
転記そのものはAIに任せています。
ある日その表を開いたら、6つぶんの工程が入っていませんでした。
表は6日前の状態で止まっていました。
同じ失敗の対策が、同じファイルに書いてありました
この表では以前にも同じことが起きています。
そのときは丸1日ぶんが落ちていました。
見つけたあと、再発させないつもりで教訓をそのファイルに書き足しました。
表の中だけを見ていても転記漏れは分からない、という趣旨です。
対策も書きました。
数字が食い違ったら、まず元の記録を検索して確かめる、という手順です。
それでも落ちました。
書いた対策は、別の場面のものでした
読み返して気づいたのですが、あの対策は「食い違いに気づいたときの手順」でした。
「落ちたことに気づく手順」ではありません。
食い違いに気づくには、まず食い違っているかもしれないと疑う必要があります。
表の中だけを見ているかぎり、その疑いが立ちません。
落ちている行は、空欄として見えるわけではないからです。
書かれている数字は全部正しくて、ただ最後の6行が無いだけです。
表としては完成して見えます。
今回見つけられたのは、別の用事でその表を開いたからでした。
用事がなければ、いまも気づいていません。
気づいたあとの手順と、気づくための手順
教訓を書いたときは、対策を書いた気になっていました。
実際に書けていたのは、問題が表に出たあとの対処です。
問題が表に出るところまでは、何も用意していませんでした。
このふたつは別の作業でした。
そして、必要だったのは後者のほうです。
表の中を何度見ても、転記漏れは出てきません。
元の記録と突き合わせて差を取る。
その作業を、誰かが決まったタイミングでやるしかありません。
対策を書くときに、どちらかを確かめる
失敗のあとに教訓を書く習慣はあって、それ自体は効いていると思っています。
ただ、書いたものが気づいたあとの手順なのか、気づくための手順なのかは分けて見るようにしました。
前者だけを書いて安心すると、次に同じ形で落ちます。
実際、同じファイルの中で起きました。
