メインフレーム“撤退表明”で待ったなし――AI時代、レガシー刷新は「変換」の話ではなくなった：2035年へのレガシーモダナイゼーション実務論（1）（1/2 ページ）

国産メインフレームからの撤退表明が相次ぎ、待ったなしとなったレガシーシステムの刷新。AIによって解析や変換が速くなる中、「AIに何を任せ、人は何を決めるのか」という視点から、2035年を見据えたモダナイゼーションの実務を考える。

[中野恭秀（アクセンチュア）, 編集：遠藤文康，＠IT]

　国産メインフレームからの撤退表明が相次ぎ、レガシー刷新は先送りできなくなった。AIはその刷新を確かに速くしている。ただし、速くなるのは工程の一部でしかない。本連載では、AIに任せられる領域と、人が決め続けなければならない領域の線引きを、移行の実務の順番に沿って考えていく。

　初回は、この連載の出発点から始めたい。AIによってレガシー刷新の何が変わり、何が変わらず残るのか。

「それで、何から手を付ければいい？」――3本の記事で残った宿題

　この夏、＠ITに筆者を取材した記事が3本掲載された。

　日本のメインフレームがなぜ世界と違う道を歩んだのかを取り上げたのが1本目。国内ベンダーがOSもデータベースも文字コードも独自に作り、その上に各社が業務を作り込んだ。だから移す先が一つに決まらない。

　「40年物のCOBOL」がなぜAIにとっても読みにくいのか、その背景を解説したのが2本目。読みにくさは言語ではなく、40年分の改修で文脈が散らばったことに由来する。

　3本目は、いわゆる「JaBOL」の評価。JaBOLとは、COBOLの構造を残したままJavaに書き換え、Javaのクラス設計を使わず、COBOLの手続き構造をそのまま写した形を指す。Javaらしくない、保守しにくい、という批判は根強い。それでも、業務の仕様を一から解釈せずに新旧の結果を突き合わせられる利点は大きい、と話した。

　ありがたいことに反響があった。ただ、その後の講演や打ち合わせで受けた質問は、驚くほど偏っていた。一つは「AIを使うと工程はどのくらい短くなりますか」。これには答えられる。工程によるが、解析や変換だけを見れば、数カ月かかっていたものが数日で形になることは実際にある。

　もう一つの質問が厄介だった。「それで、うちは何から手を付ければいいんですか」。この質問に、筆者は3本の記事で答えていない。判断の材料は話したつもりだが、順番までは説明していない。取材という形式には、そこまで収まらなかった。

　残っている宿題は、突き詰めると3つある。ソースコードからはなぜ作られたかという「Why」が分からないルールを誰がどう復元するのか。移行が終わった後、誰が保守するのか。そして、明日から何をするのか。

　この連載は、その3つを埋めるために書く。

この連載「AIに任せる、人が決める──2035年へのレガシーモダナイゼーション実務論」について

　レガシーシステムの刷新は先送りできない課題になっている。一方、AIによってシステムの解析やコード変換は大幅に速くなりつつあるが、移行方針の選択や仕様の判断など、人が決めなければならない仕事は残る。

　本連載では、2035年までのレガシーモダナイゼーションを見据え、「AIに何を任せ、人は何を決めるのか」という視点から、アセスメント、仕様復元、移行、テスト、保守までの実務と判断軸を全20回で解説する。

1円の差を巡る会議は、AIでは短くならない

　レガシーシステム移行プロジェクトの終盤には、新旧のシステムに同じデータを流し、結果を突き合わせる工程がある。移行によって業務の結果が変わっていないことを確認するためだ。このテスト工程で差異が出るのはよくあることで、たいていは環境や桁の扱いの違いで説明がつく。厄介なのは説明がつかないケースだ。

　ある案件で月次の帳票に1円の差が出た。追っていくと、利率計算のある箇所だけが、社内の設計標準と違う丸め方をしていた。切り捨てるべきところを四捨五入していたのだ。いつからかは分かった。1990年代半ばの改修だ。なぜそうしたのかは、どこにも書かれていない。当時の担当者は、とうに退職している。

