SmartBank, Inc. を創業し B/43 というサービスをはじめました
前置き
こちらのエントリーを書いてから約3年が経ちましたが、また新しいチャレンジを始めています。
少し自己紹介すると、元々フリマアプリ（フリル → 現ラクマ）を作る Fablic社を共同創業（CTO）し、同社は後に楽天へM&A、退任してからはプロダクト開発やコードを書く仕事から少し遠ざかっていたのもあり、ANGEL PORT という起業家とエンジェル投資家のマッチングサービスを作っていました。
ローンチ後は、下記のエントリーにもあるように次のフリマアプリを超えうる起業テーマ、ユーザー課題を探してロンドンやドイツなど Fintech 先進国へユーザーインタビューなどにも行っていました。
初めて起業し、フリマアプリを作った時は確か25歳でした。そこから10年後、また同じメンバーで今度はスマートバンクという社名で起業し、お金の管理に対する課題に向けてプロダクトを作っています。
smartbank.co.jp ドメインが空いていたので、取得できたのはラッキーでしたね。
改めて振り返ると自分はものづくりが好きで、作ったプロダクトから得られるフィードバックを生きる糧にしている所もあり、今回もチャレンジしがいのあるテーマを選べたなと思っています。
このエントリーでは 0 → 1 のプロダクト開発、まだアイディアの状態からどのようにして 最初のリリースを迎えていったかを技術的な視点も交えて綴っていこうと思います。
B/43 というプロダクトについて
B/43は「家計簿アプリ」と「Visaプリペイドカード」がセットになった「家計簿プリカ」という新しいサービスです。毎月の予算をカードにチャージして日々の支払いをすることで、自動で記録され、見える化されるので、支出管理を簡単に継続することができます。
なぜこのプロダクトを作ろうと思ったかは @shota の記事に、どんなプロダクトなのかは @takejune の記事にもっと詳しく書かれていますので良かったらそっちも見てもらえると嬉しいです。簡潔にいうとフリマアプリを運営する中で感じた多くの人が支出を正しく把握できていないという課題をこのプロダクトで解決したいと思っています。
初期の開発について
フリマプリの企画からリリースまでは半年でしたが、B/43 は約2年リリースにかかっています。 お金を預かってカードを発行し決済させる、お金は自由に出金もできるという銀行と同等の機能が必要で、プロダクトを成立させるまでのミニマム要件が下記のような感じでした。
- 会員 / 認証基盤
- eKYC
- AML / ASF（マネーロンダリングや反社チェックの仕組み）
- 物理カード発行 / 管理基盤
- Visa 決済システム
- 入出金システム
- 勘定系、残高管理システム
- Push 通知配信基盤
- 上述の機能を横断的に取り扱う管理画面
書き出してみると、一つの機能が大きく、それなりに大変そうですね 😌（実際大変でした）
海外では Marqeta や Stripe といった Banking as a Service（BaaS）事業者が上記の機能を部分的にサービスとして提供しており、彼らのサービスを使うことで、工数を圧縮できる余地がありますが、日本の現状だとBaaSプレイヤーは少なく、大部分は自社で開発する必要があるでしょう。
技術的なハードルについて
今回はただ作るという面以外に、実は下記の2つの要件をクリアする必要がありました。
- PCI DSS（クレジットカード業界の国際セキュリティ基準。カードを発行するために必要で、審査機関による認定を受ける必要有り）
- 資金移動業者登録（預かったお金を現金として出金できるようにするために必要）
どちらも、高いセキュリティ基準、及びそれを執行する体制、膨大な量の書類の提出が必要で、資金移動業者として登録完了までにちょうど1年程度かかりました。
振り返って考察すると、フリマアプリはプロダクトとして最低限成立させるための要素はそれほど多くなく、サービス自体をローンチさせるのはそれほど難しくなかったでしょう。事実我々がサービスインした1年後には、レッドオーシャン化し大手IT企業、メルカリのようなベンチャー企業が続々と参入してきました。（ビジネスとして勝ち切るのはまた別の話ですが）
しかし、今回のサービスは開発難易度、クリアするべき規制や法令、開発・運用にかかる莫大なコスト等々、非常にハードルが高いので、プロダクトを作れること自体がある程度の参入障壁になっているとも言えます。ベリーチャレンジングですね。ここから少し技術的な取り組みを振り返っていきましょう。
1. 技術的な取り組み - eKYC -
ユーザーが物理カードを発行する前に eKYC（本人確認手続き）を行っていますが、システム自体は内製しています。実は開発前に外部のベンダーを使うことも考えて、何社かお話を伺ったのですが、ユーザー体験を担保しつつアプリに組み込める良いサービスが無く、色々検討した末に自前で作ることに決めました。
正直、既存のサービスを組み込めば、早く簡単に導入はできるでしょう。ただ、弊社では大切なユーザー体験の一部を妥協して作るということはまずありません。よーし、自分たちで作るかー、とすんなり決まって、数日後にはアプリエンジニアがこんなかんじでどうです？とプロトタイプをあげてくれました。
eKYC はプロセスの大変さもあって高い確率でユーザーが離脱してしまうので、アプリエンジニアが注力したポイントの1つです。外部サービスに飛んだりせず、あくまでもアプリ内だけでスムーズに終えられることを念頭に作り込んでいます。
特に顔認識（ライブネスチェック、事前に予め用意した画像ではないか）するための首振りやウィンクなど動作検出部分は中々苦労しました。
開発はユーザーに試しに触ってもらいながら、この場合は検出できないなーなど、試行錯誤しながら進めていき、離脱ポイントになりやすい点を観察しながら仕上げていきました。 自分たちは昔からユーザーインタビューをたくさんやる会社で今回も150人ぐらいにはしています。こうやって手触り感を持ってプロダクトを作り込んでいくスタイルは今後もブレずにやってきたいなと思います。
2. 技術的な取り組み - PCI DSS -
PCI DSS の取得まではQSA（PCI DSSの審査機関）の選定を含めて実質半年ほどかかり、初めてだったことと、予算を節約したかったのもあり、準拠対応はそれなりに大変でした。
やってみて分かったのですが、PCI DSS はいかに準拠対象のシステムスコープをミニマムにし、範囲を狭められるかによって作業量が全然変わってきます。 社内体制によっては外部のコンサル等に監修をお願いすることもあるかと思いますが、それだとコストが掛かってしまうので、ここまでは自分達でやるといった線引きも大事です。
- PCI DSS 準拠 / 非準拠環境の境界を見極めてシステムの分離を行い、準拠スコープを局所化する
- ペネトレーションテストはツールを自社で導入、実施し外部委託コストを減らす
- ツールで対応できないテストだけを外部業者にお願いする
- 準拠資料はQSAや外部業者から雛形を調達し、必要箇所だけカスタムして記述量を減らす
上記は学んだことの一部ですが、PCI DSS は取得して終わりではなく定期的に監査があり、あと半年後には PCI DSS ver4.0 もリリースされていると思うので、次回に学びを生かしていきたいですね。
インフラ的に面白いのはコンテナをフル活用して、PCI を取得した所にあります、現行の PCI DSS ver3.2.1 が現在のクラウド技術を前提にしていない部分もあるので、QSAと相談しつつ進めたのですが、AWS Fargate を使うので、そもそも ssh させない前提でクリアにした要件もあります。
また、PCI DSS 非準拠環境（通常のアプリが使うAPI群）とインフラの管理や運用フローは統一させたかったので、AWS は使うもののアカウントは分ける、Terraform、Github Actions を使って管理やデプロイフローは統一させるなどの工夫も行っています。
3. 技術的な取り組み - Visa Network 決済 -
一番苦労した部分はどこかと聞かれたら、やはり決済システムの構築でしょう。実際のシステム稼働まで1年は掛かっていると思います。 弊社は モバイルアプリを提供するスタートアップという側面の他に、今回はカード発行会社（イシュア）という面もあります。
大きく2つの処理があり、1つはオーソリといわれている、ユーザーが加盟店でカードを使った際に決済が可能かどうか確認する処理です。 加盟店 → アクワイアラ → 国際ブランド（Visa）のネットワーク → イシュアのシステムと電文が届きます。決済システムは電文をパースしユーザーの残高と照会、購入可能かどうかを返答します。
もう一つは、クリアリングと呼ばれている売上の確定処理です。オーソリで確認した決済は、数日後に加盟店側で確定され、そのデータがイシュアへやってきます。イシュアはデータを確認し、問題なければユーザー残高を確定させます。
文字にすると簡単そうですが、VisaNet へ接続するのがそもそも難しく、また電文のパターンは多岐に渡り、Visa の膨大な資料を読みつつ仕様把握、決済処理を構築していく必要がありました。
開発していて面白かったのは、決済電文で送られてくる加盟店の情報ってかなりカオスなんですよね。 みなさんもカードの明細を見て思ったことがあるかもしれませんが、加盟店の表記がマチマチだったり（大文字、小文字、英語）支店名があったりなかったり、モールの中の特定のショップで買ったのに明細の加盟店名はモール名になってたり。
ですので、我々は家計管理において、電文の情報をただ表示するというのは、あまり良くない体験だと思っています。電文情報もきちんと蓄積、解析し、最終的には統一された見やすいフォーマットでどの店舗で決済したのかまで表示できるように取り組んで行こうと思っています。
タイムラインはスクロールに合わせてトップのグラフも連動して動きます。日や月が変わった際にも、キチンとグラフが追従し、見た目にも分かりやすく支出を把握できるようにしている所がこだわりポイントです。
今は決済されてくる電文を観察しながら、中にはプリペイドカードに適さない決済や、拒否した方がいい加盟店などもあるので、ロジックのチューニングを行っています。イシュアとして事業をやっていないと手に入らない生の決済情報を集めながらシステムをアップデートしていくのはエンジニアリング的にかなり面白いですね。
例えば、セブンイレブンとローソンはどの店舗で決済しても加盟店名は同じですが、ファミリーマートは支店名が末尾につきます。なので決済店舗を特定することが可能で、将来的には決済した場所をアプリで地図表示できるんじゃない？みたいなのを日々ウォッチしては実装しています。 サブスク系サービスの電文も個々に特徴があり、電文を眺めては将来的に Netflix や Hulu などのサービスの課金をアプリで管理できないかなーと妄想しています。
最後に
少々長くなりました。いくつかの技術的なハードルを超えて、やっとプロダクトをリリースし、今は日々数字やユーザーの反応を見ながら改善を加えていっています。
プロダクトを作ってみて、改めて簡単ではなく、ユーザーの課題を解決しつつビジネスとして成立させることの難しさも感じています。
いくつかトピックを上げたように、モバイルアプリ / インフラ / サーバサイド、どのレイヤーを切り取っても開発が難しいコンポーネントがあり技術的なチャレンジは今後も続いていくでしょう。
大変なテーマを選んだなという実感もありますが、なんだかんだいって自分はこの 0 からプロダクトを生み出していく瞬間が最高に好きです。技術力を注ぎ込んで作ったプロダクトが課題を解決するシーンを見るのが最高に楽しく、そこにエンジニアを目指した原点があると思っています。
また、チームも最高にいい状態です、スピード感があり、阿吽の呼吸で開発が進んでおり、もう数ヶ月すればまた目玉となる機能をリリースできそうです。
つらつらと書いてきましたが、入金方法拡充や送金など基本的な主機能の追加の他に、電文情報の蓄積 / マイニング、カードの非接触決済の対応やデジタルマネーの給与受取など、まだまだ対応しないといけないことがあります。Android 版もまだない...!
例によって一緒に開発してくれるメンバーを大募集中です。 このエントリーや他のエントリーを見て、ちょっとでもプロダクトに興味が湧いた人は是非カジュアルにお話させてください。とりあえず、緩く話を聞いてみたいといったレベルでも全然OKです！いつでもご連絡お待ちしております！
長文お読みいただきありがとうございました。 それでは！
