作業のルールを Markdown で書いて、AI に読ませながら仕事をしています。
先日そのルールを1つ、大きく変えました。方針を反転させる変更です。
関係するファイルを3つ直して、終わったつもりでいました。
終わっていませんでした
念のため、古いルールの特徴的な言い回しで全体を検索しました。
4つ出てきました。 どれも作業手順を書いたファイル（AI が実行時に読むもの）で、
古い基準がそのまま複製されていました。
- 「A に該当するなら◯◯へ」
- 「A を優先する」
方針を反転したのに、こちらは反転前のままです。
複製のほうが「正」になります
これが厄介なところでした。
| いつ読まれるか | |
|---|---|
| ルールを書いたファイル | 参照されたとき |
| 手順のファイル | 作業のたびに必ず |
実行時に読まれるのは手順のほうです。 つまりルールを直しても、
手順が古ければ古いほうが実際の動作になります。
放っておけば、次に作業したときに今日の判断がなかったことになっていました。
同じことを1週間前にもやっていました
別の作業で、決めたことを15箇所に反映したことがあります。
ファイルが9つ、タスク管理ツールのページが5つ、それに設定ファイルが1つ。
そのときの学びがこれでした。
判断は「書いた時点」ではなく「参照される場所すべてに届いた時点」で終わる
今回はそれを覚えていたのに、手順ファイルを「参照される場所」に数えていませんでした。
直し方を変えました
基準そのものを手順から消して、1行だけ残す形にしました。
判定の基準はここに書かない。◯◯を読む。
ルールの正は1箇所だけ。手順は何をどの順でやるかだけを持つ。
これなら、次に方針を変えたとき直す場所が1つで済みます。
5日後、形を変えてまた踏みました
これを書いてから5日後の話です。
ファイルの整合を検査するコマンドを、まず手順書に書き、それから実行しました。
実行するときに少しだけ簡略化したら、その1箇所が壊れて、
2件しか無いはずの不備が91件あるように見えました。
ルールではなくコマンドでしたが、構造は同じです。
同じものを2箇所に書いて、片方だけが変わった。
そして今回も、実際に動いたのは後から書いたほうでした。
落としどころ
「ドキュメントを更新した」で終わらせない。
古い言い回しで検索して、複製を潰すところまでが更新でした。
そして複製を見つけたら、そのとき直すだけでなく参照に置き換える。
直すだけだと、次も同じことが起きます。
ルールに限らず、同じ中身が2箇所にあるものは、いつか片方だけが古くなる。
それが分かっていても踏むので、書いた直後に検索する癖のほうを残すことにしました。
