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

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

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

「ステップ数」に代わる新たな物差し、COBOL移行の難易度を測る6項目

　AIに読ませることを前提にすると、数えるべき項目は変わる。筆者が使っているのは6つだ（図2）。

図2　AIに読ませられるかを測る、6つの項目（提供：アクセンチュア）

　ソースの欠損、コーディング世代の混在、動的呼び出し、非COBOL資産、独自技術への依存、テストデータ。この6つである。

　幾つか補足しておきたい。

　ソースの欠損は、本番で動いているのにライブラリで実物が見つからないモジュールのことだ。どの現場にも一定数ある。ゼロだった会社を、筆者は見たことがない。

　コーディング世代の混在は、以前取材いただいた記事の2本目で触れた論点だ。40年物なら、処理を別の場所へ無条件に飛ばすGOTO文を多用する1980年代前半の書き方と、それを避ける構造化以降の書き方が、1本の中で層を成していることがある。作法が混ざるほど、AIの読み違いは増える。

　動的呼び出しは、呼び出す相手が実行時に決まる書き方だ。呼びたいプログラムの名前を文字列としてデータ項目に入れておき、その項目を指定して呼ぶ。商品コードから呼び先の名前を組み立てる、といった具合である。ソースを静的に読んでも、どこに処理が移るのか分からない。当時はこれが合理的だった。商品が増えるたびに呼び出し元を直してコンパイルし直すのではなく、名前の対応表に1行足せば済む。いまで言えばプラグインに近い。

　非COBOL資産と独自技術への依存は、どちらも公開情報の少なさに起因する。アセンブラ、ベンダー独自のデータベースや通信制御、独自の文字コード体系。取材記事の1本目で触れた日本の特殊事情そのもので、AIの事前学習が最も薄い領域になる。

　最後のテストデータだけは性格が違う。読ませる難しさではなく、確かめる難しさに影響する。現行の入出力を再現できるデータが手元にあるかどうかで、検証工程の重さが変わる。

　ついでに言えば、ステップ数という数字自体も当てにならない。コメント行を含めるか、空行をどう扱うか、もう実行されていないコードをどう数えるか。会社によって流儀が違い、筆者の経験では同じシステムでも2割は優に変わる。いま思えばこの数字に単価を掛けて見積もっていたときの方が危うい。

数えるだけなら今年のうちにできる

　この6項目のうち、テストデータ以外の5つは数えるだけの作業だ。特別なツールも外部の支援も要らない。ライブラリの一覧と本番の稼働実績を突き合わせれば、かなり分かる。

　もっとも、その「数える」のがすでに難しい現場もある。同じ名前のモジュールが複数の場所にあり、どれが本番なのか分からない。テスト用の残骸が本番ライブラリに混じっている。世代管理の仕組みが途中で変わり、それ以前の履歴が追えない。この状態そのものが、最初に得られる重要な情報になる。整理がついていない事実が、そのまま難易度を語っている。

　外に出す前に自分で数えておくことに意味がある。この数字を持たずに提案を受けると、各社の見積もりが「なぜこんなに違うのか」を評価できない。「御社の見積もりは、ソース欠損をどう織り込んでいますか」と聞けるかどうかで、その後の交渉はまるで変わる。

　完璧に数える必要もない。おおよその割合が分かれば、自社の資産が素直か難物かは見当がつく。前回の記事で紹介した「聞ける人リスト」と合わせて、これが移行の判断材料になる。

　数えた結果は、そのまま次の判断につながる。移行の仕方は大きく3つある。既存の言語はほぼそのままにして動く場所だけを移す「リホスト」、別の言語に機械的に書き換える「リライト」、業務の在り方から作り直す「リビルド」だ。ソースの欠損が多ければ、リホストが難しくなる。運ぶべき実物がないからだ。独自技術への依存が深ければ、変換ツールを当てられる範囲が狭まり、リライトの手間が読めなくなる。テストデータがなければ、どれを選んでも検証の方式を先に決めないと後で行き詰まる。選び方そのものは、第11回で扱う予定だ。

---

　次回からは、AIの側の話に入る。AIはCOBOLをどこまで読めるのか。期待でも警戒でもなく、公開されている共通の問題で、何をどう測ればいいのかを設計したい。

著者紹介

中野恭秀（なかの・やすひで）

アクセンチュア株式会社 デジタルコア シニア・プリンシパル

レガシーシステムを、新基盤・システムに移行するマイグレーションを中心としたAMO（Application Modernization and Optimization）を手掛ける。アクセンチュア入社以前は、メーカー系SIerや複数のベンダーで約40年にわたりコンバージョンやメインフレームのオープン系プラットフォームへのリホスト業務などを経験。COBOLコンソーシアムの設立にも従事した。

参考文献・一次情報

・「コーディング世代の混在」がAIの読み違いを招くこと

メインフレームに眠る「年代物のCOBOLコード」、AIでも苦戦する“読みにくさ”の正体　＠IT、2026年7月29日

※同記事に「40年、50年物のレガシーシステムだと3世代ほどのコーディングパターンにまたがるのが一般的」との言及がある。

・「独自技術への依存」が公開情報の少なさに起因すること

富士通も日立も去る、日本での『メインフレーム脱却』が一筋縄ではいかない理由　＠IT、2026年7月22日

※日本のメインフレームにはベンダー独自のミドルウェアやデータベースの技術スタックがあり、それに関する公開情報がJavaに比べて乏しいことに触れている。

・レガシーシステムの可視化とドキュメント欠落の実態（本稿の前提）

経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」2025年5月28日（委員会の事務局はIPA・経済産業省・デジタル庁。掲載はIPAサイト）

※「仕様や設計のドキュメントが整備されておらず、新システムへの移行や再構築時に支障が発生」との記述がある。

・リバースエンジニアリングにおける「復元」の位置付け（第3節の記述の背景）

E. J. Chikofsky, J. H. Cross II, “Reverse Engineering and Design Recovery: A Taxonomy,” IEEE Software, 7(1), pp.13-17, 1990.

※リバースエンジニアリングとdesign recoveryの用語を定義した論文。

・図版について

図1・図2はいずれも筆者が作成した。図1は2つの資産の性格の違いを示す模式図であり、特定の案件の実測値ではない旨を図中に注記している。図2の6項目は筆者が実務で用いているもので、どの水準から要注意になるかは資産の性格により異なる旨を図中に注記している。

関連情報