内田 正章
前節はメインフレームを中心とした話でした。1980年ころには、メインフレームで動作するプログラムをメインフレームにつながったTSS（Time Sharing System）端末で開発することが主流になっていました。端末とは、メインフレームなどのホストコンピュータからの出力を表示するディスプレイとホストコンピュータへの入力を行うキーボードを持ち、入出力処理だけを行う装置です。当初はインテリジェンスの低かった端末も、やがてワープロ機能などを持つようになり、だんだんパソコン的な能力を備えるようになってきました。一方、同じころのパソコンはマイコンの後継として現れ、ホビー用という印象がありました。その当時からパソコンで動作するCOBOL製品も存在していましたが、よもやパソコン版のCOBOLが基幹業務で利用されるようになるとは思ってもいませんでした。自身の不明に恥じ入るばかりです。
その後パソコンの能力もどんどん拡大し、1980年代の半ばころになると、パソコン利用によるオフィス業務の生産性向上を目指すOA（オフィスオートメーション）が浸透し始めました。そして、1990年代に入ると、ICT機器の能力向上と価格低下の傾向からダウンサイジングの動向が顕著になってきました。すなわち、クライアント／サーバ時代の到来です。サーバには、メインフレームに代わって、UNIX系またはWindows系のOSを搭載するミッドレンジのコンピュータが多用されるようになってきました。
ただ、このころのサーバはまだ能力向上の途上だったため、データの入出力（プレゼンテーション層）の処理はクライアント側で行うことによってサーバの負荷を軽減する構成が採られました。一方で、クライアントのパソコンの能力向上は著しく、プレゼンテーション層のアプリケーションはGUI[15]ベースの分かりやすく見栄えのする操作性を持つものが主流となってきました。このような潮流を踏まえ、プレゼンテーション層のアプリケーションもCOBOLで記述することができるようにCOBOL製品も進化を遂げました。これにより、COBOLユーザが容易にクライアントプログラムを開発できるようになりました。
また、サーバで動作するアプリケーションについても、作成からテストまでの一連の開発作業がクライアント側で行えるよう、開発環境の整備も進みました。これらは、技術の進化、環境の多様化、ニーズの変化に合わせて、COBOL言語システムが柔軟に対応してきたことのほんの一例です。
21世紀を迎えると、ICT機器のコスト／パフォーマンスが一段と向上し、インターネット技術の進展と相俟って、クライアント／サーバシステムの役割分担が変わってきました。クライアントの役割であったプレゼンテーション層のアプリケーションをサーバ側に移動することによる維持コストの削減です。クライアントはある意味で端末に回帰したと言えるかもしれません[16]。この時代の話になると、この文章の想定読者層各位の方がずっと詳しいことでしょう。
COBOLは長い歴史を持つだけに、目まぐるしく進展する技術環境の中にあってなにかと風当たりが強いこともあるのでは…。そんな想いもあって、ここまで応援メッセージを綴ってきたつもりです。もう少しだけ続けさせてください。
初めてCOBOLの勉強を始めたばかりの人がいたとすると、IDENTIFICATION DIVISIONとかENVIRONMENT DIVISIONとかの長々しいキーワードに驚くことと思います[17]。入口で拒絶反応を起こす人がいるかもしれません。これが作成時省力性[18]と読解性のトレードオフの問題だとすると、読解性のウェイトが圧倒的に大きいことは言うまでもありません。昔のように1文字ずつコーディングシートに書いたりタイプインしたりするならともかく、コピー＆ペーストの現代では作成時省力性の要素はかなり低いでしょう。また、Javaでもクラスライブラリなどに関連してArrayIndexOutOfBoundsExceptionのような長ったらしい文字列が多用され、読解性重視が徹底しています。
COBOLが良いの悪いのという場合、やはり他の言語との比較で論じざるをえません。既に一部でそのように比較もしました。ただ、アプリケーションシステム設計の方針（構造化手法／オブジェクト指向）、開発の前提（新規／強化）、実行するプラットフォーム（実行形式モジュールでの持ち回りの有無）などの要素を明確にしないまま言語の優劣を論じても、あまり意味がないような気もします。前項のような表面的な話に留まるでしょう。
言語の機能の大きさを考えるとき、言語仕様だけでは比較できません。COBOLでは、文字列操作から入出力・ソート・報告書作成まで、広範な機能が言語仕様に取り込まれています。習得に時間がかかるとも言えるでしょう。一方、後発のオブジェクト指向言語では、核となる機能以外はクラスライブラリの形で提供されます。たとえばJavaでは、約200個のパッケージ（機能カテゴリーごとの格納場所）に総計約4,000個のクラス（独立性の高い機能群）が提供されているとのことで、文字列操作のようなことからデータベース処理・GUIプログラミング・Webアプリケーション作成まで、多岐にわたる分野がカバーされています。一つの言語であらゆる機能を網羅するという、かつてCOBOLが目指した道をたどっているようです。COBOLにも数十個の組込み関数が用意されていますが、とてもその比ではありません。言語の機能にはこれらのクラスライブラリまで含めて考えるのが妥当で、その意味ではCOBOLはかないません。クラスライブラリの習得については、一つのクラスの使い方をマスターすれば同様の作法で他のクラスを利用できるとも言えますが、その一方で適用すべきクラスを探し出しその仕様を理解するのには熟練が必要と思います。
一つの言語であらゆる機能が実現できるのは理想かもしれませんが、ある言語が無理に手を拡げてカバーした領域でその言語が使いやすいとも限りません。現代の技術者はデータベースの操作にはSQL、Webブラウザへの表示にはHTMLと（広義の）言語を使い分けていると思います。その延長線で、適材適所の言語を選択するという考え方が最も現実的ではないでしょうか。現場の方々にはそれなりの負担がかかる面もありますが…。
後発の言語を迎えても、ビジネスロジックの記述性という観点ではCOBOLに一日の長があります。すでに述べたレコードの表現のほか、小数部を持つ10進数値を数字データ項目として誤差なく自然に扱える点[19]など、捨てがたい魅力に溢れています。今後もCOmmon Business Oriented Languageとして輝き続けるものと確信します。