たとえるなら
味は変えずに厨房を整理整頓することです。お客さんから見える料理（動作）は何も変わりませんが、道具の置き場が整えば、次の料理は速く正確に作れます。すぐには売上に見えなくても、続けている店ほど強くなります。
もう少しくわしく
リファクタリング（refactoring）は、プログラムの動作は一切変えずに、ソースコードの中身だけを整理して読みやすく直す作業です。わかりにくい名前を直す、重複した処理をひとつにまとめる、複雑になりすぎた部分を分割する——外から見える機能は何も変わらないのに、コードの質は確実に上がります。利用者から見れば何も起きていないのに、次の修正が速く安全になる、という種類の仕事です。
やることは、ひとつずつ見ると地味です。「a」「tmp」のような中身のわからない名前を、内容が想像できる名前に変える。同じ処理を三か所に書いていたものをひとつにまとめる。表示と計算が混ざった長い処理を役割ごとに分ける。もう誰も呼び出していない古いコードを消す。一件あたりは数分で終わる小さな直しですが、積み重なると読む速さが変わります。
混同されやすいのは機能追加と作り直しです。機能追加は外から見える動きが増えること、リファクタリングは外から見える動きが変わらないこと。ここがはっきりした境界線になります。すべて捨てて一から作る「作り直し」とも違い、今動いているものを残したまま少しずつ直していきます。不具合修正とも別で、直すのは動きではなく書き方だけです。
現場では、その部分に手を入れる担当者が、機能の修正とあわせて周辺を片付ける形で進めるのが多いです。着手前に今の動きを確かめるテストを用意し、少し直すたびに動かして、動きが変わっていないことを確認しながら進めます。機能の変更と整理は別のコミットに分けるのが定番で、レビューする側が「動きが変わる変更」と「整理だけの変更」を切り分けて読めるようにします。
落とし穴の代表は、一度に広い範囲を書き換えてしまうことです。まとめて直すと、何かが壊れたときにどの変更が原因なのか追えなくなります。もうひとつは、動きを確かめる手段がない状態で始めること。変わっていない保証がないまま整理すると、ただの機能破壊になりかねません。締め切り直前の変更に整理を混ぜてしまうのも、避けたい進め方です。
働きはじめたばかりの人は、自分の判断だけで他人のコードを大きく書き換えないことを守ってください。読みにくいと感じたコードには、当時の事情が隠れていることがあります。気づいた点はレビューやチャットで共有し、直す範囲を相談してから手を動かすのが安全です。エンジニアではない立場の人は、「リファクタリングします」と言われたら画面は変わらない作業だと受け取ってください。
この作業は成果が目に見えないぶん、時間をもらいにくいのが悩みどころです。説明するときは「きれいにしたい」ではなく、「この部分の修正に毎回半日かかっているので、整理すれば次から短くなります」と後の工数で語ると通りやすくなります。整理を後回しにしたまま積み上がった状態は技術的負債と呼ばれ、放置するほど簡単な変更にも時間がかかる体質になります。
現場での使われ方
「この機能を触る前に、まずリファクタリングさせてください」
今のコードのままでは安全に修正できないので、先に整理する時間がほしいという提案です。遠回りに見えますが、散らかった状態で無理に直すより、結果として早く終わることが多い判断です。
「動作は変わってません。リファクタリングだけです」
機能追加でも不具合修正でもなく、コードの整理だけという説明です。レビューする側は動きが変わる心配をせず、書き方の良し悪しだけを見ればよくなるので、確認が速く進みます。
「そこは負債が溜まっているので、触るのに時間がかかります」
過去の応急処置が積み重なって読み解きにくい状態だという意味です。見た目には小さな要望でも工数が膨らむ理由の説明として使われ、整理の時間をもらう相談にもつながります。
「リファクタリングは別のプルリクエストで出してください」
機能の変更とコードの整理を混ぜると、レビューでどこを見ればよいのか分からなくなるため、分けて出してほしいという依頼です。手間は増えますが、後から履歴を追うときに効きます。
よくある質問
リファクタリングとバグ修正の違いは何ですか？
バグ修正は「間違った動作を正しい動作に変える」こと、リファクタリングは「動作は変えずに中身を整理する」ことです。動作が変わるかどうかがはっきりした境界線になります。レビューでも、動きが変わる変更と整理だけの変更は分けて扱われるのがふつうです。
リファクタリングは誰がいつやるのですか？
多くの現場では、その部分に手を入れる担当者が、機能の修正とあわせて少しずつ進めます。まとまった時間を取って一気に行う現場もありますが、日々の作業に混ぜるほうが続きやすいです。いずれの場合も、勝手に大きく書き換えず、直す範囲を先に相談してから始めます。
動作が変わらないのに、なぜ時間をかけるのですか？
後の修正が速く、安全になるからです。散らかったコードは読み解くのに時間がかかり、直すたびに別の場所を壊しやすくなります。長く使われるシステムほどこの差が積み上がり、やがて「簡単なはずの変更に何日もかかる」という形で、開発の速さそのものに表れてきます。
リファクタリングで不具合が出ることはありますか？
あります。動作を変えないつもりでも、書き換えの途中で意図せず動きが変わってしまうことがあるためです。だからこそ、先に動きを確かめるテストを用意し、小さく直して都度確認するのが基本の進め方になります。確かめる手段がない部分から手をつけるのは避けます。
技術的負債とは何ですか？
後回しにした整理や応急処置が積み重なって、開発の速さを落としている状態のことです。借金と同じで、放置すると利息のように手間が増えていきます。リファクタリングは、その借金を少しずつ返していく返済作業にあたり、続けているチームほど身軽に動けます。
