自動化スクリプトが半年で「読めないコード」になった理由——保守が続く設計のために、あえてやめた5つのこと

この記事の要点：自動化スクリプトを長く保守するコツは「足す」ことではなく「引く」こと。やらないと決めた5つのことで、半年後に読み返せるコードが書けるようになった。

自動化スクリプトを書き始めた頃、「完璧に動く仕組み」を目指していた。ありとあらゆる例外に対応して、一つのスクリプトで全工程を処理する。そのつもりで積み上げていったら、半年もしないうちに自分でも全体像が追えなくなっていた。

正直、焦った。書いたのは自分なのに、修正しようとするたびに「どこから手をつければいいか分からない」状態になっていたのだ。

1. あらゆる例外に対応しようとするのをやめた

以前は、少しでも想定外の入力があるたびに、それへの対処を追加していた。結果として分岐が増え、条件式が入れ子になり、半年後に読み返しても何をしているのか分からないコードができあがった。

今は「発生頻度の低い例外は自動処理の対象から外して、エラーで検知したら手動対応に回す」という方針に変えた。

• すべての例外を自動処理しようとしない
• エラーは検知できれば十分。原因は手動で判断する
• 結果として、コード全体の見通しが格段に良くなった

2. 一つのスクリプトに機能を詰め込むのをやめた

「関連する作業はまとめて一つのスクリプトで」という考えでやっていた時期があった。ところが、機能を詰め込めば詰め込むほど、どこか一箇所が壊れたときの影響範囲が広がる。原因の切り分けも難しくなる。

今は機能ごとに小さく分割して、それぞれが独立して動くように設計している。一つ変えたときに他に影響が出ないかを確認できる範囲に収める。地味な変更だが、保守のしやすさという点ではこれが一番効いている実感がある。

3. 動いているスクリプトに確認なしで手を加えるのをやめた

ちょっとした修正なら勢いでそのまま本番に手を入れていた時期がある。「5分で終わる修正」のつもりが、予期しない影響で1時間後に原因を追いかけていた、という経験を何度もした。

今はどんなに小さな変更でも、別の環境で一度試してから反映するようにしている。この一手間を惜しんで痛い目を見た経験があるからこそ、今はそれが当たり前の手順になった。

---

4. 一人で抱え込んで粘り続けるのをやめた

何かがうまく動かないとき、誰にも相談せず黙々と原因を追い続けていた時期がある。意地のようなものがあって、自分で解決しないと気が済まなかった。

今は少し行き詰まったらすぐClaudeに状況を説明して、一緒に原因を洗い出す。「自分一人で解決する」というこだわりを手放したことで、問題解決にかかる時間がはっきり短くなった。

5. 「完全な自動化」を目標にするのをやめた

全工程を機械に任せることを目標にしていた時期は、常に「まだ足りない」という感覚が消えなかった。

今は「人間が判断すべき部分は最初から人間の側に残しておく」という前提に立っている。自動化の目的は「楽をすること」ではなく「重要な判断に使える時間を増やすこと」だと整理したら、自動化そのものへの肩の力が抜けた。

---

まとめ

• 例外は「すべて自動で処理」ではなく、エラー検知＋手動対応に変える
• 機能は小さく分割して独立して動くように設計する
• 変更は必ず別環境で確認してから本番に反映する
• 行き詰まったら早めにAIを使って一緒に原因を洗い出す
• 完全な自動化は目標にしない。判断が必要な部分は人間に残す

保守を長く続けるコツは、新しい機能を足すことよりも、余計な複雑さを削ぎ落とすことにある。足し算だけでなく、引き算の判断ができるようになったことが、この数年で一番変わったことかもしれない。

関連記事
- https://note.com/quick_harte2469/n/nf17b607a121b
- https://coconala.com/contents_market/articles/cmufllea702fpbc0h7lmc7vsm

Bluesky ディスカッション

Bluesky で表示

まだ返信はありません。Bluesky で最初にコメントしましょう！