SmartBank, Inc. を創業し B/43 というサービスをはじめました

前置き

こちらのエントリーを書いてから約3年が経ちましたが、また新しいチャレンジを始めています。

少し自己紹介すると、元々フリマアプリ(フリル → 現ラクマ)を作る Fablic社を共同創業(CTO)し、同社は後に楽天M&A、退任してからはプロダクト開発やコードを書く仕事から少し遠ざかっていたのもあり、ANGEL PORT という起業家とエンジェル投資家のマッチングサービスを作っていました。

jp.techcrunch.com

ローンチ後は、下記のエントリーにもあるように次のフリマアプリを超えうる起業テーマ、ユーザー課題を探してロンドンやドイツなど Fintech 先進国へユーザーインタビューなどにも行っていました。

note.com

初めて起業し、フリマアプリを作った時は確か25歳でした。そこから10年後、また同じメンバーで今度はスマートバンクという社名で起業し、お金の管理に対する課題に向けてプロダクトを作っています。

smartbank.co.jp ドメインが空いていたので、取得できたのはラッキーでしたね。

改めて振り返ると自分はものづくりが好きで、作ったプロダクトから得られるフィードバックを生きる糧にしている所もあり、今回もチャレンジしがいのあるテーマを選べたなと思っています。

このエントリーでは 0 → 1 のプロダクト開発、まだアイディアの状態からどのようにして 最初のリリースを迎えていったかを技術的な視点も交えて綴っていこうと思います。

B/43 というプロダクトについて

www.youtube.com

B/43は「家計簿アプリ」と「Visaプリペイドカード」がセットになった「家計簿プリカ」という新しいサービスです。毎月の予算をカードにチャージして日々の支払いをすることで、自動で記録され、見える化されるので、支出管理を簡単に継続することができます。

なぜこのプロダクトを作ろうと思ったかは @shota の記事に、どんなプロダクトなのかは @takejune の記事にもっと詳しく書かれていますので良かったらそっちも見てもらえると嬉しいです。簡潔にいうとフリマアプリを運営する中で感じた多くの人が支出を正しく把握できていないという課題をこのプロダクトで解決したいと思っています。

note.com

takejune.com

初期の開発について

フリマプリの企画からリリースまでは半年でしたが、B/43 は約2年リリースにかかっています。 お金を預かってカードを発行し決済させる、お金は自由に出金もできるという銀行と同等の機能が必要で、プロダクトを成立させるまでのミニマム要件が下記のような感じでした。

  • 会員 / 認証基盤
  • eKYC
  • AML / ASF(マネーロンダリングや反社チェックの仕組み)
  • 物理カード発行 / 管理基盤
  • Visa 決済システム
  • 入出金システム
  • 勘定系、残高管理システム
  • Push 通知配信基盤
  • 上述の機能を横断的に取り扱う管理画面

書き出してみると、一つの機能が大きく、それなりに大変そうですね 😌(実際大変でした)

海外では MarqetaStripe といった 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 もリリースされていると思うので、次回に学びを生かしていきたいですね。

f:id:yutadayo:20210420212958j:plain
ドキュメント一式は Github で管理

インフラ的に面白いのはコンテナをフル活用して、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 の膨大な資料を読みつつ仕様把握、決済処理を構築していく必要がありました。

f:id:yutadayo:20190926182309j:plain
設計していた当時のホワイトボードメモ

開発していて面白かったのは、決済電文で送られてくる加盟店の情報ってかなりカオスなんですよね。 みなさんもカードの明細を見て思ったことがあるかもしれませんが、加盟店の表記がマチマチだったり(大文字、小文字、英語)支店名があったりなかったり、モールの中の特定のショップで買ったのに明細の加盟店名はモール名になってたり。

ですので、我々は家計管理において、電文の情報をただ表示するというのは、あまり良くない体験だと思っています。電文情報もきちんと蓄積、解析し、最終的には統一された見やすいフォーマットでどの店舗で決済したのかまで表示できるように取り組んで行こうと思っています。

ホームタイムライン

タイムラインはスクロールに合わせてトップのグラフも連動して動きます。日や月が変わった際にも、キチンとグラフが追従し、見た目にも分かりやすく支出を把握できるようにしている所がこだわりポイントです。

今は決済されてくる電文を観察しながら、中にはプリペイドカードに適さない決済や、拒否した方がいい加盟店などもあるので、ロジックのチューニングを行っています。イシュアとして事業をやっていないと手に入らない生の決済情報を集めながらシステムをアップデートしていくのはエンジニアリング的にかなり面白いですね。

f:id:yutadayo:20210421033528p:plain
加盟店毎の電文サンプルまとめ

