銀行の言語事情 - novtan別館

といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。
今やメガバンクになってしまいましたが、僕がIT業界に入ったときはまだ都銀と呼ばれていた某銀行でのお話。用語について一切説明せずに行ってみる。世代チェッカーかも。

ホスト系

今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。
言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基本的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を引きずっていて、色々と余裕のないフォーマットになっていて、あの手この手で情報量を減らしているせいで非常にわかりにくいことも。
まあ、バッチ処理はメインフレームは早かったりします。
最近はコア部分もJavaにしようぜって騒いでる。多分上の人はJavaの何が良いか良くわかってない気がするけど、技術者の確保がしやすいという点では有望。当然心配されているのはパフォーマンス。未だに５年位前の認識で語っている人がいる。
でもまあ、設計次第で遅くなるのはどの言語も一緒とはいえ、Javaは遅く書きやすい気もする。
ホストは色々と管理が面倒で、DASDの場所指定がめんどいとか、IMS/DBはISAMの再編成なんていう馬鹿馬鹿しい仕事も良く入るし、順編成が全件舐める逐次処理に強いのは確かだけど、そろそろRDBでもいけるよね。
システムでかいから、あんまり占有できなかったりして、いざ打鍵しようとしたらリージョン落ちてるとか、VTSを借りなきゃ返さなきゃとかあわただしい。

中継機

この辺が一番最初にオープン化されたんじゃなかろうか。僕が入ったときはもう全編UNIXな感じで。当時はLinuxなんてないも同然だったから当然商用UNIX。AIXとかHP-UXとか。Solarisはあまり見なかったけど、シェルが違うからなあ。
言語は圧倒的にC。ミドルがCのAPIしか持っていないことがほとんどだったから。Javaが活躍し始めてたけど、「Javaだとあれが使えないからなあ」という理由が多くてね。JNIなんて危険だよねってな。
この手のプログラムは電文変換をすることが多いんだけど、Cならではのありがちな「領域はみ出し」によって数々の潜在バグが作りこまれていたものです。あと、プロセスを多重化するから、処理の入り繰りでおかしくなるとかね。
フロントエンド側とはMQとかで通信できてかなり楽ちんだったけど、ホスト側はSNAとかいちいち面倒です。何が面倒かって、接続用のお手製ミドルがあるから繋ぐのは簡単と思いきや、端末の採番依頼をして定義してもらってそれを受け取って面倒な接続テストをしつつ、ホストの運用に合わせて上げたり下げたりしなきゃならない。おかしくなったからリブートしてお茶にごし、とか出来ないんだよなあ。ホスト端末イメージの場合は。

フロントエンドサーバ

相手が外部システムだったらそれに合わせて言語を選んだりするけど、WebだったらJavaですね。なんでJavaかは不明ですが、銀行がインターネットバンキングをやり始めたときに、既にJavaに注力し始めていた米IBMが作ったWebフレームワーク(と呼ぶにはちょっとアレなものだけど)を採用したからかな(多分都銀ではさくら銀行が最初だ)。それ以上の利用はあまりないけど、Java自体が商業利用にコミットしていて、IBMやSUNのサポートがかなり受けられる期待があったからかも。テレホンバンキングはCだったな。
当時のプログラムとか見ると、「オブジェクト指向ってなんだっけ」みたいなものが山ほどあるはず。だって作っている人たちもわからないもの。ちょっとAPIが多くて便利なCぐらいにしか思ってない人もいただろうし、それこそC++から来た人は「ポインタないとか言っておいてNullPointerExceptionとはなんぞ」と思っていたに違いない。
やっぱり当時のJavaは使い方が悪いと遅くて、様々なテクニックを駆使して(いる時点でJavaっぽくはならないことが多い)早くなるように頑張っていたりしました。
Javaならではの何かってのはないんだけど、とにかくスケールするWebシステムの基盤があまりなかったから、はじめから大規模システムを想定していたJ2EEは、少ない選択肢の中で独占権を得たようなものですね。
あと、なんとなくだけど、アプリケーションが別サーバーにあるとか、ソースがそのまま動作しない(コンパイル必要)とかが銀行の文化に合っているのかも知れない。リリース管理とかを考えると、ある程度大きな塊になることも重要で、JarとかWarとかになるのがいいのかもね。
ちなみに、僕はシステムの本題とは違うところでちょっとしたページを作らなきゃならなくなって、Perlで書いたCGIを動かしたりしましたよ。ただ、ちょっとした奴ね。フレームワーク作ってどうたらって話じゃなくて、元々あるプログラムのラッパーみたいな奴。

