[技術解説]

2021年3月9日(火)田口 潤、杉田 悟（IT Leaders編集部）

　経済産業省が2018年9月に公開したDXレポートにおいて、「放置すれば2025年の崖に落ちる」と指摘されたレガシーシステム。読者は、どんな印象を持っているだろうか？ ざっと、以下のようなところではないだろうか。

●20～30年以上前に構築された古いシステムで、つぎはぎだらけで一貫性を欠いている
●仕様書や設計書などのドキュメントが残っていない
●数十万ステップから数百万ステップ、時には数千万ステップと規模が大きい
●プログラミング言語はCOBOLやPL/I、RPGが使われ、データ管理などのミドルウェアも古い
●主にメインフレームで稼働し、運用に費用がかかる

レガシーシステムの悲惨さは想像を超える

　筆者も、そんなふうに見ていた。よく聞く“スパゲッティプログラム（コード）”である。それでも日本のIT企業やエンジニアが作ったものだから、解析は可能だろうと考えていた。

　しかし、レガシーシステム問題に取り組み、専用のツールを開発・販売するITbook（東京都港区）に取材したとき、この認識は間違いかもしれないと考えた。同社社長の石田伸一氏と営業本部民間3グループエグゼクティブシニアマネージャーの長谷川峰夫氏から聞いた内容を大まかにまとめると、以下のようなケースがある。

①数千万ステップのソフトウェア資産を解析すると、元は同じで一部だけを改変したと思えるプログラムが複数あった。モジュールの再利用というレベルではない。実質的な資産は、数分の1の数百万ステップになる計算だが、どこまで類似しているのか、目検では分からない。

②構造化プログラミングで整然と作られたプログラムが、仕組みを知らない技術者による改修を何十年も経る中で複雑怪奇な様相になっている。例えば、20層以上に及ぶ複雑怪奇なネストがあちこちにある。そもそもプログラムの構造や流れを把握しにくくなるネストは、避けるべきとされるが、そういった気遣いはゼロに等しい。

③上記②と同様だが、できるだけ使わないことが推奨される「goto文」が多用され、可読性がないに等しいプログラムが相当ある。もちろん機能面では問題なく動作する。

④複数のプログラミング言語で記述されたシステムがある。例えばCOBOLプログラムからアセンブラ言語で記述されたプログラムを呼び出す処理が散見されるケースで、JavaやC言語のコードもしかりである。プログラムを生成する4GL（第4世代言語）のコードが混じっていることもある。

⑤パラメータ名（プログラムにおける変数や引数の名称）に一定のルールがなく、同じシステムを構成する複数のプログラムにおいて、異なるパラメータ名が使われている。つまりシステム設計や記述の原則が存在していない。

　これだけだとイメージしにくいので、いくつか例を挙げよう。ITbookが開発した「Smart Tool」で分析した、実際の業務システムを分析した結果の一例が図1である。詳細はともかく、同ツールでは、①1つの行（ステートメント）を項目ごとに分割して項目ごとに比較する、②項目名称を数値と文字に分割して比較する、③文字列は、例えば「1st」「2nd」「3rd」とあるのをすべて「0th」に読み替えて比較する、といった工夫を行っている。それらによって、項目名を含めて完全に一致していないコード同士でも類似しているかどうかを分析できるようになっている。

　数千万ステップに及ぶ大規模システムの実態を鳥瞰的に把握するのに有用で、図1からは実際に類似のコードが複数のファイル（ソースコード）に繰り返し出現していることを見てとれる。なぜ、こんなコードがあるのかというと、プログラムの一部を改修すれば済む作業であっても、リスクを避けるために元のプログラムを残す。代わりに関係する部分を含むすべてのコードをコピーして改修し、テストを経て稼働させるといったことを繰り返した結果だ。

　もう1つ、goto文（命令）を多用したソースコードが図2である。実際のコードは例示できないので、図はサンプルである。左側が元のコードであり、青い線はSmart Toolが自動で描いている（下から上に戻るgotoを示した紫の線もある）。もっとも、この程度ならロジックを追える気がするが、現実のプログラムははるかにステップ数が多く、gotoの飛び先も遠い。人がソースコードを見て理解するのは非現実的だ。

　「そんなことは日常的だし、驚くことでもない」。こう考えるITエンジニアも少なくないかもしれない。しかしITbookの石田氏と長谷川氏、それにもう1人のIT専門家が同席した場での議論や、筆者のこれまでの取材経験からすると、今も残るレガシーシステムの特性を“よくあること”と考えている限り、対処が進まないように思える。