例えば、セブンイレブンとローソンはどの店舗で決済しても加盟店名は同じですが、ファミリーマートは支店名が末尾につきます。なので決済店舗を特定することが可能で、将来的には決済した場所をアプリで地図表示できるんじゃない?みたいなのを日々ウォッチしては実装しています。 サブスク系サービスの電文も個々に特徴があり、電文を眺めては将来的に Netflix や Hulu などのサービスの課金をアプリで管理できないかなーと妄想しています。

最後に

少々長くなりました。いくつかの技術的なハードルを超えて、やっとプロダクトをリリースし、今は日々数字やユーザーの反応を見ながら改善を加えていっています。

プロダクトを作ってみて、改めて簡単ではなく、ユーザーの課題を解決しつつビジネスとして成立させることの難しさも感じています。

いくつかトピックを上げたように、モバイルアプリ / インフラ / サーバサイド、どのレイヤーを切り取っても開発が難しいコンポーネントがあり技術的なチャレンジは今後も続いていくでしょう。

大変なテーマを選んだなという実感もありますが、なんだかんだいって自分はこの 0 からプロダクトを生み出していく瞬間が最高に好きです。技術力を注ぎ込んで作ったプロダクトが課題を解決するシーンを見るのが最高に楽しく、そこにエンジニアを目指した原点があると思っています。

また、チームも最高にいい状態です、スピード感があり、阿吽の呼吸で開発が進んでおり、もう数ヶ月すればまた目玉となる機能をリリースできそうです。

つらつらと書いてきましたが、入金方法拡充や送金など基本的な主機能の追加の他に、電文情報の蓄積 / マイニング、カードの非接触決済の対応やデジタルマネーの給与受取など、まだまだ対応しないといけないことがあります。Android 版もまだない...!

例によって一緒に開発してくれるメンバーを大募集中です。 このエントリーや他のエントリーを見て、ちょっとでもプロダクトに興味が湧いた人は是非カジュアルにお話させてください。とりあえず、緩く話を聞いてみたいといったレベルでも全然OKです!いつでもご連絡お待ちしております!

www.smartbank.co.jp

smartbank.co.jp

f:id:yutadayo:20210423183154p:plain

長文お読みいただきありがとうございました。 それでは!

Fablic, inc のCTOを退任しました。

実は、2012年に創業した Fablic, inc を楽天社への合併のタイミング(6月30日)で退任しておりました。

25歳から約7年間、会社を創業し、フリマアプリを開発、フリマ戦争の真っ只中を過ごし楽天へExit、そして退任と人生の中でもっとも濃い日々を過ごしました。

いろんな方に支えていただきながらの7年間でしたが、折角なので、少し自分がやってきたことを振り返っていけたらと思います。

創業

まず、自分の仕事は考えていた課題の検証、そしてそれを解決するプロダクトを創ることでした。 フリマアプリをなぜ創ろうとしたかは弟の 僕がフリマアプリを創った理由 のエントリーがよくまとまっています。

創業1〜2年目はフリマアプリを開発し、軌道に乗せるまでの開発が主でした。

  • フリマアプリのプロトタイプの開発
  • RailsをバックエンドとしたAPIサーバ / 決済システムの開発
  • AWSを使ったインフラ基盤の構築

当時はCtoCのプロダクトに決済の仕組みをいれるのが難しく(サービスベンダーさんからNGが出る)リリースまでやきもきしたのを覚えています。

f:id:yutadayo:20120819011619j:plain

f:id:yutadayo:20120416141218j:plain ※ 創業時は共同創業者全員でガレージ付きの1家屋で一緒に暮らしていました。

この頃は開発しつつもアプリを使ってもらえるかの検証やプロモーションで大学のサークルを周ったりとエンジニアリング以外のことも忙しくしていました。

フリマアプリのPMFはとても早く、1年ぐらいは創業メンバーだけでやっていましたが、とても開発の手が足りなかったので、2年目からエンジニア採用も同時に行っていきました。

この時の教訓

  • PMFが最優先、人が欲しがるものを創れているかの検証を素早く繰り返すこと。
  • あれが足りない、これが足りないと機能追加するのでは無く、検証課題がクリアになる開発のみ優先的に行うこと。
  • サービスが当たるかは分からん、時に技術的負債を生みつつも前に進む。
    • iOSは当時はスピード優先でネイティブでは無く、Titaniumで開発をしていました。
    • 2年後に負債の返済を行いました。

フリマアプリ勃興期

フリマアプリは驚くほどのスピードで成長していき、メルカリのようなスタートアップからサイバーエージェント、Yahoo、LINEなど大手のIT企業が続々と市場に参入してきます。

