レガシーシステムの改修テスト｜デグレを防ぐPMの判断軸

2026 8/21

2026年8月21日 2026年8月21日

「一行直しただけのはずが、翌週になってまったく別の画面から障害報告が来た」——レガシーシステムの改修テストに関わるPMなら、この冷や汗を一度は経験しているのではないでしょうか。

改修そのものは30分で終わったのに、思いもよらない場所が壊れる。原因の切り分けと謝罪に何日も溶けていきます。テストコードも仕様書もない既存システムほど、この「触っていない場所が壊れる」事故が起きやすく、そこにレガシー改修の本当の怖さがあります。

本記事は、テスト資産も仕様書もない既存システムを、限られた工数でどう安全に変えるかという「PMの判断」に絞って解説します。レガシーシステムの改修テストで最も難しいのは、テストの書き方そのものより「どこまでやるかを決めること」だからです。

そして本記事は、自動化ツールの導入手順やテストコードの実装方法は扱いません。限られた工数で「何をテストし、何を捨てるか」の判断と、顧客・上長への合意形成に絞ってお伝えします。開発者向けの技術記事とは別の、マネジメント視点の道具をお渡しします。

なぜレガシーシステムの改修テストは怖いのか（デグレの構造）

まず、恐怖の正体を言葉にしておきます。この改修が怖いのは、担当者の腕が悪いからではなく、構造的にデグレが起きやすいからです。

デグレ（デグレード）とは何か

デグレ（デグレード、デグレーション）とは、ある変更によって、これまで正常に動いていた別の機能が壊れてしまう現象を指します。今回触った箇所ではなく、一見無関係な場所で起きるのが厄介な点です。

たとえば、税率を計算する共通関数を一つ直したところ、請求書の画面表示は正しくなったのに、同じ関数を呼んでいた月次の会計連携データだけが古い税率のまま出力される、といった具合です。修正箇所と壊れた箇所が離れているほど、発見は遅れ、原因の特定に時間がかかります。

デグレが波及する経路には、いくつかの典型があります。

暗黙の依存: A機能がB機能の内部処理を前提に動いており、Bを直すとAが崩れる
共有ロジック: 複数画面が同じ共通関数を呼んでおり、一つの修正が全画面に及ぶ
データ経由の波及: 変更で保存されるデータの形が変わり、後続のバッチや帳票が誤動作する
設定・定数の共有: 共通の定数やフラグを変え、想定外の分岐が動く

デグレは「コードのつながり」だけでなく「データのつながり」でも伝わるため、画面を見ているだけでは気づけません。

レガシー特有の三重苦

苦しみ	内容	起きること
テストコードがない	自動で挙動を検証する仕組みが無い	変更の影響を機械的に確認できない
仕様書がない	正解の振る舞いが文書化されていない	「何が正しいか」の基準が誰にも分からない
作った人がいない	開発者が退職・異動している	設計意図を聞ける相手がいない

新規開発なら「仕様どおりか」を確かめれば済みます。しかしレガシーでは、その仕様そのものが失われています。

「全部テストすれば安全」が成立しない理由

「不安なら全部テストすればいい」と言いたくなりますが、これは現実には成立しません。テスト対象の母数、つまり「どこまでが影響範囲なのか」が見えないからです。

母数が見えないまま「全部」を目指すと、工数は無限に膨らみ、それでも網羅した確信は得られません。バグの存在は示せても、不在は証明できないのです。

参考として、高橋寿一氏の著書『知識ゼロから学ぶソフトウェアテスト』では「バグの約47%はプログラムの4%の部分に偏在する」という例が紹介されています。傾向として、欠陥は特定の箇所に集中しやすいということです。だからこそ、均等に薄く広くではなく、危険な箇所を見極めて厚くテストする発想が要ります。

「全部はテストできない」を出発点にする

レガシー改修のテスト戦略は、「全部はできない」という現実を認めるところから始まります。これは敗北宣言ではなく、有限のリソースを正しく配る前提条件です。

網羅は不可能という前提を共有する

まず、この前提を自分・上長・顧客の三者で共有しておくことが重要です。「テストしたのに漏れた」というトラブルの多くは、暗黙のうちに「全部テストしてくれるはず」という期待があるために起きます。

