【なんでCOBOLがリプレースされんのかという話】
要因1 単純置換できない
COBOLの特性上、普通ならSQL1本で済むようなものを何本ものプログラムをかませて作成しており、それら全部のプログラムから編集仕様を抽出して集約する必要がある。これがまずひたすらに労力がかかる。
要因2 共通関数が実質作れない
普通ならば汎用的なロジックは関数化して使うと思うが、COBOLは個々のプログラムに仕込まれている場合が殆ど。最悪、プログラム数本に渡って処理している。これを拾い上げる必要がある。数千本のプログラムから。これも発狂ネタ。
ちょっと補足すると、COBOLは基本的にコンパイル時に関数を静的リンクでロードモジュールに組み込んでしまうので、関数を修正すると使っているプログラムを全てリコンパイルし稼働確認するという地獄作業がある。そのため、関数化をあえて避けている傾向がある。
要因3 処理時間
「数百万件の取引データをDBに取り入れ、数千表の帳票を出力するのを数時間でやる」というのが汎用機以外だと事実上難しかった。Oracleだと多分数倍の時間食っちゃうと思う。これはAWSで解消できそうなので、某メガバンとかは検討に入ってるね。
参考までに。私が見た某銀行の外為夜間バッチは大体500処理。プログラムだと1200位かな。出力帳票は400位。これを入力データ20万件位で5,6時間で流す。一業務でこの規模なので全体はこの10倍以上かな
要因4 DB整理
Oracleなら必要なテーブルさえあればよく、必要に応じてビューをちょっと作ったりするが、いかんせんCOBOLだとビューに相当する中間データが鬼のようにある。何が必要で何が要らないかの取捨選択を数百数千のデータに項目単位で行う必要がある。ER図書くだけでも気が遠い。
要因5 設計書が古い
せめてExcelになっててくれればいいが、最悪手書きのPDFで、しかも更新されてませんでしたオチとかが普通にある。
リライトするかリプレース側で新規作成するかのどっちかだと思うが、これも結構な数あるので地獄の作業になることうけあいである。
ところで、「こんなにCOBOLやメインフレームで維持するのが面倒なのに、ITがコストセンターになってる銀行基幹系でまだ残ってるのか」って話すると、次の三つの理由があるんじゃないかと思うんですよね。
第一に、垂直総合の解体。現代の銀行勘定系の元になったのは、1980年代の第三次オンラインシステム(三オン)で、基本的には機能はあまり変わってないんだけど、中身はかなり変化している。
三オンができた頃って、オンラインシステムはメインフレームを中核とした垂直統合的なシステムで、昼間はオンラインを実行して夜間はバッチ処理をやるみたいな感じで、全部の業務処理がホスト機に集中していた。
ところが、三オンのテーマにもなっているけど、この時代からバッチ処理は情報系にどんどん外出しして、勘定系はオンライン制御に特化する設計だった。時代を経るにしたがって、勘定系で持ってる機能を外部化していって、それらがオープン化されていくわけです。
例えば、90年代にはDWHが流行るんですけど、この時代くらいから情報系からDWHにデータを集めて営業系で使うようになったり、帳票出力処理も情報系でやるようになっていくわけです。
これが現代的にいうと、統合DBに一旦データを集めて、そこからDWHやら営業端末やら、チャネル系や帳票系にデータを変換して渡すみたいな仕組みにつながってるわけなんですよね。
逆の言い方をすると、勘定系に集中していた処理が、周辺系に機能が移っていって、負荷が重い処理とか、新規に開発するシステムは外部化されていったという感じになる。
二つ目なんだけど、新規開発の部分は極力Javaとかに置き換えられているという点。あまりいじらない基本的な機能はCOBOLのまま残しておいて、新規機能はJavaで作るという感じが増えてる。
銀行に限らず、業務基幹系システムを10年も維持すると、新規に投入するコード量は元のシステムの10倍くらいになったりすることもある。機能向上はなくても、法令改正対応みたいな不可避案件も多いのでこれは仕方がない。
そうすると、元のレガシーなコードを極力いじらずに、新規開発をCOBOL以外のコードで書いたり、プラットフォームにRDBやオープンシステムを使う形で、置き換えて維持する形態が生まれてくる。
もちろん、元のコードを全くいじらないというわけじゃなくて、新規開発部分で入出力をしやすいように、出力形式を標準化したり、コンテナ化、システム間接続にEAIを使ってインターフェースを統一するとかいろいろな工夫をやってる。
例えば、これは(10年くらい前の)
三菱UFJ銀行の基幹系構成図なんだけど、EAI基盤を使って勘定系ホスト中心の垂直統合システムから、分散化されたシステムから標準化された通信手順で機能を呼び出すようなシステムに大きく変わっている。
三つ目なんだけど、メインフレームの性能が向上したこと。90年代くらいまでは、メインフレームの性能は分散化されたオープン系と比べてしょぼかったんだけど、いろいろな要因でメインフレームの性能はかなり上がった。
例えば、IBM Zの最新機種のz14のケースでみると、1システムに搭載できるCPUは240CPUで、動作クロックは5Ghzを超える。並列シスプレックス接続すればクラスタリングでさらに性能を上げられる。
従来的なメインフレームのソフトウェアだけでなく、メインフレーム自体でJavaやRDBを稼働させても、性能的にオープン系よりも早いようなケースが多い。
しかも、メインフレームは、論理分割や仮想化が昔からあるので、例えばメインフレームの筐体を論理分割して、メインフレームOSとLinuxを走らせてメモリ上でデータ連携する(Hyper Socket)ような新しい使い方もできる。
以上の話を踏まえると、大手銀行で基幹系のクラウド化が視野に入っているというのはそれほど不思議な話じゃないんですよ。基幹業務が外部に切り出されて周辺化されていっていて、それらを稼働させるためのプライベートクラウドが既に存在している。
運用コストの低減のために、メインフレームを論理分割してLinuxを走らせて集約化するなんて流れは10年以上前からあるし、キャパシティオンデマンドで仮想環境を運用してるんですよね。
それをパブリッククラウドに移す、みたいな流れなので、むちゃくちゃな飛躍があるわけじゃない。
相当前から研究してる話です。
