アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
雑感 (スコア:1)
そんなわけで、メインフレームにはそれほど詳しくはないのだ。なので、メインフレームに関しては、一つだけＳＩサイドの課題（？）を提示するだけに止める。
それは、なぜ、メインフレームでのアウトソーシングと、オープン系でのアウトソーシングの収益性（利益率）が違うのだろうかという疑問である。
アウトソーシングとは、サービスを提供することに意味があ
written by こうふう
Re:雑感 (スコア:1)
理由としては、現在NTTデータが運用している共同運用システムはメインフレームを使用したシステムだが、SSCの共同勘定系は地区センター(二箇所だか三箇所だか忘れたが)ごとに勘定系が稼動している。全信用組合数は340、預金規模は7月のデータで100兆円ほどだが、仮に共同センターに移行する金融機関が100金庫、預金総額30兆円、顧客数3000万程度と仮定すると、都市銀行並みの大型システムと考えられる。この想定だけでは、国内の銀行でオープン系に移行した事例はない。
だが、そもそも単一ないしは複数のシステムで30兆円規模、3000万口座レベルを格納する勘定系を用意する必要があるのだろうか？ 信用金庫の平均預金残高は3000億円程度で、平均口座数は30万程度に過ぎない。最大の信用金庫である京都信用金庫ですら預金規模3兆円ほど、地銀では中位行であるみちのく銀行や山陰合同銀行レベルに相当する。
極端な話、オープン系で勘定系を構成する場合には、金庫ごとにシステムを用意してもお釣りが来るくらいだし、このレベルであればすでに第二地銀レベルの銀行がオープン勘定系パッケージを利用した共同運用システムに移行しているのでメインフレームでなければダメだという理由にはなりにくい。単にシステム間は為替関連の通信をやってればいいわけで、イニシャルコストを安く押さえるために、UNIXではなくWindowsを採用したいというのもわからなくもない。
実は、過去にも巨大規模で似たようなシステムが存在した。旧住友銀行の第三次オンラインシステムで、旧NCRメインフレームからACOSシステムに移行するとき、単一な巨大システムを作るのではなく、店群ごとに勘定系を稼動させるという分散指向なシステムだった。
問題は、このオープン勘定系フレームワークをフューチャーが完成できるかだが･･･。