• 株式会社カンム
  • 代表取締役社長
  • 八巻 渉

3人の開発チームで、Fintech事業をどう作る?最小構成のチームで挑む、その戦略とは

〜注目を集める「Fintech」。その領域に挑むベンチャー企業、カンムが最小構成のチームで実現する、事業開発の裏側〜

白熱する「Fintech」。金融の領域に、テクノロジーの力で新しいサービスを生み出す取り組みの総称だ。そのFintechの領域に挑戦しているベンチャー企業が、CLO(※)事業「Kanmu CLO」、プリペイドカード「バンドルカード(Vandle)」を展開する、株式会社カンム。

※CLO(Card Linked Offer):クレジットカード情報を元に、ターゲティングしたクーポンをクレジットカード会員に提供するサービス

規模の小さなベンチャー企業が「金融」という大きな領域に挑むため、同社ではさまざまな工夫を凝らして事業開発を進めている。

大手企業と提携するためには、「意思決定の早い人」と出会うためのアクションを起こし、サービス開発ではプロトタイピングを重ねながら、「React Native」「Go」といった最適な技術を選定することで、3人という少人数での開発を実現している。

今回は、同社を立ち上げた八巻 渉さんと、バンドルカードのプロダクトオーナーを務める井出 優太さんに、そのサービス開発の全貌を伺った。

「お金の流れを良くする」ため、Fintech事業を立ち上げ

八巻 学生時代に、ヘッジファンドや投資銀行でインターンをしていました。そこからベンチャー企業でエンジニアとして働いた後、2011年にカンムを創業しました。技術力が売上に直接つながる会社にしたいと思っていたので、ITと相性が良い「数値」を扱う、金融の領域を選びました。

みんながお金を使い、お金が流れることで、経済は活性化します。そこで弊社では、お金の流れを良くする事業、「Kanmu CLO」とプリペイドカードサービス「Vandle Card(バンドルカード)」という、2つの事業を展開しています。

バンドルカードは、Visaの加盟店で支払いができるプリペイドカードです。ネット専用のバーチャルカードと、ネットでもリアルのお店でも使えるリアルカードの2つのカードから、選択して発行できます。

Visaの加盟店で支払いができるプリペイドカード「Vandle Card」

一番の特徴は、スマートフォンアプリをダウンロードするだけで、数分でプリペイドカードを発行できるところです。これなら、いままでクレジットカードを使っていなかった若年層の方でも、すぐにプリペイドカードを取得できます。

ベンチャーが手を出せない領域は、他のプレイヤーとの連携を模索

八巻 金融系の事業は、ベンチャー企業単体ではできないことも多く、あらゆるプレイヤーと組む必要があります。

例えば、プリペイドカードを作ろうと思うと、カード番号を発行しないといけません。Visaから直接カード番号を発行してもらうと、それだけで数十億かかるんです。そこで、Visaからカード番号を発行されていて、かつその番号を貸してくれるカード会社を探す必要がありました。

また、プリペイドカードを作るためには、高度なシステムも必要です。システムが決済の通知を受け、カード残高から決済額を引いて、レスポンスを返す。これを数秒以内に収めなければならないという制約があり、かつVisaの許認可も必要なんです。ベンチャーが手がけるようなレベルのシステムではないですよね。

そこで、金融の基幹システムを既に持っている会社を探し、そこのシステムと自社のアプリをつなぐことにしました。

「低リスクな提案」で、大手企業との提携も実現

八巻 カード番号の部分は、最終的にオリコさんと提携することになりましたが、「低リスクでプリペイドカードの事業を検証できる」という点にメリットを感じてもらえたのが、大きいと思います。

基本的にクレジットカード会社は、クレジットカード事業が主軸のため、プリペイドカードにがっつり取り組むことにはジレンマを感じていました。ただ同時に、クレジットカードを利用しない層に対して、リーチしたいという思いも持っていました。

そこで、「カード番号を貸してもらえれば、システムの構築、運用、若年層へのプリペイドカードの検証をします」という、相手にとって低リスクな提案をして、意思決定をしてもらいました。

早い意思決定をしてくれる人との「知識の信頼関係」

八巻 ベンチャー企業が大手企業と提携するコツは、早い意思決定をしてくれる人と出会うことです。というのも、基本的にベンチャー企業の強みはスピードしかないと思っており、場合にもよりますが、検討だけで1年かかるような会社とは組んではいけないと思っているからです。

実際、CLOという事業を始める時のセゾンさん、バンドルカードの時のオリコさん、ともに1ヶ月程度で意思決定をしてくれる人に出会えました。

なお、「この会社が意思決定が早い」ということはあまりなく、どこの会社にも意思決定の早い決定権のある人がいるので、その人に出会うため、常に界隈の人に会っておくことが重要です。

そして、その際にただ人に会うだけだと意味がないので、情報発信をすることを心がけました

特に弊社の場合、ユーザーもシステムもないところからの提案だったので、「知識」でしか勝負できません。そこで、その領域について「日本で一番詳しい」レベルまで調べ、「日本で一番詳しい、らしい」という噂が流れるまで情報を発信し続けました。

