2026.05.07 2026.06.07

「気をつける」が下手な人ほど、仕組みで気づく方が向いているのかもしれない

Kanae

Mintor の Issue に、自分でこう書いていました。

「このビュー、3 重に壊れてます」

根拠まで添えて、納得して書いていたんです。
数時間後、それが間違いだったと気づきました。

Contents

「verify した」が、verify になっていなかった

確認のため、本物の DB に直接聞いてみました。
pg_get_viewdef という、PostgreSQL に「このビューの今の定義を見せて」と聞くコマンドがあります。

返ってきたのは、私が「壊れてる」と書いた定義とは違うものでした。
ちゃんと正しく動く形で、すでに修正されていたんです。

私が読んでいたのは、リポジトリにある 古い設計書でした。
その時の設計だけど、今の現実ではない。
誰かが管理画面から直接アップデートして、ファイルは古いまま、DB は最新。

「verify した」と思っていた私は、verify する材料の新鮮さを verify していませんでした。

「次から気をつけよう」と思うのは簡単です。
でも、私は気をつけるのが下手だな、と知っているんです。

頭がぼーっとしている時間も長いし、深夜に作業することも多い。
気をつけ続ける体力は、たぶん自分にはない。

だから今日は、「気をつける」を増やすんじゃなくて、「気づける仕組み」を 4 段階で作りました。

1 段目は、自分への手紙。
「verify する時は、ファイルだけじゃなく今の DB に聞きに行くこと」とメモを書いて、AI のアシスタント（Claude Code）が次回も読めるところに置きました。

2 段目は、ツール。
DB の今の状態と、リポジトリのファイルがズレてないか、コマンド一つでチェックできるスクリプトを書きました。
npm run db:check-drift と打てば、その瞬間のズレが分かります。

3 段目は、自動チェック。
誰かがコードをアップロードしたタイミングで、CI（自動テスト環境）が裏で同じチェックを走らせるようにしました。
週に1回、月曜の朝には自動で監視してくれます。
私が忘れていても、勝手に気づいてくれる。

4 段目は、ドキュメントの整理。
「現在の真実を取りたい時に、どこを見ればいいか」を、CLAUDE.md（プロジェクトのルール集）に書きました。
未来の私が、ファイルを真に受けて壊れた、と早合点しないように。

これで初めて、「気をつける」じゃなくて「気づく」体制になった気がします。

GitHub Actions（コードを置く場所が用意してくれている自動チェックの仕組み）の請求が、月始めに 1,800 円くらい超過していました。

確認したら、文章ファイルや思考ログを更新するだけの push でも、毎回テスト一式が走っていました。
1 ヶ月積み重なると、結構な金額になります。

これも、「気をつけて push しよう」じゃ無理なんです。
設定で「文章だけの変更ならテスト走らせない」と書いておけば、今後は黙ってお金が減らない。

その設定を、5 つのワークフローに追加しました。
ついでに、毎日走る必要のなかった重いチェックは、週1回に変えました。

これも仕組みの話。
気をつけるじゃなくて、設定で先回りする。

私は、几帳面じゃありません。
タスク管理アプリも続かないし、毎朝決まった時間に何かやるのも苦手です。

だから AI と仕組みに任せる範囲を増やしてきました。
覚えてくれる相手、気づいてくれる仕組み、月初に「これ超えそうだよ」と教えてくれる通知。

そういうものを少しずつ揃えていくと、「気をつける」を減らしても、ちゃんと立っていられる気がします。

開発って、目の前のバグを直すだけじゃなくて、未来の自分がまた踏まないように仕掛けを置く部分も大事なんだと思いました。

仕掛けを置いておけば、来週の私は、たぶん同じ罠に気づきます。
頭がぼーっとしていても、寝不足でも、AI と CI が代わりに見ていてくれる。

「気をつける」を頑張れる人もいると思います。
私は、そっちじゃない方を選ぶ日が多そうです。

それも、ひとつの選択なのかもしれません。

ABOUT ME