「どれを選んだか」だけ書くのをやめた — ツール選定ジャーナルを未来の自分に渡す

結論 — 選定の「結果」だけ書くと、半年後の自分が同じ比較を一からやり直す

最初に結論を書きます。ツール選定で「採用した 1 個」だけメモすると、半年後の自分が同じ比較を一からやり直す事になります。zenn.dev/simplememo の「メモアプリ 6 本 × 7 軸の選定ジャーナル」を読んで、運営している AetherEchoes の選定メモを見直したら、過去半年で 3 回も同じ「Markdown editor の選び直し」をしていました。半年前の自分が「なぜ Obsidian を採用しなかったか」を書いていなかったので、今の自分が再度 Obsidian を試している、という滑稽な状態です。

選定ジャーナル (Selection Journal、選定の過程を時系列で残すメモ) は、Architecture Decision Record (ADR、設計判断記録) の非コード版だと整理できます。ADR はコードに対する設計判断を残す習慣ですが、フォント / ツール / 習慣 / 運用ルールには ADR を書く文化がほぼ無い。これを書き残すと、未来の自分が同じ比較に時間を溶かさず済みます。以下、過程を残すジャーナルの書き方を、AetherEchoes 運営での実例つきで書きます。

半年経つと「なぜそれを選んだか」を 70% 忘れる

要点を先に書きます。人間の記憶は具体例より結論の方が早く消えるので、選定の結果だけメモすると半年後に役に立たなくなります。私は AetherEchoes のフォント選定を 2025 年 11 月にやって、Bricolage Grotesque を採用しました。けれど 2026 年 4 月にデザインリニューアルを検討した時、「なぜ Inter じゃなく Bricolage Grotesque だったか」を全く思い出せなかったのです。

その時のメモには「Bricolage Grotesque 採用、見出しは Fraunces」とだけ書いてありました。比較した候補（Inter / IBM Plex Sans / DM Sans / Bricolage Grotesque）も、評価軸（個性 / 可読性 / web font の重さ / 日本語フォントとの相性）も、なぜ Inter を落としたか（個性が弱い）の理由も、全部消えていました。結局、4 月のリニューアル検討で同じ 4 候補を再度比較する羽目になり、半日溶かしました。選定結果は記憶しやすいけれど、選定理由は半年で 7 割飛ぶ、というのが体感です。

これは私だけの問題ではないと思います。Zenn の元記事の著者も「6 本のメモアプリを 7 軸で比較して 1 本に絞ったが、半年後に再検討する時に同じ作業を繰り返した」と書いていました。記憶は信用できない、と認める所から選定ジャーナルは始まります。

7 軸 × 候補 N 個の比較表が「過程の最小単位」

要点を先に書きます。選定ジャーナルの最小構成は「軸 × 候補」の比較表 1 枚で、これさえあれば後で過程を再現できるようになります。Zenn の元記事は「軸 7 個 × 候補 6 個」でしたが、私は 「軸 5 個 × 候補 4 個」 くらいが個人開発の手間として丁度よいと感じます。

私の AetherEchoes での実例を 1 つ挙げます。動画生成パイプラインを作る時、TTS（Text-To-Speech、読み上げ音声合成）の候補を 4 個比較しました。VOICEVOX / ElevenLabs / Google Cloud TTS / Amazon Polly の 4 つで、軸は「日本語の自然さ / 月額コスト / API 安定性 / ローカル実行可否 / キャラ性」の 5 つです。当時のメモには各セルに 1〜2 文だけ書きました。「VOICEVOX: 日本語自然さ◎、ローカル無料、キャラ性◎、API 不安定（ローカル daemon が落ちる）」のような形です。

このメモがあったおかげで、3 ヶ月後に「ElevenLabs って結局なぜ落としたんだっけ」と自問した時に 30 秒で答えられました（月額コストと、日本語の音声があの時点で限定的だった、という理由）。メモが無ければ確実に再調査していました。比較表 1 枚 = 30 秒 vs 半日、の差を生む小さな投資です。

