エバーグリーンノート：時間とともに複利のように価値を増していくメモの書き方

工学に関するメモのほとんどは、一度書かれると忘れ去られます。デバッグセッションで得た知見を記録し、どこかに貼り付け、2年後に見つけたときには、なぜそれが重要だったのかという文脈が一切ありません。

問題の原因は努力不足ではありません。エンジニアは常に書き続けています——コードのコメント、Slackのメッセージ、Confluenceのページ、Jiraの説明、プルリクエストの説明、アーキテクチャ図など。問題なのは、これらのメモのほとんどが特定の瞬間のために書かれており、経年劣化しやすい点にあります。それらは複利效應（コンパウンド）しません。単に蓄積するだけです。

「エバーグリーンノート（常緑のメモ）」は別のアプローチです。考え方はシンプルです。各メモを、永遠に有用であり続け、再訪するたびに改善され、時間とともにシステム全体をより価値あるものにするような方法で他のメモとつながるよう書くのです。

この用語は研究者のアンドリュー・マツシャック（Andy Matuschak）によって広められ、彼自身の公開メモはそのアイデアを大規模に実証しています。エンジニアにとって、この原則はテクニカルライティング、ドキュメンテーション、アーキテクチャ決定、そして難易度の高い教訓の長期的な記録において直接的な応用があります。

エバーグリーンノートが持つ特徴

原子性（Atomic）

エバーグリーンノートには、一つのアイデアが含まれます。一つのトピックではなく——一つのアイデアです。

「PostgreSQL」というタイトルのメモはエバーグリーンではありません。それは埋めるのを待っているコンテナ（容器）です。「部分インデックスは、クエリが小さなサブセットを対象とする際に書き込みオーバーヘッドを削減する」というメモはエバーグリーンです。これは具体的で移植可能な主張を述べています。

原子性の制約は再利用を制御するため重要です。コンテナ型のメモは、曖昧なトピックとしてのみリンクできます。一方、原子性のメモは、その特定のアイデアが適用されるどこにでもリンクできます——クエリ最適化の議論の中で、インデックス戦略の比較の中で、特定の性能問題に関するプロジェクトノートの中で。

自立性（Standalone）

エバーグリーンノートは、元のソースなしでも理解できるものでなければなりません。

つまり、自分の言葉で書くということです。「リンク先の参照——キャッシングについて良い情報が載っている」というメモはエバーグリーンではありません。「ライトスルーキャッシングは、データベースとの同期でキャッシュを更新し、書き込みごとに読み込みの一貫性を向上させますが、書き込みレイテンシが高くなる代償を払います」というメモはエバーグリーンです。1年後に読んで、元のソースを追う必要はありません。

これは聞こえるほど簡単ではありません。自立したメモを書くには、単にタグを付けたりするのではなく、読んだ内容を本当に理解する必要があります。その処理ステップこそが、学習の大部分が行われる場所です。

進化性（Evolving）

エバーグリーンノートは、古臭くなるのではなく、時間とともに改善されます。

一時的なメモにはライフサイクルがあります：書いて、瞬間を過ごし、無関係になります。エバーグリーンノートは、6ヶ月後や2年後に再訪し、洗練させる価値があるはずです。反例を追加したり、本番環境での経験で更新したり、新しいパターンにリンクしたり、単により正確に書き直すことができます。

「エバーグリーン（常緑）」という言葉は意図的なものです：これらのメモは収穫後に枯れません。存続し、改善されます。

連結性（Linked）

エバーグリーンノートは、孤立して座るのではなく、他のノートと接続します。

ライトスルーキャッシングに関する自立したノートは、読み込み集中型のワークロード、キャッシュ無効化、最終的一貫性、データベース書き込み性能に関するノートと自然につながります。各リンクは両方のノートをより有用にします——接続は、個々のノートが単独では持っていない文脈を表面化します。

リンクする習慣こそが、個々の洞察のコレクションを、つながった理解のネットワークへと変えるものです。

