レガシー刷新はどの順番で進めるべきか？──「読めたら、すぐ作る」が一番危ない理由

Q01レガシー刷新は、どの順番で進めるべきですか？

「①現行を読み解く→②検証できる形にする→③優先順位をつける→④作る」の順番です。危ない順番との差は1か所だけ──作る前に「検証できる形」を用意しているかどうかです。

このステップ②が、地味ですが効きます。読めた直後に作り始めるのではなく、現行を「答え合わせできる形」にしてから作る。順番をひとつ変えるだけで、刷新の景色は本当に変わります。

Q02AIで現行コードが読めたら、すぐ作り直してはいけないのですか？

いけません。レガシー刷新には、新規開発にない特殊事情があります。正解が、もうこの世に存在している──目の前で動いている現行システムが正解そのものだからです。ゼロから理想を作る話ではなく、「同じ挙動を、作り直す」話です。

Q03刷新プロジェクトが事故る現場の共通点は何ですか？

正解（現行）はあるのに、作り直したものと突き合わせる手段がないことです。現行の業務ルールが誰かの頭の中にしか残っておらず、「新しいものが本当に現行と同じ動きか」を確かめる物差しがないまま走り出すから事故ります。

Q04「現行を検証できる形にする」とは、具体的に何をするのですか？

現行の業務ルール・テスト観点・影響範囲を書き出し、新旧の答え合わせができる「採点表」を作ることです。AIに現行コードを渡して「この処理が満たすべき入出力の条件を、業務ルールとして一覧にして」と頼むと、人が数週間かけて棚卸ししていた暗黙の仕様が、叩き台として返ってきます。

さらに「この古い処理の中の判断条件を、もし〜なら〜の箇条書きに」と頼むと、頭の中にしかなかった判断ルール（IF-THEN）が表に出ます。あとは、そこから起こしたテストケースに同じ入力を流して、新旧の出力を照合する。これが答え合わせの土台になります。

ベテランしか書けなかったテスト観点をAIが拾い始めている、という報告もあります。ある研究では、人手で挙げたテスト項目の7割ほどを生成AIが抽出できたと。一実験の値なので断定はしませんが、「検証を仕組みにする」流れが絵空事ではなくなってきたのは確かです。

Q05レガシー刷新で、AIに丸投げしてはいけない工程はありますか？

あります。最後に人が新旧を見比べて「同じだ」と確かめてから切り替える工程です。しかも一気に全部ではなく、検証できたところから順に進めます。ここだけはAIに丸投げしない場所として残します。

よくある質問（FAQ）

Q. 仕様書が現物と違う場合は、どうすればいいですか？

A. よくあるケースです。正解は現行コードの挙動の中にしかないため、AIに現行コードを読ませて業務ルールや判断条件を書き出させ、挙動を「答え合わせできる形」にするのが「作る」より先の仕事になります。

Q. 答え合わせの「採点表」はAIに作らせられますか？

A. 作らせられます。現行コードを渡して「この処理が満たすべき入出力の条件を業務ルールとして一覧にして」と頼むと叩き台が返ってきます。人が数週間かけていた暗黙仕様の棚卸しの、最初の一歩になります。

Q. 一気に全面刷新すべきですか？

A. 勧めません。検証できたところから順に作り、人が新旧を見比べて「同じだ」と確かめてから切り替えるのが安全な進め方です。

Q. 読み解きや検証の前工程が重すぎる場合は、どうすればいいですか？

A. 毎回ゼロから手作業でやると確かに重い工程です。この前工程そのものを仕組み化するアプローチがあり、当サイトの「巨大な基幹システムをAIはどこまで読み解けるのか」の記事で実測値とあわせて解説しています。