端末とかATMとか

もはやグリーンディスプレーのダム端末などはなくて、Web端末ですよ。でも、頑張って昔の端末っぽく動くようにしているｗｗ努力無駄すぎｗｗ
まあ、テーラーさんに余計なことをやらせないためたっぷりと縛りをくれているわけです。JavaScriptを駆使したりしてて色々と大変なんだけど、とにかく電文がホストの電文だから、GWとかWebサーバは一生懸命だろうなあ。未だに高輝度指示とかするわけよｗ
ATMの印字票なんかも今更ホストに場所とか指示されなくても十分できるんだろうけど、ホスト側を変えるのもめんどくさいしなあ。

行内システムとか

これはもうWebとNotes。たまにSAP。Web部分はJavaだし、DBのバッチはCとOracleの場合Pro*Cとかで。情報系コアの処理量が多いところはホストと同じだったりするし、昔のシステムを引きずっているところもそう。面倒なのは外字だよなあ…
行内システムはわりと新しいシステムを採用する傾向があるんだけど、見た目は相変わらずホストの端末ですｗ勘弁ｗ

軽量な言語とこれから

なんでPerlやRubyが銀行で使われないのか。それはベンダー側の都合だよねえ。別に言語として使えないから、ではなくて、Javaを売り込みたいから、という戦略が続いているだけで。もちろん、スケーリングの問題が常にあるし、インタプリタなのが微妙に気持ち悪いとか、遅いだろうとか、そういうのもあるだろうけれど、Javaを中心にすえて、自社のミドルのAPIも作って、技術者も養成して、開発環境も世の中に提供して、という戦略だよね、やっぱり。
そういう意味では、SOAを大企業に適用していくってのは、フロントエンドはなんでもいい宣言になりうるわけで、現にIBMなんかはJavaとRubyの親和性を探っているし、結構プッシュもしている。Groovyってのを作ったけどあまり使われる話を聞かない。JRubyはどうなるかな。
ミッションクリティカルだったり、特殊な仕様をつかわなきゃならなかったり、他のモジュールと連携しなきゃならないときに、色々できるプログラマを集めるのもめんどいから、できるだけJavaで完結するように、という現状はありますが、今後フロントエンドのWebにJava以外の言語が使われるシチュエーションは増えていくようにも思えます。バックエンドのサービスを弄らなくていいシステムを作るんであれば、Javaである必然性はあんまりない。
でも銀行のシステムみたいな、戻るボタンを使ってあれこれして見た目と結果が違うじゃないか的難癖を付けられることを怖れるシステムでは普通のフレームワークをそのまま使えなかったりはして、色々とね。

まとめ

というわけで、銀行は、その時々によってそれなりに最先端なシステムを、しかし、慎重に導入してきました。言語もアセンブラ⇒PL/I・COBOL⇒C⇒Javaと移り変わっていっています。そのうち別の言語が使われるかもしれません。でもJavaが停滞したとしても、それに変わる言語はなかなか出てこなさそう。関数型言語なんてどうなんだろう。結構な技術者がやられちゃうような気もする。
で、今Javaが覇権を握っているのは、そうしたいと思った人と、それでいいと思った人の利害の一致に過ぎないと思います。それだけのポテンシャルがあったからこそだけれども、それだけじゃないよね。
ああ、そういえばC#というか.NETのことを忘れていましたｗポータビリティーのなさがアレなんだけど、こいつもフロントエンドだったら使いどころはあるようなないような…メガバンクじゃしばらくないよな。

あくまで某都銀の一部の事情でした。