悪いのはCOBOLじゃないのかもしれない
「COBOLは現役バリバリだ。“COBOLは化石”などと口にするのはITとエンタープライズシステムが何たるかをわかっていない証拠」。東京海上日動システムズの稲葉茂 取締役 抜本改革推進第1本部長（写真）は“不当な”評価にさらされるCOBOLの評価をこう正した。
［XDev］「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ | 日経 xTECH（クロステック）
なんという力強い言葉。世間に流されてJavaやったりRailsに走る連中よりは、ずっとまともに見える。
ところでCOBOLはさんざんバカにされている言語だけど、いろんな人からCOBOLのプロジェクトの話をちょこちょこ聞くにつけ、どうも悪いのはCOBOLという言語そのものじゃなくて、古い時代の制約に引きずられたデータ設計のほうだと思うようになった。
COBOLでシステムが作られた時代というのは、
- メモリやストレージが高価だったので、サイズを節約するためのテクニックが優先され、わかりやすさは犠牲にされた。
- RDBMSが出現する前 (あるいはRDBMSがまだ成熟する前) だったので、正規化とかDOAのようにデータを整理する手法や考え方が広まってなかった。
という状況がある。
こういった時代だから、妙なフラグがたくさんあったり、データを名前でなく先頭からの位置で指定したりとか、そんなわかりにくいロジックやデータ構造がはびこってしまった。
でもこれって、COBOLのせいじゃないよね。もちろんCOBOLの言語仕様もイケてない部分はたくさんあるんだろうけど、それよりもグシャグシャになってるデータ設計のほうが問題なんじゃないかな。
で、この話は s/COBOL/VisualBasic/g としても成り立つように思う (登場時期は違うけど)。データ構造さえしっかり整理されていれば、言語がウンコでもなんとかなる、というのが最近の結論。
だから、
「30年システムに携わっているが，COBOLは規格として長期間安定し，ビジネスロジックの書きやすさにおいては右に出る言語はない」と判断したという。
［XDev］「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ | 日経 xTECH（クロステック）
のように、ロジックの書きやすさで選ぶのは間違いで、データ構造の書きやすさや把握しやすさで選ぶべきだと思う。
そう考えているので、自分がもしフレームワークを作るなら、データ構造の可視化というか、データを整理することに力を入れたものにしたいと思う。作るかどうかわかんないけど。
稲葉取締役は「システムが複雑になったのはビジネスが複雑になったため」とぴしゃりと言う。「システムトラブルの原因を“COBOLを使っているからだ”などと話す人や“COBOLは化石”などと話している人を見ると，ビジネスに携わる技術者として見識を疑う。
［XDev］「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ | 日経 xTECH（クロステック）
その複雑になったシステムやビジネスを、いかにシンプルなものにできるかどうかが、システムが成功するかしないかの勘所だ。これについては関連する別記事を見つけたので明日書く。
参考になるかもしれないリンク:
ちなみに、ERP 業界 No.1 である SAP R/3 のデータベースはまさに COBOL 的な作りになっており、RDBMSを使っているにも関わらず普通のテーブル設計にはなってないらしい。
R/3 のテーブル構造が非公開であり API 経由のアクセスしか認められていないのは、これが原因だとか (今は違うかも)。
