COBOL云々の話が出てきたので、少し思うところを。
実際のところ、COBOLはよくできた言語で、今でも現役でいられるのはなかなかすごいと思う。
COBOL技術者がJavaになじめなかった理由としては、「パラダイムシフトだ」とか「オブジェクト指向だからだ」といった説明がよく挙げられる。
しかし、僕は データ管理の方法の違いこそが本質 ではないかと考えている。
僕自身はCOBOLの実務経験がないので伝え聞いた話が中心になるが、COBOLはとにかく データを“桁”で厳密に扱う思想 が強い。これは固定長データとの相性が驚くほどよく、むしろ データ定義そのものがCOBOLの主役 と言ってよい。
「データが決まれば処理が決まる」
――そんなコンセプトがCOBOLの根底にあるのだと思う。
当初のコンピューター環境はリソースが極めて限られており、一度に扱えるデータは可能な限りコンパクトである必要があった。
桁での厳密なデータ定義は、この制約と見事に噛み合っていた。加えて、当時の業務システムは SOR（System of Record）型 で、扱うデータの構造は最初から明確だった。
標準化された銀行間取引用データなども固定長レイアウトが主流で、COBOLにとっては非常に都合がよかった。
しかし、桁による厳密なデータ管理には弱点もある。
・設計確定の時期を後ろに延ばしたい というプログラマの本質的欲求と相容れない
・データ構造の変更・追加に極端に弱い
特に前者の弱点は、社会全体で「システム化」を進める際に致命的だった。“厳密すぎる”設計は学習コストが高く、人材供給の課題と直結していた。
その結果、業界は厳密さの一部に目をつむり、
データを桁で持つのではなく、“型”に基づく参照で扱う言語（Javaなど） へと移行していった。
コンピューターのリソースが指数関数的に増え、多少の冗長さを許容できるようになったことも追い風だった。
やがて、国際決済網や保振のデータ規格も
固定長 → 可変長（XMLやISO20022など）
へと移行していった。この時点で、COBOLの最大の強みであった「桁を基準とした固定長データの扱い」は弱点へと転じてしまった。
本来であれば、この時点でCOBOLは歴史的な役目を終えていてもおかしくなかった。しかし、そこで立ちはだかったのが “膨大なCOBOL資産” である。
その物量ゆえにCOBOLは淘汰されず、
XMLなどの可変長データを受け取って Java 等の処理系でCOBOLが想定している固定長データへ変換する仕組み（逆方向も含む）を用意することで吸収していった。
こうして、可変長データが標準となった以降の時代においても、COBOLは変換レイヤーに支えられながら 今日まで生きながらえている のだと思う。
ここで話を「なぜCOBOL技術者はJavaなどに移行しにくかったのか」に戻すと、理由はオブジェクト指向やパラダイムそのものの問題ではない。
COBOLが持っていた“厳密なデータ観”と、Javaをはじめとする“型と参照による緩やかなデータ観”が根本的に相容れなかったからだと僕は思う。
これは、Javaで育った僕が動的型付け言語に触れたときに、どこか「品質が維持しづらい」「不安がある」と感じてしまうことに近いのだろう。
文化として身に染みた前提が違えば、それを壊す方向の技術には本能的な抵抗が生まれる。それが「型」であれば、動的型付け言語に「型のような仕組み」を後付けすることで違和感を吸収できるが、
COBOLが前提にしていた 固定長／桁基準の厳密なデータ観 は、可変長へ移行する際にそのまま引き延ばすことができない。データ構造そのものが哲学的に異なるからである。
つまり「パラダイムシフトについていけなかった」という言説は、クラスや継承といったオブジェクト指向の概念が難しかったからではなく、“データをどう捉えるか”という文化的で深い部分の違和感と嫌悪感 こそが最大の障壁だったと個人的には思っている。
そして最後にもうひとつ。
文化による「えり好み」は、本来職業プログラマにはとても不利に働く。
新しい言語にしか市場がないのなら、移行を拒めば失業に直結してしまうからだ。ただし、COBOLには前述した「巨大な資産」があった。
その保守には莫大な予算がつき続けたため、
COBOL技術者は結果として 「移らない自由」 を持つことができたのだ。
86.4K
Views