Hatena::ブログ(Diary)

novtan別館 このページをアンテナに追加 RSSフィード Twitter

2008-06-29

銀行の言語事情

といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。

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

ホスト系

今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。

言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基本的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を引きずっていて、色々と余裕のないフォーマットになっていて、あの手この手で情報量を減らしているせいで非常にわかりにくいことも。

まあ、バッチ処理はメインフレームは早かったりします。

最近はコア部分もJavaにしようぜって騒いでる。多分上の人はJavaの何が良いか良くわかってない気がするけど、技術者の確保がしやすいという点では有望。当然心配されているのはパフォーマンス。未だに5年位前の認識で語っている人がいる。

でもまあ、設計次第で遅くなるのはどの言語も一緒とはいえ、Javaは遅く書きやすい気もする。

ホストは色々と管理が面倒で、DASDの場所指定がめんどいとか、IMS/DBはISAMの再編成なんていう馬鹿馬鹿しい仕事も良く入るし、順編成が全件舐める逐次処理に強いのは確かだけど、そろそろRDBでもいけるよね。

システムでかいから、あんまり占有できなかったりして、いざ打鍵しようとしたらリージョン落ちてるとか、VTSを借りなきゃ返さなきゃとかあわただしい。

中継機

この辺が一番最初にオープン化されたんじゃなかろうか。僕が入ったときはもう全編UNIXな感じで。当時はLinuxなんてないも同然だったから当然商用UNIXAIXとか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端末ですよ。でも、頑張って昔の端末っぽく動くようにしているww努力無駄すぎww

まあ、テーラーさんに余計なことをやらせないためたっぷりと縛りをくれているわけです。JavaScriptを駆使したりしてて色々と大変なんだけど、とにかく電文がホストの電文だから、GWとかWebサーバは一生懸命だろうなあ。未だに高輝度指示とかするわけよw

ATMの印字票なんかも今更ホストに場所とか指示されなくても十分できるんだろうけど、ホスト側を変えるのもめんどくさいしなあ。

行内システムとか

これはもうWebとNotes。たまにSAP。Web部分はJavaだし、DBのバッチはCとOracleの場合Pro*Cとかで。情報系コアの処理量が多いところはホストと同じだったりするし、昔のシステムを引きずっているところもそう。面倒なのは外字だよなあ…

行内システムはわりと新しいシステムを採用する傾向があるんだけど、見た目は相変わらずホストの端末ですw勘弁w

軽量な言語とこれから

なんでPerlやRubyが銀行で使われないのか。それはベンダー側の都合だよねえ。別に言語として使えないから、ではなくて、Javaを売り込みたいから、という戦略が続いているだけで。もちろん、スケーリングの問題が常にあるし、インタプリタなのが微妙に気持ち悪いとか、遅いだろうとか、そういうのもあるだろうけれど、Javaを中心にすえて、自社のミドルのAPIも作って、技術者も養成して、開発環境も世の中に提供して、という戦略だよね、やっぱり。

そういう意味では、SOAを大企業に適用していくってのは、フロントエンドはなんでもいい宣言になりうるわけで、現にIBMなんかはJavaとRubyの親和性を探っているし、結構プッシュもしている。Groovyってのを作ったけどあまり使われる話を聞かない。JRubyはどうなるかな。

ミッションクリティカルだったり、特殊な仕様をつかわなきゃならなかったり、他のモジュールと連携しなきゃならないときに、色々できるプログラマを集めるのもめんどいから、できるだけJavaで完結するように、という現状はありますが、今後フロントエンドのWebにJava以外の言語が使われるシチュエーションは増えていくようにも思えます。バックエンドのサービスを弄らなくていいシステムを作るんであれば、Javaである必然性はあんまりない。

でも銀行のシステムみたいな、戻るボタンを使ってあれこれして見た目と結果が違うじゃないか的難癖を付けられることを怖れるシステムでは普通のフレームワークをそのまま使えなかったりはして、色々とね。

まとめ

というわけで、銀行は、その時々によってそれなりに最先端なシステムを、しかし、慎重に導入してきました。言語もアセンブラ⇒PL/I・COBOL⇒C⇒Javaと移り変わっていっています。そのうち別の言語が使われるかもしれません。でもJavaが停滞したとしても、それに変わる言語はなかなか出てこなさそう。関数型言語なんてどうなんだろう。結構な技術者がやられちゃうような気もする。

で、今Javaが覇権を握っているのは、そうしたいと思った人と、それでいいと思った人の利害の一致に過ぎないと思います。それだけのポテンシャルがあったからこそだけれども、それだけじゃないよね。

ああ、そういえばC#というか.NETのことを忘れていましたwポータビリティーのなさがアレなんだけど、こいつもフロントエンドだったら使いどころはあるようなないような…メガバンクじゃしばらくないよな。

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

通りすがり通りすがり 2008/06/29 19:11 証券も似たり寄ったりです。

通りすがり2通りすがり2 2008/06/29 19:41 VOL-SEL>VOL=SERとか、大事なスキルはJCLとか、知ったかぶりですね。ってか銀行系SEっていっても情報系ですか?それならしょうがないですね。

d346prtd346prt 2008/06/29 19:58 >>2
どうして、そこまで自信満々なのだろう?
つーか、wktkがとまらないw

