金融サービスの世界では、もはやデジタルテクノロジー活用の巧拙がビジネスの成長度合いに直結するようになっている。スピード重視でサービスを拡充してきたauじぶん銀行は、副作用としてシステムの肥大化・複雑化という課題に直面していた。課題の解決策としてAPIによるシステム疎結合化を検討し、Salesforce（セールスフォース）のAPIプラットフォーム「MuleSoft Anypoint Platform」を導入。内製の体制も整備し、タイムリーに顧客にサービス提供可能で、かつ持続可能なアーキテクチャーと組織づくりに挑戦している。
肥大化・複雑化するシステムが迅速なサービス提供の足かせに
auじぶん銀行はKDDIと三菱UFJ銀行の共同出資で設立され、2008年に開業したインターネット専業銀行だ。「ネット銀行としては後発に近い開業時期だったこともあり、先行する同業他社に追い付け追い越せという意識で、積極的にサービスの拡充を続けてきました」とIT開発部IT戦略部副部長の綿引健太氏は説明する。
そうした背景から、新しいサービスを立ち上げる際は、既に似たような機能が実装されていたとしても新規にシステムを構築するという選択肢を採った。スピード感を重視して、既存のシステム資産への影響を極力考慮せずに済むようにしたからだ。しかし当然ながら、システムは乱立し、肥大化・複雑化することになる。
「どんどん増えていったシステムが、銀行の基幹系システムである勘定系システムとポイント・ツー・ポイントで接続される状態になっていました。お客様向けのスマホアプリで口座残高や取引明細を確認する際に勘定系と中継するという同じような機能を持つシステムが5本くらいあったんです。そのため、例えば勘定系システムに変更が必要になると、影響範囲を特定して改修やテストを行うための時間やコストも膨れ上がってしまいました」（綿引氏）
結果として、従来の情報システムの構造が、同社の生命線である「顧客へのスピーディーなサービス提供」を阻害する要因になってしまっていた。そこで同社は、システム間をAPIで連携させて疎結合にすることでこの課題を解決しようとした。綿引氏は「銀行が担う役割は、口座のお金を動かすという決済機能が中心です。極端に言えば、APIでそれが指示できるようになっていれば、勘定系に手を入れずに新しいサービスを作れるようになります。こうした仕組みを充実させることが、当行がお客様にタイムリーなサービスを提供していく肝になると考えました」と話す。
まずは21年に勘定系システムの刷新に合わせてシステム間連携のAPI化にチャレンジしたが、このタイミングでは「連携しているシステム全てのインターフェースを改修するには範囲が広すぎ、スピードやコストの観点から断念した」（綿引氏）経緯があった。それでもシステム間連携の課題は経営課題として取り上げられるほど深刻化していた。近年、APIの設計・開発、公開、管理などを網羅的に支援するプラットフォーム製品・サービスの市場が成熟してきたこともあり、APIによるシステム間連携への転換に再度チャレンジしたという。
将来的な内製化を前提にAPIプラットフォームを選定
auじぶん銀行は「APIを活用してシステムを疎結合にしていきたい」という前提でRFI、RFPを出し、付き合いのあったSIer数社から提案を募った。複数の有力なAPIプラットフォーム製品の中から最終的に採用したのは、MuleSoft Anypoint Platformだった。
コストは選定候補となった製品間で大きな差がなく、機能面での評価が選定にダイレクトに影響した。APIの設計・開発から管理、再利用などの一元的なプラットフォームとして活用できる点を評価したのはもちろんだが、採用の決め手になった大きなポイントは二つ。まずは金融機関ならではの要件に対応できるかを重視した。綿引氏は「金融システムならではの管理体制というのがあります。具体的にはインシデント管理やアラートの管理といったところですが、ここにまずきちんと適合できるかが重要でした。Anypoint Platformは既存の監視システムにどのように組み込めるかが提案をいただいた際に明確にイメージできました」と説明する。
二つめのポイントは内製での運用のしやすさだ。auじぶん銀行はAPIの開発・活用や再利用などの仕組みを、自社のビジネスを支えるシステムという観点で「勘定系の次に肝になる」（綿引氏）と見ていた。過去に開発したAPIを再利用すればすぐにでも新しいサービスを立ち上げられるというケースがあっても、その作業を外注していてはスムーズにプロジェクトを進められない可能性もある。請け負う側のSIerが繁忙期であれば、人的リソースを十分に確保できないこともあり得る。サービスをタイムリーに提供できる体制を整えるためにも、「製品選定の時点で最終的には行内の人員を増やして内製化で頑張ろうという方針は明確にしていました」と綿引氏は話す。
内製を前提に考えたときに、Anypoint Platformは専用の統合開発環境ツールが提供されており、GUIベースでAPIのフローを作成できることが魅力だったという。「（検討の俎上に載せた）他のAPIプラットフォーム製品は、Javaのコードをガリガリ書かなきゃいけないようなつくりになっているものもありました。現在のチームメンバーが対応できたとしても、将来的に人員が増えたときにハードルが高くなってしまうのは避けたかった。内製をやるなら、システム開発に通じた人材でなくても使いこなせるツールであるべきだと考えました」（綿引氏）
汎用的な「部品」としてAPIを再利用できるメリットは大きい
2022年の年末にAnypoint Platformの採用を決定し、約半年で基盤構築を完了。23年7月に利用を開始した。最初に実装したのは、家計簿アプリを手がける電子決済代行業者に認証・認可などの機能を提供するAPIで、23年8月には旧環境からの切り替えを完了した。綿引氏は「Anypoint Platform自体の開発に対するハードルは低く、課題もあまりなかったです」とした一方で、特に高いセキュリティレベルを要求される金融業界向けのAPI仕様「FAPI」に対応する必要があり、「社内でFAPIに精通している人間は非常に少数で、ベーシックなところから理解を深めなければならなかったのが、一番苦労したところです」と振り返る。
現状、Anypoint Platform上で管理しているAPIの数はまだそれほど多くはないが、サービス開発時の汎用的かつ安定的した稼働が見込める「部品」として再利用できるメリットを高く評価しているという。「ローン関連の新商品を管理するスタンドアローンのシステムと勘定系をつなぐAPIを新規に開発したのですが、これは先ほど申し上げたような口座のお金を指示通りに動かすというもので、非常に汎用性が高い機能です。既にさまざまな場面で再利用しています」（綿引氏）
また、新規のサービス開発に対する社員の心理的なハードルも下がったという。従来は事業部側で新しいサービスを構想しても、勘定系に手を加えなければならないとなると及び腰になりがちだった。しかし、「Anypoint Platform導入後はAPIでうまくラップしているという話を丁寧に説明していますので、今までは二の足を踏んでいたようなアイディアも前に進めようという気運は高まっていると感じます」と綿引氏は強調する。
内製の体制も整いつつある。基盤構築ではAnypoint PlatformのSIパートナーの支援を受けたが、最終的に内製化を目指すというauじぶん銀行の意向を当初から共有しており、23年7月の利用開始以降、Anypoint PlatformでのAPI開発のノウハウなどの引継ぎも進めた。「完全内製でAPIを作る案件も出てきて、まさに独り立ちし始めたところ」だという。
一方で、導入してみて明らかになった課題もある。「トランザクション量のコントロールは難しいですね」と綿引氏。APIを開発する際に、想定していた取引量と実際のAPI呼び出し回数が乖離するケースがあり、十分なパフォーマンスを出すためのチューニングには苦労しているという。「Anypoint Platformのサイジングにも癖があり、CPUとメモリが紐づいているため、どちらかに合わせると他方に余剰が出たり不足したりする傾向があります。セールスフォース経由で他のAnypoint Platformユーザー企業と情報交換する機会もあったのですが、多くの企業が同様の課題意識を持っているようで、改善されるとありがたいですね」（綿引氏）
今後はシステム間連携の仕組みを段階的にAnypoint Platformに移行し、勘定系システムとの連携基盤は同製品に統一する方針だ。「システムの数も減りますし、接続の仕方もシンプルになり、ガバナンスも向上します。サービス基盤のメンテナンス性は大幅に向上します」と綿引氏は展望を語る。
また、新サービスの開発だけでなく、行内業務の効率化や自動化にもAnypoint Platformを活用していくという。「過去のRPAの導入では、エラーが頻発して結局は人が監視しなければならなくなった業務もあります。『MuleSoft Automation』のようにAPIを使いながら業務プロセスを自動化できる製品も出てきていますので、コールセンターのフロントからバックオフィスへの連携を自動化してオペレーションを効率化するなどの取り組みを進めています」（綿引氏）。人的リソースを「作業」から解放し、人間にしかできない仕事に充てたいとしている。