“8文字の流儀”が生んだ「COBOL・謎の略語」 失われた40年分の意味を掘り出す:2035年へのレガシーモダナイゼーション実務論(6)(1/2 ページ)
AIを使えば、長年使われてきたCOBOLのコードを解析することはできる。しかし、そこに記されたデータ項目名が業務上何を意味するのかまで、正しく読み解けるわけではない。レガシーシステムの移行を阻む、長年の運用の中で失われてきた「意味」をどう取り戻せばよいのか。
連載:AIに任せる、人が決める──2035年へのレガシーモダナイゼーション実務論
40年も前にプログラミング言語「COBOL」で構築されたレガシーシステムを移行する際、現場で最初に詰まるのは、構文ではなく語彙(ごい)である。AIと人間の役割分担を軸に、レガシーシステム刷新の実務を考える本連載。第6回は、長年の運用の中で失われてきた、データ項目名の“本来の意味”を、どう掘り出すのかを解説する。
「この項目は何ですか」に誰も答えられない
レガシーシステムの移行に向けて、アセスメントの現場で一番多い質問がある。「このデータ項目は業務上何を指しているんですか」だ。
その場で答えが出ないことが驚くほど多い。
先日、業務に精通した有識者をヒアリングする場ではこのような答えが返ってきた。「たぶん掛金の元金だと思うんですが自信はないです。私が入ったときには、もうそう呼んでいたので」。この方は20年その業務を見てきた人である。それでもそう答えるしかない。
例えば「W-KKN-GK」という項目があったとする。COBOLの慣習で、先頭の「W」は作業用の領域を示す。残りはローマ字の頭文字だ。「KKN」は掛金か、期間か、基幹か。「GK」は元金か、合計か、原価か。組み合わせは幾つも考えられる。
コードを読めば、その項目に何が入り、どう計算されるかは分かる。だがその値が業務上の何を意味するのかは、どこにも書かれていない。決めるのは組織の記憶であって、コンパイラではない。
COBOLの項目名が「謎の略語」になった理由
COBOLの項目名が短い略語になった背景には、当時のメインフレームにおける技術的な制約や、命名の慣習がある。
メインフレームでは、プログラムや、項目定義をまとめた共通部品(コピー句)を、「区分データセット」という領域に格納する。区分データセットは、1つのファイルの中に複数の部品を収める形式で、プログラムやコピー句などの部品一つ一つを「メンバー」と呼ぶ。そのメンバー名が、8文字までと決まっていた。COBOLのデータ名は30文字まで使えたので、8文字という制限が直接の制約ではなかった。だがプログラムもコピー句も8文字で呼ぶ日々が続けば、中のデータ項目名も短くそろう方が自然になる。
そうしてローマ字の頭文字を並べる形が定着した。当時はディスクが高価で、画面に表示できる桁数にも限りがあった。こうした制約の下では、短い名前を使うことは合理的な判断だったのだ。
厄介なのは、項目名の付け方の“流儀”が部門ごとや時代ごとに違ったことだ。営業系と会計系で略し方が違う。1985年に入った担当者と1995年に入った担当者でもまた違う。40年たつと、その差は地層のように積み重なる。
コメントも当てにならない。当時は全角文字を扱いにくく、半角カナのコメントが残っていることがある。「ケイヤクキンガクノケイサン」といった具合だ。読めなくはないが、微妙な意味の差までは伝わらない。
では分かりやすい名前に付け直せばいいのではないか。そう思われるかもしれない。だがこれが難しい。コピー句を1カ所直せば、それを取り込んでいるプログラムもコンパイル時に変更に追随する。問題は、追随しないものが残ることだ。帳票の定義や外部とのデータ受け渡しの仕様は、項目名を文字列で持っていることが多い。こうした箇所には、コンパイルでは検出されない参照が残る。1つ変えると、どこまで波及するかが読めない。だから誰も触らなかったし、触らなかったから項目名だけが残り、その意味の方が先に失われていった。
項目名から業務上の意味を読み解く「4つの段差」
項目名が業務上何を意味するのかを明らかにするには、幾つかの段階を踏む必要がある。その過程は、4つの段差に分解できる(図1)。
1つ目は、略語の展開である。W-KKN-GKが「掛金元金」なのか「期間合計」なのかを決める。命名の規約が残っていれば機械的に解ける。なければ、候補を並べるところまでだ。
2つ目は、その候補から業務用語を選ぶ作業だ。帳票の見出しや画面のラベルと突き合わせて絞り込んでいく。ここはAIが得意な領域で、大量の資料を横断して候補を減らしてくれる。
3つ目が、その用語の定義を書くこと。「掛金元金」とは何か。業務マニュアルや規程が残っていれば、AIが下書きできる。
4つ目が一番難しい。その定義はいったいどの部門のものなのかを決める。
これらの段を上るほど、AIが作業に寄与する度合いは下がっていく。この非対称性は、本連載の第8回で扱う予定の「仕様復元」と全く同じ構造をしている。語彙の整理は仕様復元の縮図なのだ。
この4つは下から順に積み上がる。1つ目でつまずけば上には進めない。命名の規約が1枚残っているかどうかで、作業全体の難易度が変わってしまう。まず社内の規約集を探すことを勧めたい。ああいうものは案外捨てられずに残っている。
4つ目の段差についてもう少し詳しく書く。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
「AIで数週間に短縮」のはずが進まない コードモダナイゼーション、真のボトルネックと6ステップ
Anthropicは、AI駆動の大規模なコードモダナイゼーションプロジェクトに向けた準備の進め方をまとめたブログ記事を公開した。
レガシー移行を「AIに丸投げ」してはいけない 標準RAGではダメな理由と「5分割」のアプローチ
SiemensとGoogle Cloudは、レガシーコードの理解とモダナイゼーションを自動化するAIシステム「Knowledge Fabric」を構築した。数億行規模の産業用ソフトウェアを複数の専門エージェントで分割処理し、開発工数を削減するという。
メインフレームに眠る「年代物のCOBOLコード」、AIでも苦戦する"読みにくさ"の正体
複数の国産メインフレームベンダーが撤退方針を明らかにする中で、レガシーシステムの刷新は喫緊の課題だ。一方ではAIエージェントの存在がモダナイズの在り方にも影響を及ぼし始めている。40年物のシステムにどう向き合うべきか。アクセンチュアの中野氏に聞いた。
