損保ジャパンがCOBOL一掃を決断 金融機関が変われば、IT業界も変わる(ITpro)の記事によれば、損保ジャパンがCOBOLの資産をJavaに切り替えるという決断を下したとのことである。同記事によれば金融機関でも大手になるとCOBOLのアプリケーションの保守で500億円も費やすことになると言われていることから、その削減目的として移行するのだという。ただ、個人的にはそれをやったからといって根本的な問題の解決になるわけではないと考えている。
COBOL自体は幾度となく改良されている
まず大前提となる「COBOLは古い」ということについてであるが、これは登場したのが1959年で、1957年に登場したFORTRAN ((1990年に制定されたFortran 90以降は通常「Fortran」と表記する)) に次ぐ古い言語によるものだからと言える。そういう意味では「古い言語」であるとはいえる。
しかしながら、COBOL自体は年を追うごとに現代的なプログラミング言語としての要素を相当数取り入れている。第3次規格では現在使われているプログラミング言語ではほぼ確実に使われている構造化プログラミングを、第4次規格では現代のプログラミングではほぼ必須となっているオブジェクト指向プログラミングが可能になっている。
また、近年ではJavaとの親和性が向上しつつあり、COBOLからJavaのクラスライブラリーを使えるようになっているなど、改良は加えられている。
問題となるのはエンジニアのスキルあるいは考え方
それ以上に個人的に問題視しているのはエンジニアのスキルあるいは考え方にあるのではないのかと考えている。
COBOLは記述の方向性から、英語が理解できれば大体コードが書けてしまうというように設計されているため、習得難易度はそこまで高くないものの、ちゃんと学習しなければスパゲッティーなコードになってしまう可能性は比較的高いと言える。
COBOLが登場したのが古いことと、その古い言語仕様との互換性の確保からレガシーな記述が可能になってしまっていることで、現在の仕様では問題なく構造化プログラミングやオブジェクト指向プログラミングを問題なく使えるはずなのに、それを知らない、あるいは知ってても使いたがらない、あるいはそもそも知ろうとしないなどといったことからレガシーな記述を使い続けているのではないのかと考える。それでCOBOLでもそれなりに可読性が確保できるはずなのにそうなっていないということが推測される。
このままの状態でJavaなど他の言語に移行した時、そういったエンジニアがモダンな記法を理解せずに「時代遅れ」な書き方を持ち込んでしまう危険性が高く、そのままでは根本的な解決にはならないだろうと考えている。
COBOLが得意とする処理をどうするのか
上記とはまた別の問題だが、COBOLが得意とする固定小数点数や内部十進項目など、会計処理などで要求される正確な数値演算など、Javaなどに移行する際には処理のコストなどで問題となる機能があり、その点をどうするのかがネックになる。
Javaについてはjava.math.BigDecimalで十進演算が可能になるが、パフォーマンス面で問題となる上に、場合によってはCOBOL以上に可読性が落ちる可能性があるため、、その点でも気をつけなければならない。
最後に
近年「COBOLは古い」「COBOLは時代遅れ」という風潮が後を絶たないが、個人的には言語仕様よりもCOBOLエンジニアの傾向として考えられるいわゆる悪い意味での保守的な風潮がそうさせているのではないのかと考えている。
何れにしても、ただ単純にCOBOLを淘汰してJavaなど他の言語に置き換えても、エンジニアの意識を変えなければ保守性の向上やコストの削減は望めないように考えられる。
ウェブマスター。本ブログでITを中心にいろいろな情報や意見などを提供しています。主にスマートフォン向けアプリやウェブアプリの開発を携わっています。ご用の方はコメントかコンタクトフォームにて。