ちなみに、軸を 7 個以上にすると埋める手間で挫折します。私は最初 9 軸で表を作ったのですが、4 軸目あたりから「もう全部 △ でいい」と思い始めて記録が雑になりました。5 軸前後が記憶力と労力のバランス点だと、3 回くらい運用して気付きました。

「採用しなかった理由」こそ未来の自分への最大の贈り物

要点を先に書きます。比較表に書いた「不採用理由」が、半年後 / 1 年後の自分への最大の贈り物になります。「採用した理由」は結果から逆算できますが、「採用しなかった理由」は当時しか書けないからです。

実例を 1 つ。AetherEchoes の Markdown editor を 2026 年 1 月に決めた時、私は VS Code / Obsidian / Typora / Bear の 4 つを比較しました。最終的に VS Code を選んだのですが、メモには「VS Code 採用」だけ書いていました。3 ヶ月後に「Obsidian の方が見やすいと聞いた、移行する？」と頭をよぎった時、なぜ最初に Obsidian を落としたか分かりませんでした。再度試して、結局「拡張機能の生態系と、Git 連携の手間」で VS Code に戻ったのですが、これは当時のメモに「Obsidian は plugin ガチャと .obsidian/ 同期で消耗、VS Code は git 標準連携でラク」と 1 行書いていれば回避できた半日でした。

不採用理由を書くコツは 「採用しなかった候補ごとに 1 文だけ理由を書く」 ことです。長く書く必要は無く、「○○ の理由で × 」の形で十分。むしろ長文にすると書く心理ハードルが上がって、メモ自体を残さなくなります。

ジャーナルを書くタイミングは「決めた直後の 30 分以内」

要点を先に書きます。選定ジャーナルは「決めた直後の 30 分以内」に書くのが鉄則で、翌日に回すと既に記憶が曖昧になります。

私は最初、「金曜の夜にまとめて書こう」と思っていました。けれど月曜に決めた選定理由を金曜に書こうとすると、「あれ、なんで Polly 落としたんだっけ」となります。実体験として 3 日後の記憶解像度は、決めた直後の 4 割くらいに落ちる感覚です。なので今は 「採用を確定した瞬間、その場で 5 分でメモを書ききる」 ルールにしています。

5 分という短さが大事で、長く書こうとすると始められません。比較表のセルに 1〜2 文ずつ埋める作業を 5 分でやり切ると、後で読んで「あの時の頭の中」がそれなりに再現できます。完璧な記録より、書き残された 60 点の記録の方が、半年後の自分には 100 倍価値があります。

少し脱線しますが、この「決めた直後に書く」習慣は、コードのコミットメッセージにも通じます。コミット直前に書く 1〜2 文の commit message が、半年後の git blame で命綱になる経験は誰しもあるはずです。選定ジャーナルも同じ構造で、「決断 + 直後の言語化」が未来の自分への投資になります。

まとめ — ADR を非コード領域に持ち込む

選定ジャーナルは、Architecture Decision Record を非コード領域に持ち込む習慣です。フォント / ツール / 運用ルール / 習慣の選定でも、「軸 5 個 × 候補 4 個」の比較表と、各候補の「不採用理由 1 文」を残す。これだけで半年後の自分は同じ比較を繰り返さずに済みます。

私は AetherEchoes で導入してから半年が経ち、過去のフォント選定 / TTS 選定 / Markdown editor 選定の 3 件で、再検討時に「あの時の判断理由」を 30 秒で再生できるようになりました。投資コストは選定 1 回あたり 5 分、回収は半年後の数時間です。投資収益率の高さで言うと、私が個人開発で導入したこの 1 年の小さな習慣の中で、最上位クラスに入ります。執筆ペースを整える話 (月 4 本を回すための執筆スケジュール術) と同じく、「未来の自分への投資」として小さく始められる類の習慣だと思います。

「結果だけ書く」のは未来の自分への小さな嘘です。過程を書くことが、未来の自分への最大の贈り物だと、Zenn の元記事を読み返して改めて思いました。