「メインフレーム」記事へのコメント

雑感

[koufuu (6853)]

一応、最近は銀行系のシステムの話にも噛むことがあるので、断片的な聞きかじり情報はあるものの、銀行システムが専門でないので、的はずれな理解をしている可能性もあるというのを含んで貰いたい。

そんなわけで、メインフレームにはそれほど詳しくはないのだ。なので、メインフレームに関しては、一つだけＳＩサイドの課題（？）を提示するだけに止める。

それは、なぜ、メインフレームでのアウトソーシングと、オープン系でのアウトソーシングの収益性（利益率）が違うのだろうかという疑問である。

アウトソーシングとは、サービスを提供することに意味があるはずであって、サービスレベルが同等であるならば、それをメインフレームで実現しようと、オープン系で実現しようと構わないはずなのに、なぜか、世間の相場は、オープン系で実現した場合には安く抑えられるだけでなく、利益率まで低くなるという疑問である。

これに関しては、メインフレームの市場に、オープン系システムを売り込むときの売り込み方に失敗して、それが相場として定着してしまったのではないかと疑っているのだが。だれか明確な答えをお持ちの方は居ないだろうか？

それはさておき、本題としては、

■では、銀行基幹系にメインフレームは適合しないのか？

という点に絞りたいと思う。

一応、論点を整理すると、

(1)基幹システムの再構築は必要である。
　(a)自前開発は、投資コストが高くて、事実上無理
　(b)パッケージや共同システム利用による再構築も難しい
(2)メインフレームかオープン系か

と言う感じか。順番に、行こう。

まずは、(1)に関して。これは、恐らく必要であろう。何より、新しいサービスを提供するときの足枷となっているようでは、今後の競争で不利になるのは火を見るより明らかである。理想を言えば、コンポーネントで開発することで、保守容易性を確保するとか何とかなりそうなものであるが、後述するように難しいようだ。

次に(1)(a)。これも事実だろう。今までもｘ次オンラインとかいって投資しているが、今の銀行の体力では、その投資に耐えられないと思われる。

次は、(1)(b)。これは誰でも思いつくのだが、意外に難しいようだ。聞いた話をいくつか並べてみる。

・海外のパッケージでは、必要な機能が足りない。具体的には、通帳関係の機能がない。

→インドのパッケージを使っている、新生銀行でも、通帳はなかったと記憶している。恐らく、通帳関連の機能を開発するコストと効果を勘案して、開発するぐらいなら、宣伝広告費、金利優遇等の原資にした方がいいと判断したのだろう。

・日本のパッケージは、まだ、出始めで海の物とも山の物ともつかない。

→とあるパッケージを使おうとした地銀の例だが、ファーストユーザー（？）がカスタマイズしまくりで原型を止めなかったらしい。ベンダは、ファーストユーザーとパッケージを作り上げて売ろうと考え、カスタマイズ後のものを横展開する心づもりだったらしいが、あまりに独自色を出されてしまって、横展開できないらしい。
この事例はともかく、日本の企業の場合、「パッケージはそうなってるかも知れないが、うちはこうやってるから、うちのやり方に合わせてカスタマイズしてくれ」という話が多いと思われる。まぁ、ベンダの提案が下手くそなのかも知れないが。

・共同センター化もそれなりに難しい

→まぁ、最近は共同センターも一般的になってきているようだけど、上のパッケージ化と関連すると思うのだが、同じシステムを動かしてないと、共同センター化してもコストを抑える効果は少ないと思われる。
とはいいつつ、地銀レベルでは主流になっていくと思われる。また、近隣の地銀で共同センター化しておけば、合併話がしやすいということもあるかも知れない。

で、次が、(2)か。都銀クラスの場合と、地銀クラスの場合で分けた方がいいかも知れないな。

まず、都銀クラスの場合。都銀クラスの場合、システム再構築の選択肢としては、次のようなものが思いつく。（とりあえず、運用方式はおいておこう）

