触れないレガシーコードに"最初の一歩"を｜壊さず改善を始める手順
「このコード、触ったら何が起きるか分からない」。 動いてはいるけれど、書いた人はもういない。コメントもなく、テストもない。そんなコードを前に、修正の手が止まってしまう——保守の現場では、よくある光景ですよね。
障害の原因はどうやらこのあたり。改善したいのも分かっている。でも、うかつに変えて本番が止まったら、責任を取るのは自分ひとり。だから見て見ぬふりをして、また同じ問題が再発する。この繰り返し、じわじわ効いてきます。
手が止まるのは、あなたが臆病だからではありません。 「動いているが誰も中身を保証できないコード」に、安全網なしで飛び込もうとしている——ただそれだけのことです。安全網さえ用意すれば、レガシーコードは思っているより静かに直せます。
この記事では、触るのが怖いコードに壊さず"最初の一歩"を入れる進め方を、一人運用の現場目線で一緒に整理していきます。いきなり全部きれいにする必要はありません。まずは1か所だけ、安全に手を入れるところから始めます。
結論：レガシーコードは「理解→固定→最小の一歩」の順で触る。①読むだけでいったん全体像をメモする ②今の挙動を記録する特性テスト（今の出力をそのまま正解として固定するテスト）を1本だけ書く ③振る舞いを変えない小さな整理（名前を分かりやすく直す、意味のかたまりを切り出す）を1か所だけやる。この3つを1サイクル回せれば十分。まずは直近で気になっている関数を1つ選ぶところから始めます。
コードの言語や規模（PHP・Java・社内バッチ・WordPressの独自改造など）で細かいやり方は変わります。この記事の考え方を出発点に、自分の現場の道具に読み替えてください。
何が起きているのか：怖いのは「変えた影響が読めない」から
触れないコードの前で手が止まるとき、現場ではだいたいこういう状態になっています。まず、そこを言葉にしておきましょう。
- 影響範囲が見えない：この関数がどこから呼ばれているか分からない。1か所直したつもりが、別の画面が壊れるかもしれない。
- 正しい動きが分からない：「今こう動いているのが正解なのか、たまたまなのか」の判断がつかない。だから直していいのかも決められません。
- 戻せる自信がない：もし壊しても、元にすぐ戻せる保証がない。バックアップも取っていない。
- 一人で背負っている：レビューしてくれる人も、相談できる人もいない。全部の判断が自分にかかっている。
つまり、能力の問題ではなく「安全に試す仕組みがないまま、本番相当のコードを触ろうとしている」のが怖さの正体です。だから、変える前に"安全網"を先に用意するだけで、怖さはかなり小さくなります。
最初の一歩：3ステップで「壊さず触れる」状態を作る
いきなりコードを書き換えないのがコツです。次の3ステップを、この順番でやります。
- 理解する（読むだけ・まだ変えない）：対象の処理を上から読み、「何を受け取って・何をして・何を返すか」を自分の言葉で数行メモします。どこから呼ばれているか（呼び出し元）も検索して控えておきます。まだ1文字も変えません。
- 今の動きを固定する（特性テストを1本）：今の入力に対して今どんな出力になるかを記録する短いテストを1本だけ書きます。中身が正しいかは問いません。「今のまま」を正解として固定するのが目的です。これが、うっかり挙動を変えたときに気づくための安全網になります。
- 小さく一歩だけ整える（振る舞いは変えない）：分かりにくい変数名を意味の分かる名前に直す、長い処理から意味のかたまりを1つ切り出す——見た目の整理だけを1か所やります。動きは1ミリも変えません。ステップ2のテストが通ったままなら、壊していない証拠です。
ポイントは、「直す」より先に「今を固定する」こと。テストがないコードをいきなり直すのは、命綱なしで綱渡りするようなものです。先に命綱（特性テスト）をかけてから、一歩だけ踏み出します。
テストを書く環境がどうしても用意できない場合は、「同じ入力を流して、変更前と変更後の出力を目で見比べる」でも代わりになります。完璧なテストでなくてかまいません。"変える前と後で結果が同じ"を確認できれば十分です。
具体例：怖い1関数を、こう1周する
言葉だけだと固いので、ありがちな場面で1周してみましょう。たとえば「金額を計算している、やたら長い1関数」があったとします。
- 理解：読んでみると「税込金額を計算して、端数を切り捨てて返す」処理らしい。呼び出し元を検索したら、注文確定と請求書出力の2か所から呼ばれていた。→ 触るなら、この2か所への影響を見るとメモ。
- 固定：代表的な入力（1,000円・税率10%）を流したら「1,100円」が返ってきた。端数が出る入力（999円）だと「1,098円」。この「入力→今の出力」の組をそのままテストに固定する。中身が本当に正しいかは今は問わない。
- 一歩：
$a$tmpみたいな名前を$zeikomi（税込）など読める名前に直す。長い処理から「端数処理」の3行を関数に切り出す。→ 固定したテストを流して、さっきと同じ結果が返れば成功。動きは変えていないので、安心して次に進めます。
これで、少なくともこの関数は「読めば分かる・触っても気づける」状態になりました。1周まわすと、次に同じ関数を触るときの怖さが、目に見えて減っていきます。
影響：一歩を入れないと、負債は"複利"で重くなる
「怖いから、当たり障りなく避けて通る」。その気持ちはとてもよく分かります。でも、触れないまま放置すると、じわじわ効いてくる痛みがあります。
- 改修のたびに遠回りになる：中身が分からないから、毎回おそるおそる。1行直すのに半日かかる、が常態化します。
- 障害の原因が消えない：根っこにあるコードに手を入れられないので、同じ障害が形を変えて再発します。
- どんどん触れる人がいなくなる：放置した年月ぶん、前提を知る人が減る。5年後にはもっと怖くなっています。
- 引き継げない：「このコードは触らないで」としか言えない状態は、次の担当者に渡せません。
逆に言えば、小さな一歩を入れておくことは「未来の自分と次の担当者への安全網づくり」でもあります。全部をきれいにする必要はありません。触ったところから少しずつ"読める・戻せる"に変えていけば十分です。
続けるための小さなコツ
一歩を入れる価値は分かっても、続かなければ意味がありません。一人運用でも回るように、力を抜くポイントを押さえておきましょう。
- 範囲を「1関数・1ファイル」に絞る：システム全体を相手にしない。今週気になった1か所だけでいい。小さいほど戻しやすく、怖さも小さい。
- 変更前に必ず退避コピーを取る：バージョン管理があればコミット、なければ日付つきでファイルを丸ごとコピー。「いつでも戻せる」が心の余裕を作ります。
- 「理解」と「変更」を同じ日に混ぜない：読む日と、直す日を分ける。理解しながら直すと、影響を読み違えやすくなります。
- 振る舞いを変える改修と、整理は分ける：バグ修正（動きを変える）と、名前直し（動きを変えない）を一度にやらない。混ぜると、何が原因で壊れたか分からなくなります。
- 1周終えたら1行メモを残す：「この関数はここから呼ばれる／特性テストは○○にある」と残すと、次の自分がゼロから読み直さずに済みます。
「きれいなコードにする」ことをゴールにしなくて大丈夫です。読める・戻せる・気づける。この3つに一歩ずつ近づけるだけで、レガシーコードは十分に扱いやすくなります。
明日やること
- 直近で「触るのが怖い」と感じたコードを、1関数だけ選ぶ
- その関数を読むだけで「何を受け取り・何を返すか」を3行でメモする（まだ変えない）
- 呼び出し元を検索して、影響が及ぶ場所を書き出す
- 変更前の退避コピー（コミット or ファイルコピー）を取る
- 代表的な入力1〜2個で「今の出力」を記録し、特性テスト（または手動の見比べ）で固定する
- 振る舞いを変えない小さな整理（名前を1つ分かりやすく）を1か所だけやり、結果が同じか確認する
今日のチェックリスト
- 触る対象を「1関数・1ファイル」に絞った
- 変更前に退避コピー（戻せる状態）を用意した
- 「何を受け取り・何を返すか」を自分の言葉でメモした
- 呼び出し元（影響範囲）を確認した
- 今の入力→出力を記録して固定した（特性テスト or 見比べ）
- 振る舞いを変えず、整理は1か所だけにとどめた
- 整理後も結果が同じことを確認した
- 「バグ修正」と「整理」を同じ変更に混ぜていない
最初の一歩は、たぶん想像しているより小さくて大丈夫です。1関数を読み、今の動きを固定し、名前をひとつ直す。それだけでも、そのコードは「触れないもの」から「触れるもの」に変わり始めます。全部を一度に背負わなくていい。今日ひとつ、怖かったコードに小さな安全網をかけられたなら、それはもう技術的負債を返し始めた証拠です。
よければ、こちらも
- テストがないコードに手を入れる前にやる安全策
- 既存システムの改修、影響範囲を見落とさない調査の順番
- 作った人がいないシステムを引き継いだ初日にやること
- 技術的負債を「見える化」して優先順位をつける方法
保守運用の実務ヒントを、メールでお届けしています。よかったら受け取ってください。