未だ動いている富士通製ﾒｲﾝﾌﾚｰﾑ700台！

毎日配信されてくるIT系push情報に、こんなものがありました。

700社が1台ずつなのか、1社で複数台使っているのかは分かりませんが、メインフレームということからして、銀行、官公庁、大企業に使われているものと推測できます。保守が大変なものの、安定稼働を続けていることやOSの構造が公開されていないことから外部からのアタックがない（できない）ことが大きな理由になっていると思います。特に、経営の根幹を処理対象にしている基幹システムをメインフレームで動かしている場合には、安定さとアタックを受けないということへでメインフレームへの評価が高くなるのは当然で、そう簡単にはリプレースできないでしょう。

それ以外の理由を見つけるとすれば、それは処理の改変（update）が大変だということでしょう。COBOLで作られているこれらのシステムは、COBOLの使いこなす団塊の世代を中心とした技術者が退職してしまった今、怖くて触れないというのが本当のところでしょう。また、全体像を把握することができる者がいないなかで、見える（理解できている）範囲内で改廃変更するとどこにどのような影響があるのか把握できないという問題もあります。

❝どこにどのような影響が把握できない❞とならないためにあるのが仕様書です。しかし、1970年～1980年代のメインフレーム全盛の時代が去ってから40年近くなる今、その仕様書が、膨大な基幹システムとそれにつながるサブシステムとの接続仕様まで含んで、仕様書に書かれていることとソースコードと完全に同期がとれていることを保証できなくなっていると思います。怖くて触れないし、どうしてもという時には膨大な工数をかけて微に入り細に亘ってテストして不具合が起きないようにしなければなりません。しかし、タイミングや複数のリクエストがあった時の沈み込みなど、テスト方法についてのレビューをしても、テスト環境を作りにくいテストをするのは大変です。時間をかけてもできないかもしれません。JRの座席予約システムや都銀のシステムのような何千何万の端末からの処理を捌くシステムでは、全てのテストパターンを洗い出すことすら難しいことです。

1970年～1990年代、年情報を西暦下2桁で処理してきた日付管理が、2000年になると下２桁が00になって1900年になったしまうという情報システムの2000年問題がありました。2000年はまだ先のことだと思っていて悠長に構えていた関係者は大いに慌てましたが、この伝と同じで、悠長に構えていたツケがメインフレーム、COBOL問題です。まだ先だとか、できない理由を並べてズルズルとメインフレームを使い続けて来たCIOはじめ、情報システム関係者は大いに反省すべきです。彼らは、高性能パソコン、サーバ、高速なネットワーク環境の登場を見て、メインフレーム時代の終焉を見通せなかったか･･･

今正しくDXブームですが、経営戦略を情報システム支えるというSIS（戦略情報システム）が叫ばれ、組織内の有形無形なリソースを有機的に睦びつけた統合情報システムが叫ばれた1990年代に真面目に取り組んでいれば、DXという言葉に慌てることないはずです。『DXそれは、昔統合情報システムと呼んでいたもので、うちは30年以上前から取り組み、既に完成しています』と胸を張って言い、『ただし、昔はメインフレーム環境で動いていたものが、今はクライアントサーバ型、クラウド型環境になっただけのことです』と言えるはずです。

DX時代と言われ、クラウド環境、ネットワーク環境を前提としたシステム開発に適していないCOBOLで作られたシステムを今後どうするのかもメインフレーム問題と切っても切れない問題です。日経XTECHの学びたくない言語アンケートの筆頭がCOBOLになっていますが、この状態で、メインフレーム上で動くCOBOLシステムをどうするかが喫緊の問題でしょう。

将来を見渡せば、COBOLをエンハンスしてDX時代に適した機能をつけてもらうか、思い切って他の言語で作り替えるかの選択を迫られます。前者の方が安全ですが、COBOLの元締めであるCODASYL（Conference on Data Systems Language）がどこまでやるのか分かりません。各企業のCIOは頭を悩ますことでしょうが、私がCIOならどうする？経営陣を説得して予算をだしてもらい、今風の言語でrecordingします。もちろん、データーベースはベンダ固有のものではなく、オープン環境のものを使います。