(i)諦める（ぉぃ
(ii)自前で開発
(iii)自前で開発し、パッケージ化して地銀等に外販
(iv)海外パッケージを導入
(v)他行と共同開発

まぁ、(i)は論外として、(iii)はどうだろうか？オーバースペックの可能性はあるが、不可能ではないだろう。また、(iv)のように、外部のパッケージを導入できるだろうか？恐らく、新生銀行のように割り切らなければ、むしろ割高になる気がする。(v)も、都銀クラスだとメンツが絡むので現実的でない気がする。

そんなわけで、(ii)にせよ、(iii)にせよ、自前で開発するしかないのではないかと思う。 そうした場合、ＳＭＢＣの例が挙げられていたが、確か、そのシステムは住友銀行の第４次オンラインで実現したが、やったときは、仕組みとしてはすばらしいが、何の役に立つのか、金の無駄じゃないのかと、偉く叩かれたらしい。まぁ、結果的に、ＳＭＢＣ統合がスムーズに行く土台になったので結果オーライと言うことのようだが。そんなわけで、他行では、第４次オンラインをやっていないというのが、システム構成の差としてあるのかも知れない。この辺は、聞きかじり断片情報だけなので、von_yosukeyan氏の方がよほど詳しいだろう。

何はともあれ、そのシステム再構築の投資の原資をどうやって確保するかが課題だろう。で、メインフレームか、オープン系かとなると、一括再構築が難しい現状では、メインフレームを捨てられないと思われる。

次、地銀のケース。個人的には、地銀は、共同センター化していって、共同センターとＳＬＡ結んで、サービスを受けられればＯＫだと思っている。別に自前運用する必要はないだろう。で、ＳＬＡを結ぶんだったら、別にメインフレームでもオープン系でも関係ないというのが個人的な意見だ。要は、使えればいいのであって、ハードやＯＳは関係ないと思うのだ。もちろん、ＳＬＡで決めたサービスレベルを満たせない仕組みを採用することは出来ないので、オープン系の場合には、それ相応の信頼性を実現できる構成を組めるかどうかがポイントだと思うが。

あと、共同センター化することで、ディザスターサイトを作るのも作りやすくなると思うので、地銀クラスでは、自前運用は減っていくだろう。

そんなわけで、結論的には、地銀クラスは、共同センター化が進むので、ユーザー（地銀）から見ると、メインフレームかオープン系かは関係なくなり、都銀クラスは、過去のしがらみからメインフレームを捨てられないというのが、当面の動きではないかと思うのだが。あ、ＳＭＢＣは分からんけど。

勢いで書いたので、突っ込みどころ満載だと思うが。。。突っ込みよろしく。

--
written by こうふう

Re:雑感

[von_yosukeyan (3718)]

■現状認識
・都銀、信託銀行、大規模地銀(預金量10兆円付近)、系統金融機関系共同システム(信金、信組、農協)、メーカー系共同システム（地銀）のどれもでも、勘定系にオープン系を採用しているところはない

・自営地銀、新生銀行（銀行勘定規模では中規模地銀以下）、ネット銀行ではオープン系勘定系を採用している例もある

・都銀でのオープン系の採用は、情報系、国際系、対外接続系、制御系といった勘定系から見ればフロントエンド的なシステムで、比較的複雑ではないトランザクションの処理に使用されている。

■基幹系を更新する理由

・金融庁の指導（実はこれ、結構大きい）

・勘定系運用コストの削減
　a)共同運用化でスケールメリットを生かす
　b)開発費の共同分担
　e)業務の共通化、オーバースペックな第三次オンラインで付いた贅肉を落とす

・情報系やATM網を含めた運用コストの削減
　c)開発費の共同分担
　d)情報システム部門･子会社の分離（リスク部門の分離）

■基幹系を更新する方法

・パッケージを利用する
　1)自営システムの更新
　2)パッケージを使った共同システムに参加

