プログラム言語探訪 COBOL(前編)
作者の生息しているコの業界は日進月歩どころか秒進分歩と言われるほど、新しい技術がどんどん生まれ、廃れていく業界ですが、このCOBOLと言う言語は、実にしぶとく生き残っている言語です。
最初に世に出てきたのは1959年だそうなのでFORTRANの二年後にはコンピュータを事務処理計算に使うという考えが広まっていたということなんでしょうね。そしていくつかの言語仕様の改訂を経て、俗にCOBOL85と呼ばれる規格がとにかく広がりました。だいたいコの業界と言うか、汎用機やオフコンでCOBOLと言ったらCOBOL85を指す、と言うくらいに。
そしてどのくらい使われているのかというと――正確な統計が出ているわけではないのですが――世界中で使われているシステムの中でCOBOLのプログラムはソースの行数で二千億行ほどあって、数万のシステムが動いていて、全世界で処理されているトランザクションの七割以上がCOBOLによるものだとか言われているとか。某検索エンジンの処理量を遙かに上回っているというのですから驚きです。
ちなみにある程度の規模のシステムになるとプログラム本数は軽く千本を超えるので、数万のシステムということはプログラム本数は億に届くでしょう。もう訳わからん規模ですね。
なんでCOBOLが使われるのかというと、理由は色々あるのですが……割と特徴的なのがデータの扱いやすさでしょうか。
例えば、外部とやりとりする固定長ファイルデータがこんなデータレイアウトだったとします。
取引日付 数値8桁 YYYYMMDD形式
商品番号 文字10桁
売上数量 数値 整数5桁小数部2桁
……
このデータのやりとりにあたって、自社システムでは取引日付の年と月を取り出して色々処理することがある、という前提でファイルから読み込むデータ定義をするとこんな感じになります。
FILE SECTION.
FD DATA-FILE.
01 DATA-RECORD.
03 TORI-DATE.
05 TORI-DATE-YYYY PIC 9(4).
05 TORI-DATE-MM PIC 9(2).
05 TORI-DATE-DD PIC 9(2).
03 URI-HINBAN PIC X(10).
03 URI-SURYO PIC 9(5)V9(2).
……
01 DATA-RECORD以降がデータの形式を定義しています。行の先頭にある数字はレベル番号とか呼ばれ、階層の深さを表している、という程度の理解で大丈夫です。その後に変数名が続き、PICはお約束の単語なのでスルー。その後にデータ型の定義。ぱっと見で数値か文字かがわかるだけでなく、桁数もわかるし、何なら小数点の位置もなんとなくわかる。
そしてファイルから読み込むときはこんな感じ。
READ DATA-FILE.
これだけでファイルから一件データを読み込んでくれるのですが、COBOLの真価はここから。
例えばデータがこんな感じだったとします。
20251231ABCDE123450012310……
読み込んだ後、TORI-DATEを見ると20251231が入っていて、TORI-DATE-YYYYを見ると2025が。TORI-DATE-MMには12が、TORI-DATE-DDには31がセットされています。そう、勝手に区切ってそれぞれの変数に格納してくれているのですね。そしてその後TORI-DATE-DDに10をセットすると、TORI-DATEは20251210になります。逆もまた然り。もちろん、プログラムの流れの中でTORI-DATEに20240610をセットすると、TORI-DATE-MMには06が入ってます。
もうね、COBOLで書いてると、この動きがたまらなく便利で楽です。ほかの言語でなんで出来ないのか、と問い詰めたくなるくらい。
ちなみにこんな風にさらに階層を深くすると「年月」が一つの変数で扱えます。
03 TORI-DATE.
05 TORI-DATE-YYMM.
07 TORI-DATE-YYYY PIC 9(4).
07 TORI-DATE-MM PIC 9(2).
05 TORI-DATE-DD PIC 9(2).
そんなわけでデータを取り扱うのにとても便利な機能が標準装備されているのがCOBOLなのです。
そして、もう一つ大事なのが計算精度でしょう。
基本的にコンピュータの計算は二進数で行われるので、実は小数点以下の数字を扱うのが苦手です。わかりやすい例としては0.1の表現。2進数では0.1を表現できず、0.0001100110011001……という永遠に続く循環小数になってしまいます。つまり、「だいたい0.1」という扱いになってしまうわけですね。そのため、少し前のコンパイラでは0.1を十回足しても1にならない、なんてことが当たり前に起きてましたし、そもそもほとんどの場合浮動小数点数と言って、桁数が固まっていないようなデータ型で扱われるのが通常です。
ところがCOBOLでは厳格に桁数を定めて処理することが仕様で決められているので、小数点以下の誤差が出ない。お金の計算、利息がどうのとか税率をかけて指定の桁位置で端数を丸めてというときにも、思った通りの結果になる。それがCOBOLと言うわけです。他の言語もいろいろ工夫をしていますが、COBOLの積み重ねてきた歴史にはなかなか太刀打ちできない。そんなことがあってか、今でも金融機関ではCOBOLを使い続けてるところが結構あります。
しかし、世間的には「COBOLをやめよう」という流れが主流で、某国の社会保障局のシステムを数ヶ月という短期間でJavaに置き換えようと計画しているとニュースで報じられたりしています。まあ、世界中のエンジニアたちが「無理」と断言していて、作者も同じ感想です。
なんでもそのシステム、プログラムが六千万行以上あるんだそうです。
作者は数百万行のCOBOLシステムを別環境(ただしメーカーは同じ)にCOBOLのまま移植するという案件をやったことがありますが、COBOL→COBOLだったにもかかわらず一年かかってますし、不具合も結構出ました。COBOLプログラム以外のところで。その十倍以上の規模&言語も変えるという作業を半分程度の期間でというのがどれほど無謀かわかるでしょうか。
ちなみに言語の載せ替えをAIにやらせるらしいですが、AIってそこまで精度は高くないので、最終的なチェックは人がやる必要があります。何しろお金の絡む話なので、たとえ1円でも……縁者なくてドル、セントか?……間違いがあったら、あの国の場合、数千万単位の訴訟が起こされそうですから、慎重にやらないとね。
ちなみにこうした載せ替えを人間がやる場合、「だいたいこういうところでよく間違える」というのがあって、そのあたりを重点的に見ていけば不具合は潰しやすいのですが、AIにやらせた場合、「まんべんなく不具合がちりばめられる」という可能性が。数ヶ月の間に投入される人員数は如何ほどか。終わりの見えない仕事にしか見えません。さすが某国、デスマーチの次元が違う。
そもそもの疑問として上がってくるのが、
「なんでCOBOLをやめなきゃならないの?」
というのがあります。
そもそも、企業のシステムで求められているのは結構単純なところが多いです。わかりやすいところで言うと、
「単価X円の物をY個売ったら売上金額はいくらになるか?」
こういうプログラムが多いのです。それを前述したように小数点以下の精度を維持して計算してくれているプログラムがあるなら、それをそのまま使い続けることの何が悪いのか、と。
すると、こういう風に言われるのです。
「COBOLって古い言語だし」
一応、最新の規格としては2014年に制定されているようですね。その前の2002年版が一般には最新仕様、らしいです。
古いと言えば古いですが、世間が思っているほど古くはない、はず。
と言うか、そもそもの疑問として、
「古い言語だと何が悪いの?」
言語の仕様書に「この言語は○年までに使用を中止すること」と書かれているならその通りにするべきでしょうけど、そんなことはどこにも書かれていませんし。
また、言語コンパイラおよび実行環境――要するに汎用機――も日本だとNで始まる会社が、アメリカではIで始まる会社が現在も、そして今後もリリースを続けることを表明していたりしますので、使い続けることに不安はないはず。
ではなぜ?と聞くと、
「COBOLでプログラムを書けるエンジニアが減ってるから」
と言う、「いや、教育すればいいだろ」というよくわからない答えが返ってくるわけです。今後もシステムを使い続けるならなおのこと、教育すればいいはずなんですよね……
長くなったので後編へ!