こんにちは！サーバーサイドエンジニアの mitani です。
2023年に技術広報を始めたことで、少しずつB/43を知ってくださっている人が増えてきました。辰年の今年は、サービス名だけでなくB/43の機能やその実装の背景など、B/43を開発する楽しさや醍醐味をどんどん発信して、もっともっとB/43のエンジニアリングを好きになってもらえる人を増やしていこうと思います！
ということで、このブログではB/43のサーバーサイドエンジニアが最近開発していることを紹介しながら、Fintechサービスを開発する醍醐味と今後取り組んでいきたい伸びしろについてお伝えします！
できるだけ赤裸々に今の状況を “Be Open” していきたいと思うので最後までお読みください！
最近のB/43の開発事情
B/43はVisaプリペイドカードと家計簿アプリを組み合わせたサービスなので、決済システムと支出管理システムにざっくりと分けることができます。決済システムはVisaと接続して、オーソリゼーションやクリアリングといった決済リクエストを捌いてカード決済ができるようにするシステムです。一方、支出管理システムはアプリ向けに決済のタイムラインを表示したり、月間の支出まとめの計算、そのほか入金や出金を提供するシステムです。
B/43は21年にリリースしたサービスなのですが、その時点で基本的なカード決済 / 支出管理の機能は揃っていました。リリース後の22~23年は、次のような機能開発を行なってきました。
- 決済システム
- オーソリゼーション / クリアリングのBugFixや細かな改善
- 不正対策
- 新しいデザインのカード発行 & ICカードの発行
- 支出管理システム
決済システムのオーソリゼーション / クリアリング部分は22年後半にはほぼBugFixして安定稼働していました。そのため、最近はコアな部分を触ることはほとんどありませんが、不正対策だったり監視のために今でも多少触ることはあります。
ここ最近でメインで開発しているのは支出管理システム側の機能です。会社としては、お金を「使う」支出管理の機能に加えて、「貯める」や「増やす」といった方面への事業拡大を狙っていますが、22~23年は支出管理をよりやりやすくするための機能開発を行い、23年後半~24年以降はさらにその先を見据えた準備をしているところです。（詳しくはRecruiting Deckをご覧ください。）
サーバーサイド開発の醍醐味
最近の開発事情をお伝えしたところで、次はサーバーサイド開発の醍醐味をいくつかご紹介します。
複数の外部制約をクリアするシステム設計力を高められる
B/43は資金決済法で規制される第二種資金移動業者としてサービスを提供しており、法律によって行わなければならない業務が規定されています。また、プリペイドカードはVisaのネットワークを利用しているため、Visa側のルールにも則る必要もあります。例を挙げると履行保証金の供託、不正対策、eKYC、PCI-DSSへの準拠、決済金額の精算などです。
何かしら新しい機能を追加する時には、正しく法律とVisaのルールを理解して設計する必要があります。見落としがあった場合やユーザーに影響のある障害が起きた場合には金融庁への報告が必要になりますし、慎重に開発し運用する必要があります。
法律やVisa側のルールは変えられないものが多いため、こちらが合わせる形でシステムを設計しなければならない場面が多いです。外部環境からの制約とプロダクトとして実現したいことの折衷案を上手くシステムに落とし込む力が求められますし、そこが頭を悩ませて面白いところでもあります。
プロダクト開発の意思決定に大きく関与できる
今後プロダクトをどういう方面に事業拡大させていくかは経営陣がオーナーシップを持っていますが、方針を具体的にどのような機能に落とし込むかはプロジェクトチームが決めます。その話し合いは複数の職種が一緒になって行うので、全員が一体となって知恵を出し合っています。
特に、SmartBankは創業期からN1インタビューに力を入れています。新しく作る機能は必ずN1インタビューを行ってニーズを探っていますが、リリース後の機能がどのように使われているかもインタビューをしています。このN1インタビューの場にエンジニアが書記として同席し、ユーザーの生の声を聞きながら開発しています。また、数百の過去のインタビュー議事録には全員がアクセスできます。
そのため、機能を追加したり改善する際にエンジニアリング観点だけでなく、実際に聞いたユーザーの生の声を自分なりに咀嚼して意見出しができますし、複数の職種が一致団結してプロダクト開発を進めることができています。よりユーザーに近いところで開発をしたい人にとってやりがいの大きい環境だと思います。
急成長する環境でエンジニアに求められる力を高められる
これはB/43に限らず多くのスタートアップ企業がそうだと思いますが、毎年しっかりと成長しないと潰れてしまうため、成長に対してのプレッシャーが強い環境で仕事ができます。B/43では、今は細部を磨き込むフェーズではなく、できるだけ大きなボールを動かして成長を加速させるような機能開発が求められます。
より効果の高い施策を素早くリリースしたい一方で、法律やVisaなどの制約もあるため、どこまで厳密に正確に作る必要があるのか？スピードのために犠牲にしても良いポイントはどこか？と考える機会が多く、その意思決定力を養えるのもB/43を開発する醍醐味の一つです。
エンジニア間の役割分担がしっかりしている
B/43の開発を始めた2020年頃から、サーバーサイド / アプリ / SREにそれぞれ専任のエンジニアがいました。今でもそれぞれの専門分野のエンジニアを置いて開発をするスタイルを継続しています。創業間もないスタートアップではフルスタックエンジニアとして全てを見ている人もいらっしゃると思いますが、B/43ではそれぞれが専門性を持ってその分野でバリューを発揮する環境なので、サーバーサイドのエンジニアリングを深めたい人にとってマッチする環境だと思います。もちろん、開発する中でSREやアプリ側に染み出しながら開発することもあるので、別職種のエンジニアの専門性に近く触れながら開発できるのも好きな点の一つです。
カード決済の裏側が理解できる
B/43のプリペイドカードはVisaのネットワークに接続して決済システムを作っているため、世の中のクレジットカードやプリペイドカードがどのように動いているのかを知ることができます。Visaのネットワークは1958年から始まり200カ国以上の国や地域でサービスを提供しているネットワークです。そのため、例えば障害発生時のリカバリ方法などもしっかりと作り込まれており、大規模なシステムの設計手法での学びも多いです。
今ではほぼ決済システムは完成されているのでコアな部分を触ることは少ないですが、B/43の取引明細のテーブルをしっかり理解するには、決済システムのドメイン知識が求められることが多く、B/43の開発をしていると自然と決済の理解も深まっていきます。
レールから外れない開発スタイル
開発当初のCTOのこだわりポイントでもあり、今でも変わっていないのが “レールに乗ること” で、できるだけ世の中の一般的な技術やフレームワークに沿った形で開発を続けています。
例えばメインで開発してるRailsで言うと、
- MVC以外の余計なレイヤーを作らない
- Serviceクラスレイヤーは作らずPOROをうまく使う
- Railsの標準機能で実現可能な機能は代替のgemを利用しない
- paperclip / carrierwave / ridgepole / etc…
- Railsに不足している機能はコミュニティで実績があり枯れたgemを使う
- pagy / config / etc…
などがあります。
規模が大きくなってくると、標準的な機能では足りない部分が出てきて、痒い所に手が届くようなgemを入れたり、MVC以外のアーキテクチャを検討することも出てくるとは思いますが、今はできるだけ背丈に合った技術を選択するようにしています。また、リリースしてすぐの状態ではドメイン境界を明確に分けるにはリスクがあるため、意識的にモノリスにしています。
そうすることで、フレームワークのバージョンアップに追従しやすかったり、新しく入ったメンバーのオンボーディングをスムーズに行えたり、他の人が実装した機能のコードリーディングが容易だったりする点が良いなと思っています。
サーバーサイド開発の伸びしろ
いくつか開発の醍醐味をお伝えしましたが、B/43はまだリリースして3年未満の成長真っ只中のサービスです。今後、さらにエンジニアを増やし色々な機能を開発するために取り組んでいきたいと思っている “伸びしろ” についても紹介します。
チーム分割 & ドメイン分割
B/43のサーバーサイドエンジニアは現在10名で開発をしていますが、年々機能が追加されていく中で、特定のドメイン知識を全員で共有することが難しくなっています。今の段階ではどうしても開発した人がリリース後の運用を行うことが多く、別の新機能開発PJをやっている途中に運用タスクが発生すると工数確保や脳内の切り替えコストが難しくなっている状況です。
今後はうまくB/43のドメイン境界を区切ったり、会社全体のPJ体制をブラッシュアップしていきながらDevOpsを最適化していきたいなと思っています。エンジニアリング観点では、現在はモノリスで開発していますがモジュラーモノリスだったりマイクロサービスのようなアーキテクチャも検討していきたいと思っています。
ドキュメンテーション
B/43ではNotionを使ってドキュメント管理しています。チームによって仕様書をどの程度書くかに差はあるのですが、 “Be Open” という会社のバリューにもあるように、できるだけ議事録だったり決定事項をNotionに残すようにしています。
ただNotionは検索機能が弱く、なんでこういう機能にしたんだっけ？変更したいんだけど大丈夫かな？と調べたい時に欲しい情報にすぐにアクセスがしにくいです。先日、業務委託のhighwideさんにアーキテクチャ・デシジョン・レコード（ADRについてはこちら）の勉強会を開いてもらったこともあり、より活用しやすい形でドキュメントを管理していきたいなと思っています。
専門領域への拘りと進化
開発の醍醐味の部分で標準機能をできるだけ使っていると話しましたが、ユーザー規模が増えてエンジニア数も増えてくると、それでは足りないことも多く出てくると思います。一例を挙げると、隔週のパフォーマンスMTGでサービスの負荷状況を監視していますが、今では大規模なメール配信の時などにはリアルタイムで負荷状況を見たいようなニーズも出てきています。そうするとAWSのCloudWatchだけだとちょっと足りないなと思うようなケースもあり、別な可視化ツールが欲しくなったりします。サービスと組織の成長に合わせて、適切な技術を選択して使いこなしていけるようにしたいなと思っています。
他にメール配信用のツールでSendGridが欲しくなったりと、これまでrakeコマンドだけで頑張っていたものに限界が来たりしているので、Ops部分にもしっかり投資をしていきたいと思っています。
終わりに
少し長くなりましたが、B/43の開発現場がどんなものか知っていただきたいので、できるだけBe Openに今の内情を赤裸々にお伝えしました！このブログをきっかけにB/43の開発に興味を持ってもらえると嬉しいです。
もっと知りたいと思っていただければカジュアル面談などに申し込んでもらえるとお話しできるのでよろしくお願いします！（良ければ mitani のXのフォローもお願いします 🙏）
