元気にやっていますか?
私は相変わらず、曖昧な空白とともにふらふらする毎日です。
健体壮美なあなたのことだから大丈夫だとは思いますが、
くれぐれもお体にはお気をつけください。

2010/04/16

How's recent COBOL? - 現代のCOBOLが直面する課題

【COBOLとは】
COmmon Business Oriented Language. 汎商業目的言語の略。
事務処理系のプログラムを効率よく開発するためのプログラミング言語。
ベンダーごとに異なる事務処理のプログラミング言語を統一する目的で、1959年にアメリカで開発された。
文法が英語と似ているため、直感的にコーディングしやすく、可読性が高いのが特徴。
反面、記述が冗長にならざるを得ず、コーディング量は多くなってしまう。
(最近のオブジェクト指向言語しか知らないプログラマは、その冗長さに少々うんざりすることになる。)
一昔前までは、メインフレームやオフコンで盛んに利用されていたが、現在ではJavaやC++などにとって変わられつつある。
昨今、新規に開発するシステムでCOBOLを採用することは、極めて稀である。
ただし、一昔前にCOBOLで開発されたレガシー・システムが現役で活躍しているシーンは未だに多くある(特に金融機関)。
システムのオープン化の流れに対して、メインフレーム上で動作するCOBOLプログラムをどう活用していくのかが、
現在企業が直面している課題の一つである。


【課題を掘り下げる】
システムのオープン化が進行すると、メインフレームシステムの存在が問題となるのはなぜか。
通常(大手)企業は、複数のシステムを保持している。
部や課などのセクション単位で、必要とするシステムを別々に開発してきたという経緯があるからだ。
しかし、これは会社視点で見ると、非常に効率が悪い。
同じような機能を重複して開発しなければならないし、顧客情報などのマスタデータを多重管理しなければならない。
そこで登場してきたのが、ERP(Enterprise resource planning)という概念だ。
企業資源計画、つまり、会社全体のシステムを統合的に管理しましょう、ということ。
別々に開発してきたシステムを一つの基盤に載せて、データ連携させることで、処理やデータの重複をなくす作戦だ。
そこで問題となるのが、メインフレームの存在。
メインフレームはベンダー依存の独自のプロトコルを採用しているため、簡単に同じ基盤に載せることができない。
メインフレーム上で動作しているCOBOLプログラムどうしますか?というわけだ。
もちろん、オープンな仕様を持つプログラミング言語でゼロから作り直すという選択肢もあるわけだが、なにせお金がたくさんかかる。
(長期視点で見れば、ゼロから作り直したほうがよいという場合も、もちろんある。)


【どうアプローチするのか】
現実的なアプローチの方法としては大きく2通りある。
  1. メインフレームのプロトコルをオープンなプロトコルに変換するコンバータを作る。
  2. COBOLプログラムをオープンな仕様のハードウェア(UNIX/Linux/Windows搭載機)に載せかえる。
これらの方法を採用すれば、既存のCOBOL資産を活用していくことができる。
しかし、それぞれの方法にも課題はある。


【1を採用した場合の課題】
たった一つのメインフレームのために、翻訳機を作らなければならない。
一人の人間しか理解することの出来ない言語で、百科事典を作成するのに等しい作業だ。
悪く言えば、その場しのぎの擬似オープン化と言えるだろう。
今後発生するであろう、仕様の追加・変更の度に、翻訳機もいじらなければならない。
誤訳の可能性が常につきまとう。


【2を採用した場合の課題】
COBOLはコンパイル型言語のため、新たなプラットフォーム用にコンパイルしなおせば、
オープン仕様のハードウェア上でも動作させることが出来る。
なーんだ、これが一番簡単ではないかと思われるかもしれないが、
そうするためには、そのプラットフォーム用にコンパイルすることができるコンパイラが必要だ。
現在では、OpenCOBOLというオープンプラットフォーム用のコンパイラがフリーで配布されているが、OpenCOBOLができたのは、ここ数年内のこと。
それまでは、各ベンダーが自社のメインフレームで動作させることを前提に、それぞれ独自のコンパイラを提供してきた。
そのため、COBOL言語としては一定の仕様を持っているにもかかわらず、
メインフレーム用に開発されたCOBOLプログラムは、各ベンダー独自の仕様を抱え込んでいる。
つまり、その独自仕様の部分を修正しなければ、コンパイルしなおすことができない。
(OpenCOBOLは純粋なCOBOL言語仕様に基づいているため、ベンダー拡張部分をサポートしない。)
利便性を向上させるためのユーティリティ機能の追加と言えば聞こえはいいが、
顧客囲い込みの意図があったことは間違いない。


【最後に】

COBOLでの新規開発にお目にかかることは滅多にないにせよ、COBOLを学習することに意味がない、なんてことはない。
それは、お金をできるだけ使いたくない企業のITインフラストラクチャ再構築に貢献できる可能性があるからだ。
COBOLなんて触ったこともありません、という若いエンジニアは、是非ともCOBOLと向き合い、新たなIT投資の需要を喚起してほしい。

0 件のコメント:

コメントを投稿