BLOG

FIELD NOTES / MODERNIZATION ORDER

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

公開日 最終更新日 著者: 黛 政隆(株式会社GembaShift 代表取締役)

現行のコードが、AIで読めるようになった。じゃあ、すぐ作り直せばいい。──そう思った瞬間が、一番あぶないんです。

「AIを現場で動かす」がミッションの株式会社GembaShift代表の黛(まゆずみ)です。長年ブラックボックスだった基幹システムが生成AIで読めるようになってきた今、次の問いは「読めたあと、何から手をつけるか」です。

先に結論を置いておきます。レガシー刷新の成否は、技術力でも予算でもなく、手をつける順番でだいたい決まります

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

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

危ない順番と効く順番の比較。いきなり作ると答え合わせができない。読み解く→検証できる形にする→優先順位→作る、が効く順番
危ない順番と効く順番の比較。いきなり作ると答え合わせができない。読み解く→検証できる形にする→優先順位→作る、が効く順番

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

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

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

作るのは、本当に速くなりました。仕様をAIに渡して画面もロジックもどんどん吐かせるスピードは、もう疑う段階ではありません。だからこそ「読めたなら、もう作れる」に直行しがちです。

でも、ここを甘く見ると、速く・自信満々に・微妙に違うものを量産することになります。公共や大企業の大型刷新が、稼働直前で凍結したり長い係争に発展した例は珍しくありません。 「作れたはず」と「同じものが作れた」の間には、深い谷がある のです。

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

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

現場でよく聞くのが「仕様書? ありますけど、たぶん現物とは違いますよ」という一言です。正解は、現行コードの挙動の中にしかありません。

AI導入をやっていて確信していることがあります。「正しく作らせる」工夫と「間違いを見つける」仕組みは、まったく別物だということ。作る精度をいくら上げても間違いはゼロにならないので、照らし合わせて間違いを拾う仕組みがなければ、いつか必ず事故ります。

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

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

現行を検証できる形にする手順。業務ルール・テスト観点・影響範囲を書き出し、新旧の答え合わせができる採点表をつくる
現行を検証できる形にする手順。業務ルール・テスト観点・影響範囲を書き出し、新旧の答え合わせができる採点表をつくる

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

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

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

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

正直に言うと、私も昔、検証を後回しにして痛い目を見ています。作る方ばかり先に整えて答え合わせを後にしたら、ズレに気づくのが遅れて手戻りがどんどん膨らみました。作れること自体は、安全を1ミリも保証してくれません。

やることはシンプルです。「読めたら、すぐ作る」をやめて、「読めたら、まず答え合わせの土台をつくる」に変える。順番を、ひとつ変えるだけです。

よくある質問(FAQ)

Q. 仕様書が現物と違う場合は、どうすればいいですか?
A. よくあるケースです。正解は現行コードの挙動の中にしかないため、AIに現行コードを読ませて業務ルールや判断条件を書き出させ、挙動を「答え合わせできる形」にするのが「作る」より先の仕事になります。
Q. 答え合わせの「採点表」はAIに作らせられますか?
A. 作らせられます。現行コードを渡して「この処理が満たすべき入出力の条件を業務ルールとして一覧にして」と頼むと叩き台が返ってきます。人が数週間かけていた暗黙仕様の棚卸しの、最初の一歩になります。
Q. 一気に全面刷新すべきですか?
A. 勧めません。検証できたところから順に作り、人が新旧を見比べて「同じだ」と確かめてから切り替えるのが安全な進め方です。
Q. 読み解きや検証の前工程が重すぎる場合は、どうすればいいですか?
A. 毎回ゼロから手作業でやると確かに重い工程です。この前工程そのものを仕組み化するアプローチがあり、当サイトの「巨大な基幹システムをAIはどこまで読み解けるのか」の記事で実測値とあわせて解説しています。

AUTHOR

株式会社GembaShift 代表取締役CEO 黛 政隆

黛 政隆(まゆずみ まさたか)

株式会社GembaShift 代表取締役CEO

エンジニア歴20年、PM経験50件超。生成AIの導入を、現場に入って一緒に組む仕事をしています。 この記事の内容は、著者自身が実際に手を動かして業務で検証した実体験に基づいています。

FREE DOWNLOAD

AI導入の仕分けチェックシート

この記事の仕分け方を、24の問いのシートにしました。メール登録で無料で受け取れます。

無料で受け取る

まずは、現場の話から。

御社で一番「触るのが怖い」基幹システムを思い浮かべてください。いきなり作り直す前に、それを「検証できる形」に落とす前工程をどの順番で進めるか、30分の無料相談で一緒に整理します。