作った人は退職した。設計書は残っていない。テストも存在しない。残っているのはコードだけだ。それでも業務は回っている。だから誰も触れない。そして時々、こんな言葉を耳にする。「これを壊したら会社が止まる」。
本番で毎日動き、売上を立て、現場も使っている。しかし誰も全体を説明できない。そんなシステムは、多くの組織に存在するのではないだろうか。本当に怖いのは古いコードそのものではなく、そこに何が書かれているのかを誰も説明できない状態だ。
守るべきは技術スタックではなく業務知識だ
レガシーシステムの話になると、Java、C++、VBA、Accessといった技術スタックの話題に偏りがちだ。しかし守るべき対象は技術スタックではない。業務知識である。
コードには、請求タイミング、例外処理、単価計算、締日ルール、状態遷移といった、長年積み上がった現場の知恵が埋まっている。価値があるのはJavaで書かれているからではない。そのJavaの中に業務が閉じ込められているからだ。
全面リプレースが進まない理由
レガシー再開発は昔から試みられてきた。しかし、その多くは期待どおりに終わらない。
失敗の原因は実装コストの高さだけではない。業務知識の回収コストが高いことにある。ヒアリングし、仕様書を探し、現場に確認し、実際に動かしてみる。何か月もかけて設計書を復元する作業は、多くの組織で後回しにされる。その結果、人は決断できない。「今動いているから触らない」。これが、多くのレガシーシステムに共通する停滞の構造だ。
AIは書く前に読める
AIの活用というと、コード生成が注目されがちだ。しかし既存システムに対しては、読む力のほうが重要になると私は考える。
既存システムに対して、AIには画面一覧の作成、状態遷移の整理、業務ルールの抽出、責務の分類を任せられる。つまりAIは実装者であるだけでなく、調査員にもなれる。たとえば、次のように頼むだけで、既存システムの構造は文書の形で手元に残る。
このコードを精読して、責務、状態遷移、例外処理、画面構築などを設計ドキュメントとして出力して。
AIによる読解は、この回収コストを下げ、全面リプレースの前提を変える。
ただし、AIが抽出した業務ルールには誤読が含まれうる。だからこそ、人間が確認するステップが必要になる。
既存システムの作業は調査から始まる
新規開発は、壁打ちから始まり、設計、実装へと進む。既存システムは違う。まず現物がある。したがって作業は次の流れになる。
調査 → 報告 → 相談 → 仕様化 → 設計 → 実装
調査では、AIに既存コードを読ませ、業務ルールや責務を取り出す。報告では、その結果を人間に示す。相談では、「この解釈で合っているか」「本当に必要な業務か」「今ならどう作るべきか」を検討する。
たとえば、次のように頼める。
このドキュメントを見て、この業務ルールに矛盾や抜けがないか指摘して。根拠になるコードの箇所も示して。
仕様化では、相談で確定した振る舞いをテストとして書き、仕様を固定する。既存コードの現状を記録する特性テストである。AIはテストケースを大量に生成できるが、どの振る舞いを正とするかは人間が決める。現状の振る舞いには既存のバグも含まれるため、その判断は相談の段階で済ませておく必要がある。
たとえば、次のように頼める。
この関数の今の振る舞いを、テストケースとして書いて。正しいかどうかは判断せず、現状どおりの結果を期待値にして。
既存システムは負債ではなく鉱山だ
以前は、レガシーシステムを負債として捉えていた。しかし見方は変わりつつある。
コードは価値そのものではない。だが、コードの中には業務知識という価値が埋まっている。既存システムは保守対象というより、業務知識の鉱山だと考えられる。
AIによって、その鉱脈を掘り当てるコストは大きく下がった。もしそうなら、古いコードを延命するために苦しみ続ける必要はない。まず採掘して業務知識を取り出し、そのうえで新しい技術で作り直す。そうした選択肢が現実味を帯びてきた。
まとめ
いつか、システムを動かす器は消える。古いOSかもしれない、古いOfficeかもしれない、古いランタイムかもしれない。しかし業務は続く。問題は、業務を知る人がいなくなる前に、その知識を掘り出せるかどうかだ。
AIはコード生成ツールとして語られることが多い。しかし本当に価値があるのは、コードの中から業務知識を採掘できるようになったことかもしれない。