BaaSを使って開発した「セゾンポケット」
スマートプラスがクレディセゾンと協業し、BaaSを活用して開発したセゾンポケットはシンプルなモノリス構造で実現した金融サービスである。
セゾンポケットがリリースされたのは2019年11月。その特徴は投資信託や株式（1株単位から）の積み立て投資ができること。また積立の原資にはセゾンカード、UCカードだけではなく永久不滅ポイントも利用でき、カードで積み立てすると永久不滅ポイントも貯まっていく。「クレジットカードを用いた株式積立は日本初、クレジットカードを用いた投資信託の積立も日本に数えるほどしかない。クレジットカード発行会社であるクレディセゾンと、BaaSで初期コストを低く抑えられるFinatextが協業したからこそ実現できた、画期的なサービスです」と大木氏は付け加える。
セゾンポケットのメインサービスの積立はどんな仕組みで実現しているのか。
まずセゾンポケットのサーバからBaaSに対して、すべての積み立てリクエストを投げる。次にBaaSで「顧客のクレジットカード・ポイントの決済」「決済した金額を顧客の証券口座へ入金」「顧客の口座残高を利用し、株式・投資信託を発注」という処理を行う。そしてセゾンポケットのサーバで、積み立て結果を取り込むのである。
BaaSで行っている処理の流れは投資信託と株式で異なる。投資信託の場合はポイントの決済・クレジットカード決済が成功した時点で顧客から証券への受注金額が確定し、その後、証券から委託会社へ買付発注が行われる。一方株式の場合は、ポイントの決済をして、顧客勘定へ入金し、スマートプラスの自己勘定で市場へ買い付け発注をする。発注が終わるとユーザーのクレジットカードで残額を決済し、顧客勘定へ入金、スマートプラスの保有残（在庫）を顧客が買い付けするという流れになる。「顧客がクレジットカード決済に失敗した場合は、スマートプラスが在庫を抱えることになる」と大木氏は言う。
なぜこのような流れになるのか。「投資信託に関しては金額単位で買い付けできるのでクレカ決済後に発注することが可能だが、株式は買付金額が寄付（よりつき）後に初めて確定するので、金額が決まっていない寄付前にクレジットカードの決済をすることはできない」と大木氏は説明する。
買い付け発注前にクレジットカードで決済・入金し、余った分を口座残高に残すという方法が考えつくかもしれないが、「クレジットカードのショッピング枠の現金化に該当するのでできない」と大木氏。また買い付け発注の前に決済会社にカードの与信枠を確保し、後に実際の金額でカード決済を行うという方法も考えられるが、「指定されたカード決済システムの仕様上、与信枠は取り消せないため、さらに実際支払うであろう金額を上乗せした与信枠が必要になる」と大木氏は話す。
またバッチ処理の仕組みについても解説。「セゾンポケットではさまざまなバッチ処理が動いている」と大木氏。BaaSとセゾンポケットの連携部分では、セゾンポケットからBaaSへ積立申請を連携するバッチとBaaSからセゾンポケットへ積立結果を連携するバッチの2種類。BaaS単体では、BaaSの中で各マイクロサービスに積立申請を連携するバッチやクレジットカードや永久不滅ポイントを決済し、入金するバッチ、株式を発注するバッチ、投信を発注するバッチなどがある。セゾンポケット単体でもセゾンポケットでユーザーに積立結果を通知するバッチがある。「このほかにも集計バッチ、また先に紹介したバッチの中で複数のバッチに分かれていたりしている」（大木氏）
バッチ処理の設計でさまざまなことを意識しているが、その中で最も肝となるのが冪等（べきとう）性とトランザクション制御だ。冪等性とは、ある操作を複数回行っても、インプットが同じであれば結果は同じになるという概念である。バッチを冪等に作る理由として、どんなバッチにも必ず失敗する可能性があることと、問題を取り除いた後、再度手動でバッチを走らせることができることが挙げられる。
冪等性の実装方法は大きく「すべての処理をやり直す」「未処理のもののみ実行する」の2種類ある。前者は厳密な意味での冪等性が担保されるが、再実行時に時間がかかってしまう（条件分岐は少ない）。一方後者の場合は、再実行時に残りの件数を実行するだけなので時間はかからないが、ステータスでハンドリングする分、条件分岐は増えてしまうというデメリットがある。
セゾンポケットではこの2つの実装方法を両方採用した。例えばセゾンポケットからBaaSに対して積立リクエストを送るバッチと、セゾンポケットでBaaSから積立結果を取り込むバッチは全ての処理をやり直す方法を採用している。クレジットカードやポイントを支払うバッチや積立結果を、メールなどでユーザーに通知するバッチは未処理のもののみ実行するようにしている。「外部に作用を持ってしまうものは、未処理のもののみ実行する方法で実装せざるを得ない」と大木氏は説明する。
その場合に気をつけなければならないのが、トランザクション制御である。ここで言うトランザクションとはある意味を持った一連の処理の塊のことで、また、トランザクション制御とはトランザクション内でデータの整合性が保たれることと定義するが、「これが結構難しい」と大木氏は投資信託の決済バッチを例に説明した。特にサービスをまたぐ上で、制御できないさまざまなエラーが起こるからだ。
例えばネットワークエラーや相手方のハードウェアの故障などが起これば、永久不滅ポイント分の入金時、クレジットカード利用時、クレジットカード分の入金時、ステータス更新時などにエラーが発生することが想定される。
このようなエラーに対応するため、「トランザクション制御は障害が起こることを前提に設計している」と大木氏。処理単位ごとに細かくデータベースをアップデートすることはもちろん、データベースのやり取りを失敗する場合に備えて、外部接続のやり取りはすべてログに吐き出しているという。実際に障害が起きた場合は、システムがエラーを察知して自動でバッチを止め、待機させているオンコールのエンジニアに通知が飛ぶようにしているという。
最後に大木氏は「私たちと一緒に、次世代の金融システムをモダンな技術で開発してみませんか」と呼びかけ、セッションを締めた。
