次のセッションの自分へ — デイリーノートと引き継ぎ (4)

「分析した、フィルタ追加した、結果が改善した。」 1か月後の自分が、この3行で引き継いで働けるでしょうか。

要約だけが残った記録は、引き継がれない

前の3回がAIの読むルールとメモリだったとすれば、今回は次のセッションの自分が読む記録です。今日、何を、なぜ、どうやったかを時系列で残すデイリーノートです。

問題は、ほとんどの記録が要約で止まることです。

## 異常検知作業
- 誤報を分析した
- フィルタ追加
- 結果改善

1か月後にこのノートを開くと、なぜフィルタだったのか、どれだけ改善したのか、何が残っているのかが分かりません。成果物は何をしたかは示しますが、なぜそうしたかは含められないからです。

なぜ（Why）を残すことは、業界が長く磨いてきた規律である

「結果ではなく理由を残す」は、いまさらの助言ではありません。ソフトウェア業界は、これをさまざまな形で制度化してきました。

• アーキテクチャ決定記録（ADR） — 2011年にマイケル・ナイガードが提案した形式で、決定ごとにタイトル・状態・文脈（Context）・決定・結果を1〜2ページで残します。肝心なのは「文脈」、つまりそのときどんな力が働いていたかを書くことです。理由を残さなければ、新しく来た人が過去の決定を盲目的に受け入れたり覆したりする、という問題意識から出発しました（原文、2011）。ThoughtWorksはこの慣行を、テクノロジーレーダーのAdoptリング（2017）に載せました。
• コミットメッセージ — 開発者が広く従うコミットメッセージの作法の7番目のルールは、「本文には何を、なぜを説明せよ（どうやってはコードが示す）」です。

韓国企業の現場も同じです。Woowa Brothersは新規入社者のオンボーディングで「歩んできた足跡を残すようにイシュー履歴を文書として記録する」と明かし（Woowa Brothers技術ブログ）、決定した内容をADRとして残すことで「新しいチームメンバーの合流や、過去の決定の背景確認に大いに役立った」と記しています（Woowa Brothers技術ブログ）。

理論の根もあります。野中郁次郎の知識創造理論において、**表出化（externalization）**は、頭の中の暗黙知を文章に移して形式知にする段階です。国内の研究も、この表出化の能力が組織のサービス品質と成果につながることを実証しました（サービス経営学会誌、2016）。記録は雑務ではなく、頭の中の知識を資産に変えるプロセスです。

再び引き継げるノートの形

同じ作業でも、こう残せば1か月後にもすぐ引き継げます。

## 振動異常検知 — 誤報の原因分析 (09:10〜)
- 問題: 現場の誤報7件（目標 週1件以下）、すべて22〜24時
- 原因: 隣接する空調機の起動振動が120Hz帯域に混ざる（稼働ログと7件の時刻が一致）
- 最初はセンサー不良を疑う → 他のセンサー2台にも同じ成分があり棄却
- 対処: 110〜130Hzのノッチフィルタ追加 → 誤報 7件→1件
- 決定: 再学習（2日）ではなくフィルタ（+0.4ms）。コスト対効果
- 保留: 他設備への影響は未確認 — 設備リストの返信待ち
- 次: フィルタ適用版で現場試験を再開

ルールはいくつかだけです。

• 1日1ファイル、仕事が一つ終わるたびに末尾に追記。セッションの終わりにまとめて書きません。
• 原因 → 対処 → 数値 → 決定 → 保留の骨格。「直した」ではなく根拠まで。
• 誤った診断も消しません。「最初はXと見たがYで棄却」まで残してこそ、同じ誤判断を繰り返しません。
• 最後の行に「次」。この一行が次のセッションの出発点です。

とりわけ最後の行が重要です。第1回で「◯◯の続きをやろう」でセッションを始めると述べましたが、その復元の質は、前日に残した「次」の行で決まります。

続く話

ここまでが個人の記録でした。次回は、この記録をチームの言葉へ昇格させる話です — トラッカー・ウィキ・Git。実務者の一日で解きほぐした別の連載も参考になさってください。

良いデイリーノートの様式と例が必要でしたら、お問い合わせからご連絡ください。

---

「AIを記憶する同僚として使う方法」シリーズ

1. AIはなぜ昨日を忘れるのか — セッションの忘却とコンテキストコスト
2. ルールは一か所に — AIルールファイルの書き方
3. 一つのファイルに一つの事実 — AI自動メモリ
4. 次のセッションの自分へ — デイリーノートと引き継ぎ（現在の記事）
5. チームの言葉へ昇格 — トラッカー・ウィキ・Git
6. 落とし穴と4週間の導入ロードマップ