こんにちは。ラクスル Advent Calendar 2025 10 日目です。MBS開発部でDirectorを務めているkasuya(@n.ile)が担当します。初日に続いて２度目の登場になります。
今回はリファクタリングについて、私が心がけていることをまとめてみました。
リファクタリングとは
リファクタリングは、外部から見た振る舞いを変えずに内部構造を改善することです。目的は機能追加やバグ修正ではなく、可読性・保守性・変更容易性の向上です。
プロダクト開発では変更が重なるほどコードは複雑化します。だからこそ、小さく・こまめにリファクタリングする習慣が重要です。本ページでは、特に日常開発での小規模リファクタリングに焦点を当てます。
リファクタリングすべき時
ボーイスカウトルールを基本に
「来たときよりも美しく」。触れた箇所を少し良くして返す、を徹底します。AIエージェントの支援も積極的に活用しましょう。
具体的なタイミング
- 機能実装前: これからの実装を載せやすくするための下ごしらえ（依存の分離、命名の整理、構造の平準化 など）
- 機能実装後: 追加したコードをより良い形へ磨き込み（重複解消、抽象化、責務分離 など）
実装中に同時進行で大きく触るのは非推奨です。リファクタリングは「振る舞いを変えず、内部のみ改善」が原則。PRも機能実装と分けて、テストとレビューを明瞭にしましょう。
成功させるコツ
- 対象を広げない: いま触る範囲に限定。雪だるま式の拡大を避ける。
- 時間を決める: 時間箱で区切り、終わりのない改修にしない。
- 見積もりに含める: リファクタリングは開発の一部。タスク見積もりに前広で織り込む。
リファクタリングすべきでない時
リファクタリングを見送る判断も重要です。
テストがない場合
前提は「振る舞いを変えない」こと。その保証には自動テスト（特にユニットテスト）が不可欠です。
- 対応: 先にテストを用意してから着手。
納期が迫っている場合
納期がタイト、またはスプリントゴール達成が危ういときは実装を優先。
- 対応: リファクタリングは次機会に回す。
見積もり超過が見えている場合
想定以上に大きくなりそうなら、いったん立ち止まる。
- 対応: まず機能を完了し、必要なら別タスクとして計画し直す。いま本当に必要かも再評価。
スリーアウトルールのススメ
リファクタリングはしたいが、毎回工数は取れない——そんなときの実践的ガイドラインが3アウトルール（The Rule of Three）です。
1回目（最初の実装）: とにかく動くものを作る。将来の再利用は過度に気にしない。 2回目（重複の発生）: 重複に気づきつつも、そのまま重複させる。 3回目（リファクタリング）: 三度目に同様の実装が必要になったら、重複解消（共通化・抽象化）を行う。
重複回避の指針ですが、他の観点にも応用可能です。つまり、同じ箇所で2度「直したい」と感じたら、3度目は迷わず実施。必要なリファクタリングに集中し、完璧主義の沼を避けられます。
ステークホルダーへの説明
本来は説明が要る規模になる前に、日常の「小さなリファクタリング」で負債の増大を防ぐのが理想です。それでも一定の工数が不可避なら、計画に組み込む根拠を明快に示します。
- 現状の課題は何か
- そのために何を行うのか（具体的な手当）
- 必要工数（期間・人日）
- 実施しない場合の影響（品質・生産性・リードタイム・将来の施策阻害 等）
リファクタリングは価値が見えづらく、他施策との比較対象になりがちです。定量（例: n時間/月の損失、失敗率、MTTR）と具体例で説明し、POやビジネスの理解を得ましょう。
例:
- 将来の施策Aを上記課題が阻害。現状のままでは実現不可、または工数が過大化。
- 既存の不具合や運用負荷により、月あたりn時間の生産性低下。対応で改善が見込める。
説明を怠ると、チームの活動価値が伝わらず、信頼・関係性の毀損につながります。
まとめ
- 小さく、こまめに、頑張りすぎない
- やる/やらないの見極めを明確に（テスト・納期・見積もり）
- 説明責務を果たし、ステークホルダーの納得感を得る
