COBOLはいつまで 動くのか~高価なものほど捨てにくい~

179 Views

November 10, 24

スライド概要

三宮.devのLT大会withカメラマンで使ったスライドです。内容的には前回使わなかった部分の再利用なので一部重複しています。

profile-image

いつのまにか業務系システム開発で二桁年数のゆるエンジニア LTとかイベント参加が増えてきたので資料まとめのために使っています

Docswellを使いましょう

(ダウンロード不可)

関連スライド

各ページのテキスト
1.

COBOLはいつまで 動くのか ~高価なものほど捨てにくい~ 2024.11.9 LT大会 with カメラマン みやもと

2.

自己紹介 みやもと(@Mymt_aggw2208) 大学卒業後にSIerに就職 途中職業適性を疑ってジョブチェンジを図ったものの、転職先 でことごとくシステム周りに配置されたため諦めて出戻り 現在はSES企業所属のエンジニア 使用言語はCOBOL→Java COBOL自体はともかくとして、COBOLの現場はあんまり思い 出したくない 画像は会社の懇親会で焼肉食べてる時に撮られた写真をそれなりに加工したもの

3.

COBOLとは? 以下Wikipedia「COBOL」の項から部分的に抜粋 COBOL(コボル)は、1959年に事務処理用に開発されたプログラミ ング言語である。名前は「Common Business Oriented Language」 (共通事務処理用言語)に由来する。 非理系の事務員や官吏でもプログラミングできる言語として設計され たため、自然言語である英語に近い記述をめざしたコマンド語彙や 構文(シンタックス)が採用されている。特に金額計算など事務処理 用に広く使われている。 膨大なCOBOLプログラムおよびそれらの処理するデータが、企業や政 府機関に長年開発し続けられ稼働している。 画像はCOBOLの主な住処たるメインフレーム( IBM)

4.

COBOLは消える言語? 私が新卒で就職してCOBOLのシステム案件に参画した頃に言われたのが 「COBOLはそのうち消える言語」 「なんで今時COBOLとかやってるの?」私が知りたい Windows95の普及もあってどんどんパソコンが普及していった時期のことです。 実際に参画先ではメインフレームからWindowsやLinux等のサーバーに移行しよ うという話も結構聞きました。 私自身も「このままCOBOLを続けていて仕事がずっとあるだろうか?」という不安 を感じていました。 その後、あるタイミングでJavaのプロジェクトに配属が決まって以降しばらく COBOLとの反復横飛びを経て、今は完全にJavaに移りました。

5.

時は流れて現在 とりあえず「COBOL 現状」とかで検索をかけると 「オワコンと言われる理由」 「なぜ無くならないのか」 「滅びゆく言語」 私も知りたい もう20年くらい滅ぶ滅ぶ言われている気がする その他ネガティブな見出しが並んでいます。 「本当に古いのか?」と疑問を投げかける見出しがあったから見てみたらIBMの 記事だったので、これはCOBOL技術者ひいてはメインフレーム利用者を増やした いIBMのプロモーションでは?と思ったり とにかく検索するまでもなく

6.

時は流れて現在 とりあえず「COBOL 現状」とかで検索をかけると 「オワコンと言われる理由」 「なぜ無くならないのか」 「滅びゆく言語」 私も知りたい もう20年くらい滅ぶ滅ぶ言われている気がする なんかまだある その他ネガティブな見出しが並んでいます。 「本当に古いのか?」と疑問を投げかける見出しがあったから見てみたらIBMの 記事だったので、これはCOBOL技術者ひいてはメインフレーム利用者を増やした いIBMのプロモーションでは?と思ったり とにかく検索するまでもなく

7.

どうしてここまで残っているのか? いろいろ本やWeb記事で理由や原因について語られているので、ある程度定説 はできている感じがします。 ただ、検索して出てくる話を見ても「なんか他人事だなー」という感じ。 COBOLを離れてそれなり経ちますが、当時の雰囲気と か思い出しつつCOBOLが残っている理由についてちょっ と思うところをお話したいと思います。 めちゃくちゃ私見かつ自分の体験に基づいての考察なの で、全然あてはまらない現場も普通にあるはずです。 あくまでひとつの例、意見としてご了承ください。

