von_yosukeyanの日記： BW21に見る地銀システム開発の失敗(4)

(3)に戻る

大手銀行が勘定系システムに採用しているメインフレームベンダーとしては、IBM(S/390 z/OS)、富士通(OS/IV)、日立(VOS)、NEC(ACOS)があるが、この他に周辺システムや地方銀行向けのシステムとして、NCR(System3000)、Unisys(2200/MCP)などがある。かつて、メインフレーム業界は、日本以外では「一人の巨人とその他一味」と呼ばれていた。巨人とは、言うまでもなくIBMのことだが、一味(BUNCH)とは、Burroughs、UNIVAC(Sperry)、NCR、CDC、Honeywellの5社を指した。86年にSperryとBurroughsは合併してUNISYSとなり、CDCは実質的に70年代にはメインフレーム業界からは消滅した。NCRは、91年にAT&T(当時)の傘下に入り、大型メインフレームからは事実上撤退して、IA系システムによる超並列サーバを指向するようになる。Honeywellは、元々GEから買収したシステム資産があったが、92年に仏Bull社にメインフレーム部門を売却している

一方の日本企業では、IBMとIBM互換機ベンダーだったアムダールからの技術提携を受けて、富士通と日立がIBM互換機を製造しており、NECはGE(後のHoneywellを経てBull)と技術提携していた関係から、gcos(Multics系統)と歴史的には関係のあるACOS-4を独自開発している(BullはNECと資本提携しているが、Bullのgcos7/gcos8系は現在ではItaniumで稼動しておりNOAH/Itaniumで稼動するACOS-4とは全く別物)。しかし、90年代に富士通はIBM互換機路線(IBMメインフレームOSとの互換性の維持)を放棄し、OS開発は独自に行いはじめ、日立は元々関係の深いIBMからメインフレーム用プロセッサの供給を受けるようになり、メインフレームの供給体制に変化が出始めてきた。日立は90年代後半に至り、独自のメインフレームプロセッサの開発を停止してIBMからの供給に全面的に依存するようになった。一方で、UNISYSは、2200系とMCP系の二つのメインフレームの開発を停止し、超大型のWindows/IA系サーバに注力するようになる。NCRに至っては、すでに90年代初頭には独自大型メインフレームの開発を停止し、超大型･超並列IA系サーバのSystem3000系統に移行しており、さらにハードウェアベンダーからコンサルタントやシステムインテグレーションを主体としつつある

こういった、メインフレームベンダーの減少は、すでに縮小を決定してしまったUNISYS･NCRのシステムを使用している地方銀行にとって、現状利用しているシステムの将来を断たれるという結果をもたらした。もちろん、メインフレームは利用者がベンダーに対して保守料金を払いさえすれば、20年や30年といった期間でも使用しつづけることができる(例えばGEが60年代に製造したMulticsメインフレームを採用した最後のサイトがシャットダウンされたのは何と1999年。メインフレームではないがDECのPDP-8やPDP-11に至っては現在でも稼動しているサイトは極めて多い)。だが、増大しつづけるトランザクションをさばくための能力向上や、機能追加には後継機種が存在しない状況は明らかに問題であるし、そもそもいつ停止されるかわからない部品供給状態や保守人員の確保だけで、こういったベンダーのメインフレーム基盤を採用している地方銀行の中には、現状のシステム資産を放棄して、全く別のシステムに移行することを考え始める銀行が増えてきた

加えて、UNIXやPCサーバの能力向上により、IBM、富士通、日立、NECといった大手メインフレームベンダーのメインフレームに対する姿勢も変化しはじめてきた。IBMと富士通は、相変わらずメインフレームの機能追加や能力向上に積極的だが、日立とNECは独自プロセッサの設計に消極的な態度を見せ始め、金融業以外のユーザーには、UNIXやPCサーバへの移行パスを推進しはじめてきた。こういった、メインフレームベンダーの動揺は、金融系情報システムに強い影響を与えつづけてきた大手銀行のシステム部門の再編によって増幅され、地方銀行は消極的な理由付けではあるが、一斉に次期システムの模索を開始することになる

こういった地銀の次期システムへの動きは、大きく分けて次の三つがある。一つは、システムの共同開発･運用である。これは、すでに第三次オンライン開発時に、独力での開発が難しかった第二地方銀行を中心に実例があるのだが、システムを複数の地銀が共同開発して、運用体制も統一化する方法である。この方法を採用したのは、じゅうだん会(IBM系)、広島･福岡(IBM系)、みちのく･肥後･山陰合同(日立系)などが代表的で、すでにある先進的なシステムに、ベンダーの強力の下、他行が必要とする機能を追加して共同で開発･運用を行うタイプである

もう一つが、ベンダー側が開発の中心となり、銀行間の共通する業務機能を絞り出してパッケージとし、各銀行が必要とする機能を追加していくというタイプで、やはり第三次オンライン時にNTTデータやUNISYSを中心としたベンダーが一部で提供していたが、もっと機能を体系化して先進化したものである。代表的な例に、NTTデータのBeSTA、BeSTAをベースとする日立のNEXTBASE。富士通のProbank、UNISYSのBankVision、そしてNECのBankingWeb21(BW21)などがあり、この他にIBMのNEFSS、印iFlexsolutionsのFlexcubeなどがある。これらのパッケージは、NEFSSとFlexcubeを除いて、単純に既存システムをパッケージで置き換えるというというだけでなく、運用体制などでベンダー側の支援を受ける形となり、多くが共同運用センターで運用する形態をとっているという点も指摘できよう

最後に挙げるのは、地銀のシステム子会社をシステムごとベンダーに売却する手法である。つまり、既存システムはそのままに、運用開発体制をベンダーに丸投げする方式であり、銀行側にはシステム企画部門が限定的に残るだけである。ケースによっては、運用センターを都市部に移設する形態もとることがあるが、実例としてはあまり多くない

こういった地銀側の需要に対応するように、ベンダー側も地銀向けのシステム体系を次々に提案するようになる。短期的に開発費がかかっても、長期的に見ればシステムインテグレーションや、アウトソーシング、運用支援などで十分にペイすると考えられるからだ。その中でも、パッケージ化の案件では、ベンダーごとに自社が得意とする基盤技術をベースに、様々なソリューション体系を提案していった。しかし、それには重大な欠点があった

(5)に進む