古典としてのCOBOL

日経新聞のサイトに下記の記事が載った。

COBOLに罪はない　トップ自ら情報戦略を　　:日本経済新聞

• [Tech]
• [考察]

日経BP(日経コンピュータなど)系よりもまとも。

2019/08/12 09:01

「COBOL」というプログラミング言語がある。1959年に業務用に開発され、金融機関などの基幹システムでは依然として現役だ。

(中略)

電子立国は80年代の日本の代名詞ではなかったか。COBOLに罪はない。これから前面に出るべきは経営者であり、牛歩のような電子化を進めてきた政府ではないか。

一方で日経BPの人。

COBOLベースの基幹系システムの面倒を見られる技術者はまもなく絶滅する。というか、中堅中小企業では既に絶滅したところも多い。そうなると、基幹系システムを誰も触れないだけでなく、利用部門の業務プロセスを知る人は誰一人いなくなる。全ての情報、知見は基幹系のブラックボックスの中。 https://t.co/SuHViLgvWm

— 木村岳史(東葛人) (@toukatsujin) August 12, 2019

 探せばツイート出てくるけど、このおじさん若者にCOBOLを触らせるな派である。

これなんだよ。これ！→筆者は「若者をCOBOL技術者にするな」と主張してきた。保守要員として働くのがよくない。いずれ老朽化したプログラムを一掃しなければならないときが来る。そのとき中年になった、保守しかできない技術者にどんなキャリアパスがあるだろうか。 https://t.co/zqL5KiPsO5

— 木村岳史(東葛人) (@toukatsujin) May 15, 2019

 ね。

日本の教育カリキュラムでは古文や漢文を学ぶし、ヨーロッパではラテン語を学ぶ。

小・中・高校でのラテン語教育を推進する人たちは、子どもたちがラテン語を学ぶとよい影響が見られると指摘する。イギリスの教育チャリティー団体クラシックス・フォー・オール（ラテン語や古典ギリシャ語などの古典教科を教えるため、小・中学校に資金援助する）が挙げる理由は以下だ。

英語の力がアップする：ラテン語は最初から文法をしっかり学ばないといけないため、英語の文法理解にもつながる。
文化をよりよく理解できる：神話は、現代アートや現代文学の基礎になっている。
ヨーロッパの哲学や歴史の土台を知る：ラテン語はヨーロッパの社会や考え方に影響を与えた。
多様な文化背景の人を理解できる：ラテン語話者たちには現代人とはまったく異なる面もあったので、ラテン語を学ぶと他者理解に役立つ。
広い視野を持てる：ラテン語を学ぶということは、文学、歴史、哲学、アートを学ぶことでもある。
ビジネスシーンで役立つ：学校や大学でラテン語を勉強した人は尊敬のまなざしを受ける。古典教科を学ぶと、明確な考え方ができ、細部に目が行き、討論がしっかりとできる力が育つ。

　実用的ではないからとか、子どもの負担が大きいから学習不要という意見もあるが、今後も、ヨーロッパでは、子どもたちがラテン語を学ぶ枠がなくなることはないだろう。

残念ながら現在はCOBOLを学んだからと言っても尊敬されるということもないし、広い視野を持てるということもない。

しかし、COBOLって割と英語ベースで分かりやすい言語なので、基本的な言語仕様を理解するためにはそれほど労力を要しない。他の言語ができるエンジニアがついでにCOBOLも覚えておけば、システム移行の時に役に立つ。逆に言えばCOBOLくらい古典として覚えておけと言った方がいいか。

COBOLを使ったシステムが無くなるまで、誰かがCOBOLに習熟していなければ無くすことは難しい。ブラックボックス化するからである。COBOLについて言えば、ロストテクノロジー化するならきちんとロードマップをもって滅却完了するまでは技術者を確保し続ける必要がある。つまり、はっきり書くと日経BPの雑なおじさんの無責任なツイートの通りでは、COBOLを使ったシステムのブラックボックス化が進むだけで無くすることはできない。

日経BPのおじさんは現場知らないからCOBOLエンジニアを無くせばCOBOLが無くなる、COBOLのシステムが無くなると保守してたエンジニアの職が急に無くなると思ってるみたいだけど、本当にそれしか知らないって人は対象がCOBOLじゃなくてもおまんまの食い上げになる確率は高いし、普通は長年やってれば複数の技術を身に着けてくるので他に目を向ければ別に困らずに職を確保できるものである。

標準COBOLプログラミング

COBOLポケットリファレンス

あと記事にちょっと突っ込み。

ランニングコストも高い。日本情報システム・ユーザー協会の調査では、多くの企業がIT予算全体の8割以上を既存の事業システムの維持運営に費やし、比率はこれまでほとんど変わらない。

これは長年ITを使ってきて資産があるんだからある程度は仕方ないだろ。COBOLを使わなければランニングコストが掛からないというわけでもない。AWS駆使しようがGCP駆使しようがForce.com駆使しようが、掛かるものは掛かる。確かにPaaS駆使すれば自前のコードは減るのでその分の保守コストは減るけど、ランニングはするしな。

ランニング向けJ-POP

----

ここから長いおまけ。

オレは最初に入った会社で、一年目はCOBOLのコンパイラ屋にいた。会社に入って新入社員研修の時に習った言語はPASCAL、アセンブラだった。配属されて担当部分の言語はPASCALだったが、COBOLを読み込んで中間形式に変換するのでCOBOLのデータ定義部分や計算部分を把握する必要があり、すぐに把握できた。

その後事故対策担当に廻ったのでさらにCOBOLの言語仕様全般を把握することになった。事故対策担当は現場からCOBOLコンパイラの不良か？と疑われて送られてくるCOBOLソースコード、利用先の環境を復元してコンパイルしたりダンプファイルを追いかけたりする仕事である。送られてくる9割はコンパイラの問題ではなくコーディング不正、送られてくる8割はクソコードだった。

この1年目で身に付けた他人が書いたCOBOLソースのデバッグ力は、後々役に立つ。いろんなシステム移行の際、COBOLのソースコードを読めるSEはオレ以外にほとんどいなかったので、移行ツール→不具合があればプログラマがチェック→お手上げのものはオレへみたいなエスカレーションルートが。

紙テープシステムをUNIXワークステーションで作っている時に（こっちはC言語）、メインフレーム側の担当者のプログラムがクソ過ぎたのでオレが全部リライトした。プロじゃないプログラマーってただのグラマーか？って言ってた。

また、某国の郵便貯金システムを作っている時も、異常終了するプログラムに困っているプログラマに実際にデバッグをやってみせて、問題箇所を教えてあげる&デバッグ方法を教えてあげるとか。デバッグする前から異常終了のコードを見てまずい箇所は分かってたけど。

あと、高給が欲しかったらCOBOLをやるというのも一つの手である。COBOL以外にもJavaとかできるほうがさらにいいけど。