ノートの種類と使用タイミング

エバーグリーンノートを理解するには、それが何 ではないか を理解する必要があります。

一時的なメモ（Fleeting notes） は一時的なキャプチャです。デバッグセッション中にメモした一行、後で再訪するためのブックマーク、フォローアップする質問。一時的なメモは瞬間に役立ちます。それらは素早く処理され、破棄するか、より耐久性のあるものへ昇格させるべきです。一時的なメモのほとんどはエバーグリーンノートにはなりません。それで問題ありません。

文献ノート（Literature notes） は外部ソースの要約です——ドキュメントページ、ポストアテム、書籍の章、カンファレンスの講演。文献ノートは、ソースが何と言ったかを保存します。それらは理解そのものではなく、理解への一歩です。文献ノートは「このソースはXと主張している」と言います。エバーグリーンノートは「私はこれらの理由のためにXだと信じている」と言います。

エバーグリーンノート は、あなたが理解に至ったものを統合します。それらは学習プロセスの入力ではなく、出力に存在します。

エバーグリーン技術メモの書き方

良いエバーグリーン技術メモの構造は、主張、証拠、含意というシンプルな論理に従います。

# ライトスルーキャッシングは書き込みレイテンシの代償として読み込みの一貫性を向上させる

ライトスルーキャッシングは、基盤となるストアへの書き込みと同時に、
すべての書き込み時にキャッシュを更新します。書き込みパスは、書き込みが
確認される前に一貫性を確保するため、すべての読み込みは新鮮なデータにヒットします。

トレードオフは書き込みレイテンシです——すべての書き込みは、呼び出し元に確認が
返される前に2つの操作（ストアとキャッシュ）を完了する必要があります。

このパターンは、製品在庫数やユーザー設定など、キャッシュの古さが実際の
ビジネス影響を与える読み込み集中型のワークロードに適しています。

Links:
- [[Read-through caching shifts cache population to read time]]
- [[Cache invalidation is a coordination problem]]
- [[Write-behind caching trades consistency for write throughput]]

そのノートはソースなしでも有用です。主張を述べ、トレードオフを説明し、適用されるコンテキストを与え、関連するアイデアにリンクしています。

避けるべきこと

時間依存の参照 は経年劣化します。「Postgres 14の時点で、この動作はこう機能します」は文献ノートであり、エバーグリーンノートではありません。代わりに原則を書いてください：「プランナーは、見積もり行数がテーブルサイズに対する閾値を超えた場合、インデックススキャンをスキップします。」この主張は、閾値が変わってもバージョン変更を超えて生存します。

文脈のないツール固有のコマンド はスニペットであり、ノートではありません。StackOverflowの回答からコピーした kubectl コマンドだけのメモはエバーグリーンではありません。そのコマンドが なぜ 機能するのか——それが影響するKubernetesリソースと、解決する問題——に関するメモなら、可能性はあります。

読者の知識に関する前提 は急速に劣化します。現在のコンテキストにいない有能な同僚に説明しているかのように書いてください。

エンジニアリングにおけるエバーグリーンノートの良い候補

広範な適用性を持つ難易度の高い教訓は、ほぼすべて良い候補です：

• アーキテクチャのトレードオフと決定背後の理屈
• システム全体に適用されるデバッグパターン
• API設計のルールとそのエッジケース
• 現実の数字が添えられた性能特性
• 誤りであったことが判明したセキュリティ前提
• アプローチが失敗したプロジェクトからのテスト戦略の教訓
• チームの働き方を変えたデプロイ制約

共通点：実行可能ほど具体的であり、一度以上適用できるほど一般的であること。

エバーグリーンのワークフロー

ステップ1: 一時的なメモをキャプチャする

考えすぎずに素早くキャプチャします。目標は、その場でエバーグリーンノートを生み出すことではありません——それを生み出すための原材料を保存することです。

デバッグセッション中：