例えば、今は週一でブログを書いてますが、カード業界の人100人くらいに一方的に送りつけてるんですね。ほとんど見られていないと思いますが、出会うべき意思決定の早い人は情報感度も高く、ちゃんとリアクションしてくれます。このような形で「知識の信頼関係」を深めることを常に意識しています。

仕様変更の影響が大きいシステムには、仮説検証を重視

井出 私はカンムで、デザイナー兼プロダクトオーナーを担当しています。

八巻が言うように、プロダクトを作るためには、金融の基幹システムやチャージを実現する決済代行など多くのプレイヤーと連携する必要があります。1つの機能を追加するにもどこかと連携しなければならない場合も多く、提携先が増えると仕様変更が起こってしまった場合の影響も大きくなります。

そのため、開発初期の段階で、若年層が必要とする・持ちたくなるようなカードとは何かを検証し、機能を絞っていく必要がありました。そこで、プロトタイピングツール「Prott(プロット)」などでプロトタイプを作り、ユーザー候補の高校生や大学生を対象に、数十人ほどにユーザーテストをしていきました。そしてコアとなりそうな機能以外は、実装する前に徹底的に削っていきました。

例えば、3日ごと、1ヶ月ごとに、カードの利用状況を集計する機能を当初入れていたのですが、それもすべて削りました。それよりは、やはり「スマートフォンから1分でプリペイドカードを発行できる」という機能がコアだと考え、そこに集中することにしました。

ユーザーテストには、必要な機能を考える上での「発想のベースを作る」という目的もありました。

クレジットカードを持っていない高校生や大学生がどのようにお金を使っているのか、実態を把握することで、リアルな発想がしやすくなります。

テストの結果、彼らは意外にもネット決済をしないということがわかったんです。人はカードを持つと、ネット決済の量が増えます。彼らにプリペイドカードを普及させることで、マーケットが広がる可能性を感じることができました。

手戻りを減らすため、ミーティングは「3時間ごと」!?

井出 開発チームは、3人だけの最小構成です。僕がデザインとフロントエンドのプログラミングを行い、フロントエンドとバックエンドのプログラミングおよび社内システム上のAPI仕様を決めるメンバーが1人、インフラ構築やバックエンドのプログラミング、金融の基幹システムと弊社のシステムをつなぐAPI仕様を決めているメンバーが1人です。

少人数かつ短期間で開発をするために、仕様を決めながら開発を進めていたため、デザイン、フロントエンド、バックエンドのいずれも仕様変更が発生していました。そこで、仕様変更の影響をすぐに共有・相談する工夫として、開発チームでは3時間ごとのショートミーティングを行うようになったんです

結果として、常にお互いがどの部分を開発しているかを話すことで全体の進捗が共有できるようになりましたし、テディベアメソッド(※)的にハマっているポイントを抜け出しやすくなりました。

※テディベアに話しかけることで、問題点が整理されてバグを見つけられるという例え

技術の選択にもこだわりを。「React Native」「Go」

井出 3人という最小リソースで金融系の事業を開発するためには、技術選びも重要です。バンドルカードのアプリ開発では、「React Native」を採用しています。

開発コストを抑えるためには、iOSアプリもAndroidアプリもJavaScriptで書けるとうたっている、React Nativeは魅力的でした。もともとReactでWebアプリを開発していたこともあり、新たな学習コストが少ないということもメリットです。

問題としては2015年時点で、React Nativeをプロダクトで採用した事例がほとんどなかったことです。そのため、実際にプログラムを書いてみてパフォーマンスなどに問題がないかを試し、問題なく使えることを検証してから採用しました。

バックエンドには、Go言語を採用しています。金融系のサービスという特性上、エラーが発生してお金を使えなくなったりすると、大問題になってしまいます。そのため、コンパイルの時点で不具合をある程度検知できる、静的型付け言語の安心感が欲しかったんです。

また、僕たちのチームのエンジニアはPythonの経験者で、PythonからGoに移行している人が多かったのもポイントです。彼らに話を聞くと、Goは動的型付け言語のようにサクサク書けて、標準ライブラリが充実しているためフレームワークを使わずに書きやすい、ということでした。非同期の処理が書きやすいのも大きかったようです

ただ、実際に使えるかはわからなかったので、バックエンド担当のエンジニアがプロトタイプを作りました。別のアプリのバックエンドをGoで書いてみて、一通りの機能を試し、問題なさそうだったのでGoを採用することにしました。

ただし、RDBMSのテーブル定義管理、テーブル定義マイグレーションはPythonのSQLAlchemyとAlembicを使う、シナリオテストにはlocustioを使う、管理画面はDjangoを使うなど、Python製のライブラリ/ツールが適切と思われる部分では敢えてGoは使わずにPythonを使っています。

「決済手数料ゼロ」の未来を実現したい

八巻 クレジットカードやプリペイドカードを使わないことによって、「不便さ」というコストがかかっています。もし多くの人がカードを使うようになると、カードを支えるコストをみんなで按分できるので、決済手数料は下がってきます。いまの日本だと決済手数料は約2.5%ですが、世界だと0.8%くらいになっていたりします。

そして、決済手数料が下がるとカードを使える店が増えて、さらに便利になるんです。最終的には、カード利用に関するデータをためて、データで稼ぐことによって、決済手数料をゼロにしたいと考えています。(了)

;