8.

まずはAIに聞いてみる とりあえず生成AIの中では比較的愛用しているGeminiさんに聞いてみました。 ちょっと長いので次のページで少し省略して書き出します。

9.

COBOLが無くならない理由 ● ミッションクリティカルシステムの基盤 COBOLが主に使われているのは金融機関や政府機関など社会インフラを支える多くのシステムで、長年に わたって安定稼働しており安易に置き換えることが難しい。 ● 膨大なレガシーコード 何十年にもわたって積み重ねられたコード総量が膨大であり、すべて新しい言語に書き換える時間とコスト を考えると現実的ではない。 ● 熟練プログラマーの減少 COBOLを熟知したプログラマーが年々減少傾向にある。 ● COBOLの強み 数値計算や大量データ処理に強く、特に金融機関で求められる高い信頼性と正確性を確保する上では依然 として有効な選択肢。 ● COBOLの進化 最新のCOBOLコンパイラはオブジェクト指向や新しいデータ型に対応するなど、時代に合わせて進化してい る。

10.

COBOLが無くならない理由 ● ミッションクリティカルシステムの基盤 COBOLが主に使われているのは金融機関や政府機関など社会インフラを支える多くのシステムで、長年に わたって安定稼働しており安易に置き換えることが難しい。 ● ● ● 膨大なレガシーコード 何十年にもわたって積み重ねられたコード総量が膨大であり、すべて新しい言語に書き換える時間とコスト を考えると現実的ではない。 後ろ2つは既存システムが残っ ている理由としてはちょっと違 熟練プログラマーの減少 う?と判断して考察対象から除 COBOLを熟知したプログラマーが年々減少傾向にある。 外 COBOLの強み 数値計算や大量データ処理に強く、特に金融機関で求められる高い信頼性と正確性を確保する上では依然 として有効な選択肢。 ● COBOLの進化 最新のCOBOLコンパイラはオブジェクト指向や新しいデータ型に対応するなど、時代に合わせて進化してい る。 次のページからひとつひとつ考えていきます

11.

ここでお詫び 今回のLTは、もともと先月参加したLT会用に作った内容になります。 全部話すと時間に収まりきらないということで、3つの中から1つだけ選んでもらって どうにかそれなりの時間に収めました。 残る2つをそのまま無かったことにするのはもったいないな……とみやもとが貧乏性 を発揮した結果本日参加のはこびとなりましたが、それでもやっぱり時間が足りな いので本日は1.のみ発表させていただきます。 1. 2. 3. ミッションクリティカルシステムの基盤 膨大なレガシーコード 熟練プログラマーの減少 3.はスライドのサブタイトルだけ変えた上でまたどこか で使わせていただきます。

12.

1.ミッションクリティカルシステムの基盤 過去に配属されたCOBOLの現場は金融系が多かったです。 他にも製造業やエネルギー業もあり、さらに過去の記憶をさかのぼれば学生 時代のバイト先だった大手スーパーでもメインフレームシステムとおぼしき画 面を操作していたので、おそらく流通業にもありました。 共通するのは名前を聞けば誰でも知ってそうな大手 確かにシステム移行によるトラブルが発生したらかなりの影響があることは間 違いないでしょう。 でも、じっくり時間をかけて段階的に移行して、旧システムと並行稼働 とかで対応できたりしないの?と疑問も浮かびます。

13.

