memory システムの活用: 教訓をどう残しているか
ツール工房.ai の開発で地味に効いているのが、memory（相棒のツールがプロジェクト内で参照するメモ）の活用です。
同じ失敗を二度繰り返さないために、教訓やルールを短いメモとして残し続けています。
結論から言うと、「気付いたその瞬間に、1ファイル1テーマで短く残す」が一番運用しやすい、というのが現時点の結論です。
どんなときにメモを残しているか
メモを残すトリガーは、同じミスを2回やってしまったとき、公式情報と自分の理解がズレていたとき、長時間ハマったとき、ルール化したい運用方針が見えたとき、別のプロジェクトでも再利用できそうな知見、のいずれかです。
逆に「成功したけど一度きり」や「軽微な好み」はメモにしません。ストックは増えるほど検索性が落ちるので、本当に再発防止・再利用に値する話だけを選ぶようにしています。
1ファイル1テーマで短く書く
メモは必ず1ファイル1テーマで書いています。
1ファイルに複数の話題を混ぜると、検索したときに「他の話に埋もれる」ので、結果として読み返されません。
書き方の型は、次の順番です。
- 何が起きたか
- なぜ起きたか
- どう対処したか
- 次に取るべき行動
長くても画面1〜2スクロール分。長文で書くと結局読み返さないからです。
カテゴリで命名すると検索しやすい
ファイル名は接頭辞を揃えています。
feedback_（失敗からの学び）project_（特定プロジェクトの固有事情）reference_（公式仕様の要点）user_（自分のこと・役割や好み）
接頭辞を揃えておくと、相棒のツールが文脈に応じて「このタスクなら feedback_ を見に行く」と判断しやすくなる感触があります。
教訓メモの実例
たとえば「公式ページの割引前/割引後を見極める手順」というメモがあります。
スマホ料金比較ツールを作っているとき、相棒が「割引前の高い金額を割引後と勘違いして表示する」事故が何度かありました。
原因は、ページ上で割引後の金額に色が付いているのですが、機械的に読むときには色情報が失われるためです。
「重要な料金は必ず HTML を生で見て、CSS のクラス名で割引後を判別する」という対処手順を書き残しました。以後、同じ落とし穴に落ちることはなくなりました。
残してはいけないものもある
メモには「個人情報」「未公開の運用情報」「気分で書いた感想」は残さないようにしています。
プロジェクト内で何度も参照される性質上、別の作業のときに急に呼び出される可能性があります。そのときに「これは公開系のプロジェクトで読み出してほしくないな」と思うものは、最初から残さない方針です。
定期的に整理する
メモは増えすぎると逆に検索しづらくなります。
ときどき棚卸しをして、対処済みのもの、仕様変更で古くなったもの、別のメモと重複しているものを削除・統合しています。
完璧な整理を狙うのではなく、「明らかに不要なものだけ取り除く」軽い掃除で十分です。
残しておいて良かった、と感じる瞬間
メモを残しておいて一番嬉しかったのは、しばらく経ったころの自分が同じ問題にぶつかったときに、メモのおかげで5分で解決した瞬間です。
個人開発は同じテーマを毎日触り続けるわけではありません。間が空くと、前回どこで詰まったかを綺麗に忘れます。
そこで助けてくれるのが、過去の自分が残した短いメモです。
地味で派手さはない作業ですが、長期戦になる個人開発では、こうした記憶のインフラを育てていくことが意外と効いてきます。
残すコストは数分、未来の自分への投資としては破格に安い、という感覚で日々書き足しています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