　どう説明すべきか適切な表現が浮かばないが、「不作為の罪（なすべき行為をしなかったことへの罪）」や「悪意のない悪意」が集積した結果が、その正体だからだ。中途半端な意識で対応しようとすると行き詰まる。災いを覚悟して開くべき「パンドラの箱」なのである。少し遠回りになるが、それはなぜなのか、説明を試みよう。

ERPレガシー問題、膨れ上がったアドオンとカスタマイズ

　一口にレガシーシステムといっても、DXレポートが指摘したそれは2つに大別される。1つは、独SAPのERPアプリケーションパッケージ「SAP ERP」を使って構築された業務システム群である。

　SAP ERPと言えば、財務会計（FI：Financial Accounting）と管理会計（CO：Controlling）のシステムが多いが、販売管理（SD：Sales and Distribution）と在庫購買管理（MM：Material Management）もある。

　これらはバックオフィス業務向けであり、バージョンアップする必要性は高くないが、2018年の段階で「SAP ERP 6.0およびSAP Business Suite 7までの製品のサポートを2025年末に終了する」と発表された（SAP2025年問題）。その後、ユーザーのマイグレーション（移行）状況を考慮して、サポートの期限は2027年末に延長されたが、ユーザーはその期限までに、現行バージョンである「SAP S/4HANA」にマイグレーションするなど、何らかの対処をしなければならない。

　移行と言っても、PCのOSやオフィスソフトを最新のバージョンにするとは難度がまったく異なる。難しい理由の1つはSAP ERPとS/4HANAの違いの大きさ。両者は内部構造が異なっており、違うERPパッケージに移行するのと同じくらいの困難があると言われる。

　もちろん、移行を支援するツールやプログラムは提供されているが、効果があるとは限らない。優秀な導入責任者や第3者の立場でアドバイスする独立系コンサルタントが関与した一部の導入プロジェクトを除き、特に日本ではERPのコードを変更したり別モジュールを外部に追加したりする、カスタマイズやアドオンと呼ばれる追加開発が広範に行われたからだ。

　その理由は、企業ごとに異なる業務のやり方やデータ項目の違いを吸収する、生産管理など他のシステムと連携させる、利用者の不満ができないように画面操作に関する要望を反映させる、といったことだが、これらはある意味、表向き。もう1つ、導入プロジェクトを担当するITコンサルティング会社やITベンダー/SIerにとって、カスタマイズやアドオンが多いほどコンサルタントや技術者の稼働が増え、売上げが増える構図があった。発注企業の業務要件をできるだけ汲み取って追加開発すれば、プロジェクト規模を大きくできるのだ。

　本来、SAP ERPのような業務パッケージを導入するなら、そのメリットを生かせるようにカスタマイズを最少にし、業務をSAP ERPに近づける工夫や努力をすべきだったが、そうした力学は働かない。むしろ導入企業の担当者もIT企業の技術者も、利用部門の要望を聞き入れて実現することを優先した。結果、多くの企業で動いているSAP ERPは、“手組み（スクラッチ）”のシステムに近いものになっている。必然的にマイグレーションは大変な作業になるし、支援ツールを使っても自ずと限界がある。

　長々とSAP ERPのことを書いてきたが、この記事の本題は、もう1つのレガシーシステム、すなわち手組みで開発された自社固有の基幹業務システム（以下、基幹システム）である。ここでいう基幹システムとは、製造業なら開発や設計、調達、生産、物流など、金融業なら商品やサービスそのもの、といったように企業の中核業務（本業）を直接サポートする。業種や業態が違うと業務内容は大きく異なるし、同じ業種でも企業が創意工夫するノウハウの塊なので、企業ごとの差異は小さくなく、利用できる業務パッケージが少ない。

　このため1990年代以前に開発された企業情報システムのうち、相対的に共通性が高い会計や販売管理のシステムは次第にSAP ERPなどに置き換わったが、基幹システムは温存された。もちろんパッケージやSaaSが存在し、利用できたシステム（好例はANAやJALなど航空会社の予約システム）のような例外もある。だが、今も稼働しているレガシーシステムの多くは、業務や制度変更などで改修や拡張が繰り返し施され、構築時点とは似て非なるものになった。SAP ERPに施されたアドオンやカスタマイズは、これに比べれば可愛く見える、と言われるほどである。

●Next：自社システム開発・構築が“素人仕事”になっていった理由