・共同運用システムに参加する
　3)すでに稼動している自営他行のシステムに参加する
　4)すでに稼動している自営行同士が自主開発したシステムを持ち寄る
　5)メーカー/コンサルが開発した共同運用システムを利用する
　6)何行かがメーカー/コンサルを中心に集まって共同システムを開発･利用
　7)勘定系、国際系、証券系といったシステムごとにASP利用
　8)自行システムをメーカーに売却

・基幹系を更新しない

・自主開発を続ける

・余力のありそうな金融機関と合併する

■メインフレームを採用しつづける理由

・既存の資源が再利用できる

・管理･運用負荷が低く、開発も楽

・コストパフォーマンスが高い

・トランザクション管理、ワークロード管理のための特殊なツールをわざわざ開発しなくていい

・開発体制を変更しなくてもよい

・生産性の高い言語、ミドルウェア

■オープン系を採用する理由

・豊富なミドルウェア

・ハードウェア、ソフトウェアが安い

・豊富で優秀な技術者

・開発期間の短縮化

・開発したフレームワークを他にも販売できるかもしれないところ

・分散化がやりやすく、安定した運用が期待できる

■メインフレームがダメなところ

・運用･管理コストが高い

・技術者の不足

・既存の資源を再利用してもコストの削減にならない。将来的な拡張にも耐えられない

・メインフレーマーの掠奪体質、付き合いのあるベンダーとのしがらみを断ち切れない

・開発期間の長期化

■オープン系のダメなところ

・運用･管理コストが高い

・ワークロード管理やトランザクション管理などメインフレームで実現されている機能がオープン系では不足している

・既存の資源を再利用できない

・メーカーやベンダーによる手厚いサポートが受けられない

・開発体制や管理体制を再確立する必要がある

・開発管理がきちんとしてる金融系ベンダーやコンサルがあまりいない

Re:雑感

[von_yosukeyan (3718)]

まぁそういうメインフレームとオープン系（藁）それぞれの利点と欠点を考えても、系統金融機関の運用する共同運用システムでは、オープン系を採用するメリットは大きい

理由としては、現在NTTデータが運用している共同運用システムはメインフレームを使用したシステムだが、SSCの共同勘定系は地区センター(二箇所だか三箇所だか忘れたが)ごとに勘定系が稼動している。全信用組合数は340、預金規模は7月のデータで100兆円ほどだが、仮に共同センターに移行する金融機関が100金庫、預金総額30兆円、顧客数3000万程度と仮定すると、都市銀行並みの大型システムと考えられる。この想定だけでは、国内の銀行でオープン系に移行した事例はない。

だが、そもそも単一ないしは複数のシステムで30兆円規模、3000万口座レベルを格納する勘定系を用意する必要があるのだろうか？　信用金庫の平均預金残高は3000億円程度で、平均口座数は30万程度に過ぎない。最大の信用金庫である京都信用金庫ですら預金規模3兆円ほど、地銀では中位行であるみちのく銀行や山陰合同銀行レベルに相当する。

極端な話、オープン系で勘定系を構成する場合には、金庫ごとにシステムを用意してもお釣りが来るくらいだし、このレベルであればすでに第二地銀レベルの銀行がオープン勘定系パッケージを利用した共同運用システムに移行しているのでメインフレームでなければダメだという理由にはなりにくい。単にシステム間は為替関連の通信をやってればいいわけで、イニシャルコストを安く押さえるために、UNIXではなくWindowsを採用したいというのもわからなくもない。

実は、過去にも巨大規模で似たようなシステムが存在した。旧住友銀行の第三次オンラインシステムで、旧NCRメインフレームからACOSシステムに移行するとき、単一な巨大システムを作るのではなく、店群ごとに勘定系を稼動させるという分散指向なシステムだった。

問題は、このオープン勘定系フレームワークをフューチャーが完成できるかだが･･･。