改修後のデグレを防ぐ｜回帰確認する範囲の決め方
「直したいところは、ちゃんと直った」。 そこまで確認して、いざ本番に当てる。数日後、まったく別の画面から「エラーが出る」と問い合わせが来て、たどってみたらあの改修が原因だった——。保守運用をしていると、この「直したはずが、別のどこかを壊していた」がいちばん後を引く失敗ですよね。
これはデグレ（デグレード＝改修によって、前は動いていた別の箇所が動かなくなる後退）と呼ばれる現象です。厄介なのは、直したところ自体は正しく直っているので、その場では気づけないこと。そして一人運用だと、「ほかも見て」と言ってくれる人がいないぶん、確認の範囲を自分ひとりで決めなければなりません。
かといって、毎回システム全部を触って確かめる時間はありません。ここで必要なのは、「どこまで確認すればいいか」を影響の経路から絞り込む考え方です。この記事では、テストが揃っていなくても使える回帰確認（かいきかくにん＝直した箇所以外が前と同じに動くかを確かめること）の範囲の決め方を、一緒に整理します。
結論：デグレを防ぐ回帰確認は「全部見る」ではなく、影響が伝わる経路をたどって3階層だけ確かめます。①直接（直したもの自体が、狙いどおり直ったか）→ ②隣（それを呼んでいる側・同じデータや設定を共有する箇所）→ ③出口（メール・帳票・バッチ・外部連携など、後で人やシステムが受け取る場所）。全部を等しく見るのではなく、壊れても気づきにくい所・戻せない出口から優先して確認します。
確認に使うコマンドや画面は、言語・構成・システムの作りで変わります。ここで持ち帰ってほしいのは順番と観点です。自分の現場の道具に置き換えて使ってください。
何が起きているか：なぜ「直したところ」以外が壊れるのか
直したところは直っているのに別が壊れる。これは不思議なことではなく、システムに次のようなつながりがあるから起きます。自分の確認不足を責める前に、構造を知っておくと範囲を決めやすくなります。
- 共有されている：直した関数・カラム・設定値が、その画面だけでなく、離れた別の処理からも使われている。片方に合わせて変えると、もう片方の前提が崩れる。
- 見えないところで呼ばれている：画面からは呼ばれていなくても、夜間バッチや外部連携、非同期処理がこっそり同じ処理を使っている。手元で動かしても、その経路は動かないので気づけない。
- 出口が別にある：画面表示はよくても、同じデータを使うメール・帳票・CSV・APIレスポンスの見た目や中身が変わってしまう。人が受け取って初めて発覚する。
- 一人だと確認の目が一組しかない：レビューしてくれる人がいない一人運用では、「そこ、あっちにも影響しない?」と気づいてくれる相手が自分だけ。だからこそ、確認の範囲を型として外に持っておくことが効きます。
つまりデグレは、腕の問題ではなく「つながりを見落とす」構造の問題です。だから対策も、つながりをたどって確認範囲を決めるという形になります。
回帰確認の範囲を決める3階層
改修が終わったら、直した箇所を中心に、内側から外へ順番に確認していきます。すべてを均等に見るのではなく、影響が届きそうな経路だけをたどるのがコツです。
① 直接：直したもの自体が、狙いどおり直ったか
まずは当たり前ですが、直したかった不具合が本当に直っているかを確かめます。
- 元の問題が再現しなくなったか。直す前に再現手順を控えておき、それをそのままなぞる。
- 直したことで、その画面・機能自体に別のおかしさが出ていないか。境界（空欄、ゼロ、最大値、日付またぎなど）も軽く触る。
- ここは「直った気がする」で終わらせない。直す前と後で、同じ操作を1回ずつ通すのが確実です。
再現手順の押さえ方はバグの再現から原因特定までの最短ルートにまとめています。直す前に再現を固めておくと、直った確認もそのまま楽になります。
② 隣：それを呼んでいる側・同じものを共有している箇所
デグレがいちばん潜みやすいのが、この「隣」です。直したものがどこから使われているかを、着手前の影響範囲調査を手がかりにたどります。
- 触った関数名・カラム名・設定キーで検索し（
grep -rn "対象の名前" .、Git管理下ならgit grep -n "対象の名前"）、呼び出し元を一覧にする。 - 同じデータ（テーブル・カラム）を読み書きしている別の画面や処理がないか。片方の入れ方を変えると、もう片方の読み方が崩れることがある。
- 共通関数・共通部品を直した場合は、それを使っている画面を代表的に2〜3本、実際に動かしてみる。全部は無理でも、性格の違うものを選ぶと網羅性が上がる。
ここで「呼び出し元が多い」と分かったら、それは範囲を広げる合図です。影響範囲そのものを抜けなく洗い出す順番は既存システムの改修｜影響範囲を見落とさない調査の順番にありますので、着手前とセットで使ってください。
③ 出口：後で人やシステムが受け取る場所
画面の中だけ見て安心してしまいがちですが、同じデータは画面の外にも出ていきます。ここは壊れても即座に気づけないぶん、優先して確認します。
- メール・通知：文言やデータを流用していないか。変えたなら、検証環境で実際に1通送って中身を見る。送信済みは戻せないので、本番前に必ず。
- 帳票・CSV・ダウンロード：桁・並び・項目名が変わっていないか。受け取った相手が使えなくなる形になっていないか。
- バッチ・非同期処理：夜間や定期で動く処理が同じロジックを使っているなら、可能なら手動で一度流して結果を確認する。動かせないなら、次回実行後の結果を見る算段を先に決めておく。
- 外部連携・API：レスポンスの形や値が変わって、連携先が受け取れなくならないか。相手がいる分、事前確認の価値が高い。
出口は「後で人が見る／別システムが受け取る」場所です。壊れると発覚が遅れ、戻すのも難しい。だから3階層の中でも、ここを最優先で確認すると決めておくと迷いません。
具体例：「送料の計算を1か所直す」を3階層で見てみる
たとえば「送料の計算がおかしいので、計算関数を1か所直したい」という改修。3階層に当てるとこう見えてきます。
- ①直接：不具合のあった条件（たとえば離島の送料）で、直った値が出るか。ついでに通常地域・送料無料の境界も1回ずつ確認 → OK。
- ②隣：
calc_shippingでgrep → 注文画面のほかに、カート画面の合計表示と、注文確定後のマイページ表示が同じ関数を呼んでいた。3画面とも同じ送料が出るか確認 → カート画面の表示だけ古い値のままキャッシュされていて食い違う、と発見。 - ③出口：送料は注文確認メールと、経理向けの売上CSVにも入っていた。検証でメールを1通送り、CSVを1件出して、金額が一致するか確認 → 一致。
「送料計算を1か所」のはずが、②でカート表示との食い違い、③でメールとCSVという出口が見つかりました。もし①だけ見て本番に当てていたら、注文画面は正しいのにカートとメールで金額が違う、という一番ややこしいデグレを世に出していたことになります。ここに気づけたのは、直したあとに隣と出口をたどったからです。
影響：確認範囲を決めておくと、何が変わるか
回帰確認の範囲を3階層で持っておくと、改修そのものより先に、判断の軸が手に入ります。
- 「全部見なきゃ」でも「直したとこだけでいいや」でもなく、影響の経路に沿って必要な分だけ確認できる。時間の使いどころがはっきりする。
- 「どこまで見たか」を自分でも人にも説明できる。「①②③を通しました」と言えると、本番反映の判断に根拠が持てる。
- デグレが起きても、確認済みの範囲が記録に残っていれば、切り分けの出発点になる。「見たところ以外が怪しい」と早く絞れる。
- 毎回ゼロから「どこ見よう」と考えなくてよくなり、忙しい日でも確認の質が落ちにくい。
逆に、範囲を決めずに「なんとなく」で確認していると、余裕のある日は広く見て、忙しい日は直したところだけ、とムラが出ます。そのムラのある日に限って、出口が壊れていたりするものです。
明日やること：次の改修で「隣と出口」を1回ずつたどる
いきなり回帰テストの仕組みを整える必要はありません。明日できる、いちばん小さな一歩はこれです。
- 次の改修で、直す前に再現手順（または正常時の動き）を1つ控える。
- 直したあと、①：控えた手順をなぞって、直ったこと・変な副作用がないことを確認する。
- ②：触った名前で
grep（またはgit grep）を1回かけ、呼び出し元を一覧にする。共通部品なら代表2〜3本を実際に動かす。 - ③：そのデータがメール・帳票・バッチ・外部連携に出ていかないかを一度だけ考え、出ていくなら検証で1回だけ通す。
- 見た範囲を1行メモに残す（「①②③まで確認。③はメールのみ検証で送信済み」）。
慣れれば、影響の小さい改修なら数分で通せます。全部の経路を完璧に追う必要はありません。「隣と出口を一度は思い出す」、それだけでデグレの多くは本番に出る前に止まります。
「デグレを防ぐ回帰確認」チェックリスト
改修を本番に当てる前に、これだけ確認できているかを見る項目です。コピーして自分のメモに当ててみてください。全部を毎回構える必要はありません。
まず外せない最低ラインはこの3つ。
- 【最低ライン・①直接】直したい不具合が直り、その機能に新たな副作用が出ていないか（直す前の手順でなぞった）
- 【最低ライン・②隣】触った名前で検索し、呼び出し元・同じデータを使う箇所を一覧にしたか
- 【最低ライン・③出口】そのデータがメール・帳票・バッチ・外部連携に出ていかないか、一度考えたか
次は、共通部品を直したとき・出口に波及するときだけ追加で確認します。当てはまらなければ飛ばして大丈夫です。
- 共通関数・共通部品なら、性格の違う呼び出し元を2〜3本、実際に動かしたか
- メール・通知に波及するなら、検証環境で実際に1通送って中身を見たか
- 帳票・CSVに波及するなら、桁・並び・項目名が変わっていないか確認したか
- バッチ・非同期・外部連携が同じ処理を使うなら、手動実行か次回結果の確認を段取りしたか
- どこまで確認したかを1行記録したか
全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに③の出口を思い出せた時点で、いちばん気づきにくいデグレはかなり防げています。
よければ、こちらも
回帰確認は、安全な改修の「出口側」の備えです。着手前の影響調査や、テストがない状態での安全策とセットにしておくと、改修の前後がつながって楽になります。
- 既存システムの改修｜影響範囲を見落とさない調査の順番：②の「隣」を、着手前に抜けなく洗い出したいときに。
- テストがないコードに手を入れる前にやる安全策：自動テストが頼れない現場で、手動でも後退を防ぐ工夫を整理しています。
- 小さな改修の変更前チェックリスト｜本番事故を防ぐ確認の型：着手前の確認と合わせて、改修の前後を1枚でつなげたいときに。
デグレがこわいのは、直したところは直っているのに、離れた場所がこっそり壊れて、あとから発覚するからです。でも、直したものを中心に「隣」と「出口」を一度たどる型があれば、その見落としはちゃんと減らせます。 今日は次の改修で、直したあとに grep を1回かけて呼び出し元を数え、そのデータがメールや帳票に出ていかないかを一度だけ思い出してみてください。その一手間が、あなたを「まさか、あの改修で」から守ってくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。