真昼の集中を守るために夜間へ逃がした

Cron / Queue で回す個人開発のバッチ処理見直し

ターミナルに、また同じコマンドを打っていた。

npm run backup
npm run weekly:stats

真昼のカーテンは閉じている。
内向きの仕事の時間なのに、個人開発の「ついで」が割り込んでくる（笑）

処理そのものは悪いことじゃない。
悪いのは、人が起きている時間帯に人が手で回していることでした。

夏に向けて、僕はバッチ処理の置き場所を見直しました。
定時は Cron。
重い・再試行が要るものは Queue。

どちらも、原則は夜間——
または「今じゃなくていいとき」——へ逃がす。

真昼の集中を守るための、技術側の設計記録です。

バッチは便利なのに日中の敵にもなる

みなさんは、個人開発のメンテ作業を「今ちょっとだけ」と真昼に回して、そのまま集中が戻らなくなった経験はありますか。

僕には、それが何度もありました。

真昼を避けてリズムを戻した話では、真昼を内向きの仕事——執筆・思索・静かな実装——に使うと書きました。

光の強さに、仕事の向きを合わせる。

それでも、個人開発のリポジトリを開くと別の声が来る。

「バックアップ、今日まだだ」
「週次の集計、忘れそう」
「このレポート、先に出しておこう」

全部、真面目に聞こえる。
だから厄介です（汗）

触らない一本で、リファクタは週の札にした。

バッチは、リファクタじゃない顔をして割り込んでくる。
掃除でも改修でもなく、運用の雑務。
雑務ほど、真昼の集中を静かに削る。

問題はバッチ処理そのものではない。
いつ、誰が回すかが設計されていなかったのです。

夏の個人開発は、機能の追加より先に、運用の雑音を減らす季節でもある。
真昼にカーテンを閉じても、ターミナルが騒げば部屋の静けさは戻らない。
だから今回の主題は、新しいフレームワークではない。
既存のメンテを人の手元から夜間へ移すことです。

手動実行が真昼の集中を削っていた

かつての僕の個人開発運用は、だいたいこうでした。

| 作業 | やり方 | 起きていたこと |
|:---|:---|:---|
| バックアップ | 思い出したときに手動 | 忘れる／真昼に思い出す |
| 週次集計 | 日曜の夜に手動 | 忘れると翌週へ持ち越し |
| 重い出力 | 必要になった瞬間に実行 | ノートパソコンが熱くなり、執筆が止まる |

夏はとくにきつい。
エアコンの効いた部屋でも、重い処理を回すとファンの音が上がる。
Mac mini はファンが小さく、熱くなりにくいですが、MacBook Pro は熱くなりやすい（汗）
画面の応答も鈍くなる。
内向きの仕事の静けさが、物理的に壊れる。

吃音のある僕は、外の喧騒を避けて真昼に閉じる選択をした。
なのに、自分のターミナルが喧騒を持ち込んでいた。

もう一つの失敗は、ローカル Cron への過信でした。

ノートを閉じるとジョブは走らない。
出張や昼寝で蓋を閉じたまま、朝「何も動いていない」と気づく。
意志の問題ではなく、実行環境の問題です。

環境を変えて朝を戻した実験と同じ構造でした。

頑張るのではなく、前提を移す。

バッチも、人の手元から離す必要があったのです。

今やらなくていい処理を夜間の仕事として定義し直す

転機は、処理の分類を変えたことでした。

以前は、自動化したい作業と雑に括っていました。
今は、次の三つの問いだけ先に立てます。

【バッチ見直しの三問】
1. これは、今この瞬間に結果が要るか？
2. 失敗したら、人がすぐ対応すべきか？
3. 日中の集中を削ってまで、手で回す価値があるか？

答えが「いいえ」に寄るものから、夜間へ逃がす。

七夕の技術の願い事で、リファクタしたい／触りたい／手放したいを分けました。

今回は運用側の分け方です。

日中に触るものと、夜間に任せるもの。

触らない一本が手を伸ばす先を減らすなら、夜間バッチは手を伸ばす時間帯を減らす。
同じ夏の設計の技術側の線です。

8 月の空白週を先入れした話が時間の箱を確保するなら、今日の話は処理の箱を夜間に移す。

空白もバッチも、走っている今だからこそ先に設計できる。

【設計】 Cron と Queue の使い分け

道具を増やす前に、役割を固定しました。

| | Cron（定時） | Queue（待ち行列） |
|:---|:---|:---|
| 向くもの | 毎日／毎週、決まった時刻で足りる | 発生は不定期、重い、再試行したい |
| 例 | バックアップ、ヘルスチェック、週次 README | レポート生成、画像一括、通知のまとめて送信 |
| 失敗時 | 翌朝まとめて見る | リトライ＋デッドレターを設計する |
| 僕の置き場 | GitHub Actions の `schedule` | アプリ内のジョブ Queue（再試行付き） |

ポイントは、全部を Queue にしないことです。
個人開発で Queue 基盤だけを厚くすると、増やさない週の精神に反する。
定時で足りるものは Cron のままが軽い。

逆に、ユーザー操作や溜まった作業を Cron に無理に載せると、空っぽの時間に空振りしたり、ピークで重なったりする。
重いものは Queue に積んで、ワーカーが夜間に消化する。

僕のルールは一行です。