　原因の特定まではまだ速い方だった。全プログラムを横断して丸め処理を洗い出し、該当箇所を突き止める。いまなら数日だが、当時は人手で数週間かかった。

　問題はその先である。旧システムに合わせるのか、標準に合わせるのか。旧システムに合わせれば、標準と違う処理を新環境に持ち込むことになる。標準に合わせれば結果が変わる。過去データと整合性があるか、監査で説明できるか、顧客に影響が出るなら誰がいつ通知するのか、という問題がある。システム部門だけでは決まらない。業務部門が呼ばれ、経理が呼ばれ、最後は役員の判断になった。

　この1円の差について決着するまでに6週間かかった。AIをどれだけ賢くしても、この6週間という期間は短くならない。会議の日程が調整できない。判断材料をそろえるのに部門をまたぐ。決めた人が責任を負う。どれもAIの外側の話だ。

　その上厄介なことに、解析が速くなった分こうした論点は以前より早く、まとめて出てくる。以前は解析そのものに数カ月かかったので、論点もその間に順次出てきた。かつて工程の後半に少しずつ現れたものが、いまは前半に一気に現れる。準備がなければそこで詰まる。

　結局、全体の期間は速くならない部分の量で決まる。実装が10分の1になっても、決めるのに同じ時間がかかるなら、プロジェクトが10分の1になることはない（図1）。

図1　AIで短くなる工程と、短くならない工程（提供：アクセンチュア）

　AIが安くしたのは実装のコストであって、意思決定のコストではない。これが本連載の出発点だ。この非対称は昔からあったものではない。件のシステムが作られた1980年代、丸め方は現場で決まっていたはずだ。仕様を書く人もコードを書く人も業務の担当者も同じフロアにいて、決めるコストが安かった。だから記録も残らなかった。

　ピーター・ナウアという計算機科学者が1985年に、プログラミングとは本来コードを書く作業ではなくそのシステムが何のためにどう作られているのかという「理論」を人の頭の中に築く作業だ、という論文を書いた。理論は文書にならない。だから、その人たちがいなくなれば失われる。違う丸め方をした例のかつての担当者も、頭の中では筋の通った理由を持っていたはずだ。それが残っていない。

　いま同じ判断をしようとしても当時を知る人はおらず、根拠は失われ、関係部門は分散し、外部への説明責任だけが増えている。作る側はAIで速くなった。決める側は40年かけて遅くなった。開いているのはこの差だ。

序盤で貯めた時間を、全部吐き出した会社の話

　もう一つの事例を書いておく。特定を避けるため細部は変えているが、典型的なパターンだ。ある企業は、AIによる解析と変換の効果を早い段階で確認していた。序盤は計画より速く進み、仕様の復元も変換も想定を上回るペースで形になった。

　つまずいたのは、やはりテストだった。現新比較で差異が数百件出た。件数自体は異常ではない。問題は、その一件ごとに「許容するのか、直すのか、そもそもどちらが正しいのか」を判断する人と基準が、計画のどこにも書かれていなかったことだ。

　現場は判断を求めて問題を上位者に報告する。上位者は判断材料が足りないと言って部下に戻す。その往復に時間を割いた。最後に集計すると、解析と変換で稼いだ時間の大半は、この工程で消えていた。

　この企業がしたのは「AIの導入」で、やらなかったのは「AIと人の役割分担の決定」だった。誰が何を決めるのかが先に決まっていれば、本番稼働前に差異が数百件見つかったことはむしろ良い知らせだったはずだ。

　もっとも、これを発注側の準備不足と片付けるつもりはない。支援する側も、「AIでこれだけ工程が速くなります」と熱心に言ってきたが、「決める仕事が前倒しで増えます」とは言ってこなかった。反省を込めて書いている。