カテゴリー機能は終了いたしました。まとめ作成時にはタグをご活用ください。
93
(๑╹◡╹๑) @tsuchie88
[続報]スルガ銀-IBM裁判、東京地裁はITベンダーの責任を重く認定 - ニュース:ITpro http://t.co/URFcTOGF #itprojp ようやく判決か・・・業界注目の裁判だったけど、やっぱりIBMの無理は通らなかったか
(๑╹◡╹๑) @tsuchie88
背景的な話をすると、地銀でもユニークな経営で知られているスルガ銀行は、ネット支店の先行例でありほとんど唯一といっていいほど収益を上げてるところなんだが、勘定系システムに関しては80年代に構築された三オンベースのシステムを使い続けている
(๑╹◡╹๑) @tsuchie88
00年代に入って、都銀に続いて地銀でも三オンの更新時期を迎えると、NEC、富士通、NTTデータ、日立、UNISYSがそれぞれ自社開発の勘定系パッケージでの更新を働きかえるようになる。特に、NECと富士通はソリューションビジネスの中核に位置づけて力を入れていたわけだが
(๑╹◡╹๑) @tsuchie88
まぁ実際のところは銀行業務の実情もわからんITベンダーが、金融パッケージ製品なんぞ作れるわけもなく、最初の導入銀行に大幅な値引きをして、その銀行をモデルに共通部分と個別開発部分を分離したパッケージつくりをしようとしたんだが、このパッケージ部分の作りこみが難しい
(๑╹◡╹๑) @tsuchie88
あるパッケージでは、初期導入行の専用システムみたいになってしまって、つぶしが利かないシステムになってしまったし、あるシステムでは基本部分だけしかないので、他の銀行で使いには同じく大量の個別実装が必要となってしまい、パッケージ作りにはある意味で失敗している。
(๑╹◡╹๑) @tsuchie88
実際、パッケージとして完成度が高かったのは、NTTデータの地銀共同システムと、日立のNEXTBASE、UNISYSのBankVsionくらいだと思う。データは、デ通サ時代から豊富な金融開発の経験があるのと、日立はデータの開発したパッケージをカスタマイズしただけなんで
(๑╹◡╹๑) @tsuchie88
UNISYSの場合は、百五銀行や九州の三大地銀を相手に、何年もかけてパッケージ化に必要な要件を勉強会と称して交流しながら構築していったので、Windows Serverが基盤というかなり難易度の高いシステムだが、ほとんどトラブルなく構築を完了させている
(๑╹◡╹๑) @tsuchie88
で、まぁこれがおおよそ00年代半ばにかけての地銀の「第一期システム更新」といえる時期で、00年代後半から本格化する第二期では、各ベンダーがロクに採算も取れない個別開発をやめて、NTTデータが開発したパッケージを中核に各ベンダーのシステム上で走るシステムになっとるわけであるが
(๑╹◡╹๑) @tsuchie88
で、問題なのは、第一期の中で先行したNEC、富士通、NTTデータ(とおまけの日立)と、ちょっと遅れて参入したUNISYSとIBMである。UNISYSの場合は、前述したようにかなり時間をかけて作りこんでいて評判がいいんだが、IBMは日本の地銀を先行事例として世界展開を考えていた
(๑╹◡╹๑) @tsuchie88
というのは、世界的に見ると銀行の勘定系パッケージ製品でトップシェアにあるのが、OracleのFlexcubeだからだ。Flexcubeは、元々Citibankが海外拠点向けにインドで開発したパッケージを外販しはじめたのがはじまりで、今はOracle傘下にある
(๑╹◡╹๑) @tsuchie88
日本でも、新生銀行や一部のネット銀行、それに大手銀行でも海外系システムなんかで使われてたりするメジャーなパッケージで、メインフレームではなくUNIXサーバやWindows Serverで稼動するのでコストが安い
(๑╹◡╹๑) @tsuchie88
IBMは、金融向けシステムではダントツの強さにあるんだけど、その最大の理由はメインフレームからIAサーバまで貫徹するサーバやOS群と、世界中どこの国でも同じようなサービスを提供できる体制にあるんだが、その牙城を崩してるのがOracleなわけだ。
(๑╹◡╹๑) @tsuchie88
なので、世界的に見て勘定系システムの先進地域である日本で開発したパッケージを世界中に展開するという発想が生まれる。これが、IBMがスルガに提案したCorebankというパッケージだった
(๑╹◡╹๑) @tsuchie88
Corebankは、まったくゼロから開発されたものではない。NECが、オープン勘定系の基盤として、旧住友銀行(というか日本総合研究所)と共同開発したミドルウェア基盤DIOSA/OPBASEをベースにしていたように、元々は米国の保険会社と共同開発した基盤が元になっていた
(๑╹◡╹๑) @tsuchie88
この基盤がNEFSSというシステムなのだが、実際のところはSAILをJava EEで置き換えた程度の基盤に過ぎず、これに銀行業務システムを実装するにはかなりの手間が必要だった。そこで、その辺りの作りこみを目指したのがCoreBankで、最初のユーザーがスルガ銀行だった
(๑╹◡╹๑) @tsuchie88
スルガ銀行は、慶応閥のオーナー経営上場地銀というと聞こえは悪いが、競争環境としては最良かつ最悪で、神奈川県南部という成長地域を抱えながら、地銀の雄浜銀とドけち巨大地銀静銀にはさまれるというすさまじい地盤である。独自性がないととても生き残れないので、ユニーク経営なんであるが
(๑╹◡╹๑) @tsuchie88
スルガのシステム部門は、とてつもなく優秀で周辺系システムは90年代後半からMSFTと戦略的提携をして先進的なシステムを作り続けている。新しいシステムに寛容で、しかも長年のIBMの優良顧客、しかもIBMがターゲットとしていた中規模地銀という要件を満たす最良の選択だったわけだが
(๑╹◡╹๑) @tsuchie88
で、実際やってみると、パッケージ自体が非実存システムなんで、スルガ向けに実装しながらの作り上げになっていたんだが、スルガはスルガで要求が高い。勘定系ってのは、収益を生まないんだからケチるのが当然、という行風なんだが、ある意味正しい。
(๑╹◡╹๑) @tsuchie88
ところが、パッケージを作りあげることに注力すべきなのに、単独採算性という両立しない目標も追っていたので、要件の洗い出しの時点でかあんり計画が遅延していた。計画の遅延に業を煮やしたスルガに、とんでもない金額をふっかけたIBMを提訴して、問題がこじれる
(๑╹◡╹๑) @tsuchie88
ここからは、民訴の技術的な話になるんだが、スルガ側は契約を完成したシステムが稼動するまでの一貫した契約であったから、それに費やした費用を請求した。一方で、IBMは契約は独立した個別案件の集合体であり、計画の失敗はスルガ側の不誠実な対応に振り回されたのが原因であると主張した
(๑╹◡╹๑) @tsuchie88
しかも、要件定義段階で、要件の洗い出しなど成果は出ているので、この成果は他のシステムにも流用可能なので、スルガ側の請求は失当であるという無理なりな主張を展開した。この主張に、割と違和感を持ったユーザー企業も多かったように思える
(๑╹◡╹๑) @tsuchie88
プロジェクトの失敗原因は別としても、法廷戦術としてIBMの主張はちょっと無理があるんじゃねぇか、というのが大体の反応だったと思う。実際、主文と賠償額だけを見ると、IBM側の主張は受け入れられていないように見える。なぜだか知らんが、理由開示を禁止する申し立てもやってるみたいだし
(๑╹◡╹๑) @tsuchie88
昨日は、スルガ対IBM訴訟の経緯的なものを書いたんだけど、その後どうなったか、という話が抜けてたんで簡単に書いておく
(๑╹◡╹๑) @tsuchie88
NEFSS/Corebankは、最初の顧客であるスルガ以降客がつかなかったが、唯一稼動にこぎつけたのが、住信とSBIが共同出資して設立した住信SBIネット銀行の基幹系で、使ってるとなぜスルガが採用しようとしたのかがよくわかる。これ自体は非常に面白い思想で設計されてる
(๑╹◡╹๑) @tsuchie88
通常、銀行の勘定系では預金口座単位で階層DBが組まれていて、三オン以降のシステムでは、顧客が保有する口座をCIFデータベースによって紐付けされる形になっているが、NEFSSでは勘定系レベルで顧客データと口座情報が一体化している。
残りを読む(12)

コメント

ログインして広告を非表示にする
ログインして広告を非表示にする