リファクタリングって楽しいですよね。
コードを整えて、設計を洗練させていく感覚。最終出力が変わらないにもかかわらず、どんどんスマートになっていく構造。
「なんて気持ちいいんだ！」と思いながら、つい時間を忘れて没頭してしまいます。
しかし——楽しいからといって、いつでもどこでもリファクタリングしていいわけではありません。
今回は、自戒を込めて、**「リファクタリングが楽しすぎて失敗した話」**を共有したいと思います。
リファクタリング沼にハマった3日間
ある機能の開発を進めている中で、ふと5段階構成のうちの「第5段階」が気になりました。
「ここの処理、ちょっと冗長だな。リファクタしたらもっと良くなるかも」と思ったのが始まりです。
その時点では、いくつか手動の処理もあり、それらが安定してきたので「ついでに自動化もしよう」と考えました。
ここまではまだ良かったと思います。実際、構造もスッキリし、実装コストに見合う価値もありました。
でも問題はそこから。
気づけば「どうせなら全体をキレイにしたい」と思ってしまい、第1段階からリファクタを始めてしまったのです。
1段階目→2段階目→…と、止まらなくなりました。
楽しかったのは間違いありません。しかし、終わってみれば3日が溶けていたのです。
なぜリファクタは楽しいのか？
自分なりに理由を考えてみました。
- 設計が洗練されていく達成感
- すでに動いているコードだからこその安心感
- 失敗しても戻せる気軽さ
- ちょうどいい知的作業（頭の体操）
この「安心感＋達成感＋没頭できる作業」の三拍子がそろっているからこそ、ハマってしまうのだと思います。
でもそれ、本当に必要？
今回の学びはここに尽きます。
- リファクタしたいと思った**“きっかけ”の部分だけ**をやればよかった
- それ以外の気になるところは「気になるけど、今はやらない」と決めるべきだった
つまり、“コア”を見極め、それ以外は後回しにする勇気が必要だったのです。
リファクタの鉄則：「常に動く状態をキープせよ」
もうひとつ大きな反省点があります。
私は今回、「段階ごとにリファクタ→テスト」を繰り返していましたが、全体の統合を最後に回してしまったのです。
その結果、途中までは綺麗でも、最後で全体が動かないという事態に。
エンジニアとしては「責務が明確で、各モジュールが整っている」ことに満足してしまいがちですが、
**ビジネスとして価値があるのは“全体がちゃんと動くこと”**です。
結論：エンジニアである前に、ビジネスマンであれ
リファクタリングは楽しい。だけど、その楽しさに溺れてはいけません。
コードがきれいになっても、ビジネス的に意味がなければ失敗です。
今後はこう決めました。
- リファクタの動機を明確にする
- 目的の“コア”を特定する
- 気になる部分があっても、今じゃないならやらない
- 常に“全体が動く状態”をキープする
今回の経験を通して、自分が「リファクタが好きすぎるタイプ」だと再認識しました。
だからこそ、「そのリファクタ、本当に必要か？」と自問する習慣を大切にしていきたいと思います。
このブログが、同じようにリファクタリング沼にハマりかけている方の一助になれば幸いです。