当時はサービスをスケールすることが大きな課題で、主にデータベースへの高負荷が悩みの種でした。

ボトルネックであったタイムラインの仕様を変えて再実装したり、AWSVPC環境に移行させ、Amazon Aurora を導入したりなどインフラよりの仕事が多かったと記憶しています。

この間、iOSAndroidの大きなリニューアルを何度か行ったり、テレビCMに向けたインフラ強化、ボルネック箇所のチューニング、RIDE という車両に特化したフリマアプリの新規事業開発など、新しいサービスの立ち上げなどもやっていました。

この時の教訓

  • スタートアップの利点を活かして、開発スピードで絶対に大企業に負けないこと。
    • 最も怖いのは大手では無く、同じように死に物狂いでやってくる他のスタートアップである。
  • 目の前の小さいことでは無く、N倍スケールした時にどうなるかという視点で、開発も組織創りも行う。
    • この時は女性限定サービスから男性向けにサービス解放、テレビCMの放映などを実施
  • 採用(それもBigなHiring)や良い開発文化、組織のモメンタムを創り続けるのは創業者の仕事。それをやるためにもっと、権限委譲を早く適切に行うべきであった。

楽天へのExit

2016年に楽天グループ入りした後は、さらなるサービスの強化に向けて、 ログ基盤を整備したり、テレビCMの対策などが主でした。

この頃から、開発の仕事から徐々に離れて、全社採用や、評価制度の再設計、バックオフィス部門のマネジメントなど裏方の仕事が増えてきました。

開発はFablicには本当に優秀なメンバーが沢山いたので、安心して任せることができました。

後半は、新潟に新しくCSの拠点を立ち上げるため、新潟に出張し、オフィスビルの選定から、助成金の兼ね合いで県や市との折衝、オフィスインフラの整備など創業時は思いもしなかった仕事もすることになり、バリエーションも増えていきました。

そして、2018年に会社が楽天と合併し、新体制になったタイミングで、創業者としての役目を終わりにし、退任する決意をしました。 これからもラクマ(旧フリル)は楽天経済圏の力を活かしながら大きな資本力を背景に、もっと大きくなっていくでしょう。

この時の教訓

  • 社員旅行はとても良かった。余裕があれば、全社員でいくことをオススメする。
  • 子会社化した後も会社の文化を拠り所にして、採用を加速させることができた。
  • 本質的でユーザーにとってより良い開発を行おうとする文化、透明度が高く、率直なコミュニケーションが行われる社風を創れたのは非常によかった。
  • 楽天社は数字の達成意識が尋常じゃないほと高かった。開発組織が中心だと、売上などの数字感に弱くなりがちなので売上目標を達成するためのコミットは学ぶことが多かった。

総じて

たくさんのサービスが生まれては消えていく中、フリマアプリという沢山のユーザーに使ってもらえるサービスを創れたことは、1人のエンジニアとして嬉しくもあり、自信にもなりました。

フリマアプリ戦争という過渡期を過ごしたことは起業家として貴重な経験であり、 あのひり付くような、焼け焦げるような混沌と狂乱の中、サービスと会社を大きくするために情熱を傾けた日々を一生忘れないでしょう。

また、本当に自分達は良い仲間に恵まれたなと思います、プロダクトや会社について深く理解し、支えてくれた社員の皆には感謝してもしきれないです。

一方で、正直この7年で自分自身に至らないことも多く、様々な課題が見つかりました。

これから

また Fablic, inc の共同創業者である @shota @takejune と一緒にフリマアプリを超えるようなサービス、課題解決をしていこうと考えています。

今は ANGEL PORT というサービスを開発しています。 起業家でもあり、エンジェル投資家でもある、自分たちから見えた課題の解決と 若い起業家やスタートアップ業界に、自分たちがお世話になり、学んだことを少しでも返していけたらと思っています。

開発の経緯などはリリースノート に綴っていますので、興味があれば是非見てみて下さい。

また、ランチや飲みのお誘い、開発周りの相談等あればTwitterFacebookまでお気軽にご連絡ください!

f:id:yutadayo:20181114170642j:plain

最後まで、長文にお付き合いいただきありがとうございました。

エンジェル投資家 リスクを大胆に取り巨額のリターンを得る人は何を見抜くのか

エンジェル投資家ジェイソン・カラカニスがエンジェル投資について記した著書

エンジェル投資について、書いた本はあんまりないのとジェイソン・カラカニスの人柄が分かるような、文体、構成がとても良かった。

ただ、日本とシリコンバレーでは環境が違う部分もあるので、これを読んだ人が、本にあるような実践をいきなりできるかでいうと難しいと思う。

  • 投資資産が1億円以上ある
  • 10件のシンジケート投資を行う
  • etc...

