COBOLが悪いと言っている人は、COBOLを理解していない。 しかし、これから学ぶ言語ではない。

をを結果結果結果

情報処理技術者試験の出題から、COBOLが外されました。
むしろ遅すぎたぐらいです。

COBOLというキーワードで検索すると
「COBOL　悪い」とか「COBOL　リスク」とか「COBOL 時代遅れ」とか
まぁ　評判悪いわけですよ

今回の日本のIT屋に一言は、
COBOLが、悪いと言っている人は、COBOLを理解していない。 しかし、これから学ぶ言語ではない。
と題して COBOL バッシングと今後の見通しについて考えてみよう。

小難しい話をわかりやすく開設しながらブログにまとめました。
最後まで読んでいただけたら幸いです。

スポンサーリンク

還暦を迎えたプログラム言語

COBOLというプログラム言語が誕生して今年（2019年）で60年
少し前の企業ならば　定年を迎える年齢です。

IT小僧は、COBOLについて、以前　プログラム言語について記事を書いたことがあります。

世界経済を長い間支えてきたCOBOLの優秀性を知ってほしかったからです。

検索で COBOL を検索すると
「COBOL　悪い」とか「COBOL　リスク」とか「COBOL 時代遅れ」とか　悪いイメージばかりなんですね。

新しい開発には、使われないし、ほぼ保守作業のみ
とても若い人に教育する言語ではないのですよ。

役目が終わったといえば　終わったわけですが、世の中には、変えられないものも多くあるわけです。

COBOLについて

ここで、なぜCOBOLが多く使われてきたかについて考えてみよう。

数字に強い

COBOLは、数字を10進数で計算しています。

例えば、
10進数の0～9を、4ビットの2進数で表現しています。
7231は、0111 0010 0011 0001と表現します。
4桁ずつの0/1の数字が、それぞれ10進数の「7」、「2」、「3」、「1」に対応しています。

コンピュータに詳しい人ならばわかると思いますが、コンピュータ内部で2進数で演算したものを10進数に変換するという処理が不要になるのです。

例えば、Javaで実現するには、BigDeicimal型のインスタンスを生成した上で演算処理を記述する必要があります。

COBOLは、変換する事で生じる丸め誤差の考慮が不要となるため、計算の誤差が許されない金額計算で使用されてきました。

大量の事務計算では、COBOLは、今でも最強と言っていいでしょう。

小数点何桁もの計算が必要な金融系で「絶対に誤計算が許されないシステム」を堅牢に作り上げるためには、COBOLが最適だったのです。

方言が強い

COBOLの最大の問題点は、大型汎用機で使わえる場合が多く、メーカー毎、コンピュータ毎に拡張された方言が多いのです。
つまり、COBOLのエンジニアといっても、それは、IBM、FUJITU、HITACHI、UNIVACなどなど、それぞれ、独自につくっていたために互換性がないシステムになってしまったのです。

ここが、移植作業での大きな問題点で、自分も過去に何度か泥沼状態になったことがあります。

もっとも、昔のパソコンの開発環境も似たようなもので、いまでこそ　プログラム言語が統一さえていますが、30年ほど前は、バラバラでした。

今の環境と過去の環境を比べることは、意味がありません。

エンジニアの引退問題

COBOL全盛期のエンジニアは、おそらく60歳に近くなっています。
正直、引退時期なので古い環境の保守が厳しくなっています。

そこで新しい人材を入れようとするシステム屋さんもありますが、それは、止めたほうがよい。
この時代にCOBOLなどを教え込むことが愚かな行為です。

負の遺産と言われる

こういう状態のことを負の遺産と呼んで COBOLが嫌われる要因です。
でもこれって、COBOLだけではなく、Visual Basicも同じことで　更に言えば、Javaだって同じ運命をたどる可能性だってあるのです。
Oracle Javaの有料化によって、今後は、Javaの開発は減る可能性もあるのです。

他の言語や環境だって「COBOL」と同じ運命になるかも知れません。

10年後に Javaが、負の遺産と言われることだってあるのです。

20年以上 COBOLアプリケーションが現役

COBOL開発・や行環境大手の英マイクロフォーカス（Micro Focus）社の調査結果報告によると

COBOLアプリケーションを持つ企業の3分の2が「COBOLアプリケーションを維持し、機能改善していく」と述べています。

また　英マイクロフォーカス社のスチュアート・マクギルCTO（最高技術責任者）は、

「今後20年以上、COBOLアプリケーションは現役で動き続けるだろう」

と発言しています。

コンポーネント化

マクギルCTOは、その理由として
「コンテナやマイクロサービスアーキテクチャーといった技術によって、COBOLアプリケーションは1つのコンポーネントとして扱えるようになるからだ」

コンポーネントにしてしまえば、計算ロジックのブラックボックスとなるので他のシステムからもAPIで呼び出すようにして
COBOLで開発されているビジネスロジックが長年変わらない業務を支えているシステムでそれをそのまま使おうという考えです。

すでにある完成されたロジックを再構築ではなく、再利用するというわけです。

マクギルCTOは、
「保守しにくいCOBOLアプリケーションが動き続けているのは日本だけではない。世界中で同様の課題が発生している」
それを
「スモールチームでマイグレーション」
を行い
「チームにシニアエンジニアを登用」
して、コンポーネント化を目指す。

そのためには
「開発当時のシニアエンジニアの力を借りるのが最善策」
とマクギルCTOは、言っていますが、人材を集めるのが厳しい。

正直、自分も30年前のシステムの再構築と言われても尻込みするだろう。
でも目の前にCOBOLのソースコードを出されても簡単に解読できる自信があります。

それぐらい、COBOLは、最近のシステムや言語と違い、シンプルでソースコードは、比較的簡単です。

少なくても他人の書いた Javaを解析するよりは、遥かに簡単なことなのです。

シニアエンジニアの力を借りる場合

引退したエンジニアを再雇用するしか、COBOLの問題を解決する道はないと思います。

シニアエンジニアを使う上で間違ってはいけないのは、プロジェクトマネージャーを同年代にやらせること

若いマネージャーでCOBOLの経験も知識がなく、ある意味　バカにしているようなひとを絶対に使ってはいけない。
COBOLのエンジニアは、現役時代、最先端の仕事だったのでプライドがあります。

同年代のプロジェクトチームでやることが、成功の鍵を握っています。

若い人材を使うな

COBOLの保守作業を将来のある若い人にやらせてはいけません。
新規案件は、これから出てこないので未来はないと思います。

若い人をCOBOLの現場に向かわせるような会社だったら、逃げることも考えよう。

まとめ

COBOLの実務経験がない人ほどCOBOLを下に見る傾向があります。

「テスト工数がかかり、１銭以下のズレが許されず、バグはゼロが当たり前な世界」
とか言っている人もいますが、

「システム屋として、当然目指すべき目標」ではないでしょうか？

「人間だから　バグがあって当たり前という」
考えは重大なバグを生み出します。

バグゼロの姿勢が重要ということをわかっていないのです。

バグゼロ、小数点４桁までの数値チェック
何十万件のデータ処理で１円どころか、0.001円の誤差が許されない世界を守っている人がいるのです。

そのような厳しい世界で戦ってきた エンジニアの先輩方に対して
「古臭い」とか「時代遅れ」などと　言うのは、やめたほうがよい。

スポンサーリンク