ログは「記録」より「再開ポイント」 — 翌日の自分のために書く

なぜ書いたか

タスクログを「何をやったかの報告書」として書いていた時期があります。読んでみると、翌日の自分が再開するために必要な情報がまるで足りない ことに気づきました。今回はログのフォーマットを「再開ポイントを残す」軸に切り替えた話です。

やったこと

ログには4つのセクションを必ず置くようにしました。

1. 暫定Done: スライス着手前に書く「今回はどこまでやれば一区切りとするか」
2. 検証結果: build / unit test / 手動シナリオの結果。ここまでは普通の報告書
3. 持ち越し差分（accepted residual gaps）: 今回意図的に未着手にしたもの、レビュー指摘で次に持ち越したもの
4. 再開起点（restart point）: 「次に着手するなら、ここから読めばいい」という指示

特に4つ目が効きます。コードのファイルパス、参照すべきVBファイル、確認すべき業務シナリオ、これらを5〜6行にまとめておくだけで、翌日の認知コストが激減します。

ログのテンプレ例

## task: 申請処理画面 S2 — Oracle 列追加スライス

### 暫定 Done
- 関連マスタの 3 系統（本体・内訳・添付）の列を追加
- API / Blazor までマッピング反映

### 検証
- build: ok
- unit test: ok
- 手動シナリオ: 新規登録 → 一覧表示まで確認
- review-1: 指摘 2 件（権限制御漏れ、関数呼び出し漏れ）

### 持ち越し
- 履歴モード時の表示列差分は次スライス
- 帳票出力の引数変更は未対応（mapping S5 に転記済み）

### 再開起点
- 着手場所: 申請処理画面 S3
- 必読: VB の `*_Click` ハンドラ周辺、共通モジュールの SQL 組み立て箇所
- 注意: 高権限ユーザー判定が UI / API 両方に必要（前スライスで指摘された観点）

わかったこと

• ログを「報告」ではなく「再開ポイント」と捉えると、書き方が変わります。読み手は明日の自分 で、過去の自慢話は要らない
• 持ち越し差分は 数を恐れずに書く。書かない持ち越しは消える
• AIに実装を任せていても、ログだけはOrchestratorのルーチンに組み込んで自動的に書かせるのが安全。書き忘れと表記揺れがなくなります

次にやること / 未解決の問題

• ログのテンプレをtask-log.mdとして整備済みだが、テンプレを使わず自由記述になっているスライスもまだ残っている
• 再開起点の粒度をどこまで細かく書くかは、人によってばらつきがある。最低限の必須項目を縛るルールを足したい