役割変更後にキャッシュが古いユーザー権限を返していることが判明。
TTLは5分だったが、役割の更新は即時だった。
これをどう処理するか考えなければならない——書き込み時の無効化？
それとも短いTTL？ またはイベント駆動型の更新？

それは一時的なメモです。それはエバーグリーンノートではありませんが、いくつかのメモの種を含んでいます。

ステップ2: 48時間以内にエバーグリーンノートに処理する

処理こそが、価値が現れる場所です。原材料を取り、保存する価値のあるアイデアを抽出します。

そのデバッグノートから、あなたは以下のように書くかもしれません：

# 役割ベースのキャッシュエントリは、TTL切れだけでなく書き込み時の無効化を必要とする

キャッシュされたデータが権限や役割をエンコードする場合、TTLベースの有効期限は安全ではありません。
役割がダウングレードされたユーザーは、TTLが切れるまで昇格された権限を持ち続けます。
権限に敏感なキャッシュでの正確性のために、書き込み時の無効化——または役割変更時のイベント駆動型キャッシュ更新——が必要です。

Links:
- [[Cache invalidation is a coordination problem]]
- [[Authorization decisions should not be cached at rest without validation]]

デバッグの文脈は消えています。移植可能なアイデアが残っています。

ステップ3: 既存のノートに接続する

ノートを書いた後、2分を使って以下を問います：

• これはどの既存のノートに関連するか？
• これはどの概念に依存するか？
• これは何を拡張し、何を矛盾するか？

双方向にリンクを追加します。新しいノートは既存のノートにリンクします。接続により今より豊かになった既存のノートは、逆方向にリンクします。

ステップ4: 再訪して改善する

エバーグリーンノートには、単一の正しい状態はありません。生産インシデント、設計レビュー、コードレビューコメントなどで、そのアイデアに再び遭遇するたびに、ノートに戻り、それをより良くすることを検討します。

あなたは以下を行うかもしれません：

• より具体的な例を追加する
• 新しい証拠に基づいて主張を更新する
• 重要でないと判明した免責事項を削除する
• 新しい関連ノートへのリンクを追加する
• 明確さのために冒頭文を書き直す

この洗練のサイクルこそが、ノートを劣化させるのではなく複利させるものです。

エバーグリーンノートとドキュメンテーション

個人的なエバーグリーンノートとチームのドキュメンテーションの間には、有用な区別があります。

個人的なエバーグリーンノートは、未来のあなたのために書かれたあなたの理解です。それらは粗く、意見的、不完全であっても構いません。それらの価値は、思考のための再利用性にあります。

チームのドキュメンテーションは、共有された理解のためにあります。正確性、アクセスしやすさ、メンテナンスの所有権が必要です。

これらの2つのレイヤーは互いに補完します。システムが特定の理由で設計された理由に関するあなたのエバーグリーンノートは、アーキテクチャ決定記録（ADR）の原材料になります。デバッグノートはランブックにフィードされます。API設計ノートはスタイルガイドに情報を提供します。

流れの方向は通常：エバーグリーンノート → 洗練されたドキュメンテーションであり、逆ではありません。

エバーグリーンノートとRAGシステム

AI強化型知識ツールがより実用的になるにつれて、よく書かれたエバーグリーンノートは、検索ソース素材としてますます価値が高まります。知識管理における 検索と表現 の問題は、本質的にソース素材の質に関するものであり、エバーグリーンノートは原子性、自立性、理解のために書かれているため、ベクトル検索のためにチャンク化されやすいです。

原子性のエバーグリーンノートのツェッテルカステン（Zettelkasten）は、パーソナルな RAG システムの自然な基盤です。原子構造は検索チャンクサイズと一致します。自立性は、検索されたノートが追加の文脈なしでも有用であることを意味します。リンク構造は、キーワード検索を超えたグラフ探索の機会を提供します。

これは、毎回ゼロから始めるのではなく、LLMで自身の知識ベースをクエリしたいエンジニアにとって、ますます関連性が高まっています。

