増田 和信（ＮＥＣソリューションイノベータ）
「COBOLは習得が難しい」という事が話題になることがありますが、マイグレーション業務とCOBOL言語に携わって10年あまり、自身ではそういった認識を持っていません。
いったい何が難しいのかな？と思い、自身の経験を踏まえて、考えてみました。
プログラミング言語に初めて触れたのは、大学1年でJavaを習った時でした。この頃はオブジェクト指向を必死に勉強していましたが、大学2年でC言語の授業があり、「ライブラリが充実しているJava」と「メモリまで意識してコーディングするC言語」のギャップに驚いた記憶があります。
COBOLを触ったのは入社して1年目からになりますが、最初は上司が昔の教育で使ったというメインフレーム用のCOBOL問題集を、Windows上で動くCOBOLを使ってやりました。当然、Windowsで動かすためにはいくつかの変更が必要なのですが、処理を作る上では、学習した言語の概念とマッピングできれば、手続き型の言語としては変わりがなかったため、すぐに慣れることができました。それよりも、学習する上で苦しんだのはさまざまな概念です。
当時はメインフレームに触ったことも無いため、「装置名」というものがまったく理解できませんでした。そもそもメインフレームにおける装置がイメージできないのですが、Windows上で動かすためには何を指定すればいいのか、ファイル記述項にどうやってパスを入れてやればいいのか、などで四苦八苦した記憶があります。
COBOLは扱えるデータの種類が多いと感じた事が印象に残っています。パック10進数やアンパック10進数にエンディアン固定の形式など、数値にはデータの持ち方がいろいろある事を知識としては知っていましたが、COBOLを使って初めて強く意識しました。
その後、実際の業務ではお客様のCOBOLプログラムコードを読む事が多くなりましたが、難しいと感じるのは「データに依存した問題」です。
C言語でいう共用体なのですが、COBOLでは使われる頻度が多く、他言語へ変換する場合には、データの問題が起きやすいものの1つです。特にマルチレイアウトレコードは、実際に入ってくるレコードデータによってある領域がまったく異なるデータ形式として使われたり、そもそもレコード全体のレイアウトが異なったりします。また、1つの巨大なX項目は別々のプログラムで異なるレイアウトに定義されている場合があり、複数のプログラムで処理された結果、マルチレイアウトレコードのファイルが出来上がる、という場合もあります。
メインフレームはEBCDICコードのデータを処理するのに対し、マイグレーション後の環境はASCIIコードのデータを処理します。プログラムでEBCDICを想定しているようなものがあれば問題が起きるのはすぐわかりますが、逆にメインフレームでASCIIコードのデータを処理する前提だったりすると、前後の処理を見たりしないといけない場合があります。
このように、業務を通してCOBOLプログラムを読み書きできるようになっていきましたが、改めて考えてみると、難しいのは次のような点です。
つまり「COBOLは習得が難しい」というのは、COBOLプログラムの理解や習得が難しいという事では無く、「COBOLプログラムを取り巻く業務システム(OS含む周辺システムやデータを含めた処理内容)を理解するのが難しい」ということだと理解できます。
これは「COBOLが大規模な基幹システムで使われている事が多い」という事にも起因していると思いますが、このような難しさは他の言語においても同様であるように感じます。
個人的な感覚になりますが、大規模なシステムのCOBOLプログラムはコーディングルールが決められている事が多く、変数がわかりにくいとか、プログラムの全体像を掴みにくい、といった事はあまり無いように思います。
また、もともと事務員でもプログラミングできる言語として設計されたものであるため、プログラミングの難しい概念を知らない人でも素直に読み書きできるのかな、とも思います。