テストがないコードに手を入れる前にやる安全策｜一人保守の現場で
「ここ、直しておいて」と渡されたのは、誰が書いたのかも分からない古いコード。 コメントはほとんどなく、関数は長く、似た処理があちこちに散らばっている。そして当然のように、テストはひとつもない。
直したい場所は分かる。でも、その一行を変えたら、どこか別の場所が静かに壊れるんじゃないか——そう思うと、手が止まりますよね。
この怖さは、あなたの技術が足りないからではありません。 「壊れたらすぐ気づける仕組み」がないまま、本番で動いているコードを触らされている——ただそれだけのことです。テストがあるコードなら、変なところを触った瞬間に赤くなって教えてくれます。それがない場所では、誰だって慎重になります。
この記事では、テストがないコードに手を入れる前に、「壊さずに直す」ための守りを先に用意するやり方を、一人保守の現場目線で一緒に整理していきます。一度に全部そろえなくて大丈夫です。まず次の1回ぶんの改修から始められる、小さな備えからお話しします。
結論：テストがないコードは、いきなり直さない。先に「壊れたら気づける状態」を作ってから触ります。やることは4つ。①触る範囲をできるだけ小さく区切る、②今の動き（入力と出力）を記録して"正解"を控える、③本番のコピー（検証環境）で先に試す、④変えたら、控えた"正解"と見比べて確かめる。まずは「今このコードが何を返しているか」を1パターン記録するところから始めます。
言語や構成（PHP・Java・社内システム・WordPressなど）によって、できる備えの種類は変わります。 この記事の考え方を出発点に、自分の環境で取れる手段に読み替えてください。本番に反映する前には、必ず検証環境や公式情報で確認しましょう。
なぜ「テストがないコード」はこんなに怖いのか
手が止まるのは、臆病だからではありません。理由がちゃんとあります。まずそこを言葉にしておくと、対策が見えてきます。
- 変えた影響が、すぐには分からない：テストがあれば「壊した瞬間」に気づけます。ないと、本番で誰かが操作して初めて発覚する。気づくのが遅れるほど、傷は深くなります。
- どこから呼ばれているか見えない：その関数を、自分の知らない別の画面やバッチが使っているかもしれない。「ここだけ直したつもり」が、思わぬ場所に飛び火します。
- "正しい動き"が誰も分からない：仕様書がなく、作った人もいない。今の動きが正解なのかバグなのかすら、判断できない。
- 一人で抱えていて、聞ける人がいない：「これ触って大丈夫ですか」と確認できる相手がいない。最後の判断を、全部自分でしないといけない。
どれも「気をつけて直す」だけでは消えない怖さです。だからこそ、直す前に守りを用意することが効いてきます。順番に見ていきましょう。
安全策の全体像：直す前に「守り」を3つ用意する
テストがないコードを安全に直すコツは、いきなり本体をきれいにしようとしないことです。先に、こわごわ触るための「守り」を3つ用意します。
- 触る範囲を、できるだけ小さく区切る：システム全体を相手にしない。今回直す一箇所と、そこに関係する入口・出口だけに集中します。
- 今の動きを記録して、"正解"として控える：直す前のコードに、いくつかの入力を与えて、どんな出力を返すかを書き留めておく。これが「変えても壊れていないか」を確かめる物差しになります。
- 本番のコピー（検証環境）で先に試す：いきなり本番で直さない。同じデータ・同じ設定のコピーで動かして、おかしくなっていないかを確認してから本番に入れます。
この3つがそろってから、ようやく本体に手を入れます。順に、もう少し具体的に見ていきます。
守り①：触る範囲を、小さく区切る
古いコードを前にすると、「ついでにここも直したい」「いっそ全部書き直したい」という気持ちが湧きます。でも、テストがない状態での大きな書き換えは、いちばん事故を起こします。
まずやるのは、今回の改修で「変える場所」と「変えない場所」の線を引くことです。
- 今回直すのはどの関数・どのファイルの、どの部分かを、一文で言えるまで絞る。
- その部分が何を受け取って（入力）、何を返すか（出力）を確認する。
- 「ついで」の改善は、別の機会のメモに逃がす。今回は混ぜない。
範囲が小さいほど、影響も追いやすく、戻すのも簡単です。「全部きれいにしたい」気持ちは大切ですが、今日守るべきは"動いている本番"。改善は、安全に直せる足場ができてから少しずつで大丈夫です。
守り②：今の動きを「記録」して、正解を控える
ここが、テストがないコードを直すときのいちばんのコツです。 やりたいのは、「直す前のコードが、今どう動いているか」をそのまま記録すること。これがあれば、直したあとに「前と同じ動きか」を見比べられます。
これは、正しい仕様を当てる作業ではありません。今の動き（正しかろうがバグだろうが）を、そのまま"現状の正解"として固定する作業です。専門的には「現状の振る舞いを写し取るテスト（characterization test）」と呼ばれますが、難しく考えなくて大丈夫。やることはシンプルです。
記録のしかた（テストの仕組みがなくてもできる）
- 直す対象に、代表的な入力をいくつか用意する（よくある値・空っぽ・極端な値・エラーになりそうな値など）。
- 直す前のコードにそれを通して、返ってきた出力を控える。画面の表示、戻り値、保存されたデータ、出力ファイルなど、結果が分かるものを記録します。
- テストを書ける環境なら、その入力と出力をそのままテストコードにする。書けない場合は、入力と出力の組を作業メモや表に書き留めるだけでも十分役立ちます。
記録できる「出口」を増やす小ワザ
中身が複雑で出力が見えにくいときは、一時的にログを仕込んで、何が起きているかを見える化します。関数の入り口で受け取った値、出口で返す値をログに出しておくと、現状の動きを記録しやすくなります（このログは、改修が終わったら消すか、調査用として整理して残します）。
ここまでやると、「直したら、記録した出力と見比べる」という確かめ方ができるようになります。当てずっぽうで"動いてそう"を卒業して、"前と同じだと確かめた"に変わる——これが守り②の効果です。
AIに手伝わせるなら（たたき台として）
入力パターンや記録用テストを一から書くのがしんどいときは、対象のコードをAIに読ませて、characterization testのたたき台や、抜けがちな入力（空・極端な値・エラー系）の候補を出させる選択肢もあります。守り①で挙げた「どこから呼ばれているか」の洗い出しや、変更前後の差分レビューも、見落としの当たりをつける相棒として使えます。ただし大前提として、AIが書いたテストが緑になっても「正しい」わけではありません。それは「AIが想像した動き」をなぞっているだけかもしれず、現状の振る舞いを写し取れているとは限りません。生成された入力・出力は直す前の本物のコードに通して値を取り直し、機微な情報は渡す前に伏せ、緑か赤かは人が見て納得してから採用してください。AIは下書きを速くする道具で、何が正解かを決めるのはこちら側です。
守り③：本番のコピーで、先に試す
記録した正解を手に、いよいよ直していきます。でも、最初の試し打ちは絶対に本番でやらない。本番と同じデータ・設定のコピー（検証環境）で動かします。
- 検証環境がなければ、本番のデータを写したコピーを一時的に用意する（個人情報などはマスクする）。
- そこで直したコードを動かし、守り②で記録した出力と見比べる。
- 想定外のところが変わっていないか、エラーが出ていないかも確認する。
「検証環境を用意する余裕がない」という現場も多いですよね。それでも、せめて本番とは別の場所で一度通してから本番に入れる——この一手間が、取り返しのつかない事故をいちばん多く防ぎます。どうしても本番でしか試せないときは、後述の「戻せる形で出す」を必ずセットにしてください。
具体例：よくある3つの「触って壊した」場面
現場では、こんな形で事故が起きがちです。直し方とセットで見てみましょう。
- 共通関数を直したら、別の画面が壊れた：1つの画面のために共通関数を変えたら、同じ関数を使う他の画面が動かなくなった。→ 直す前に「どこから呼ばれているか」を検索で洗い出し、影響範囲を区切っておけば気づけました。
- 条件を一つ変えたら、別パターンがおかしくなった：if 文を少し直したら、自分が試した値では正常でも、別の入力では結果が変わっていた。→ 守り②で複数パターンの入力と出力を記録しておけば、見比べた時点で気づけました。
- 本番で直接直して、戻せなくなった：検証せず本番のファイルを直接書き換え、旧版を残していなかった。→ コピーで試す・旧版を退避するの片方でもあれば、すぐ戻せました。
どれも「もっと慎重に」では防ぎきれず、範囲を区切る・現状を記録する・コピーで試す・戻せる形で出すのどれかがあれば救えたものばかりです。
影響：守りを先に置くと、何が変わるか
テストがないコードを「守ってから直す」やり方に変えると、結果だけでなく日々の気持ちが変わります。
- 直すときの「壊したかも」という動悸が、はっきり軽くなる。記録した正解と見比べられるからです。
- バグを混入させても、本番に出る前に・自分の手元で気づける回数が増える。
- 一度記録したテストやメモが次の改修でも使える資産になり、同じコードを触るたびに少しずつ楽になる。
- 「ここは記録があるから安全に直せる」という足場が増え、怖くて触れなかったコードに、少しずつ手を入れられるようになる。
逆に、守りなしで直し続けると、いつか「自分が変えた覚えはないのに壊れている」という、原因の見えない夜が来ます。先に物差しを用意しておくことが、未来の自分を助けます。
明日やること：1パターンだけ「今の動き」を記録する
いきなりテストを全部そろえなくて大丈夫です。明日できる、いちばん小さな一歩はこれです。
- 次に直す予定のコードを1つ思い浮かべ、今回触る範囲を一文で書き出す（「○○関数の、××の計算部分だけ」）。
- そのコードがどこから呼ばれているかを、検索（grep）でざっと洗い出す。影響しそうな場所を控える。
- 代表的な入力を1つ選び、直す前のコードに通して、返ってくる出力を1つ記録する。見えにくければ一時的にログを仕込む。
- 直したあと、その入力を通して記録した出力と見比べる。同じならひと安心、違えば原因を確認する。
- できれば本番とは別の場所で一度通してから、本番に入れる。すぐ戻せるよう、変更前のファイル・設定は退避しておく。
たった1パターンの記録でも、「壊れていないか分からない」が「前と同じだと確かめた」に変わります。完璧な備えを一気に作ろうとせず、まず次の1改修から始めましょう。
「テストがないコードを直す前」チェックリスト
手を入れる前に、守りがそろっているかを確かめる項目です。コピーして、自分の改修に当ててみてください。
- 今回触る範囲を、一文で言えるくらい小さく区切ったか
- そのコードが「どこから呼ばれているか」を検索で洗い出したか
- 直す前の「今の動き」を、入力と出力のセットで1つ以上記録したか
- 代表的な入力（よくある値・空・極端な値・エラー系）を意識して選んだか
- 出力が見えにくい場合、一時的にログを仕込んで現状を見える化したか
- 本番ではなく、コピー（検証環境）で先に動かして確かめたか
- 直したあと、記録した出力と見比べて「前と同じ」を確認したか
- 変更前のファイル・設定を退避し、すぐ戻せる状態にしてあるか
- 「ついでの改善」を今回に混ぜず、別メモに逃がしたか
- 記録したテスト・メモを、次回も使えるよう残したか
全部に○が付かなくても大丈夫です。1つでも「守り」を足せたら、それだけで次の改修の怖さはぐっと下がります。
よければ、こちらも
テストがないコードの改修は、影響範囲の調査・データ修正・リリースの戻し方・引き継ぎと地続きの仕事です。あわせて整えておくと、いざという時に落ち着けます。
- 既存システムの改修｜影響範囲を見落とさない調査の順番：「どこから呼ばれているか」を見落とさないための、調査の進め方です。
- データ修正をSQLで安全に行う手順｜バックアップと件数確認：コードだけでなくデータを触るときの、戻せる形の作り方です。
- ロールバック手順の作り方｜すぐ戻せるリリース設計を一人運用で：直した結果を本番に出すとき、戻せる状態で出すための段取りです。
- 作った人がいないシステムを引き継いだ初日にやること：誰も知らないコードと向き合う、その最初の一歩を整理しています。
テストのないコードが怖いのは、あなたが慎重すぎるからではありません。気づける仕組みがないまま、大事な本番を任されているからです。 今日は、次に直すコードの「今の動き」を1パターン記録するだけで十分です。その小さな物差しが、「壊したかも」という不安から、あなたを少しずつ解放してくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。