COBOLコンソーシアム会長
ISO/IEC JTC 1/SC 22/WG 4 (国際COBOL委員会) 主査
高木 渉 (日立製作所)
プログラミング言語COBOLに関係する情報は、巷に氾濫しているとは言い難い。普段COBOLに接していなければ、もう使われていないという印象をもつかもしれないし、COBOLを使っている人達にすれば、自分たちはCOBOLを使い続けていいのかと不安になりかねない。
実際はどうなのだろうか。(独)情報処理推進機構の「ソフトウェア開発データ白書2010-2011」によれば、開発に使用した言語の割合は表1のとおりである。COBOLは、VBやCよりも多く選択されている。同じ文献から、COBOLが新規開発でも他言語同様に使われていることが読みとれる。プログラム資産があるから、仕方なく保守を続けているという構図ではない。また、既存資産の量について、2010年に開催されたCOBOL誕生50周年記念セミナーで日本アイ・ビー・エムが、世界で2,000億行という推定を出している。
| Java | 25.4% |
| COBOL | 16.8% |
| VB | 14.1% |
| C | 11.8% |
第１回答だけを集計
プロジェクト数: 2,417/2,584件
出典: (独)情報処理推進機構 ソフトウェア開発データ白書2010-2011
ここから想定できる現状は、目立ってはいないが、COBOLに関係する人はそれなりに多く、仕事もそれなりにある、というものである。
プログラマー個人は、自分のキャリアを考えると、より目立つ花形の技術に関係するスキルを磨く方が得策と判断するだろう。しかし、業界全体からみると、COBOL資産がそもそも膨大な上に、新規開発で増え続けているにもかかわらず、ベテランが引退していく一方で、新しい人材が供給されないのは問題である。
では、COBOLのプログラマーの養成は難しいのだろうか。実はCOBOLという言語自体を理解するのは、そう難しいことではない。他の言語でプログラミングの経験があるなら、対応する概念でCOBOLの仕様の多くを理解できるし、COBOL固有の部分にクセはあっても難しさはない。
COBOLを習得するのが難しくないのであれば、人材不足という問題はなくてもよさそうなものである。しかし、COBOLに直接・間接に関連するハードルはある。
COBOLがよく使われているという情報が届いていない以上、COBOLを学ぶ意義は理解されにくい。また、COBOL自体に、独特の雰囲気があるのは確かである。C言語の系統の構文を持つ言語を習得した人などには、COBOLを学習し始めるのに心理的な壁がある。COBOLでは、変数の宣言からして長いし、用語も独特である。
十進の固定小数点数で計算したり、ファイルのレコードをバイト単位で数えて設計したりするのも、最初は戸惑う点だろう。こうした側面を見ても拒否反応を起こさず、あるがままで受け入れることができれば、後は汎用のプログラミング言語である。
多くのプログラムは、それ単体で処理をするのではなく、OS（オペレーティングシステム）や、画面インタフェース、通信、データベース、印刷などを司る周辺のミドルウェア群と協調して動作する。これら周辺技術の習得は、必ずしも容易ではない。COBOLという言語自体の習得は難しくないので、COBOL技術者不足と、ひと括りにされる問題の多くは、実はこのカテゴリに入るように思える。
ミドルウェア等に、一般の人が触れられる機会には濃淡がある。広く普及している商品やオープンソースソフトウェアであれば機会はある。しかし、そうだとしても、使いこなせるようになるには、プログラミング言語の知識より多くの知識を必要としたりする。また、COBOLの場合、メインフレームコンピュータで稼動中のプログラムも多いが、メインフレームに触れる環境にいる人は少なく、人材の供給は不足する。
周辺技術の問題は、COBOLやメインフレームに限ったことではない。花形のプログラミング言語には、周辺技術が次々と生まれ、解説書が売られ、その技術を適用したプログラムが作られていく。しかし、技術が短命だったり、互換性なく発展したりすれば、そうしたプログラムはいずれ書き直しが必要になる。こうして、一人の技術者が知るべきとされる周辺技術は際限なく増えていく。
プログラム資産を保守するなら、言語に関係なく、他人のプログラムを読解する必要がある。COBOLに特徴的なのは、構造化プログラミング以前のプログラムが存在することである。今では、逐次、反復、分岐でプログラムを書くのは当たり前になったが、1980年代までのプログラムには浸透してない。また、COBOLの言語仕様も、1985年の規格で、ようやく構造化プログラミングを積極的にサポートする構文が導入された。それ以前のプログラムであれば、今風の制御構造では書かれていない。
昔のひどいスパゲッティープログラムを追うのが大変で、COBOLが嫌いになったという人もいるが、他人の思考の跡を面白がって読むくらいの心持ちが欲しい。
会社や行政機関等の業務システムを組むプログラマーであれば、業務内容を知った上でプログラムを開発・保守できる人材であって欲しい。周辺技術の習得に追われている時間は、必要ではあるが、実はもったいない。
純粋にプログラムに関する能力では、次の3点が、実務で必要になると考える。これらは、プログラミング言語に依存しない。
現実問題として、一からプログラムを書くより、他人のプログラムを変更する仕事が多い。修正の前には、まず既存のプログラムを理解し、方針を立て、修正箇所を洗い出す作業が必要である。COBOLの古いプログラムは、好意的に見れば、ロジックを追う良い教材になりうる。
他人のプログラムを改変するのであれば、改変した部分が正しく動作することはもちろん、改変していないところが以前と同じ振舞いであることを確認するのに必要十分なテストケースを準備できる必要がある。
代表的なスクリプト言語やオブジェクト指向言語では、リソースが抽象化されている。そうした環境では、枯渇させた経験がなければリソースが有限であることを実感しにくいが、メモリや時間を始めとするリソースとの戦いになることは多い。COBOLのプログラミングでは、ファイルやメモリなどのリソースに触れている実感がある。また、プログラムに必要とされるメモリ量を概算することは比較的容易である。
どのプログラミング言語で学習するにしても、ここまで書いてきた次のような能力を獲得しようとすれば、実務経験が必要になる。
(1) プログラムが対象とする業務を理解している
(2) プログラムの周辺の技術知識を持っている
(3) プログラミングに関する実務に必要な能力を習得している
その他にも必要とされる能力は多く、実務以外の場で勉強しただけでは即戦力とはなりにくい。しかし、(1) の対象業務を理解する素地と、(3) の実務で必要なプログラミングの能力の素地を、併せて養成する場として、商業教育は適しているように思える。
COBOLの資産は膨大で、とても無くせるものではない。したがって、COBOLの仕事がなくなることもないが、花形の技術とは言えず、個人がキャリアとして選びにくいのは理解できる。一方で、多くの業務プログラム資産は、COBOLで書かれている。COBOLを学習するのに心理的な壁があることを考えると、一度でもCOBOLに触れたという経験があれば、個人にもプラスに働くし、業界としても人材不足解消に役立つと考える。