作業ログが実況だった僕を設計図が救った

「何をしたか」 から 「なぜそうしたか」 への書き方の実験

「今日やったこと」を毎日書いていました。

終業前に Obsidian を開いて、その日の作業を箇条書きにする。

それなりに「記録している」感覚があった。

でも、1 週間後にそのページを開いたとき何も役に立たなかったのです。

実況ログは後から読めない

PR レビュー 3 件と書いてある。
でも何を指摘したのか、なぜそのコードに引っかかったのかは一切残っていない。

バグ修正（認証まわり）と書いてある。
でもどんな原因でどう直したか、同じバグを防ぐためにどう考えたかはどこにもない。

これは記録ではなく実況だったのです。

実況は、そのときだけ価値がある。
スポーツ中継のようにリアルタイムには意味がある。
でも翌日読み返しても、試合の展開は分かっても「なぜあのシーンが転換点だったか」は語られていない。

作業ログも同じでした。
「何が起きたか」は書いてある。
「なぜそうなったか」はどこにもない。

コミットログに救われた夜と、 救われなかった夜

この感覚を、以前別の文脈で経験したことがありました。

深夜の緊急バグ対応です。

git log --oneline を走らせると、こんなログが並んでいた。

a1b2c3d fix bug
e4f5g6h update style
i7j8k9l fix

「fix bug って、なんのバグだよ……」

半年前の自分は、何も語ってくれませんでした。
コードを見れば「何をしたか」はわかる。
でも「なぜそうしたのか」はどこにもない。

そのとき初めて、ログの失敗は「書かなかったこと」ではなく「実況しか書かなかったこと」だと気づいたのです。

逆に過去のあるコミットにはこう書いてありました。

fix: Prisma の N+1 を解消（findMany → include に変更）
理由: ユーザー一覧画面でリクエスト数が急増していたため。
include で relations を一括取得するよう変更。

これは読めた。
過去の自分が、未来の自分に設計図を渡してくれていたのです。

設計図ログの 3 要素

作業ログを実況から設計図に変えるために、僕が試みた変換は 3 つの問いを加えることでした。