またぞろCOBOLの悪口が始まったようだ。
また池田信夫かよ… と思ったんだけど、どうやら氏の妄想の類ではなくて元ネタは厚労省のリリースらしい。
毎月勤労統計調査を巡る不適切な取扱いに係る事実関係とその評価等に関する報告書について
それでまぁいろんなCOBOLに対するネガティブ話も流れて来たのだが、MSの澤さんが、いい感じで言語化してくれている。
元COBOLプログラマから見た、最近の「COBOL狂騒曲」に関する考察【連載：澤円】
まぁだいたいいつも言ってることなんだけど。
私がいつも言ってるのは、
に書いているので、澤さんのエントリと併せて見てくれると良いかと。ちなみに、私の職業プログラマーとしてのキャリアは、COBOLじゃなくてFORTRANが最初だ。
氏のエントリで重要だと思うのは、
今はバリバリ現役のJavaやC#でコーディングされたプログラムも、10年後はどうなるか分かりません。
だ。幸いにして、JavaもC#も、多分10年後には別の言語と言って良いくらい変化しているだろう。もしかしたら、その過程で後方互換性は失なっているかも知れない。PHPやRubyやPythonがメジャーバージョンアップした時、いくつかの古い仕様はなくなったり変更されたりしたわけで。
後方互換性が損われた言語は、嫌でもコードが更新されることになるか、あるいは捨てられてしまう。そのお陰で強制的に棚卸しされる。その結果、あまりレガシー化しない。そういった意味では、氏のエントリにあるJavaやC#の未来はCOBOLほどは危うくないかも知れない。
他方、後方互換性があるということは、コードの寿命が長いということである。しっかり作ったCOBOLのプログラムの寿命は長い。それは、システムを運用する時にTCOを良くする。IT技術者は勘違いしやすいが、「エンドユーザ」は特に問題がなければ、コンピュータシステムを更新したくはないのだ。限りなくコストは下げたい。そういった点で
COBOLは超優等生
と言っても良い。
運用に手や金をかけないで済むということは、結局手や金をかけないという当たり前の方向に落ちつく。そうなると、それをマネージする人もいらないということになり、単なるブラックボックスになってしまう。そして、いつの間にかレガシーになってしまう。
つまりはそう言ったことで、COBOLのマネージメント上での最大の問題は、最大のメリットと表裏であるということだ。
エンドユーザは安定を求める。その結果、システムはレガシー化をする。そういったことを考えたら、最初から
レガシー化を前提
としてシステムを設計することが必要かも知れない。「テストコードをちゃんと書いてレガシー化しないようにしましょう」ということも重要であるが、それ以上の「何か」が必要だろう。それが何であるかはよくわからないが。
PS.
何億回でも言うが、COBOLが滅びることはおよそない。それを明日にでも消えてなくなるかのようなことを喧伝して、若者にCOBOLを敬遠させるようなことを書き続ける日経コンピュータの罪は深い。
COBOLが滅びない限り、COBOLがいじれるエンジニアは必要とされる。COBOLを敬遠させてしまったら、COBOLコードをメンテする人すらいなくなってしまう。それがこの話の発端となった事件ではないか？
Qiitaにドヤ顔で、
典型的なCOBOLだと、関数がありません。サブルーチンしかなく、変数のカプセル化が出来ない
とりあえずここではCOBOLとは昔ながらのCOBOLということで話すすめます
などと書いてしまう輩まで出る始末だ。あのな、40年以上前の仕様なんかで言語を論じるなよ。40過ぎのおっさんに、「お前おしめしてるだろ」って言うに等しいぞ。