最初に「全数テストは不可能であり、リスクの高い箇所に絞って重点的に確認する」と明言しておけば、後の合意形成がぐっと楽になります。逆に、この前提を曖昧にしたまま進めると、漏れが出たときに「なぜ全部見なかったのか」という水掛け論に陥りがちです。最初のひと言が、後のトラブルを未然に防ぐ予防線になります。

テストしない範囲を「決める」のもPMの仕事

見落とされがちですが、何をテストしないかを決めることも、立派なマネジメント判断です。

「なんとなく手が回らなかった」で漏れるのと、「ここは今回リスクが低いと判断して対象外にした」と記録して漏れるのとでは、意味がまったく違います。前者は事故ですが、後者は管理された意思決定です。

捨てる範囲とその理由を記録に残す。この一手間が、後で「なぜここをテストしなかったのか」と問われたときの盾になります。

リスク＝発生確率×影響度で優先度をつける

限られた工数をどこに配るかは、リスクの大きさで決めます。リスクは「壊れる可能性の高さ（発生確率）」と「壊れたときの痛さ（影響度）」の掛け算で捉えると整理できます。

観点	高リスク（厚くテスト）	低リスク（薄く・対象外も可）
変更との距離	直接変更した箇所・その呼び出し元	変更と無関係な独立機能
利用頻度	主要導線・毎日使われる機能	ほとんど使われない画面
壊れたときの影響	課金・決済・データ更新	表示崩れ程度で済む箇所
過去の実績	以前もバグが出た箇所	長年安定している箇所

この表を顧客や上長に見せながら「ここに工数を集中させます」と説明すると、テスト計画が主観ではなく判断に見えます。なお、この「発生確率×影響度」は次章で扱う「重要度×変更への近さ」と地続きです。変更に近い箇所ほど壊れる確率が高く、重要な機能ほど壊れたときの影響が大きい、という関係になっています。

「テストしない」を記録に残す書き方

対象外にした範囲は、頭の中だけで決めず、短くてよいので必ず記録に残します。後で「なぜここを見なかったのか」と問われたときに、判断の根拠を示せるかどうかが分かれ目になるからです。

書式は凝る必要はありません。次の三点が並んでいれば十分です。

記録する項目	書く内容の例
対象外にした範囲	管理者向けの月次設定画面
対象外にした理由	今回の変更と依存がなく、利用頻度も低いため
残るリスクと前提	万一影響する場合は表示のみで、業務は止まらない見込み

この一覧を計画書やチケットに一行足しておくだけで、抜けが「事故」から「合意済みの判断」に変わります。顧客や上長との合意形成のときにも、そのまま説明材料として使えます。

影響範囲をどう見立てるか（コードだけで終わらせない）

変更点を中心に呼び出し元・共有モジュール・データ・連携先・バッチへ影響が同心円状に広がる関係図

デグレを防ぐ核心は、影響範囲の見立ての精度です。ここが甘いと、どれだけテストを頑張っても的外れになります。逆に、影響範囲さえ正しく絞れれば、少ない工数でも「危ない箇所は確かに見た」という状態を作れます。

テスト量そのものより、どこを見るかを決める段階に頭を使うべきなのは、このためです。見立ては一度で完璧を目指さず、変更に着手して新たな依存が見えたら、その都度書き足していくくらいの気持ちで臨みます。

変更箇所から追う技術的依存

まずはコード上のつながりを追います。基本は「その変更が、直接どこに触れるか」です。

変更した関数・メソッドの呼び出し元をすべて洗う
変更箇所が使う共有モジュール・共通ライブラリを確認する
同じデータベーステーブルやファイルを読み書きする他処理を探す

コードに現れない影響を見落とさない

技術的依存だけを追うと、必ず穴が空きます。

業務フロー: この機能は、どの業務のどの段階で使われるか
データ: 変更後のデータを、後続の別処理が読んでいないか
連携先: 外部システムやAPIに渡すデータ形式に影響しないか
バッチ・夜間処理: 日次・月次の集計や連携が前提を崩されないか

画面をいくら触っても見えない「夜中に動くバッチ」や「月末だけ走る処理」こそ、デグレの温床です。

