JP_Stripes (Stripe ユーザーグループ）Tokyo Vol.10 -- SaaS! SaaS!! SaaS!!! --やってきた
JP_Stripesの東京での第10回のミートアップを開催しました。ここ最近は運営メンバーがそれぞれ興味ある分野のテーマを設定してミートアップを企画しています。
今回はSaaS特集。Stripeのアップデート情報とTwilio Payのデモ、4つの事例セッションと盛りだくさんでした。
冒頭ではStripe Advent Calendar 2018の紹介をさせていただきました。すでにすべての枠が埋まっています！12月が楽しみですね。
当日の様子はこちらのTogetterをご覧ください。
ここからは僕の感想も織り交ぜつつ、イベントをふりかえってみます。
Stripe アップデート + Twilio Pay 連携デモ
StripeからはアップデートとしてTerminalの紹介とTwilio Payのデモがありました。
TerminalはPOSからStripeに決済できる仕組みです。これがあるとリアル店舗での決済、オンラインでの決済をStripe上で取りまとめられるようになる感じかと思います。まだ日本上陸してないのですが、今後の展開が楽しみです。
Twilio PayのデモではTwilioの赤い人、高橋さんがお客さん役として電話でケーキを注文して決済までする、というデモをしていただきました。
宅配ピザや寿司なんかもこれに対応すると、配達スタッフが小銭をジャラジャラ言わせることがなくなって良いのではないかなと思います。現在は日本円での決済ができないようですが近いうちに対応予定とのこと。
より詳しい話については、28日にイベントがあります。
「Stripe Billingで価格改訂」 デジタルキューブ 岡本さん
登壇者一人目はデジタルキューブの岡本さん。ツイートの強力プッシュからセッションがスタートw（ありがとうございます！）。
Stripeを使って価格改訂をする際の手順について紹介がありました。
StripeにはProduct, Planがありますが、このPlanの価格は変更できないので、新たなPlanを作って既存のPlanを削除、SubscriptionをUpdateしてPlanを新しい方に切り替える感じになるようです。この場合にはSubscriptionの切り替えをバッチなどで一気にやることになります。
もう1つの方法としては、新たなPlanを作成してユーザーのアクションベースで新しいPlanに切り替えをしていってもらう感じになります。GitHubとかのプラン切り替えもこんな感じでしたね。新・旧プランが混在する形です。
だたこの場合には、旧プランの料金体系を残しておくことになるので、サポートのコストがかかってしまいそうです。期限を区切って期限日がきたら自動で新プランに移行します、という形がよさそう。
今だと来年10月の消費税増税のタイミングとかに合わせて期限を区切るケースとか考えられますね。
「ヌーラボのサービスにおける Stripe の活用」ヌーラボ 馬場さん
登壇者二人目はヌーラボの馬場さん。
馬場さんは発表内容に関してブログも書かれています。
ヌーラボの決済の歴史について紹介がありました。最初の頃は人力で対応していたとのこと。思えばうちも最初の頃は請求書の印刷も会社のプリンターで印刷して三つ折りして封筒に入れて、みたいにしていたなあと思い出しながら聞いていました。（今は請求書の発行はMFクラウド請求書です）
その後ヌーラボさんでは複数のサービスでの決済を共通化するため、ジャパンネット銀行のAPI、海外向けにStripe、国内向けにWebpayでの決済システムを作ったとのこと。StripeのSubscriptionは使わずに全て自前で実装したということです。そしてPlanやBillingといった設計もStripeに似ている！これはすごい！やはりそのへんに詳しい人が設計すると似るんでしょうか。これが2015年頃のことだそうです。
ヌーラボでWebpayをガッツリ活用していた話が出てきたので面白かったです。WebpayはStripeで言うところのCustomer,Subscription,ChargeのデータはあるもののInvoiceがなかったので、自前でInvoiceのデータを作ってChargeに対して金額が一緒で契約期間が一番古いInvoiceをひもづけて入金済にする、みたいな実装をしたのを思い出しました。
なおリリース当日胃腸炎で寝てたらWebpayのサービス終了告知があったので結局その実装はリリースされず、Stripeで実装しなおしたらStripe側で完結するようになって素晴らしい！と思ったものでした。
ヌーラボさんの場合だとJCB対応の関係でWebpayの移行先としてPAY.JPを選んだとのこと。
StripeのSubscriptionを使わずに自前で決済を実装したとのことで、今回僕がやった対応と全く逆の方向性で興味深かったです。僕が銀行振込も含めてStripeに完全に寄せる事ができたのも2018年になりStripeでできることが増えたという時代の流れもあるのかなとは思います。あとはStripeと同等の決済システムを自前で作りたくないという僕の実装力w・・・。
「SaaSを海外展開するために準備した3つのこと」Instoll 友田さん
登壇者3人目はInstallの友田さん。
SaaSを海外展開するために準備した3つのこと、ということで海外に法人をおかないで日本法人だけで海外展開するために必要なことをお話しいただきました。
ミートアップに来ていた方は海外に事業所があって、みたいな方も多かったようですが、スタートアップだとそういうわけにはいかないので、そういった人たちが海外展開するときにどういった点に気をつけなければいけないのか、実際にどのへんが海外のマーケットとして存在しうるのか、といった話はとても刺さるものだったと思います。
「Stripeで実現する銀行振込」 TOWN 岩崎
僕からはStripeで銀行振込をする、ということで話をさせていただきました。
なぜStripeで銀行振込に対応しようと思ったかについてのきっかけを2つ紹介いたします。
対応するきっかけその1
ミートアップ翌日に自分が開発しているサービスの新料金プランをリリースしました！機能ごとにそれぞれ異なるユーザー数で契約することができるような料金体系になっています。
最近はS,M,Lといったプランごとに使える機能が異なるパターンではなく、ZenDeskやIntercomなどのように機能ごとにプランを用意して組み合わせるパターンが増えてきています。
今回は11の機能が用意されていて、まずはクレジットカード対応から開発を始めました。Stripeによるクレジットカード対応の実装が終わり、銀行振込対応を考えたとき、プラン体系がガラッと変わり、1つのSubscriptionに複数のSubscription Itemが入る形になるので、今までの銀行振込用の自前実装だけでは対応しきれません。もう一度作り直すとしたときにStripeの設計が多分一番マッチするんだろうなと感じましたが、Stripeと同じProduct, Plan, Subscription, Invoice, Chargeを再設計、実装し直すのは辛いと感じていました。（どうしても劣化コピーになるのが避けられない）
また、運用上の問題として銀行振込の場合、契約内容の変更は問い合わせをもらって運営者側で差額の案内などの対応をしていました。11の機能別になったときにそのあたりの運用コストが増えることが予想されたので、システム的に巻き取りたいというのもありました。
対応するきっかけその2
前々回のJP_Stripesのミートアップのとき、ビットジャーニーの道川さんが、Stripeで請求書払を検討している、という話をしているのを聞いて、「確かに実現できそう」と思い、銀行振込をStripeで対応する方向で開発をすることにしました。
実際にどういった形で対応をしたかについてはスライドをご覧ください。
補足
金春さんから「銀行振込だったら他のサービスもあるのになんでStripeにしたの？」と質問いただいて、そのときははっきりとした回答ができなかったので補足です。
一番大きい理由としては、決済データを1箇所に集約したい、というのがあります。
もちろん他のサービスを使って連携するとかもできるかと思いますが、そうなると決済のデータをどこかに持たせないといけません。自前で実装したくないと考えたとき、決済データを持っている銀行振込に対応したサービスを使うことが考えられますが、そうなるとStripeとそのサービスと2箇所で決済のデータを持つことになります。
クレジットカードの場合と銀行振込の場合で差額の計算ルールが違ったり、月末の処理が違ったりしてくると面倒なので、Stripeに統一してBillingのサイクルのルールを1つにしておきたい、プランや金額などのマスタデータを1箇所に集約しておきたいというのがありました。
消込までStripeでできればベストですが、今回はどちらかと言うとこれらの点からStripeに寄せることにしました。
あとは将来的にStripeで消込対応できそうかなあという予感があるからですw。
まとめ
今回はSaaSしばりということでしたが幅広い事例を聞くことができました。ご登壇いただいたみなさま、ご参加いただいたみなさま、ありがとうございました！
そして全国のJP_Stripes運営メンバーも多く集まり、来年の展望に期待です。