銀行にクラウド化の波 (ふくおかFGがグーグル採用)

日経新聞の令和元年10月3日付記事です。ふくおかFGが2020年設立予定のネット銀行「みんなの銀行」の基幹システムにグーグルのGCPを採用することを報道しています。ほかの地銀にも外販することも検討中だそうです。初期費用が大幅に安くなり、運用や保守もクラウド事業者が担うので、銀行は本業に専念できる。勘定系をクラウド化する動きは、北國銀、ソニー銀でも始まっていると書いています。

更に、トモニホールディングスやTSUBASAアライアンスなどを参照しながら、クラウド化でシステム統合がやり易くなり、再編の選択肢が広がるとも付け加えています。ベンダーの動きとして、NTTデータがドイツのマンブー社と提携して、勘定系クラウド化を提案しているとか、グーグル・クラウド・ジャパンの「海外ではコアバンキングでも採用されている。」といった話も紹介しています。

この記事を読んだ時には、「また、金融IT素人が上滑った記事を書いている。銀行のシステム部は頭取から、ウチはどうする?といった相変わらずのご下問に、時間を取られて迷惑なことだろう。」などと思っていました。金融経済新聞が10月7日付の記事で「ネット新銀行設立の背中押す」との見出しで、ふくおかFGが2日に行なった記者会見の内容を報道していました。新銀行設立の検討を始めた2年前からパブリック・クラウドを使う方向にあった。アジャイル開発が可能なこと、拡張性・柔軟性・他社との連携容易性などを検証し、運用コストも10分の一程度に抑えられるとの結論に至ったことなどを紹介しています。今後、他行が続く可能性について、福岡銀行の横田副頭取は、そうした安易な見方を否定し、「われわれもコンサル会社と共同でなんとか開発にこぎつけた。一定の業容・規模と高度なスキルを持つ運用スタッフの存在が前提となる。」と説明したことを紹介しています。

筆者の知る限り、金融経済新聞にITに精通した記者はいないのですが、正確な報道内容で、思わず、日経は負けておるなと思い、当コラムに紹介する次第であります。例えば日経記事は、運用保守をクラウドに任せられると書いていますが、誰がアプリケーションの運用管理を行なうのかという問題を無視しています。FFGは2日の記者会見できちんと説明しています。クラウドベンダーの社員が個々の銀行アプリを理解している筈がありません。IaaSである限り、運用はユーザーの責任です。ユーザーは自行のアプリを熟知するだけでなく、グーグルを使うのであればGCPも熟知していなければ安定した運用など不可能です。運用の負担が増える可能性すらあります。運用が10分の一になると言いますが、運用にかかるコストのどこが減って10分の一になるのか?と、金経の記者は、記事には書かないまでも確認しておくべきでしたが。

みんなの銀行の開発費は70億円という話を聞きます。ネット銀のシンプルな勘定系で70億は随分と高いなという感じです。海外からの新規参入者であれば、普通10億円、少し贅沢して20億円というのが相場です。ベンダーはこの違いを、法定帳簿が大変などと説明します。普通、銀行員はこれで納得してしまいます。ですが、今日、法定帳簿と言われる当局向けを中心とする報告書の種類は減る一方です。先日、ある業態で教えてもらった時は40種程度しかありませんでした。それも、月末や期末の科目別や口座数などの数値と前期比程度の簡単なものです。これでは50億円以上の差の説明になりません。

日本の勘定系と海外のコアバンクとは何がどう違うのか。コアバンクは通常、科目別元帳に純粋な業務処理プロセスを組み合わせたサイロ式の構造です。つまり会計に関わる処理しかしない。勘定系はコアバンク機能に、総勘定元帳、科目間連動、センターカット連携、支店別管理、コンプライアンスチェックなどを組み込みます。途端に開発量と一取引を処理するロジック(パスレングスなどと言う)が飛躍的に膨れ上がります。これを具体的に理解していないと、日本の銀行勘定系に海外パッケージを使おうとして屍累々の結果を繰返すことになります。ふくおかFGは、その辺りを理解している筈です。その結果が70億という開発費になるのでしょう。もっとも、ネット専業銀として取り扱う商品やサービスが何かによっても大きく異なります、それに関する説明も出所不明の情報もありません。決まっていないとすれば、2020年本番は難しい。

最近、BaaS(Banking as a Service)という言い方が増えています。筆者を含めて、各自勝手な解釈をして判ったつもりでいます。無難なのは、非金融機関に銀行業務の一部機能をAPI経由で連携処理するケースです。(もっとも、銀行が要求するであろうトランザクション処理料を見て、ネオバンク・サービスを計画するFinTech企業などは、絶句するでしょう。ビジネスモデルは成立しません。)最も危険なのは、クラウド上に銀行機能が並んでいて、各行が自社に必要な機能を指定すると、カストマイズの必要もなく、自由勝手に使えると思うことです。確かに理想であるのですが。近頃、こんな理想形の営業を行なうベンダーがいます。それを真に受ける銀行も見かけます。物理モデルも具体的な移行方法もないのですが。筆者はこうした相談を寄せられると、その銀行がきちんと評価して理解できるかを先に確認します。無理そうなら、適当に距離を置くようにします。いちいち対応しても無駄だし、こちらが危険にさらされますので。

最近、あるベンダーが金融デジタル化の進まないのは、レガシー勘定系が悪い、勘定系が密結合になっているからという説明をします。(密結合の説明はないので、各自勝手な解釈をします。)行政当局の皆さんは、この話を聞いて、勘定系を脱レガシー化し、クラウド化しなくてはいけないと考えます。最終形はそうだとしても、そこに至る道筋を考えなくてはなりません。新銀行を創る時は、移行は必要ないので、問題ありません。経営危機で革命的なリストラを余議ない時も、問答無用で移行を最小限にすることで採用可能でしょう。要は割り切りの問題なので、それができるガバナンスが真の問題となります。

気になるのは、パブリック・クラウドがいつまで、コストや拡張性・柔軟性でオンプレミスに対する優位性を維持できるかです。システムの利用形態は昔から内部処理と外部委託を交互に繰返しています。基幹系をオープン化しながらクラウドに乗せるとして、その次の姿も視野に入れておかないと、次回もロックイン状態に巻き込まれ、その次の理想形に移るのに大変な時間、費用、人的負荷がかかるリスクを考えておく必要があります。その解を求めるには、OSSなどの動きから技術変移の流れと、自社内部のスキル戦略を見据えたITソーシング戦略を決めて、頻繁に更新し続けることが必要です。今日の正がいつまで正かは誰も判りません。ただ、ソーシング戦略とITスキル戦略がIT戦略の要であることは、今後とも変わりありません。

 

                                   (令和元年10月9日 島田 直貴)