一般的な落とし穴

広すぎる書き方

トピック全体をカバーするノートはエバーグリーンノートではありません——それは下書き記事です。ノートが画面一杯を越え、一つの主張以上をカバーする場合、それを小さなノートに分割し、リンクしてください。

狭すぎる書き方

一つのコンテキストに特化しすぎたノートは再利用価値がありません。「2024-03-14に請求サービスキャッシュのバグを修正した」はログエントリであり、エバーグリーンノートではありません。抽象レベルを上げ、アイデアが少なくとも3つの異なるコンテキストで適用されるまで持ち上げます。

「エバーグリーン」を「変更されない」と混同する

エバーグリーンとは不変を意味しません。それは、ノートが再訪する価値があるままであることを意味します。2022年に書かれたGoジェネリクスに関するノートは、2024年のパターンの進化を反映するように更新されれば、依然としてエバーグリーンです。永久に正しいと信じて決して触れないノートは、やがて沈黙の中で誤りになります。

処理ステップをスキップする

最も一般的な失敗は、エバーグリーンノートを書き方の実践ではなく、コレクションのターゲットとして扱うことです。ブックマークを保存することで、高品質な原子性ノートのコレクションを成長させることはできません。エバーグリーンノートは、あなたが読んだ記事ではありません——あなたが自分の言葉でそこから抽出したものです。

ツール

Obsidian

Obsidian は、エバーグリーンノートのための最も人気のあるツールです。ローカルのMarkdownファイル、双方向リンク、グラフビューは、この実践とよく一致します。シンプルな構造：

vault/
  fleeting/
    daily/
  literature/
  evergreen/
  maps/       ← エバーグリーンノートのクラスターのためのインデックスノート

Obsidianのグラフビューはリンククラスターを可視化します——どの概念がインデックスノートや公開記事になる可能性がある自然なグループを形成するかを発見するのに役立ちます。

プレーンなMarkdownとGit

Markdown ファイルのGitリポジトリはよく機能し、特定のツールへの依存はありません。標準的なMarkdownリンクがノートを接続します。検索はエディタや grep によって処理されます。バージョン履歴はGitから来ます。

knowledge/
  evergreen/
    caching/
    api-design/
    performance/
  literature/
  fleeting/

ツールに関係なく、規律は同じです——ノートごとに一つのアイデア、自分の言葉で書き、関連するノートにリンクします。

ゼロからの開始

始めるのに最も有用な方法は、既存のノートを移行することではありません。今日、一つのエバーグリーンノートを書くことです。

過去1週間に学んだものを取ります。それを主張として書きます。自分の言葉で1段落で説明します。ゼロまたは一つの関連アイデアへのリンクを追加します。

それが完全なエバーグリーンノートです。6ヶ月間、週に一度これを繰り返せば、動作するシステムが手に入ります。

複利效應は時間がかかるまで目に見えません。1年間エバーグリーンノートを維持するエンジニアは、彼らのノートが質問を完了する前に答えを返し始めるようになる——以前の文脈ですでに答えを書いているため——と報告することがよくあります。

最終的な思考

エバーグリーンノートが機能する理由は、ストレージが優れているからではありません。それらは思考において優れています。ノートごとに一つの移植可能なアイデアを、自分の言葉で、関連するアイデアへのリンクとともに書くという規律は、受動的なコレクションでは強制されない理解を強制します。

エンジニアにとって、これには実用的な結果があります。エバーグリーン形式に処理した生産インシデントのノートは、インシデントログよりも有用です。原子性ノートに凝縮した設計トレードオフは、アーキテクチャ図よりも有用です。特定のバグから一般化したデバッグパターンは、チケットよりも再利用可能です。

アクティブな仕事の整理のための PARAメソッド と併用して使用すると、エバーグリーンノートはPARAが提供しない概念レイヤーを提供します——プロジェクトを超え、役割を超え、年を超えて存続する、再利用可能な理解の成長するネットワークです。