“Visual COBOL”に期待か？　“死んだ言語”「COBOL」復活の条件

さまざまな理由で古い「COBOL」プログラムを使い続ければならない組織は、COBOLとどう向き合っていけばよいのか。「COBOLそのものが変わればよい」という考え方もあるが、それは根本的な解決策になるのか。

公開 2021年05月25日 05時00分

著者

Jim O'Reilly

[TechTarget]

印刷する連載新着通知を受け取る

　「COBOL」は古くから基幹システムなど重要なシステムを支えるプログラムの開発に用いられてきたプログラミング言語だ。レガシーなCOBOLプログラミングをそのまま稼働させ続けることはリスクを伴う。システム刷新のために「プライベートクラウド」（リソース専有型クラウドインフラ）など、新しいインフラにCOBOLプログラムを移行させることを検討する組織もあるだろう。

　組織はCOBOLプログラムのインフラ移行に付随する問題にも目を向ける必要がある。COBOLプログラムの担当者はたいてい、退職が迫ったベテランの従業員だ。そうした従業員は、業務システムと自社の事業に関する膨大な経験により、高い精度でピンポイントにプログラムを変更できる。

併せて読みたいお薦め記事

レガシーシステムのクラウド移行

ベンダーが考えるモダナイゼーション

“死んだCOBOL”を生き返らせる解は“Visual COBOL”か？

　問題はCOBOL業界で新人が育成されていないことだ。大学や専門学校でCOBOLを教えるところは多くないだろう。COBOLは「昔からのIT業務でしか利用されない“死んだプログラミング言語”」になった。

　ではどうすればいいのか。答えは「COBOL自体を若返らせること」だ。Microsoftが開発するプログラミング言語「Visual Basic」はかつて、現代のシステム開発に即した機能設計を通じて、プログラミング言語「BASIC」を蘇生させた。同様にCOBOLが“Visual COBOL”のような形でアップデートすれば、新人開発者がCOBOLを習得しやすくなり、開発プロセスを高速化できるようになるだろう。

　“Visual COBOL”は完全な答えではない。組織はシステム移行に伴ってシステムにまつわる業務プロセスを更新する必要があり、それには相当の労力を必要とする。レガシーなCOBOLプログラムは改修に時間がかかり、アジャイル開発（開発とリリースを短いサイクルで繰り返すシステム開発方法）が求められる現代の業務にはそぐわない。

転換を促す競争圧力

　COBOLプログラムを新しいインフラに移行させても、新しい技術の圧力に直面することがある。言い換えればCOBOLプログラムのインフラ移行を決断しても、現代の技術を採用したアプリケーションへの避けられない移行を遅らせることにしかならない場合がある。

　新しい技術は、一般的にレガシーなCOBOLプログラムよりもデータを高速に扱えるプログラムを実現する。例えば以下の技術がそうだ。

データをメモリに記録することで高速な読み書きを実現する「インメモリデータベース」
CPUを補助するため、GPU（グラフィックス処理プロセッサ）などのハードウェアで演算処理を実行する「ハードウェアアクセラレーション」
多数のコンピュータやマイクロプロセッサを並列で稼働させて単位時間当たりの演算速度を高める「MPP」（Massively Parallel Processing）

　最高情報責任者（CIO）にとっての課題は、レガシーなCOBOLプログラムを新しいインフラに移行させてモダナイゼーション（最新化）をするのか、それとも完全に刷新するのかを判断することだ。