「新しい」ことは「いいこと」なのか？

つっちーさん

おはよう人類。

少し前の記事だが、こういう記事があった。

違和感が強い記事で、アーキテクチャも含めた全面刷新を「塩漬け」と評して、主要なアプリケーションの全面刷新を行わないSMBCやMUFJと言ったメガバンクや、浜銀を中核とした地銀共同システムMEJARの姿勢を名指しで批判する内容になっている。

特に、SMBCの勘定系システムは、大手銀行の中では最も先進的と評されているが、記者の手にかかれば「問題の先送り」とまで強い言葉まで使われてるのは、ちょっと首をかしげてしまう。SMBCの勘定系は、ユーザー数がめっきり少なくなったNEC製のACOSメインフレームを使っているが、1994年に現在のシステムの元になった住友銀行第四次オンラインシステムの登場時点で、SOAアーキテクチャ(当時はそのような呼び方はしていなかったが)や、バッチレスといった先進的な機能を有し、勘定系そのものが疎結合型のホスト群で構成されているという、今なお他行では実現できていない機能まで実装されている。

その後、およそ10年おきに稼働するホスト機を更新しながら、災害対策や規模が住銀よりも大きかったさくら銀行との合併、オープンアーキテクチャへの機能移植実証(実際に移植は行われなかった)と、折り目折り目で時代の要請に合わせたシステム対応を行ってきた。そして、2025年頃に登場する次期システムでは、大手銀行では初めてとなるフル24時間対応(現在は毎週日曜21時から翌朝月曜日7時までオンラインが休止する)を実現する。

「先送り」ではなく環境適応

1990年代に全面的に再構築されたSMBCはちょっと例外的なのだけど、邦銀の勘定系システムは1980年代に構築された第三次オンラインシステム(三オン)を元に発展してきた。三オンという単一のシステムがあったわけではなく、この時代に構築された勘定系システムが、だいたい同じような目標、目的、機能を実装していたからで、実際に構築されたシステムは銀行によって温度差があって、第二次オンラインシステムをベースに発展させたものや、三オンで全面的に作り直した銀行もある。

1990年代以降は、10年おきにシステムを全面刷新するようなことは行われなくなった。一つは、インターネットバンキングや24時間サービス化など状況の変化はあるものの、勘定系で扱う機能に大規模な刷新を伴う大きな変化がなかったという点だ。基本的に現行のシステムをベースに、勘定系の機能をホスト機の外に疎結合化して、ブロック化された機能モジュールを追加していく方法で対応されてきた。メガや大手地銀ではよく取られている手法である。

二つ目が、パッケージ化・共同化の流れだ。これは主に地銀を中心に、ITベンダーや有力地銀が開発したシステムを使ったり、運用そのものも含めてアウトソーシングする動きで、「お金を払って」「利用する」形態に変わっていった点だ。メガや大手地銀と違って、特に中規模の地銀では単独でシステム開発や運用を行うのが難しく、かといって制度対応やネット対応など必要な投資を維持するためには、共通化を進めてコストを削減することに大きな関心が集まった。

どちらのケースでも共通しているのは、三オン以後の勘定系システムでは、勘定系の刷新を伴うような大規模なシステムの再構築が必要なほど、差し迫った課題がなく、むしろ肥大化するシステム規模とシステム経費を節減するアプローチを求め続けることになる。

画像1

上記の図は、日銀金融システムレポート別冊「2020年度の銀行・信用金庫決算」(2021年7月28日)から引用した貸出金利別の貸出変化を示したものだが、貸出金利の低下は顕著なものがあり、経費率の低下圧力が増している。

画像2

実際に、経費の内訳をみてもシステム経費が含まれる物件費の抑制圧力は高く、人件費抑制効果や新サービスの提供による新たな増収効果がない限りは、新規投資がやりにくい状況にある。システムを全面刷新する動機は、非常に低くなってきている。

システム全面刷新は経営リスク

いずれにせよ、メガでも地銀でも業務に合わせたほどほどのシステムを実情に合わせて選択しているのだが、全面刷新を行うような銀行ほど、実は現行システムが老朽化していて刷新せざるを得ない状況に陥っているからともいえる。できれば、全面刷新は避けたいのだ。