「重要度×変更への近さ」の二軸で集中させる

影響範囲を洗い出したら、二軸でテストの濃淡を決めます。一つは「変更にどれだけ近いか」、もう一つは「その機能が業務上どれだけ重要か」。前章の「発生確率×影響度」を改修という文脈に落とし込んだものが、この二軸だと考えてください。両方が高い交点にテストを集中させます。

「どこにバグが偏るか」の当たりをつけるヒントも押さえておきます。

変更頻度が高い箇所: 何度も手が入り、複雑化・劣化しやすい
過去に障害が出た箇所: 構造的に脆く、再び壊れやすい
分岐（条件・例外処理）が多い箇所: 経路が多く、抜けが生まれやすい

これらが重なる場所ほど「当たり所」です。影響範囲の絞り込みそのものの手順は、回帰テストのスコープ決定術で詳しく解説しています。ただし判断の芯は本記事に残しておくと、「変更に近い×重要×過去に壊れた」の三つが重なる箇所を最優先で厚くテストする、これが工数配分の結論です。

四面でチェックすると安全です。

コード面: 呼び出し元・共有モジュール・共通定数
業務面: どの業務プロセスのどこで使われるか
データ面: 保存・参照するデータの形と、それを読む後続処理
連携面: 外部システム・API・バッチ・帳票への波及

見落としやすい依存の具体例

抽象論だけではイメージしにくいので、現場でよく踏む「見えない依存」を具体例で挙げておきます。いずれも、変更した画面の中だけを見ていても気づけないものばかりです。

共通関数の相乗り: 送料計算のロジックを注文画面のために直したら、同じ関数を使う定期購入のバッチが誤った送料を計算していた
ステータス値の追加: 受注ステータスに新しい区分を足したら、そのステータスを想定していない集計クエリが対象から漏れ、売上レポートの数字がずれた
日付フォーマットの変更: 画面表示の日付書式を整えたら、その値をそのまま出力していたCSV連携の取り込み側でエラーになった
権限チェックの共通化: ある画面の権限判定を共通部品に寄せたら、別画面で本来見えてはいけないボタンが表示されるようになった

共通しているのは、「一つの部品を複数の場所が共有している」ときほど、変更の影響が思わぬ遠くまで飛ぶという構図です。洗い出しの段階で「この部品を他に誰が使っているか」を一度立ち止まって確認するだけで、事故のかなりの部分は防げます。

仕様書がないなら、動いている本物から手がかりを得る

「仕様書がないシステムのテストはどうすればいいのか」——保守現場で最も多い悩みです。答えはシンプルで、正解は文書ではなく「今動いている本物」の中にあります。

正解は「現行の振る舞い」にある

現行システムが日々業務を回せているなら、その振る舞いこそが事実上の仕様です。

実際の画面操作: 入力に対してどんな出力が返るかを観察する
本番ログ: どんなデータが流れ、どんな処理が呼ばれているか
実データ: データベースに蓄積された値のパターンから制約を読む
コード: 最終手段だが、分岐条件から仕様を逆算できる

現場担当者・障害履歴も一次資料

手がかり源	そこから分かること
現場の運用担当者	「この機能はこう使う」という生きた仕様
過去の問い合わせ	利用者がつまずく点・想定外の使い方
障害・バグの履歴	過去に壊れた箇所＝再び壊れやすい箇所
運用マニュアル・手順書	正式仕様書より実態に近い操作の記録

障害履歴は特に価値があります。一度デグレを起こした箇所は、構造的に脆いことが多く、次の改修でも要注意ポイントになります。こうした手がかりから仕様を組み立てる進め方は、ドキュメント不足でもテストは実施できるでも扱っています。

判明した仕様は軽く書き残す

苦労して読み解いた振る舞いは、次の改修に備えて軽くメモに残しておきます。完璧な仕様書は要りません。「この画面はこう動く」という箇条書きで十分です。残すときは、次の四点だけ押さえておくと後で使える資料になります。

対象: どの画面・どの機能の話か
入力と条件: どんな値・状態のときの挙動か
期待する出力: 正常時に何が返るか（画面表示・データ・帳票）
例外・注意: つまずきやすい入力や、既知の癖

