von_yosukeyanの日記： Probankはなぜ失敗したのか？

ちと、前の文でBWとProbankは失敗したようなことを書いたが、あまり正確ではない。BWはパッケージといえばパッケージなのだが、NECの提供する金融ソリューションの総称で極めて広い概念である。これに対して、Probankは勘定系システムを中核とした金融パッケージそのものの話なのでちょっと説明が必要かなと思う

ちと、(ネットに接続していなかったブランクが長かったので)Probankの話題を追えなかったのがアレなのだが、今のところわかってる範囲でProbankの失敗とその影響の大きさについて考えてみたい。

そもそも、F通の金融システムへのコミットは非常に長い歴史を持っている。旧都市銀行の中でも、さくら銀行や第一勧業銀行、東京銀行などのシステムを担当しているし、今年稼動したBTMの新国際システムの一部(グロカスとか)や新営業システム、SMBCの営業系システムなどで実績がある。

これだけでなく、最近ではジャパンネット銀行やソニー銀行のシステムを担当しているのもF通である。確かに、現時点で大手銀行のシステムでは、来年10月の稼動を目指しているみずほ銀行の統合基幹系システムだけだが、金融システム事業では長い歴史と経験があることには違いない。

90年代後半、F通は地方銀行のシステムパッケージとしてProbankを提唱しはじめる。これに、富士通系システムを利用している5行に加え、UNISYS系システムなど他社のシステムを採用した4行の合計9行が採用を決定、キックカスタマーとして東邦銀行が決定した。

しかし、この時点でパッケージが存在してたわけではない。まず、東邦銀行向けのシステムを作った上で、他のカスタマーに水平展開していく。第二次の水平展開には、九州地方の地銀三行の共同システム案件が決定しており、さらに第二地銀や有力地方銀行なども参加を予定していた。

普通、東邦のような中規模地銀のシステムを第二地銀や有力地銀に水平展開していくには多少無理があったことは確かだが、まずは東邦向けのシステム開発に注力することになった。しかし、東邦とF側の意思疎通に問題があり、開発スキームも曖昧だったことから、共有フレームワーク部分と東邦側の要求仕様の擦り合わせがうまくいかず、結果的にプロジェクトは遅延した。

遅延の原因には、Fのプロジェクト管理に問題があったことも確かだが、主要な原因はフレームワークができなかったことだ。そもそもFは、顧客企業への積極的な係わり合いを通じて得られた豊富な業務知識を武器に規模を拡大してきたという歴史的な背景がある。Probankは、そういった従来の開発手法をとりながら、他の銀行に水平展開可能なパッケージも同時に開発していくという手法を取った。

比較事例として面白いのがBWを採用した八千代銀行と、IBMと提携してシステムを水平展開した八十二銀行のじゅうだん会、そして日立と提携した肥後銀行の共同システム事例である。

BWも、パッケージとしては完成段階にあるとは言いがたいが、BWの採用表明を行っているのは第二地銀を中心としていくつかの事例があり、平行して開発することができた。NEC自体が、第三次オンライン時代に地方銀行向けにシステムの水平展開を行った経験があることと、元々住友銀行の第四次システムに関与した経験があるため、金融システムに一応の経験があったからだ。結果的に、八千代銀行の場合には要求仕様に合わせたシステム開発に手間取り展開が遅れたが、八千代の特殊事情や、後始末という観点から八千代の事例はあまり問題視されていない

#初期導入段階で問題が発生したが、今のところは安定稼動しているようだ。ちなみに八千代での展開は、当初02年時点での稼動を予定していたが、Q1からQ4に稼動が延期され、それからさらに五ヶ月延期され、最終的には一年遅れの稼動となった
#八千代銀行は分類上第二地方銀行で、預金額も1兆円に満たない小規模地銀である。しかし、信用金庫から普通銀行に転換したという非常に希な存在で、自営システムの老朽化が進んでいた。このため、信金系の共同システムを利用することができず、やむなく新システムを開発することになったが、小規模な地銀の上、破綻した国民銀行の営業譲渡を受けたこと、公的資金の注入を受けている関係から、システム開発にあまり予算を割けなかったという特殊な事情があり、破談状態であるが経営が悪化している都民銀行との合併交渉に付いていた時期もあった。
#結局このシステムが成功したかどうかは議論があるが、メインフレームから脱却した本格的なオープン系システムに移行したという意味では意義がある。しかし、C/Oの遅延と経費の一時的な拡大は、経営上としてはいささか問題があると言わざるを得ない(まぁ東京相和銀行の例を見るまでもなく)

#期限が守れて安定稼動すればいいという問題でもないのだ。例えばコストの問題や、投資回収とか(以下際限がないので省略)

もう一つの事例であるじゅうだん会の事例だが、IBM系のユーザーで比較的先進的なシステムで有名だった八十二銀行のシステムをベースに共同化を行ったことに特徴がある。これだけでなく、じゅうだん会の場合には勘定系の共同化だけでなく、周辺システムやATM管理、業務手順の共通化など様々な点で八十二銀行と共同化を行った点に特徴がある。そういった意味で、じゅうだん会の事例は、業務まで踏み込んだ統合作業で、もう一押しすれば合併に近い作業だったのだが、参加銀行のトップダウンが利いた成功事例であったと言える

最後に、肥後銀行の三行共同システムである。このシステムは、やはり日立系で比較的先進的なユーザーであった肥後銀行のシステムをベースに共同化した事例だが、じゅうだん会とは反対の事例である。このシステムは、肥後銀行の勘定系と情報系に加えて、地銀の国際系システムでは外販を行っている山陰合同銀行の国際系システム(UNISYS)を組み合わせたもので、運用自体はアウトソーシング子会社ではなく、日立本体に直接的な責任を負わせている点に特徴がある。加えて、システムが安定稼動すれば三行は日立に、不安定であれば日立は三行にそれぞれ報償を支払うという契約である点でも特徴的だ。さらに、三行は肥後銀行のシステムをそのまま導入するのではなく、業務を洗い出して不要な部分を思い切って切り捨て、単純化したところに特徴がある。

さて、Probankの場合にはキックカスタマーである東邦と、二次展開先である九州三行の要求仕様が際限なく提出され、フレームワーク開発と独自の要求仕様の盛り込みに追われつづけ、いつまでたっても要件定義ができなかった。F側にもそれを調整する努力を払わなかったために、東邦向けシステム開発が遅延し、みずほ問題の影響もあってか、三行向けシステムを当面延期し、余剰人員を東邦向けに集中投入するという「人海戦術」を取った。

それでも、結局は当初のC/O期限を達成できなかった。おまけに、当初想定していたパフォーマンスが達成できず、東邦向けシステムでは当初のシステムより一世代新しいメインフレームにアップグレードした上で、9月稼動の目処がついた状況だ。

ところが、九州三行の中には元々のFユーザーではない銀行もあり、三行向けのC/Oの遅れが非現実的なスケジュールであったために、採用を断念したというのが九州三行断念の背景のようだ。東邦と三行以外に採用を予定していた五行も、これ以前に不採用を表明しており、Probankを採用するのは現実的に東邦以外にあり得ず、(スケジュールは送れているが)まだ採用行が残っているBWとは状況が異なるのだ

こういった金融システムの失敗は、銀行ではないが過去に大和総研の証券共同システムでも発生している。証券共同システムとしては、NRIのSTARに次いで規模の大きいSONAR-lllをオープンシステムに置き換える野心的な計画だったが、安定稼動せずキックカスタマーの証券会社との間で訴訟問題に発展してしまった。結局、このシステムは現在は安定稼動しているが、赤字を垂れ流しつづけている。