SIerがSaaSを作る果敢なチャレンジでStripe決済を組み込んだ話 / inside story gusuku Customine with Stripe.

SIerがSaaSを作る果敢なチャレンジでStripe決済を組み込んだ話 / inside story gusuku Customine with Stripe.

JP_Stripes (Stripe ユーザーグループ)in 沖縄 Vol.2
https://eventregist.com/e/JP_Stripes_OKA2

事例セッション「SIerがSaaSを作る果敢なチャレンジでStripe決済を組み込んだ話」の資料です。

893969a535f9cc0cc904485f44fe15ee?s=128

R3 institute

October 19, 2018
Tweet

Transcript

  1. SIer がSaaS を作る果敢なチャレンジで Stripe 決済を組み込んだ話 2018 年10 ⽉19 ⽇ JP_Stripes

    in 沖縄 Vol.2 アールスリーインスティテュート ⻄島
  2. このトークのアジェンダ Stripe を導⼊したビジネスの背景 決済⽅法の選定:何故Stripe を必要としたか 実際のStripe 組み込み Easy or not?

    決済結果の内訳 まとめ 2
  3. ⻄島 幸⼀郎 @k_nishijima ⼤阪の会社であるアールスリーインスティテュ ートに、沖縄のワンコx2 がいる⾃宅からリモー トワークで参画している根っからのクラウド・ コミュニティ⼤好き⼈間。オープンソースとク ラフトビールをこよなく愛する。 コミュニティ活動

    JAWS−UG 沖縄 コアメンバー ハッカーズチャンプルー実⾏委員⻑ 3
  4. アールスリーインスティテュート 2014 年よりサイボウズのパートナーとして活動 サイボウズ公認kintone エバンジェリストを3 名 擁し、強くコミット kintone とAWS を効果的に組み合わせた案件を多

    数創出 全国有数のkintone SI 実積を保有 営業・エンジニア全員がkintone 資格所有 4
  5. アールスリーはシステム開発会社 いままでは全ての売上がシステム開発・運⽤保守 全ての売上がB2B (法⼈向け) 99.9% が請求書発⾏(⼀部電⼦請求) なのに何故クレジットカード決済が必要に? 5

  6. Stripe を導⼊したビジネスの背景 kintone を活⽤したシステム開発案件を⼿がけていく中、⾃分たちが欲 しい機能を作り、サービスとして提供 gusuku Deploit https://deploit.gusuku.io/ システム開発会社として初めて、⾃社開発のサ ービスを提供開始。

    決済は⽉額および年額の請求書ベース。 6
  7. 続いて開発したのが gusuku Customine kintone のJavaScript によるプログラミングの柔軟性を、⾮エンジニア でもフル活⽤できる No-Code プラットフォーム gusuku

    Customine https://customine.gusuku.io/ ⾃社サービスに初めてクレジットカード決済を 導⼊しました。今回はこの話。 システム構成等、内部の話を公開するのはこれが初めてになります 7
  8. 価格表 クレジットカードの⽉額課⾦、請求書の年払い・ライセンスパックとい う特殊な課⾦⽅法の3 種類。 8

  9. 何故B2B のサービスにクレジットカード 決済を⼊れたかったか? 9

  10. 何故B2B のサービスにクレジットカード 決済を⼊れたかったか? 便利に使っていただいた分の対価を頂けるよ うにしたい ⇛ つまりは、従量課⾦⽅式で提供したい 従来の請求書ベースでは、運⽤的にほぼ不可能 10

  11. 何故B2B のサービスにクレジットカード 決済を⼊れたかったか? お客様が必要なときに、必要な分だけ購⼊できるサービスになれば、お 互いにとってハッピーなのでは? という想い Customine では、「アプリスロット数」という単位で、お客様が⾃分で 利⽤する量を調整できる。 これで、ぜひいっぱい使って欲しい!

    11
  12. よし、クレジットカード決済を⼊れよう でも何故Stripe に? 12

  13. でも何故Stripe に? アールスリーはあらゆる領域のシステムを開発 してきた歴史ある会社。社内にも勿論別会社の クレジットカード課⾦コンポーネントはありま した ただ「今回は新規開発なので、なんか⼊れてみ ない?」 単純に「楽しそうだから」⼊れて みました

    13
  14. 笑い事ではないんです システム開発会社の競争⼒とは・・・勿論エンジニアです。 そのエンジニアがクリエイティビティを⼀番発 揮するのは? = ⾃由に楽しく開発している時なんです 14

  15. 「より価値のある」システムを作り続け ていくために 【お客様の要望通り、場合によっては⾒えていない将来を⾒越した システムを作る】 【⾃分たちや世の中の誰かの役に⽴つシステムを作って、サービス として売る】 ひとつの会社の中でこの2 つの命題を達成するには、 「楽しく」開発 し、常にクリエイティビティを発揮していくこと

    はとても重要です。 15
  16. 実際のStripe 組み込み Easy or not? #JP_Stripes でみんな「簡単」っていうので 期待していましたが・・・ 16

  17. まずはシステム構成 シンプルなSPA+API サーバ+ バッチ群 17

  18. 決済を組み込む部分 SPA (フロント側: Vue.js + TypeScript | Stripe.js で画⾯周り) API

    サーバ(初回のCustomer 作成時) バッチ(サブスクリプションの作成/ 更新) 後のPoC で、どこにどの機能を持たせていくか を検討 18
  19. 実際のスケジュール 3 ⽉27 ⽇ プレビューリリース。その後毎週アップデートリリース 7 ⽉06 ⽇ JP_Stripes in

    沖縄 キックオフ 7 ⽉13 ⽇ 試⽤開始。⾊々遊ぶ| いじる(PoC 期間) 試⽤の結果を踏まえ、商品構成、どの機能を使うかなどを検討 噂通り⽇本語サポートが爆速でレスポンスくれることを思い知る 7 ⽉20 ⽇ おおよその商品マスタと利⽤機能を決定 19
  20. 実際のスケジュール 7 ⽉31 ⽇ 1 ⽇掛けてフロント側実装完了 8 ⽉いっぱい テスト・サーバ側バッチなどもろもろ実装(Stripe だけ

    やっている訳ではないです) 9 ⽉03 ⽇ 正式リリース 10 ⽉1 ⽇ 初回バッチ(サブスクリプション作成) 10 ⽉10 ⽇ 初回課⾦(うまく⾏きました!) 10 ⽉19 ⽇ = 今⽇!初めての⼊⾦(うまく⾏く、はず) 20
  21. PoC 最重要 どの機能を使って、⾃社のビジネスモデルを表 現するか? ⇒ ひとつひとつ curl でAPI を叩きながら、実際の動きを確認しながら確 認・議論できる。ほぼそのまま動かせるAPI

    ドキュメント素晴らしい。 例:プラン⼀覧取得 21
  22. 今回使った主な機能 サブスクリプション クーポン 商品:⽉額固定+個数で可変のオプション どのタイミングで請求⾦額を確定するか、実際に課 ⾦するのはいつか、マーケティング上どのような施 策を⾏うかなど、細々したことを全てPoC で試して から、実装に進みました。 22

  23. 実装は簡単か?と⾔われると… コーディング⾃体は容易 フロント側(Vue.js + TypeScript) への組み込みは⼀瞬で出来るのは素 晴らしい サーバ側はJava で実装(このSDK はあまりセンスがないが…

    過去経験したライブラリはここでは⾔えないレベルで(ry TypeScript の型定義もちゃんとあります: https://www.npmjs.com/package/@types/stripe-v3 23
  24. ハマりどころというか、検討が必要な点 は多い もちろん簡単なことは簡単に出来るが、⾃社のビジネスにかっちり合わ せようとするときにはもちろん難度が急に上がる。 必ず複数回のREST 呼び出しが必要になるので、全体のトランザクシ ョンとしてどうするか?を考えておく必要がある 必要なら1 画⾯に全てを詰め込まず、分解して決済画⾯フローを作 る必要がある

    24
  25. ハマりどころというか、検討が必要な点 は多い 直感的でない動きをすることもあるので必ずテストする必要がある サブスクリプション周りは⾊々「⽇本の商習慣」とずれる場合が 多いので… ドキュメントを読んで、思い込みで実装、危険 25

  26. 例えば課⾦⽇ ※「必ず毎⽉1 ⽇に決済したいんだ!」とか そんな事ではなくw 26

  27. 例えば課⾦⽇ B2B の場合、課⾦予告をする必要がある 毎⽉1 ⽇0 時の状態で、課⾦⾦額を決定 ルールは「前⽉購⼊した分の最⼤値で課⾦」するモデル 決定した⾦額を予告としてメール通知 ここまでが課⾦するまでの準備。 27

  28. 例えば課⾦⽇ B2B の場合、課⾦予告をする必要がある これを⾒て顧客が何らか応答 or 無いことが望ましいが、課⾦⾦額の間違いがあれば修正する 実際の決済⽇は毎⽉10 ⽇(これは例だがいつでも良い) このフローを実現するには、まあまあ作り込む必要があります。 28

  29. 例えばプラン変更 年額払いのプラン変更で、顧客にどうにも説明 しづらい端数が出る 年額プランのプラン変更をした場合、proration_date にぴったり翌⽉の 同時間を秒単位で指定しても「年額÷12× 残契約期間」のように計算さ れず、微妙に端数が出る 29

  30. 微妙・・・ 年払いだと秒単位で端数が出る必要はなく、年額/12 の単位で計算して 欲しいが、それは不可能な模様(PoC 当時)。 30

  31. どう対応したか? 年払いのクレジットカード決済を⽌めた 元々年払いの⾦額は⼤きくなるので、無くても差し⽀えないと判断。 繰り返しますが決済⼿段が⾊々ある場合には、実際に実験することが⼤ 切です。 31

  32. 例えばテスト環境から本番環境への移⾏ 商品データの移⾏が⾃動では⾏かなくて仰け反 りました エクスポートはあったけど、インポートはなかったようなので、⼿で作 りました… 。 このサービスは商品が少ないから良かったけど、多い場合はどうするの かな・・・?(API かな?) 32

  33. ⾊々頑張って実現されたクレカ決済 どうなったと思います? まだ1 ヶ⽉しか経っていませんが… 33

  34. 決済結果の内訳(件数ベース) ほぼ綺麗に7 対3 ! 34

  35. まとめ 価格に弾⼒性をもたせたいときには、B2B であったとしてもクレジッ トカード決済は有効 シンプルな価格にしたほうが実装は楽:あたりまえ もし複雑でも、API 強⼒なのでなんとかなる サポート爆速:ありがたい(Facebook グループで質問している場合 ではない?

    35
  36. ありがとうございました gusuku Customine をよろしくお願いします https://customine.gusuku.io/ 36