ファイル整理って、後からやるとかなりしんどい
目次
先に本音
最近、ローカルで回しているアプリ置き場のフォルダ整理をやっていて、あらためて思ったことがありました。
ファイル整理って、散らかってからやると、かなりしんどいです。しかも、そのしんどさって、単に片づけが面倒という話ではないんですよね。
もっと正確に言うと、後からのファイル整理って、ただの掃除じゃなくて、ほぼ構造変更です。
今回どんな整理をしたか
今回整理したのは、08_apps のような、小さめのローカル自動化アプリをいくつか置いている場所でした。最初はたぶん、どれも自然に増えていったんだと思います。Python の本体があって、実行用の .bat があって、スケジューラ登録用の .ps1 があって、ログが出て、状態保存用の .json が増えて、一時ファイルも置かれて、設定用の .env もある。
この流れ、すごく普通なんですよね。最初の1本、2本のうちは全然困らない。むしろ近くに置いてあるほうが分かりやすいくらいです。
でも、数が増えてくると、急に苦しくなります。
どれが本体で、どれが補助スクリプトで、どれが生成物なのか分かりにくくなるし、root 直下にいろんな種類のファイルが並び始める。しかも本当に怖いのは、見た目が散らかることより、「このファイル、どこから参照されてるんだっけ」が分からなくなることなんです。
なぜ後からしんどくなるのか
ここが、後から整理すると大変な理由でした。
たとえばログファイルを移すだけでも、バッチ側の出力先を直さないといけないかもしれない。状態ファイルを移したら、Python 側の参照パスを直す必要がある。.env をまとめるなら、各アプリの読み込み元を変えないといけない。さらに、スケジュールタスクが古いパスを見ていたら、整理した瞬間に定期実行が止まることもある。
つまり、後からの整理って、「ファイルを移せば終わり」ではないんですよね。コード、スクリプト、設定、実行環境まで含めて、壊さずに組み替える作業になる。だから重い。
ただ、このしんどさは、どんなフォルダでも同じ強さで出るわけではありません。
特に大変なのは、ファイル参照や実行経路が複雑に絡み合っているアプリ置き場です。Python 本体、バッチ、PowerShell、state、ログ、.env、スケジューラ登録が全部つながっているようなフォルダだと、少し動かすだけでも影響範囲が広い。
逆に、単発のメモ置き場や、参照関係の少ないシンプルなフォルダなら、ここまで大ごとにならないこともあります。
それでも厄介なのは、ルールそのものを変えることなんですよね。置き場所の意味や生成ルールを後から定義し直すので、単なる掃除よりずっと手間がかかる。
今回やっていて一番大きかった学びは、散らかる原因って、だらしなさじゃないな、ということでした。
置き場所の意味が最初に決まっていなかった。たぶん、これが本質です。
ファイルが増えるのは自然です。でも、「何をどこに生成するか」「何をどこに置くか」のルールがないまま増えていくと、あとで必ず苦しくなる。
なので、やっぱり先に決めておいたほうがいいです。完璧な設計じゃなくていいので、最低限の生成ルールは先に持っておく。それだけで、後からのコストはかなり変わります。
今回しっくりきたルール
今回、最終的にかなりしっくりきたのは、こんなルールでした。
1フォルダ = 1アプリ / 1用途- アプリの中は役割ごとに分ける
- 共有設定だけ共通の場所に寄せる
構成としては、こんな感じです。
app-name/
src/
scripts/
state/
logs/
tmp/
archive/
README.md
src は本体コード、scripts は起動やスケジューラ登録用、state は継続利用する JSON やキャッシュ、logs はログ、tmp は一時ファイル、archive は旧ファイルや退避物。見ての通り、すごく素朴です。でも、小さい自動化アプリにはこのくらいの素朴さがちょうどいいなと思いました。
実際、この型で news-collector と morning-briefing の2つを連続で移行しました。ここで大事だったのは、1件だけきれいにできたかではなく、同じルールが2件目でもそのまま通用するかを確かめたことでした。
1件だけだと、その場しのぎの整理になりやすいんですよね。でも2件目も同じ型で移せると、「これは再利用できる整理ルールなんだな」と分かる。
この「横展開できる」が、たぶん大事なんだと思います。整理って、きれいに見せることが目的じゃなくて、次に増えたときに困らない状態を作ることなので。
先に決めておくと楽になること
じゃあ、最初に何を決めておくといいか。実務的には、たぶんこのあたりです。
1. 本体コードと生成物を同じ階層に置かない
コードとログと状態ファイルが横並びになると、保守性が一気に落ちます。見るたびに「何が成果物で、何が副産物か」を頭の中で判定しなければいけなくなるからです。
2. state と tmp を分ける
どちらもデータっぽく見えるのですが、再利用するものと捨てていいものは意味が違います。ここが混ざると、消していいかどうかの判断が毎回必要になります。
3. .env の置き方を最初に決める
アプリごとに持つのか、共通設定に寄せるのか。これを後回しにすると、整理するときに参照先の統一で必ず苦しみます。
4. 起動スクリプトは scripts/ に寄せる
.bat や .ps1 が root に散り始めると、実行入口が増え、どれが現役なのか分かりにくくなります。
5. いきなり削除せず、まず archive/ に逃がす
整理中は「不要に見えるけど参照されている」ものが意外とあります。非破壊で進めるほうが、結果的にずっと速いです。
6. README.md に最低限の運用ルールを書く
起動方法、ログの場所、state の意味、スケジューラの有無。このくらいでも書いておくと、未来の自分がかなり助かります。
特に、.env、state、logs、スケジューラまわりは、後回しにすると負債化しやすいです。動いているうちは目立たないのに、整理しようとした瞬間に一気に効いてきます。
AIに頼むなら、先にルールを作ったほうがいい
あと、今回もうひとつ思ったのは、AI にこういう整理を手伝ってもらうなら、先にルール作りをしたほうが圧倒的にいい、ということです。
AI は移動案を出したり、参照パスの修正箇所を洗ったりするのはかなり得意です。でも、ルールがない状態だと、その場をきれいにすることはできても、再利用できる構造にはなりにくい。
逆に、「1フォルダ = 1用途」「ログは logs」「状態は state」みたいな原則を先に決めておくと、かなり安定して一緒に進められる。AI に整理を頼むというより、整理ルールの実装を手伝ってもらう、くらいの感覚がちょうどいい気がしました。
しかも、こういう整理作業って、見た目以上にトークンを消費します。関係ファイルを読み、参照先を追い、どこまで影響するかを説明しながら進めるので、普通の文章生成よりずっと重い。だからこそ、最初にルールを置いておくことの意味が大きいんだと思います。
まとめ
ファイル整理って、つい見た目の話にされがちなんですが、実際は情報設計なんですよね。どこに何があり、何が生成物で、何が本体で、何が共有物なのか。それを後から読んでも分かる状態にしておくこと。
後からやると苦しい。だから、最初から完璧じゃなくていいので、生成ルールだけは先に置いておく。たぶんそれだけで、未来の自分はかなり助かると思います。