一般的に、システムの全面刷新となると基本構想から要件定義に非常に時間がかかる。特に、要件定義段階での業務解析・基本設計に問題があると、後々の詳細設計や実装の段階で後戻りが発生してプロジェクトが遅延してしまう。また、システム再構築を行うプロジェクト期間では、現行システムへの機能追加は、構築中のシステムに後追いで機能を追加する二重開発となってしまうので、基本的にプロジェクト期間はほとんどの新規開発要求が凍結されてしまう。

プロジェクト管理が破綻したみずほ銀行の刷新の場合、長期にわたるプロジェクトの結果勘定系システムの刷新には一定の成功を収めたものの、勘定系以外のシステムの刷新が遅れたため、相対的にネット対応や営業店のDXが他行に比べて見劣りするもになってしまっている。全面刷新が必要なくらい老朽化したシステムを抱えている銀行では、「ほどほどのシステムを維持している」銀行並みにキャッチアップするだけでも大変なのだ。

しかも、全面刷新となると地銀規模では200億円、メガクラスになると数千億円が必要となる。ゼロレベルでシステムを見直すとなれば、開発期間は5年程度は見なければならない。ここまでのリスクを負っても、得られるベネフィットはそこまで高くない。これが全面刷新に躊躇する理由である。

クラウド化は誰もが恩恵を受けらるわけではない

もちろん、新技術への適応や、DX化を推し進める上でいつまでも古いアーキテクチャを使い続けるのは難しいという理由もあると思う。確かに、BankVison(日本ユニシス)やFBaaS(富士通)、Flexcube(Oracle)、MINRI(アクセンチュア)などクラウドレディを謳うパッケージも登場しているし、実際にソニー銀行、北國銀行、みんなの銀行(FFG系)などはすでに導入を表明または稼働している銀行も現れている。

遠からず、ネット銀行や地銀だけでなく、メガクラスの銀行でも勘定系へのクラウド適応は進んでいくと思う。ただし、それは一般的なパブリッククラウドとはちょっと違った形になると思う。

というのは、すでに地銀の共同センター方式では、パッケージソフトの採用と運用の委託というレベルの共同化から、システムの利用頻度に応じた従量制課金となっていて、利用銀行には専用の筐体や論理区画をソフトを借りているのではなく、金融システムサービスを買っているという形になっている。そして、サービスの中には単にシステム利用というだけでなく、参加銀行相互に業務を共通化して、それを基軸に業務最適化を図っているケースも多い。

なので、現在はメインフレームベースで運用されている共同センター方式でも遠からずオープンアーキテクチャベースのクラウドに移行するのは自然な流れだし、このまま現行のシステムを使い続けたとしても利用料金は下がっていく方向にある。何より、パッケージに合わせて業務を最適化しているので、別のパッケージや共同センターへの乗り換えというのはよほど料金が高止まりしない限りはあまりおこっていない。

現に、地銀向けで最大シェアを持っているNTTDataの場合、勘定系コアパッケージのBeSTAを基軸として、中堅銀行向け(地銀共同センター)、MEJAR(大規模地銀向け)、STELLA CUBE(小規模銀行向け)、BeSTAcloud(第二地銀向け)と共同運用システムで差を付けた様々なメニューを用意していて、これに情報系やインターネットバンキング(ANSER)など周辺システムをパッケージ化して提供している。さらに、料金が高いという声に対応するため、現在メインフレームベースで動いているシステムを、順次オープンシステムに移植してコストの低減に乗り出している。現在利用しているパッケージから離脱したり、独自に機能を追加する動きの方が例外的だ。

これは他社のパッケージでも同様で、自営行(自行開発の勘定系を自行で運用している銀行)や、参加銀行が少なくコスト競争力が低いパッケージが乗り換える事はあっても、やはりより参加行が多くロードマップが描けているパッケージに乗りかることが多い。ネット銀行や、一部の大規模地銀のように自社で開発運用するリソースがある銀行では、独自のパッケージをパブリッククラウドで運用するパターンもあるが、外販でも考えない限り勘定系の独自開発と運用を新規に始める合理性は低いのだ。

むしろ、勘定系に投資するよりも、インターネットバンキングや銀行アプリ、決済基盤への投資が差し迫って必要な対応で、投資意欲も高い。今頃になって勘定系投資や刷新を考えているというのは、ちょっと周回遅れな事情を抱えているという理解の方が適切ではないかと思う。

この記事が気に入ったらサポートをしてみませんか？