地方銀行各行が，勘定系システムの再構築と運用にかかるコストを削減するため，いくつかのグループに分かれてシステム共同化を進めている。共通のパッケージ・ソフトを採用する，必要なハードウエアを共同利用する，といった取り組みだ。複数あるグループの中で，日本アイ・ビー・エムがITベンダーとして参加するプロジェクトが要注目である。
日本IBMが担当するプロジェクトは，他のITベンダーが担当する共同化プロジェクトとは異なる二つの特徴がある。一つは，次世代勘定系システムの基盤となるパッケージ・ソフトを，日本IBMではなく先進的なユーザー企業が開発する点。第2は，安定稼働の実績がある既存システムのプログラムを転用して，このパッケージを開発する点である。
パッケージ・ソフトをITベンダー主導で開発したり，ゼロからプログラムを開発する共同化プロジェクトでは，難航する案件が相次いでいる。日本IBMのプロジェクトが成功を収めれば，今後進展が予想される第二地方銀行のシステム共同化や電子自治体構築におけるシステム共同化において，有力なリファレンス・モデルとなる可能性がある。
富士通は仕様の定義に苦労
5月の連休明け，長崎県の十八銀行と福岡県の筑邦銀行，そして佐賀銀行が，相次いで“衝撃的”な発表を行った。3行と富士通の4者が共同で進めていたシステム共同化プロジェクトを白紙撤回することを明らかにしたのだ。
白紙撤回の理由は，「富士通が開発する次世代勘定系システムのパッケージ・ソフト『PROBANK』の開発が遅れたためだ」（十八銀行と筑邦銀行の担当者）。十八銀行は2004年1月，佐賀銀行と筑邦銀行は2004年7月にPROBANKを使ったシステムを稼働させ現行システムから移行する予定を立てていた。
しかし，富士通から「開発の進捗状況を鑑み安全・確実な稼働に万全を期し十分な開発期間を確保したい」という要請を受けた3行は2002年10月，それぞれ2006年1月と2007年1月に稼働開始時期を延期すると決めた。
その後，半年をかけて現行システムの“延命”コストを計算した結果の決断が，白紙撤回だった。筑邦銀行では，2007年まで現行システムを使い続けるためには，更新を控えているホスト・コンピュータの入れ替えが必要になる。「入れ替えたホストを，2-3年後にまた富士通のホストに入れ替えるのでは，コスト削減という当初の狙いが達成できない」（筑邦銀行担当者）と判断した。
「どうせ稼働開始を延期するのならば，オープン系のシステムも検討できる。今後，ホストを扱える技術者は減っていくことを考えれば，オープン系も有力な候補だ」（十八銀行と筑邦銀行の担当者）というのは，3行に共通する事情である。PROBANKは，富士通のメインフレーム上で稼働する。
PROBANKの開発が遅れた原因は，仕様の定義が困難だったこと。PROBANKの仕様は，富士通が主導し，九州3行のほか，福島県の東邦銀行や静岡県の清水銀行も協力して固めていた。しかし，富士通が各行の要求をまとめ切れなかった。「どこまでを共通機能にするかなどの切り分け作業が難航した」（富士通広報）という。
NECはプログラムにミス
仕様が無事に定義できても，大規模なパッケージ・ソフトをゼロから開発するのは容易ではない。
NECは連休明け，次世代勘定系システムのパッケージ・ソフト「BankingWeb21」を，ファースト・ユーザーである東京都の八千代銀行で稼働させた。しかし，稼働初日である5月6日から，他行取り引きができなくなる事態に見舞われた。
他行取り引きとは，八千代銀行に口座を持つ顧客が他行のATMなどを使って行う取り引きや，他行の顧客が八千代銀行のATMを通じて行う取り引きのことである。他行とATMを共同利用するためのネットワーク接続プログラムの一部に不具合があった。
BakingWeb21は，オブジェクト指向技術と呼ばれる先進技術を使い，機能ごとに部品化してプログラムを新規開発したもの。八千代銀行のプロジェクトは，2002年10月に予定していた稼働開始予定を，「移行に際して万全を期す」（八千代銀行総務課）ことなどを理由に2回にわたって延期した。だが，障害の発生を防ぐことはできなかった。
東京三菱銀行の既存システムを元にパッケージ開発
一方，日本IBMが4月に発表した，栃木県の足利銀行，岐阜県の十六銀行，茨城県の常陽銀行，香川県の百十四銀行が参加する共同化プロジェクトでは，日本IBMではなく，東京三菱銀行がパッケージ・ソフトを開発する。「銀行業務の仕様を最もよく知っているのは銀行自身。パッケージ・ソフトの仕様は先進的な銀行が主導して決める方が良い」（日本IBMで都市銀行以外の金融機関向け営業を担当する西岡修 金融サービス第三サービス営業部部長）。この方法ならば，複数の銀行から上がってくるさまざまな要求をベンダーが調整する必要もない。
さらにパッケージ開発では，東京三菱銀行が現在利用している勘定系システムのプログラムをそのまま利用して開発する。顧客ファイルや店舗マスターの設定など参加地銀に固有の部分をパラメータで設定できるよう，既存システムに“汎用化”を施す。ゼロから開発する場合に比べて，業務仕様とシステムの不整合やバグが発生する確率を小さく抑えられる可能性が高い。
完成は2006年中の予定。参加地銀は，このパッケージを原則としてカスタマイズすることなく利用する。東京三菱銀行自身も，このパッケージを利用する。
もちろん，東京三菱銀行が開発するパッケージだけで，参加地銀の次世代勘定系システムが構築できるわけではない。そこで日本IBMは，「PKO」と呼ぶフレームワークに則ってシステム共同化プロジェクトを進める。「P」は「パッケージ」の略で，東京三菱銀行が開発するパッケージ部分を指す。
都市銀行と地銀では業務が異なるため，「P」部分には，地銀には不要な機能も含まれる。しかし，「東京三菱銀行のように優れた銀行の業務ノウハウを安全に利用できることを考えれば，無駄な機能の存在はたいして問題にはならない」（日本IBMの西岡部長）という。
「K」は参加地銀が「共同」で利用する部分。地銀に固有の業務で，「P」に欠けている部分は，参加地銀が協力して仕様を決め開発する。この作業は，参加地銀と日本IBM，東京三菱銀行が出資して2004年秋にもに設立する「開発運用会社」が担当する。
「K」部分の仕様決定に当たっては，参加地銀の意見の対立や混乱が起こる可能性は否定できない。しかし，中核部分は「P」部分に含まれているので，大きく混乱する可能性は低いだろう。日本IBMと東京三菱銀行も仕様決定に協力することになりそうだ。
開発運用会社の規模や経営陣の人事，業務内容の詳細は未定だ。ただし，日本IBMが資本金の過半を出資する。
最後の「O」は参加地銀に「Original」な部分。この部分をどのように開発していくかの詳細は未定だ。ただし，開発運用会社が何かしらの形で関与する可能性が高い。
八十二銀行では予定通りパッケージが完成
日本IBMが取り組む今回のプロジェクトはまだ緒についたばかりで，成功する保証があるわけではない。しかし日本IBMは，今回のプロジェクトと同様の方針で立ち上げた別の共同化プロジェクトを今のところ順調に進めている。長野県の八十二銀行が中心になっているプロジェクトだ。八十二銀行のほか，徳島県の阿波銀行，茨城県の関東つくば銀行，長崎県の親和銀行，宮崎銀行，山形銀行，沖縄県の琉球銀行が参加している。
このプロジェクトでは，八十二銀行が同行の既存勘定系システムをベースにパッケージ・ソフトを開発。完成したパッケージが，八十二銀行において2002年4月に稼働開始した。今年5月6日には，関東つくば銀行が移行を完了。さらに今後，参加地銀が順次，移行することになっている。
東京三菱銀行が果たす役割を八十二銀行が果たしているわけだ。八十二銀行は自分自身が地銀なので，パッケージには「PKO」の「P」と「K」の部分まで含む。この意味では，東京三菱銀行以上に，大きな役割を果たしているとも言える。
「ITベンダー主導でソフトを新規開発」は悪なのか？
富士通やNECが採ったITベンダー主導でソフトをゼロから新規開発する，というやり方が悪いとは一概には言い切れない。大手ITベンダーは，地銀において数多くのシステム開発を手がけてきた実績を持つ。この経験で培った業務ノウハウを生かせば，特定の地銀の業務ノウハウにとどまらない優れた仕様のシステムを開発することは可能なはずだ。
また，ITの進歩は非常に速いため，最新のITを駆使したシステムにするためには，既存のシステムにとらわれることなく，新たにゼロから開発した方が良い面もある。しかし，現実にはプロジェクトは難航した。
金融機関では今後，第二地銀におけるシステム共同化の検討が活発化する。さらに，電子自治体構築プロジェクトも共同化が前提でシステム化が進められることになる。日本IBMが担当するこれらの地銀システム共同化プロジェクトが成功すれば，他の業種・業態のシステム共同化プロジェクトにも，影響を及ぼすことになるだろう。
（森 永輔＝BizTech副編集長）
■この記事は，BizTechイノベーターのコラム「視点」に，2003年5月20日付けで掲載した記事を転載したものです。
