本記事はBASEアドベントカレンダー2024の11日目の記事です。
はじめに
はじめましての人ははじめまして、こんにちは！BASE BANK Division（以下、BANKチーム）のフロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です。
今回は私が担当しているPAY.JP YELL BANKというサービスについてお話しします！
エンジニアとしてこのプロダクトを担当していて感じるおもしろいところがたくさんあるので、ぜひ一緒に開発しましょ！！というお誘い記事でもあります！！
全部読んでいただけるととっても嬉しいですが、熱がこもりすぎてとても長い記事になってしまいましたので、記事下部にある、まとめだけを読んでいただく形でもよいです！
よろしくお願いします！
この記事を読む上でのキーワード:
- エンベデッドファイナンス
- PoCフェーズ〜グロースフェーズ
- 分析 / フルサイクルエンジニア
- 機械学習
- FinTech
PAY.JP YELL BANKについて
まずはPAY.JP YELL BANKについて軽くご紹介させてください。
- サービスサイト: https://pay.jp/yellbank
- 2024年6月に正式公開された際のプレスリリース: https://prtimes.jp/main/html/rd/p/000000224.000030814.html
PAY.JP YELL BANK自体は「将来債権ファクタリング」という仕組みの金融サービスになります。もともとネットショップ作成サービスBASE（以下、BASE）向けに同様のサービスとして提供していた「YELL BANK」が元になっており、オンライン決済サービスPAY.JPを利用しているユーザー（以下、PAY.JP加盟店）に将来の売り上げを「ファクタリング」というスキームですぐに使えるお金に代えるサービスになります。
[補足]YELL BANKのサービスサイト: https://yellbank-lp.thebase.com/
BANKチーム、PAY.JP YELL BANKの今後について
BANKチームは元々、BASEのショップオーナーの金融課題を解決する機能を提供するチームとして立ち上がり、BASE向けYELL BANKを軸に、BASE Card、お急ぎ振り込み機能と、ショップオーナーの金融課題を解決するための機能を拡充する形で展開してきました。
これは今後も変わらずに進めていく予定で、実際に2024年も請求書カード払いの提供開始など引き続きBASEのショップオーナーの金融課題を解決するために新領域にも展開をしていきます。
そして、中長期目線では、YELL BANK機能の展開を皮切りにBANKチームで開発・運用している各機能の提供プラットフォームを拡大して、より広いユーザーに価値を提供できるようにしようとしています。
元々、BANKチームが開発・運用しているYELL BANKをはじめとした各機能は、エンベデッドファイナンス（組み込み型金融）と呼ばれるサービス形態のものです。
これは「金融以外のサービス提供企業（非金融企業）が、既存サービスに金融サービスを組み込んで金融サービスを提供する」という形のサービス提供方法に名前がついたもので、「ネットショップ作成サービスBASE（非金融サービス）と将来債権ファクタリングのYELL BANK」のような関係のことを言います。
詳しくはこちらの解説ページや、「エンベデッド・ファイナンスの衝撃―すべての企業は金融サービス企業になる」という書籍に譲ります。
これらの金融関連の各機能をBASE以外のプラットフォームに提供を始めることで、BANKチームが関わるプロダクト自体はよりエンベデッドファイナンスっぽい形になりはじめてきています。
その第1弾として、BASEグループのPAY株式会社が提供している「オンライン決済サービスPAY.JP」向けに提供を始めた「PAY.JP YELL BANK」はBANKチームで2018年から開発・運用してきた「YELL BANK」のBASE以外のプラットフォームへの展開というところで、上述の付加価値拡大の方針の試金石にもなるプロダクトになっています。
PAY.JP YELL BANKの技術構成について
PoC期間から現在までは、以下ような形の技術構成になっています。
バックエンドはGoで書かれたPAY.JP加盟店ごとの債権管理などのシステム全体の処理の責務を担うAPIと、Pythonで書かれた機械学習を使ったPAY.JP加盟店ごとの売上予測を提供する責務を担うAPIの2つをAWS ECS Fargate上に置き、フロントエンドはNext.jsをAWS Amplifyで動かしてページをiframeでPAY.JPの画面に埋め込むようにしています。
これは、YELL BANKのシステムアーキテクチャを参考に実装しており、再利用できる部分を再利用してアジリティ高くPAY.JP YELL BANKの機能提供を開始できるように実装してきました。
また、フロントエンドはPoC段階の機能の提供速度を早めるためにBANKチーム管轄でNext.jsアプリケーションを作成し、それをPAY.JPの管理画面に埋め込んでもらう形をとりました。
技術構成のこれから
その後、PoC期間が終わり、6月に正式提供が開始されてから約5ヶ月が経った今は、スピード重視で作ってきた技術構成を中長期的に運用がしやすく、さらにグロースするために必要な機能を追加しやすいように一部変えようとしているところです。
フロントエンドはiframeで画面丸ごと埋め込む形をやめ、PAY.JPの管理画面に直接機能を実装して、Next.jsのフロントエンド・BFFからではなくPAY.JPのバックエンドからGoのAPIを利用する形に変えていこうとし始めています。
これは、PAY.JP加盟店ユーザーの動線上に適切に表示し、よりシームレスな資金調達体験を作ることと、その先の調達した資金を使った加盟店成長に繋げてもらうためのアップデートです。
ただ、PAY.JPはクレジットカード番号を直接取り扱うプロダクトであるため、開発するメンバーはPCI DSS準拠のリリースフロー・開発ルールに則って実装を進める必要がありました。
そのためのBANKチームメンバーのPCI DSSを理解度を上げるトレーニングや事前準備を進めたりしてきたので、満を持してPAY.JPへの直接実装をしていくぞ！というタイミングが今だったりします。
他にも、グロースさせていくフェーズに入ったため、新たに必要になった機能を開発する上での各バックエンドAPI改修、分析基盤との連動のためのバッチの追加などを今後も進めていく予定です。
PAY.JP YELL BANKの開発のおもしろいところ
さて、そんなPAY.JP YELL BANKを開発する上での特徴であり、個人的に担当していてとてもおもしろいと感じていることを皆さまにも少し知ってもらえればと思います。
大きく分けて、3つあります
- BASE / YELL BANKのリソースを活用した開発スピードの速さ・手数の多さ
- エンベデッドファイナンスという少し特殊なプロダクトであること
- 金融のドメイン知識と機械学習・銀行APIなどのテクノロジーを組み合わせて課題解決していること
BASE / YELL BANKのリソースを活用した開発スピードの速さ・手数の多さ
「リソースを活用」と書くと、いささかタダ乗りしているようなニュアンスを含んでしまいますが、どちらかというと伴走してくれるチームやプロダクトがとても近いところにいて、一緒に開発できている状態で、それがとても価値があるものだと思っています。
より具体的には、先人の知見をベースに再設計したり検討した上でPAY.JP YELL BANKに取り込んだり、新しい機能を作る際には調査を共に進めて分担したり、そういった知の高速道路に乗りながらBANKチーム・BASEグループ全体で向かうべき未来を目指して開発をしている点です。
また、後述のエンベデッドファイナンスというプロダクトである特徴の話にも重なりますが、BASE・PAY.JPという既存プラットフォームがあり、そこに異なる角度からの新しい機能を追加するという経験はプロダクトを完全にゼロから模索するよりも、ある程度ターゲットが絞れている分、高速に開発を始めることができます。
さらに、既存プラットフォームで得た資金を投資することで、よりダイナミックに機能を作ることが出来るところも魅力です。
他にも、普段の開発を組織規模やフェーズが先に進んでいるプロダクトと深く関わり、同じ会社内で同じ方向を向いて働くのはとても楽しいです。
BANKチームの紹介資料にも記載がありますが、フルサイクルエンジニアを目指すエンジニアチーム風土であるため、エンジニアはアプリケーションはもちろん、インフラや分析基盤、企画にも携わっていくことが多々あります。
GoやPythonの話をBANKチームのメンバーに聞いたり、AWSの知識が深いBASE内の別のチームに聞いたり、フロントエンドの話を聞かれて答えたりと、それぞれ持っている役割や得意な領域を互いに組み合わせてプロダクト作りを進められているのはエンジニア組織としておもしろいところだなと常日頃から感じています。
エンベデッドファイナンスという少し特殊なプロダクトであること
エンベデッドファイナンスの特徴として、BtoBtoC（BASE BANK to BASE to BASEユーザー）という流れでサービスを提供する形になるので、BASE BANK目線だと提供先によってユーザーのタイプがかなり変わるという特徴があります。
PAY.JP YELL BANKの初期提供時は、BASE向けに提供しているYELL BANKの知識をベースに作り始めていたのですが、年始あたりからはPAY.JPの加盟店の特性をLookerなどを使って分析し、より適したサービス提供方法を模索しています。
エンジニア目線では、エンべデットファイナンスというサービス形態は「（外部展開も見据えて、）社外の人が使うAPIとしてどう設計するべきか？技術構成はどうするべきか？」を一緒に考える必要があります。
これは他のサービス形態だとなかなか深く考えることがないポイントで、自分の技術力や設計力を伸ばす上で必要な観点であるし、それを磨くことでサービスとしての価値が高まることに繋がるのでとてもやりがいがある開発になります。
PAY.JP YELL BANKにおいては、これまではNext.js製のアプリケーションがBANKチームが提供するAPIのクッションと画面実装を担っていましたが、今後はPAY.JPのバックエンド向けAPIを直接提供する形に差し替えていくので、よりAPIスキーマを重視する方向で動き始めています。
金融のドメインに機械学習・銀行APIなどのテクノロジーを組み合わせて課題解決していること
PAY.JP YELL BANKでは「PAY.JP加盟店の将来の売上予測」がサービスのコアにあり、その機能を実現するために機械学習を使っています。
このPAY.JP YELL BANKにおける売上予測の開発には
① PAY.JP加盟店の売上をより精緻に予測し、適切な額を資金提供して回収まで滞りなく実現することで、BASE BANKとしての事業継続性を高めるための「守りの売上予測精度向上」
② リスクコントロールが可能な範囲で資金提供可能な金額を上げるためにどのようなデータを追加で提供してもらって機械学習モデルに取り込むべきか考えて、より多くのPAY.JP加盟店に使ってもらえるようにするための「攻めの売上予測精度向上」
の2種類があり、今後もこの辺りは改善を進めていこうと考えていたりもします。
その他にも、お金に関わるプロダクトであるため、高い責任感が求められる面とそれをテクノロジーを使って解決できることがPAY.JP YELL BANK開発、ひいてはBANKチームで開発を行うことのおもしろさであると思っています。
一例としては、銀行APIなどを使った振込入金におけるユーザー体験の改善などが挙げられます。
また、実際に資金提供を行うことが加盟店の運営・成長につながる一手になりうることもBANKチームで積極的に行なっているユーザーインタビューから様々なユーザーの声を聞いて知ることができ、自分たちのやりがいにつながってもいます。
まとめ
ここまで長々と自分が担当しているPAY.JP YELL BANKというプロダクトのおもしろいところ、所属しているチームのいいところをたくさん語らせていただきましたが、ザッとまとめると以下の通りです！
【プロダクト内容・フェーズ的なおもしろいところ】
- これからグロースしていくフェーズなので、新機能や技術構成のアップデートなどダイナミックさがあるところ
- エンベデッドファイナンスは直接金融サービスを提供するよりはBtoBtoCという形で複雑だが、既存のユーザーの課題により適した形でサービス価値を提供することができるところ
【組織的なおもしろいところ】
- BASE / PAY.JPと伴走してプロダクトのグロースや開発を進めていくところ
- フルサイクルエンジニアを目指す風土なので企画、開発、運用や分析も含めて全てのステップに深く関わるところ
【技術的なおもしろいところ】
- プロダクトのコア体験につながる売上予測に機械学習を使っているので、データの集め方やデータ連携の契約の組み方を考える余地がまだまだあるところ
- 金融（特に資金調達と決済）のドメイン知識を深めることができること
- 外部向けAPIとしての設計、そのためのワークフロー構築ができる・必要なこと
私自身は、この環境で開発を行なっていくことで自分の技術力やエンジニアとしての成長に繋げられるなと感じているので、今後もPAY.JP YELL BANKの開発に深く携わって、どんどんとサービスの価値を高めていけるように開発をしていく予定です！🙋
おわりに
ここまでPAY.JP YELL BANK、BANKチームについての紹介をお読みいただきありがとうございました！
BASE BANKチーム（求人媒体での記載はYELL BANK）ではエンジニアを大募集中ですので、少しでも気になるな👀 と思っていただけたのであれば、ぜひぜひカジュアル面談やX（ @gatchan0807 ）などでお声がけいただけると嬉しいです！
明日は kitamuran さんと pigooosuke さんの記事2本立てです！お楽しみに〜！