具体的なエンジェル投資家としての活動内容、起業家とのミーティングにおける振る舞い
下記はカラカニスがメンタリング時に聞く質問

創業者に必ず聞く、4つの質問

  1. あなたは今どんな仕事をしていますか?
  2. あなたはなぜこれをやっているのですか?
  3. なぜ今なのか?
  4. あなたの不当なまでの優位性は何か?

シンジケートやプロラタなど、専門的な内容から、ブリッジラウンドを申し込んで来た起業家への接し方(評価額がなぜあがるのか?) など、具体的かつ、エピソードも交えて書いてあるので、非常に面白かった。
※ エンジェル投資は高いリスクを伴うと随所に書いてあるが

特にTwitter の投資を見送って後悔したところなど、確かに140文字のテキストコミュニケーションプラットフォームが、あそこまで巨大になるとは思わなかっただろうなと思った。

だからこそ、カラカニスが記しているように、プロダクトや市場ではなく創業者に投資するというのは、自分もとても Agree でハングリーさに溢れた実践的な起業家に投資したいなと思う。

まだ、聞いてないですが、ジェイソン・カラカニスがPodcastもやってるようなので、聞いてみたいと思う。

www.angelpodcast.com

自分が起業した時よりも、日本でもスタートアップをとりまく環境は変わって来ていて、エンジェル投資家と呼ばれる人たちの増加や、スタートアップを支援する環境が整って来たように思うし、これからも加速していると思うとそこにビジネスになるようなチャンスもあるのではと思う。

後日

縁あって、出版した本のイベントで来日していた、ジェイソンとランチする機会に恵まれた。 これはその時の2ショット(逆光...)、とてもエネルギッシュでユーモアに溢れた方でした。 日本の市場にもとても興味を持たれていたので、またお会いできると嬉しい。

f:id:yutadayo:20180921145931j:plain

構造化面接のススメ

以下は2017-12-22に会社(Fablic, inc.)の技術ブログinFablicに投稿した記事(http://in.fablic.co.jp/entry/2017/12/22/172546)になります。
inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。

元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。


これは Fablic Advent Calendar 22日目の記事です。

こんにちは Fablic でCTOをしている @yutadayo です。
ここ1年程は採用や福利厚生、会社の制度設計に関わることが多く、エンジニアとしての人権は失いつつあるこの頃です。

みなさんの会社では面接はどのように行われているでしょうか?
面接の目的は 候補者の方がチームに加わった時に、どのぐらい力を発揮できるか予想すること にあると思います。 しかし、限られた時間の中で、候補者の方の人となりや能力を正しく測ることは困難を極めます。

あなたの会社では面接の担当者は決まっていますか?
候補者の方に質問する内容は同じですか?バラバラですか?
候補者の方々を全て同じ基準で判定していますか?

面接に仕組みがあれば、候補者と面接者双方にとって、よい体験になると思います。
今回は 採用 をテーマに Fablic が取り組んでいる構造化面接の紹介をしたいと思います。

続きを読む

Codenize.tools を使ったインフラ管理について

以下は2016-12-19に会社(Fablic, inc.)の技術ブログinFablicに投稿した記事(http://in.fablic.co.jp/entry/2016/12/19/123807)になります。
inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。

元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。


この記事は Fablic Advent Calendar 19日目の記事です。

こんにちは、Fablicでサーバーサイドエンジニアをやっている yutadayo です。

今回は AWS の環境設定をコードで管理できる Codenize.tools の紹介と弊社での運用事例についてご紹介しようと思います。

続きを読む

Amazon Auroraへの移行

以下は2016-04-27に会社(Fablic, inc.)の技術ブログinFablicに投稿した記事(http://in.fablic.co.jp/entry/2016/04/27/182453)になります。
inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。

元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。


こんにちは、エンジニアの@yutadayoです。 Fablic が運営するフリルでは先日インフラをEC2-Classic環境からVPC環境に全面移行し、同時にリリース当時から使っていた Amazon RDS for MySQL から Amazon Aurora へと移行しました。

まず、移行して2ヶ月程度Auroraを運用した上での、良かった点と改善が必要な点を紹介します。

続きを読む

フリルのログ収集基盤について

以下は2015-12-25に会社(Fablic, inc.)の技術ブログinFablicに投稿した記事(http://in.fablic.co.jp/entry/2015/12/25/110618)になります。
inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。

元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。


この記事は Fablic Advent Calendar 2015 の25日目のエントリです。

こんにちは、Fablicでサーバーサイドエンジニアをしている@yutadayoです。今回はフリルのアクセスログをどのように収集し、活用しているかを紹介します。

続きを読む