NOV1975NOV1975 2008/06/29 22:02 >通りすがりさん
そんなもんですか。昔証券やってた人の話では「障害?んな損失ディールで取り戻すから早く新しい機能入れてよ!」って言われてたらしいですよ。
まあ、最近はそうは行かないでしょうけれども。あと、東証みたいなシステムはちょっと違いますね。
新しいシステムの噂は色々と聞いています。

>通りすがり2さん
くっくっく…それがお前の最大のネガコメか?そんなものはわしには効かん!なぜならホスト系のプロジェクトをやったことはないからだ!
ちなみに情報系でもないよ。ウェブ系とか中継系。
VOL=SERのtypoは見ただけじゃあ身に付かないって証明ですね。JCLは超大事だよ!あれわからないとろくにテストもできないじゃん。大事じゃないってのはどういう根拠?
ホストは幅が広すぎて自分のやっているところ以外がどんなのかはわからなかったりするから、僕の話に聞く(というか隣の席の)プロジェクトとは違うのかも知れないけどね。

>d346prtさん
wktkしないしないww

NOV1975NOV1975 2008/06/29 22:04 ああでもtypoをそのままにしておくのはアレなんで、取り消し線で直したよ!余計醜くなったけど、meta情報としてはDELタグついてた方が良いよね。

文系大学生文系大学生 2008/06/29 22:38 はじめまして、こんばんわ。
今現在就活をしています。
例えばですけど、文系で知識ゼロの私が
ttp://www.future.co.jp/ 
こういった企業に入って、プロジェクトに関わって仕事を
進めていくことは無謀なのでしょうか?
こと採用市場では文系の人で知識なくても、こういった企業に
入社することは可能ですが、その道を究めたりするには数学が
必要だから一定レベルまでにしか至らないだとか、
そういったことはありますでしょうか?

初歩的な質問失礼しました。

NOV1975NOV1975 2008/06/30 00:21 デバイス系やったり数理系やったりするのであれば、限界はあると思いますよ。あと、かなりコアな部分までやろうと思ったら、まっさらから初めて経験だけで追いつけるかどうかはかなり怪しいです。少なくとも、ここで聞いているようでは。
文系理系はあまり関係ありませんが、「知識ゼロ」で出来るのは下積みから出来るSIerか、プログラマだかコーダーだかわからない偽装派遣会社ですね。
もちろん、それがキャリアとしてマイナスになるか、あるいはプラスに出来るかは、入ってからの努力次第です。
でも、ここ最近これだけインターネットで色々できる時代に「知識ゼロ」と胸を張ってちゃいかんとも思います。
僕も文系出身ですが、知識が0でなかったことが大きなアドバンテージでしたよ。
その会社がどうして例に挙がったかはわかりませんが、コンサル系にいきなり入ろうというのは似非コンサル目指しているわけでなければ止めて置いた方が良いと思います。僕らのためにも。ちゃんと教育が整っているならいいかも知れませんね。
あと、努力だけじゃなんともならないことがあります。どうしてもかなわないなって思う人はいるし、そういう人を目指すか、違う道に行くかを適切に選ぶことも大切。もちろん、入ってからでも間に合います。

その会社が社員にどういう動きを求めているかによって、その会社で上にいけるかどうかは決まってくるのではないでしょうか。

d346prtd346prt 2008/06/30 00:35 > wktkしないしないww
ちぇーw

でも、コメに良いオチがついてて楽しめました。(^^)/

通りすがり(1)通りすがり(1) 2008/06/30 01:30 んー、たしかに。
ディーラーの席で開発してる部隊は早いです。
ろくにテストせずにSQL流しちゃいます。いまどきの開発プロセス何のその。

業務系は銀行と同じだけど、
銀行よりは、新システムの導入は速いですね。
むしろネット系はどんどんチャレンジしている感じ。

元銀行系元銀行系 2008/06/30 08:20 IBMはGroovyは作ってはいません、借りてきています。
本拠地はあくまでもcodehaus
http://groovy.codehaus.org/Japanese+Documentation

Rubyでもいいかもしれませんが Java VMをRuby VMに交換しなくてはなりません。
Javaのversion upでさえ大変なのに、runtimeであるVMの完全入れ替えは大変に困難です。
多様な種類のマシンの上で動作可能なVMは実質Javaしか存在しません。
Ruby VMが UNIX やホストやいろいろなマシンの上で動くようにすればよいかもしれませんか、
その移植のテスト、動作保証のコストは、Java VMを作り続けたコストにとても近くなります、
つまり高額な移行コストが発生します。
Rubyに移行したいという思いがあって、このコストをだれかが負担すれば実現できるかもしれません。
プログラマーではなく、銀行経営者から見て何かメリットがあれば実現できるかもしれませんが、
可能性は低いと思います。

NOV1975NOV1975 2008/07/01 08:19 >1の人
やっぱりそういう違いはありますね。銀行はいい意味でも悪い意味でも慎重ですから…

>元銀行系さん
ごめんなさい、そこは繋げてないつもりだった…

ご存知と思いますが、銀行って他業種でたくさん実績が積まれてから採用しますよね。言語系の動作保証はそこで。
COBOLからJavaに移行したときも同じような話がありましたから、明らかなメリットがあれば可能性は0ではありません。
あるいは、Javaが急速に廃れて人がいなくなっちゃうとか。
別に新しいフロントエンドを作るのに移植コストが掛かるわけでもないし、移行コストはサーバー入れ替えだけでも発生することがあるので
可能性が低いということはないかと。
ただ、「Rubyに移行したい」という理由では銀行は動きませんよね。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/NOV1975/20080629/p1