昭和50年代くらいから基幹系システムで利用されることが多いCOBOL言語は目の敵にされることが増えています。旧式な言語だから、Javaに置き換えた方が良いという、いろいろな企業の思惑で人為的に作られた流れです。
COBOLは先が無い言語という雰囲気が2000年台くらいから漂い始めて、COBOLを積極的に学ぶ人も少なくなってしまいました。したがって、このままCOBOLでシステムを運営していくと、維持管理できる人がいなくなるということも問題になっています。
COBOLは言語仕様上、データ定義をしっかりとやって、論理を構造化しながらコーディングすることができる言語です。オブジェクト指向のような実装は難しいですが、例えば法律を実装していくような場合には適した言語であるということもできます。
しかし、最近はCOBOLが悪いという先入観が一般化しつつあるので、COBOLで書かれたシステムをそのままJavaでリライトするような案件が出てきています。本来はCOBOLの方がバッチ処理（一括処理）では優れていても、それさえもJavaで書き換えてしまい、プログラム構造を見直すわけではないので、なんだかCOBOLの構造を持ったままのJava言語で書かれたモジュールが仕上がっていきます。
機械（ツール）でCOBOLからJavaへ一括変換するような事例もありますが、どこまで可読性が高い、どんなJavaのソースコードが生成されるのか、一度、見てみたいです。
日経XTECHでCOBOLからJavaへのリライトに関する問題点を指摘する記事が掲載されていました。こちらの記事です。
COBOLをJavaで「リライト」の愚、SI企業の良識はどこに？
まったく、この記事の主張の通りだと思います。実際、COBOLからJavaにリライトしたシステムで、サービス開始後にどの程度、保守性や生産性が変わったのか、定量的な数字が知りたくて調べてみたのですが、その数字を見つけることができませんでした。予想としては、さほど良くなっていないどころか悪くなっている場合もあるのではないかと思います。
たとえ、機械で一括変換できたとしても、生成したプログラムが意図した通りに機能的、非機能的に動くのかは、試験をしなければいけません。この試験にも工数はかかるので、本当にリライトする工数と比較して、リライト実施後のコスト削減効果はどの程度あるのかは、よく見積もった方が良いです。
記事の中にも書かれていましたが、要件定義や設計の内容が、システムを何十年も維持していくうちに失われていることが最も大きな問題だと思います。また、これまでの制度の変遷の中で、プログラムの中には条件分岐が複雑になったり使われないロジックが残っていたりするかもしれません。その事業の制度的にも過去から引き継がれてきた諸々の遺産が積みあがってきていることで、もっとシンプルな制度設計ができるのかもしれません、本当に保守費用を削減したり、開発時の生産性を上げたいのであれば、ユーザーも含めて無理無駄が積みあがった中身をよく分析して、シンプルにしていかないといけないと思います。
コメント