レガシー改修では、どうしても複雑なコードに目が行きます。
処理が長い。分岐が深い。命名が古い。コメントが少ない。
読むだけで時間がかかるコードは、たしかに扱いにくいです。
ただ、実際に手を入れるときに怖いのは、コードが複雑なことだけではありません。
「このコードは、削除してよいのか」が判断できないことがあります。
コード検索をしても参照が見当たらない。画面からも呼ばれていないように見える。テストを動かしても、特に失敗しない。
それでも、すぐに不要だとは判断しにくいケースがあります。
コード検索では参照が見つからなくても、実際には夜間バッチから呼ばれていたり、外部ツールやストアドプロシージャから使われていたりすることがあります。特定のユーザーID、特定の契約状態、特定の運用手順のときだけ通る分岐として残っている場合もあります。
画面上では見えない処理でも、運用のどこかで使われている可能性があります。ここが、レガシー改修の難しいところです。
参照がないように見えても、使われていないとは限らない
コード検索は、とても頼りになる確認手段です。
呼び出し元を追い、参照関係を見て、影響範囲を絞る作業は欠かせません。
ただ、検索で見つからないことと、実際に使われていないことは同じではありません。
たとえば、設定ファイルからクラス名や関数名を文字列で指定している場合、通常の参照検索では追いにくくなります。バッチ処理や外部連携、運用担当者が使う管理ツールなども、アプリケーション本体のコードだけを見ていると確認から漏れやすいです。
ゲーム開発やWebサービスの運用でも、似たようなことは起きます。
特定のイベント期間だけ動く処理、古い課金導線の互換処理、管理画面からだけ呼ばれる処理、障害対応のために残された一時的な分岐。普段の動作確認では通らない道が、リリース後や運用作業の中で急に必要になることがあります。
参照がないように見えるコードを見つけたときは、「消せる」と決める前に、どこから動く可能性があるかを確認した方が安全です。
古いコードには、過去の判断が残っている
古いコードは、必ずしも質が低いコードとは限りません。
今の設計方針から見ると、読みづらいものはあります。命名規則が揃っていないこともありますし、責務の分け方が今の基準とは合わないこともあります。
それでも、そのコードが残っている背景には、過去の障害対応や運用上の事情がある場合があります。
当時の仕様変更に追いつくために入れた分岐。
特定の端末やブラウザでだけ起きる不具合を避けるための処理。
外部システムとの連携条件を満たすために残した変換処理。
問い合わせ対応で必要になった管理用の処理。
今見ると不自然でも、その時点では必要だった可能性があります。
レガシーコードは、単に古いコードというより、過去の判断と運用の積み重ねが残った履歴に近いものです。
その履歴を知らないまま整理を進めると、実装上はきれいになっても、運用で必要だった処理まで消してしまうことがあります。
コードを読む力と、コードの意図を確認する力は別のスキル
レガシー改修では、コードを読む力が求められます。
ただ、実際には「コードを読めること」と、「そのコードがなぜ残っているのかを確認できること」は、別のスキルとして見た方がよいケースがあります。
処理内容は追える。
分岐条件も読める。
変数の値もログで確認できる。
それでも、なぜその分岐が必要だったのか、今も必要なのか、削除したときに誰のどの作業に影響するのかまでは、コードだけでは分からないことがあります。
仕様書、チケット、障害対応の記録、リリース履歴、運用手順、問い合わせ対応のメモ。
こうした情報を合わせて見ないと、判断しにくいコードがあります。
ここで見たいのは、書いた人の良し悪しではありません。
確認すべき情報が残っていない状態そのものが、改修を難しくしています。
担当者が変わり、運用が変わり、使われ方が変わる中で、コードだけが残ることがあります。すると、後から触る開発メンバーは、処理の意味だけでなく、判断の根拠まで探すことになります。
「壊す」前に確認できることを増やす
不要なコードを整理することは、もちろん大事です。
使われていない処理を残し続けると、読む範囲が増えます。修正時の影響範囲を追いにくくなります。レビューでも、どこまで確認すればよいか迷いやすくなります。
だから、整理しない方が安全という話ではありません。
テストやツールを使いながら、安全に削除できる状態を作っていくことが大切です。
削除候補のコードを見つけたら、参照検索だけで判断せず、バッチ、外部ツール、ストアドプロシージャ、設定ファイル、管理画面、運用手順も確認します。ログを追加できるなら、一定期間その処理が通っているかを見る方法もあります。
テストで確認できる範囲を増やすことも助かります。
ユニットテストだけでなく、結合テスト、バッチ実行、管理画面の操作、特定条件でのデータ処理まで確認できると、削除や整理の判断がしやすくなります。
判断に迷う場合は、すぐに消さず、削除候補として記録するだけでも前に進みます。
どの処理を見たのか、何を根拠に残したのか、次に何を確認すればよいのかが残っていれば、後から同じ調査を繰り返しにくくなります。
整理は、負債を資産に変える作業でもある
レガシー改修では、「壊す勇気」が必要になる場面があります。
古い処理を残し続けるだけでは、開発の負担が減りません。
ただ、その勇気と同じくらい、背景を確認する姿勢も大切です。
なぜこのコードがあるのか。
今も使われているのか。
使われているなら、どの画面、どのバッチ、どの運用で必要なのか。
削除する場合、どのテストで確認できるのか。
残す場合、次に触る人が判断できるように何を記録するのか。
こうした確認があると、単に古いコードを消すだけでなく、システムの理解が進みます。
レビュー時に見るポイントを揃えやすくなり、実装担当者も修正範囲を判断しやすくなります。テスト担当者も、どの条件を確認すればよいか決めやすくなります。
怖いのは、古いコードそのものではなく、判断材料がないまま触ることです。
コード、テスト、ログ、運用記録をつなげて見られる状態にしていくと、次に同じ処理を見た人が迷う時間を減らせます。
レガシーコードは、放っておくと負担になります。
ただ、理由を確認しながら少しずつ整理すれば、過去の判断を今の開発に使える情報へ変えていけます。そこまで含めて、レガシー改修の腕の見せどころなのだと思います。
おわりに
X（旧Twitter）やBlueskyを中心に日々発信しております。
是非他のSNSもご覧いただけますと幸甚でございます。
https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social
https://www.facebook.com/ichino.souta
また、辰巳電子工業SS事業部では、エンジニアが安心して長く働ける環境づくりに取り組んでおります。「今の経験で応募できるか知りたい」「案件やキャリア支援について聞いてみたい」という方は、是非カジュアル面談からお気軽にご相談願います。
