構造が腐る前に

1. 908行のファイルを見て思ったこと

あるとき、自動化ワークフローの設定ファイルを開いて、行数を数えた。908行あった。

最初は数十行だった。機能を追加するたびに少しずつ伸びていった。最初のうちは問題なかった。動いていた。便利だった。だがある日、新しい機能を追加しようとして気づいた。どこに何が書いてあるか、すぐにはわからない。

それが腐り始めのサインだった。

2. モノリスの引力

「モノリス」とは、すべてが一体化した構造のことだ。一つのファイルに、あるいは一つのシステムに、あらゆる機能が詰め込まれた状態を指す。

モノリスには強い引力がある。何かを追加するとき、既存のファイルに書き足す方が新しいファイルを作るより速い。動いているものを壊したくないから、既存の構造の中に収める。その積み重ねが、ファイルを肥大化させる。

最初の選択は正しい。小さいうちは一体化している方が見通しがいい。問題は、その判断を更新しないことだ。構造の見直しが必要なタイミングが来ているのに、「まだ動いているから」と放置する。それが腐敗の始まりだ。

3. 腐敗の三つのサイン

構造が腐り始めているかどうかは、いくつかのサインで判断できる。

一つ目は「どこに何があるかわからない」だ。ファイルを開いて、目当ての処理を探すのに時間がかかるようになったら、構造が複雑になりすぎている。

二つ目は「変えると壊れる気がする」だ。一部を修正するとき、他の部分への影響が読めなくて慎重になりすぎる。変更に対して臆病になっているなら、結合が強くなりすぎている。

三つ目は「新しいものを追加するのが億劫になる」だ。本来は楽しいはずの拡張が、既存の構造への配慮で重くなっている。この感覚が出てきたら、設計の見直しのタイミングだ。

4. 分解の原則：一つのファイルに一つの責任

リファクタリングで最初に考えることは、「何が一緒にある必要があるか」だ。

908行のファイルには、14個の異なるアクションが詰め込まれていた。プロジェクト管理、ファイル操作、メール送信、音声メモ記録。それぞれが独立した処理だった。なのに同じファイルに書かれていた。なぜなら、「一緒に実行されるから」という理由だけで。

「一緒に実行される」と「一緒にある必要がある」は別のことだ。実行タイミングが同じでも、責任が異なるものは分けていい。それぞれを独立したファイルに切り出した。

変更前: 設定ファイル1本（908行）に14アクションのPythonが混在
変更後: 設定ファイル1本（184行）+ アクションごとの独立ファイル17本

設定ファイルは「何を実行するか」だけを書く場所になった。「どう実行するか」は個別ファイルに移した。役割が明確になると、読むのも直すのも速くなった。

5. リファクタリングのコストという誤解

「リファクタリングは時間がかかる」という認識は、半分正しく半分誤っている。

確かに、その瞬間は時間がかかる。動いているものを解体して、再構成する。テストして、確認する。その工数は実在する。

だが比較対象を間違えてはいけない。正しい比較は「リファクタリングにかかる時間」対「腐敗した構造の上に機能を追加し続けるコストの累積」だ。腐敗が進むほど、一つの変更にかかる時間が増える。バグが増える。理解するための時間が増える。その積み重ねは、リファクタリングの工数を遥かに超える。

早い段階で構造を直す方が、トータルのコストは安い。これはソフトウェア開発の古典的な知見だが、個人のインフラにも等しく当てはまる。

6. 「これ以上追加する前に」という判断

リファクタリングのタイミングを測る問いがある。「このまま次の機能を追加しようとしたとき、躊躇するか。」

躊躇するなら、それが合図だ。次を追加する前に、まず構造を直す。追加してから直すより、直してから追加する方がずっと楽だ。

実際、今回の分解は新しいアクションを追加しようとした瞬間に決断した。追加しようとして「この構造に入れたくない」と感じた。その感覚を信じた。機能追加を一時停止して、構造の修正を先行させた。

結果、新しいアクションは2行で追加できるようになった。ファイルを作り、設定に1行足すだけ。腐敗した構造の上なら、既存コードへの影響確認に時間を取られていたはずだ。

7. 腐敗は意図しない選択の積み重ね

構造が腐るのは、誰かが悪い設計を意図したからではない。それぞれの時点での最善の選択が、積み重なって腐敗を生む。

最初の10行は正しかった。50行になっても問題なかった。200行で少し気になり始め、500行で明らかに重くなった。900行を超えたとき、もう限界だった。だが各時点での判断は間違っていなかった。問題は、「そろそろ見直す必要がある」という判断を更新しなかったことだ。

インフラに限らず、組織も、習慣も、関係も、同じように腐敗する。意図しない選択の積み重ねが、ある時点で限界に達する。腐りきってから直すのは大手術だ。腐り始めに気づいて手を入れる方が、はるかに小さな作業で済む。

8. 長く動かすための設計姿勢

1000年動き続けるシステムを設計するとき、機能の追加よりも構造の維持が重要になる。どれだけ優れた機能も、読めないコードの上に積まれれば、いずれ誰も触れなくなる。

「構造が腐る前に直す」という姿勢は、技術的な話であると同時に、時間に対する姿勢でもある。短期的なスピードより、長期的な持続を選ぶ判断だ。

腐敗のサインを見逃さない。躊躇を感じたら立ち止まる。機能追加より構造修正を優先する場面を、意識的に作る。それが、長く動き続けるインフラを育てることになる。