COBOLの移行で「本数とステップ数」の物差しはもう通用しない――その理由と“難易度を測る6項目”：2035年へのレガシーモダナイゼーション実務論（3）（1/2 ページ）

レガシーシステムの移行に当たり、工数や期間を見積もる際の指標として使われてきたプログラムの本数やステップ数。しかし、AIを活用した移行では、同じ規模のシステムでも必要な工数が大きく異なることがある。従来の指標だけでは見えてこない移行の難しさを、どう見極めればよいのか。

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

　移行の見積もりは、たいてい「プログラムは何本ありますか」という質問から始まる。だがAIにプログラムを読ませることを前提にすると、本数では工数が決まらなくなる。第3回は、アセスメントで測るべきものがどう変わったのかを説明する。

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

　国産メインフレームベンダーの撤退表明が相次ぐ中、COBOLなどで構築されたレガシーシステムの刷新は先送りできない課題になっている。一方、AIによってシステムの解析やコード変換は大幅に速くなりつつあるが、移行方針の選択や仕様の判断など、人が決めなければならない仕事は残る。

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

見積もりは「何本ありますか」から始まる

　レガシー移行の相談を受けたとき、最初に交わされる質問はだいたい決まっている。プログラムは何本か。総ステップ数（おおむねソースの行数）はどれくらいか。JCL（バッチ処理の手順を書いた定義体）は幾つあるか。

　この数字が出れば、経験のある会社なら概算の工数を答えられる。1本当たり何人日という単価を規模に掛ける。長年そうしてきたし、大きく外したこともあまりなかった。

　従来のアセスメントが出す成果物も決まっている。資産の一覧、プログラムごとの複雑度、そこから積み上げた工数と期間。人が手を動かす前提であれば、いまでもその方法で間違ってはいない。

　だが最近、この掛け算が合わなくなってきた。同じ本数のはずなのに、実際にかかる手間が数倍違う。しかも、その差が着手前には見えていない。

　理由ははっきりしている。本数とステップ数という物差しは、「人が読んで書き直す」ことを前提に作られたものだからだ。

AIによるCOBOL移行、工数を左右するのは「ステップ数」ではない

　人が1本のプログラムを読んで書き直すとき、かかる時間はその長さにおおむね比例する。100ステップより1000ステップの方が時間がかかる。当たり前の話で、だからこそステップ数は良い物差しだった。

　ところがAIに読ませると、この比例関係が崩れる。1000ステップを読むのも100ステップを読むのも、AIにはさほど違わない。長さが工数を決めなくなる。

　もっとも、長さが無関係になるわけではない。AIが一度に扱える分量には上限があり、極端に長いプログラムは分割して読ませることになる。分割すれば前後のつながりは切れる。上限に届く手前でも、入力が長くなるほど中ほどの記述を取りこぼしやすくなる。ただ、1万ステップのプログラムが1000ステップの10倍の手間になる、ということにはならない。

　では何が決めるのか。

　AIが「読める」ことと「移行できる」ことを隔てているのは、文脈の量である。AIに正しく読ませるには、そのプログラム単体ではなく、周辺の情報を一緒に渡す必要がある。コピー句、呼び出し先のプログラム、データベースの定義、実行時の環境。これがそろっていれば速く、欠けていればそこで止まる。コピー句というのは、複数のプログラムが共有するデータのレイアウト定義である。口座番号10桁、氏名40文字、残高9桁といった項目の並びを1つのファイルに書いておき、各プログラムの先頭で「COPY 口座レコード」のように1行書いて取り込む。C言語のヘッダファイルと同じ使い方だ。

　つまりAIを前提にして工数を決めるのは、資産の大きさではなく、渡せる情報がどの程度そろっているかである。

　むしろ厄介なのは、短いのに文脈が散らばっているプログラムだ。200ステップしかないのに、コピー句を10本取り込み、5本のプログラムを実行時にならないと決まらない形（後述する動的呼び出し）で呼び、独自のデータベースを3種類触っている。人が読むなら短くて楽だが、AIに渡すべき周辺情報は多い。従来の物差しでは「小さいプログラム」に分類されてしまう。

同じ5000本でも手間は一緒ではない

　AIに読ませる難しさを具体的に考えてみたい（図1）。

図1　同じ5000本でも、AIに読ませる難しさは違う（提供：アクセンチュア）

　プログラム5000本のシステムが2つあるとする。従来の物差しでは同じ規模だ。同じ見積もりが出る。

　だがA社のシステムは、ソースが全部そろい、コーディングの作法もほぼ一世代に統一され、どのプログラムがどれを呼ぶかもソースを読めば追える。

　一方のB社は違う。本番で動いているのにソースが見つからないモジュールが数十本ある。1980年代前半の書き方と構造化以降の書き方が混在し、呼び出し先が実行時にならないと決まらない箇所も多い。しかも一部にアセンブラ（機械語に一対一で対応する低水準の言語）が残っている。

　この2つは、AIに読ませる難しさがまったく違う。B社は、まず「読ませられる状態にする」ところに工数がかかる。ソースを探し、見つからなければ復元するか作り直す。呼び出し関係の工数は稼働ログから推定する。アセンブラの部分は、結局は人が読む。

　筆者が見た中で最も苦しかった案件は、本数ベースの見積もりで契約した後に、ソースの欠損とアセンブラが発覚したものだった。欠損は全体の2％に満たない。だが、その2％が業務の中核にあった。計画は最初の半年で崩れた。

　割合自体は小さい。だが移行では、欠けている1本が先の工程を丸ごと止める。従来の物差しでは、この性質が捉えられない。

　なぜ中核のモジュールほど欠けるのか。メインフレームの正規の手順を知ると腑（ふ）に落ちる。修正したソースをライブラリ（メインフレームでソースや実行形式を格納しておく保管場所のこと。一般的な「外部の再利用コード」の意味ではない）に登録し、それをコンパイルして実行形式を作り、本番へ配置する。この3段階だ。

　よく使われるモジュールほど、障害や制度改正のたびに緊急で手が入る。深夜の対応では、この1段目が飛ばされる。手元で直したソースをコンパイルし、実行形式だけを本番へ置く。落ち着いてから登録するつもりで、そのまま忘れる。残るのは、本番は動いているのに、ライブラリのソースは修正前のまま、あるいはどこにもない、という状態だ。欠損は偶然に散らばるのではなく、重要な場所に偏って起きる。