1-1.私見:パフォーマンスの問題 時代遅れと言われつつ、メインフレームの処理性能はなんだかんだ高水準です。 2020年の記事ですが、「ベンチマークからみるIBMメインフレーム─AWS EC2 vs IBM LinuxONE」という性能比較の記事にこんな記載があります。 実際に、メインフレームで構築された大規模システムをダウンサイジングし、x86アーキテ クチャあるいはクラウドへ移行した場合、ほとんどのケースでサーバ台数あるいはクラウド サーバインスタンスが非常に増えてしまいます。 これこそが、メインフレームの性能の高さを物語っています。もともと単一のメインフレーム で行っていた処理を他のプラットフォームへと移行して実行する場合、サーバ台数やイン スタンスを増やして、並行処理させるというシステム構成が必要になってしまうのです。

14.

1-1.私見:パフォーマンスの問題 代表的な例で言えば、銀行その他金融システムで処理するデータは膨大です。 月初月末や五十日 (ごとおび)等、企業間取引の区切りの日は特に何十万件、何百万件 を処理することも珍しくありません。 こういう大量データを処理するバッチは夜間のうちに起動して翌日の始業時間までに終 わらせるものですが、これがダウンサイジングによって処理時間が延びた結果、決まった 時間までに終わらなかったらどうなるでしょうか? もちろんそれも考慮した上で先に書かれていたようなサーバー台数やインスタンス数を増 やす等の対応はするはずですが、計算違いや考慮漏れなどでトラブルが起こらないとも 限りません。 危ない橋は渡りたくないですし、踏ん切りも付けにくいのでしょう

15.

1-2.私見:お金の問題 日本でメインフレームによるシステムの導入が進んだのはだいたい1960年代頃だそ うです。 契機となる出来事として ● ● 1964年にIBMがSystem/360(後のメインフレームに大きな影響を与えるシリー ズ)を発表 日本でも1960年代後半に国産メインフレームの開発を開始 これは日本の高度経済成長~バブル経済の時期にあたります。 値段は明確にはわかりませんが、IBM公式サイトが見積もり前提で直接購入が想定 されていない構成になっていることからおそらくめちゃくちゃ高い。 当時システム導入した会社は高価なメインフレームを導入しても利益が出ると見込ん で、ばんばん設備投資につぎ込んだものと思います。

16.

1-2.私見:お金の問題 その後はバブル崩壊で不景気に突入しました。 この不景気と、メインフレームから分散システムへのダウンサイジングがもてはやさ れた時期は私の体感としては割とリンクしていた気がします。

17.

1-2.私見:お金の問題 ここで想像してみてください。 車でも洗濯機でも冷蔵庫でも何でも構いませんが、購入後20年の保証がついた高級 品を買ったとします。 残り10年保証が残っているタイミングで廉価版の製品が発売されました。 性能は高級品には劣りますが、あなたが必要とする性能だけなら十分満たしている ように見えます。 あなたはすぐに買い換えて高級品を捨てますか? こんなことを考えませんか? 廉価版の性能がもっと上がるかもしれないし、 高級品のサポートが終了するぎりぎりの時期を 見計らって買い換えよう

18.

1-2.私見:お金の問題 私が見聞きした範囲の話にはなりますが、メインフレームからの移行案件が動き始める のはたいていの場合、「サポートの終了まで○○年」と保証期限が迫ったあたりからでし た。 「まだ使えるものをそうそう簡単に廃棄できない」 「できるだけシステムにかける費用を抑えたい」 という方針のもと、着手までに時間がかかった可能性は高いと思います。 そして、いざ移行案件が開始後に工数が膨れ上がって当初想定した期限に間に合わな かったり、先のパフォーマンスの問題で思っていたほど安い予算内に収めることができ ず、移行自体を断念したのではないでしょうか?

19.

おわりに 個人的な感覚としては、まだしばらくCOBOLは無くならないんじゃないかという気 がしています。 既に20年消える消える詐欺していますが、もう10年くらい残るんじゃないでしょう か それでも様々なきっかけでCOBOLを脱却する企業もあります し、少しずつでも廃止されていつかはニュースにもならない過 去の言語になっていくのでしょう。 それまでにいくつ障害でニュースになるか…… COBOLに関わる人、主にプログラマーのみなさまの心が少し でも安らかであることを祈って、本日のLTを終わりたいと思い ます。 ありがとうございました