これを一改修に一枚ずつ積み重ねると、失われていた仕様が少しずつ資産に変わり、チーム全体の改修速度が上がっていきます。属人化していた「あの人しか分からない挙動」が、チームの共有知に変わっていくのも大きな効果です。

変更前に「今の振る舞い」を固定する——レガシーシステムの改修テストの核

ここが本記事の心臓部です。デグレを防ぐ最も確実な考え方は、「変える前に、変わってはいけない基準を作っておく」ことに尽きます。

現状固定とは何か（用語の整理）

改修に手をつける前に、現状のシステムが返す出力を記録し、それを「変わってはいけない基準」とします。この、既存の振る舞いを記録して差分で守る考え方を特性化テスト（characterization test）と呼びます。そのなかでも、出力全体をスナップショットとして丸ごと押さえる進め方を、特にゴールデンマスターと呼びます。つまり特性化テストという大きな考え方の一形態がゴールデンマスターであり、両者は同義ではなく包含関係です。

本記事では概念の紹介にとどめ、実装コードやフレームワーク手順には踏み込みません。ここで押さえたいのは「正しさ」ではなく「今と同じか」を基準に置く発想です。

なお、この「現状を固定し、改修後と照合してデグレを検出する」営みは、業界標準の用語では回帰テスト（リグレッションテスト）そのものです。回帰テストという用語の位置づけは、テスト技術者資格を運営するJSTQBの公式サイトが示すシラバス体系でも整理されています。想定している粒度は、主に画面・機能レベル——結合テストやE2Eテストに近い層だと考えてください。単体レベルの網羅ではなく、業務が回るかどうかを守るテストです。

ツール不要で今日からできる「現状固定」の最小手

「特性化テストと言われても、今日から何をすればいいのか」——ここが一番大事です。専用ツールもテストコードも要りません。手作業でも現状固定はできます。

今回触る機能の「代表入力」を複数選ぶ。正常系の代表値だけでなく、境界値（上限・下限・0・空）や例外系（不正値・欠損データ）も含める。同値分割・境界値の考え方で、固定＝万能ではないと意識する
改修前に、その入力での出力を残す。画面なら結果をキャプチャ保存、帳票・CSVなら出力ファイルを控える、DBなら該当レコードの値を退避する
改修後に、同じ入力でもう一度動かし、保存した出力と一目で突き合わせる

この泥臭い手作業だけで、「変えていないはずの箇所が変わった」を機械的に拾えます。まずは今週触る1機能から始めれば十分です。

差分は「意図した変更か／デグレか」を切り分ける

現状固定で最も重要な注意が二つあります。

差分＝即デグレではない: バグ修正が目的の改修では、正しく直した箇所に差分が出るのが正常です。差分が出たら必ず「意図した変更か／デグレか」を切り分け（triage）ます。この判断を飛ばすと、正しい変更まで巻き戻してしまいます
現状固定は「正しさ」を保証しない: 固定するのは今の挙動であって、その挙動が正しい保証はありません。既存のバグも「あるべき基準」として一緒に固定されてしまう点に注意が必要です。必要ならバグは別途、意図した変更として直します

この切り分けを確実にするために、もう一つ守りたい原則があります。挙動を変えない整理（リファクタリング）と、挙動を変える機能変更を、同じ回に混ぜないことです。両者を混ぜると、差分が出たときに「意図した変更なのか、デグレなのか」の判断ができなくなります。リファクタリングと機能変更の切り分けは、リファクタリングとは？も参考になります。

安全な進め方は、次の三ステップに集約できます。

固定: 変更前の振る舞いを記録し、基準を作る
変更: 一度に一つだけ、意図した変更を加える
照合: 基準と突き合わせ、意図しない差分（デグレ）がないか切り分ける

変更は小さく刻み、都度確認する

この三ステップのうち「変更」を、どれだけ小さく刻めるかで安全性は大きく変わります。十箇所をまとめて直し、最後にまとめてテストしてデグレが出たとします。原因候補が十個あって相互に絡むため、「どの一手が壊したのか」の特定は非常に困難です。

