なぜ日本では“BaaS（Banking as a Service）”を提供している銀行が少ないのか。国内初のデジタルバンク「みんなの銀行」の、勘定系システム開発と運用を担うゼロバンク・デザインファクトリーでバックエンドのエンジニアリーダーを務める髙杉健吾さんに、BaaS実現にあたって重要となる「システム」について話を聞いていきます。
※この記事はオウンドメディア『みんなの銀行 公式note』からの転載です。
銀行は顧客から預かったお金を運用
——自己紹介をお願いします。
髙杉 ゼロバンク・デザインファクトリーには2020年に中途採用で入社したのですが、これまでは国内大手ITベンダーで10年ほど銀行の勘定系システム開発に携わったり、某銀行のシステム部で4年ほど、勘定系システムの更改、全銀モアタイムシステムへの対応に携わったりしてきました。ゼロバンク・デザインファクトリーにジョインする直前はいわゆるFintech企業におり、ゼロから暗号資産取引所のシステム開発をしていました。
——ゼロバンク・デザインファクトリーへジョインした理由は？
髙杉 Fintech企業で働いてみて気付いたのは、Fintech企業ができることには限界がある、ということでした。というのも暗号資産取引所にて顧客から預かった資産は、当然といえば当然なのですが、運用したり他の人に貸付をしたりということができません。
その点銀行は顧客から預かったお金を運用や貸付に回すことができる特殊な業種です。銀行にしかできないという強みを活かして、もっと顧客に寄り添った金融サービスを提供できるポテンシャルが銀行にこそあると思いました。
そういった想いから、Fintech企業で培った経験も活かして、もう一度、銀行の中でFintech以上にイケてるサービスを作りたい、と一念発起してゼロバンク・デザインファクトリーへジョインへのジョインを決めました。
——私も前職はFintech企業にいましたので、非常に共感します。様々な種類のシステム開発に携わってこられた髙杉さんですが、銀行の勘定系システムと銀行ではない事業会社の基幹システムとは、ざっくりいうと何が違うのでしょう？
髙杉 まず大きな違いとしては、銀行は顧客のお金を預かっている、ということです。銀行では実際に預かった現金残高とシステム上の帳簿の残高が、たとえ1円でも合わない、ということが起きると大変な問題になります。それゆえに銀行の勘定系システムには、残高の整合性チェック、二重処理のチェック、細かい処理順序の設計など、正確さや確実性という意味で非常に高いレベルのシステムが求められます。
またこういった性質からFISC（金融情報システムセンター）が規定する安全対策基準に則ったシステムの構築が求められ、監督官庁である金融庁の検査をクリアする必要もあります。
銀行のAPIを使いたい企業は確実に存在するし、ほかの業種との融合はもっと盛んになる
——なるほど。大手ITベンダーしか勘定系システムを取り扱っていない理由がよくわかりました。BaaSの実現はこの勘定系システムにAPIという玄関を作るところから始まると思うのですが、そもそも銀行APIの活用自体、あまり進んでいないような印象です。
髙杉 前職にいるときにFintech企業という立場で某銀行のAPI利用を検討したことがあるのですが、初期費用もランニングコストとなるAPI利用料もめちゃくちゃ高かったんですよね。銀行からすると慈善事業ではないですしAPIも相当にお金をかけて整備しているので、そういった価格設定で収益を確保しないとAPI開発コストもペイしない、というのはわかるのですが……。正直これでは資金力のある大手企業以外は使えないなー、と思いました。
逆に言うと銀行側がよりリーズナブルな価格設定でAPIを提供できれば、銀行のAPIを使いたい企業は確実に存在しているし、銀行とほかの業種との融合はもっと盛んになると思っています。
私としてはこのAPI利用料の価格設定の柔軟さを担保するために、特にBaaSシステムは内製化にこだわっています。
——勘定系システムでは大手ITベンダーがパッケージソリューションを提供していますが、パッケージソリューションを採用してBaaSを実現することは難しいのでしょうか？
髙杉 結論から言うと、パッケージソリューションを採用していてもBaaSを実現することは可能だと思います。ただ先ほどのAPI利用料の話につながるのですが、パッケージソリューション自体も、またそれが接続する外部システムの接続費用や利用料も、既存の枠組みの中にあるためどうしても下げられないコスト=原価となってしまいます。API利用料の価格設定についてできるだけ柔軟さを担保したい、という想いから内製化にこだわっている、ということです。
またBaaSは、パートナー企業様が抱える課題をいかに銀行のサービスや機能を使って解決できるかが重要だと思うので、パートナー企業様と一緒にサービスを共創していくビジネスモデルだと思います。多種多様なニーズに対してクイックに対応していくためにも、みんなの銀行では内製化を進めるメリットは大きいと考えています。
例えばパートナー企業様のニーズに応じてシステム開発をしようとなったとき、仮にシステム開発を外部の業者に委託していたとしたら、まず見積もりを取り寄せ、収支計画を立て、予算を確保して、業者に発注をかけ、体制を確保して……とそれだけで2～3ヵ月かかってしまいますよね。これに対して内製できるエンジニアを自社に抱えていれば、意思決定から開発着手までが圧倒的に早くなります。
関係者が多岐にわたるBaaSではアジャイル開発が最適
——BaaSというビジネスモデルの性質上、システム開発の体制面も重要ということですね。
髙杉 はい。みんなの銀行でのBaaSの実現にあたっては開発手法にもこだわりがあり、基本的にアジャイル開発を採用する予定です。7～8人までの少人数でひとつのスクラムチームを作り、2週間スプリントでどんどんとアウトプットを出していくイメージです。
従来主流だったウォーターフォール型の開発だと、いざ開発が完了してアウトプットを見てみるとイメージしていたものと違う、ということが多々あります。一方でアジャイル開発は早めに、高い頻度でアウトプットを関係者に確認してもらいながら進めていくため、こういったズレが少なくなる開発手法です。特にBaaSは関係者が多岐にわたるため、こうしたズレを極力なくすためにアジャイル開発が最適だと考えています。
——実際にBaaS活用を検討中の企業様とやりとりするとき、企業様にとって新規事業という位置づけとなることが多いので、小さく早く始めたいというニーズに対しても内製化とアジャイル開発は一つのメリットとなりそうな気がしました。実際のシステムの構成としては、なにかBaaSビジネスを意識した作りになっているのでしょうか？
髙杉 BaaSのシステムについてはこれから開発していくという段階なのであくまで私の構想ですが、勘定系システムとは別の領域にBaaSのシステムを作りたいと考えています。
というのも勘定系システムは銀行のコアとなる機能なので一度リリースした後は比較的手入れの必要性は低く、逆にBaaSは様々な企業のニーズに応えていくので手入れの必要性が高い、という性質の違いがあるからです。BaaSのシステムは個別の企業様ともご相談しながらスクラップ＆ビルドを繰り返していくために、勘定系システムとは切り離し、柔軟に手入れができるシステムにする必要があると思っています。
ここまででお話した通り、勘定系システムというのは非常に堅牢なシステムなので、この領域と手をつなぐことを唯一許されたBaaSシステムを通して、外部のパートナー企業様にBaaSを利用いただくことを考えています。いわば勘定系システムとBaaSパートナーをつなぐ中継役のシステムですね。これをゴリゴリ作っていきたい思っています。