一方、一箇所直すたびに確認すれば、デグレが出た瞬間に「今の一手が原因」と即座に分かります。変更を小さく刻む最大の利点は、テストが楽になることではなく、壊れたときに原因が一目で分かることです。

一度の変更は、意味のある最小単位にとどめる
変更ごとに、その場で確認する
問題が出たら、その一手だけを戻せば元に戻せる

刻むたびに回す「最小の確認セット」は、毎回ゼロから考えず、あらかじめ固定メニュー化しておくと迷いません。

今回触った箇所: 変更が直接影響する機能
過去にデグレした箇所: 履歴から分かる脆い部分
主要導線: 業務上とりわけ重要な、絶対に止められない機能

この最小セットの組み立て方は、テスト観点の洗い出し手順の考え方が応用できます。要は、上の三点を毎回の固定メニューとして回すのが結論です。

テスト工数を顧客・上長にどう説明し、合意を取るか

守る範囲・割り切る範囲・残存リスクの3層で工数配分を説明し合意して明記する説明フレーム図

技術的に正しいテスト計画を立てても、工数の合意が取れなければ実行できません。

デグレのコストで費用対効果を語る

テスト工数を「コスト」として説明すると、削減対象に見えます。そうではなく、テストは「デグレによる手戻りと信頼失墜を防ぐ保険」として語るのが有効です。

本番でデグレが起きれば、緊急対応・原因調査・再テスト・謝罪と、事前テストとは比べものにならない工数と信用を失います。開発規模と工数・不具合の関係を客観的に示したい場合は、IPAが公開するソフトウェア開発分析データ集のような公的資料を補強材料に使えます。個別の数値を断定するのではなく、こうした客観データを土台に「事前テストの工数」と「デグレ発生時の損失」を並べて説明すると、上長の納得を得やすくなります。

稟議に使える「簡易試算フォーマット」

費用対効果は、次の枠組みに自社の数字を入れれば稟議資料になります。具体的な数値はプロジェクトごとに異なるため、ここでは計算の型だけ示します。

項目	計算の枠組み
① 本番バグ1件の対応工数	調査＋修正＋再テスト＋顧客対応の人日を合算
② 想定発生確率	テストを省いた場合に本番でデグレが出る見込み
③ デグレの期待コスト	① × ②
④ 事前テスト工数	今回、重点テストにかける人日
判断	③（期待コスト）が ④（テスト工数）を上回れば、テストは投資回収に見合う

数字は自社の実績（過去の障害対応にかかった人日など）から埋めます。捏造した平均値ではなく、自分たちの案件の肌感を入れるのがポイントです。

やらない範囲と残存リスクを明文化する

説明の順序	伝える内容	目的
現状リスク	このまま無防備に改修するとデグレの恐れ	課題を共有する
やること	影響範囲を絞り重点的にテストする	対策を示す
やらないこと	低リスク箇所は今回対象外とする	工数の現実を共有する
残リスク	対象外部分に残る可能性と、その低さ	想定外を予防する

顧客に「ここはテストしません」と伝えるのは角が立ちがちですが、言い換えれば波風は立ちません。たとえば「全数保証ではなく、影響度の高い範囲に工数を集中します。低リスク箇所は今回の対象外とし、残リスクは合意事項として明記します」と伝えれば、手抜きではなく合理的な設計として受け止められます。

社内リソースが限界のときの選択肢

複数案件を抱え、兼任中心のテスト体制ではどうしても手が回らない局面もあります。そうしたときは、外部の検証リソースで一時的に補うのも現実的な選択肢です。いきなり全面委託である必要はありません。まずは今回の改修で不安な1機能だけをスポットで頼むなど、小さく始める入り方もあります。

判断の目安は、次のように整理できます。

状況	現実的な打ち手
特定の1機能だけが不安	その範囲をスポットで外部検証に出す
回帰テストの手作業が毎回重い	現状固定・照合の作業を切り出して委託する
社内に検証観点の知見が薄い	影響範囲の洗い出しから伴走してもらう

結論として、内製と外注は二択ではなく、リスクの高い一部だけ外に出す配分も取り得ます。大事なのは「全部を抱える」でも「全部を手放す」でもなく、どこを自分たちで守り、どこを外に委ねるかを、リスクの大きさで線引きすることです。