サブスクリプションD2CはどこまでEC SaaSに依存するべきか問題

こんにちは、ベースフード株式会社の技術責任者をやっておりまして、
2021年の1月でちょうど転職してから丸1年になります。 @sugaret と申します。
去年は（チームメイトのおかげで）ISUCON10の決勝に行ったりできました、楽しかったな。
https://sugaret.hatenablog.com/entry/2020/09/13/163547

サブスクリプションD2Cとは

ECサイトなどを自前で用意し、開発から販売までを一貫して行うサービスの形態のこと、といった理解でよいと思います。
ちなみに弊社は健康を当たり前にできる社会を作るというビジョンのもと、
「かんたん・おいしい・からだにいい」をコンセプトにした完全栄養の主食を販売しております。
先日も新味のメープル・シナモンが発売されまして、おかげさまで好評をいただいております！
https://basefood.co.jp

D2Cサービスにおけるエンジニアの役割とは

D2Cの事業としてはそれほどエンジニアが活躍する場面は多くないように見えるかもしれません。
しかし、販売はECサイトであるため、
・いわゆるECサイト内のチューニング（流入、回遊、カートから決済の流れなど）
・webサイト上の様々なオンライン施策（友達招待やロイヤルティプログラムなど）
といった、お客様が商品を購入する体験に手を加えるためにはエンジニアの力が必要になります。

EC SaaSの存在

前提として、スタートアップで全て自前でECサイトを作り上げるのは車輪の再発明になる可能性が高く、かなり無駄が多いです。
商品管理、決済、注文管理、顧客管理、ロジとの連携など、ECサイトを作りたいとき、そのおおよその仕組みを提供しているSaaSがあり、全部、もしくは一部、それを利用するほうが効率が良いでしょう。

最近ではかなり自由度の高いECサイトのSaaSも生まれてきており、
自分たちでシステムを作らず、全てを依存してしまうというのも十分ありえる手です。自分たちで作る場合と比較して低コストで利用できますし、たとえば
・購入時にポイントを付与し、それが次回の割引として1ポイント1円で使える
・クレカでもAmazonPayでも決済したい
といった、どこかで見たような機能が利用できることもあります。

ただし、EC SaaS側の立場からすれば、基本的に最大公約数的にシステムを作るため、
「自分たちの商材のためのチューニング」を即時用意してもらうことは難しく、
実現しても2-3ヶ月後、あるいはそもそも対応などしてくれないということもあるのではないでしょうか。

たとえば基本無料で利用できる国内EC SaaSのBASEと、かなり自由度の高い海外EC SaaSのShopifyについて比較してみます。

	base	shopify
料金	基本無料 BASEロゴを外すために500円/月 その他機能に費用がかかることがあるが、大体の機能は無料の模様	月29ドル〜299ドル https://www.shopify.jp/pricing 別途、Shopify plusという「多くのカスタマイズを可能にする」プランも存在する
支払い方法・手数料	* クレカ * キャリア決済 * 振り込み など 3.6% + 40円	* クレカ * amazon pay * キャリア決済 など https://www.shopify.jp/blog/payments-list 国内発行のカード　3.25%〜3.4% 海外発行のカード / American Express　3.8%〜3.9% JCB　4.05%〜4.15% その他、ここにない手段を利用することもできる。ただしその場合は0.5%-2.0%の手数料を別途納める必要あり。
定期販売	可能 ただし、skipや日付変更、内容変更は不可の模様。キャンセルも事業者側が対応をする必要あり https://apps.thebase.in/detail/62	最近公式で可能になった。 それまでは自前で用意する必要があった。 現状も細かくチューニングするには自前で作る必要がありそう
ポイントの付与	不可？見つからなかった	shopifyアプリで可能。自前で作ることもできる。
チューニング	存在する機能を入れることで機能のチューニングができる。 HTML/CSSをいじることができる。 https://apps.thebase.in/detail/107	簡易的にshopifyアプリで対応することもできるし、 API経由で商品の情報を取得したり注文を作成したりなど、 おおよそあらゆるチューニングができる。

baseはより「かんたん」に、shopifyはより「チューニング可能」に振っているように見えます。このあたりはユースケースに合わせて選択するのがよいと思います。

重要なのは「どの部分を競合優位にするつもりなのか」

一般的に用意されている機能で十分なのであればSaaSにまかせたほうがよいでしょう。外部にコストをまかせられますし、彼らはその当たり前品質を守るプロなわけですから。
一方で、独自性を持っていろいろ試行錯誤すべきポイントについては自社でチューニングできるようにしておくことが肝要だと思っています。ここでは継続率を上げることについて考えてみます。

定期購入における継続率の重要性

たとえば定期購入の事業では、月次の解約率の1%が事業に与える影響がかなり大きいです。雑に説明すると、

例えば月次解約率90%で1年たつと、
(0.9)^12 = 0.28242953648 で、もともといたユーザーは28%ほどになります。
月次解約時91%と89%も比較してみると以下のようになり
(0.91)^12 = 0.32247548741
(0.89)^12 = 0.24699040356

定期購入ユーザーが1万人、平均購入単価が3000円だとしたらこんな感じの差分になります。
10,000 * 3,000 * (0.91)^12 ≒ 9,674,264
10,000 * 3,000 * (0.9)^12 ≒ 8,472,886
10,000 * 3,000 * (0.89)^12 ≒ 7,409,712

これは12ヶ月後だけの話ですが、当然2ヶ月目〜11ヶ月目にも差分があるため、
その累積を考えると更に差分が大きいことを感じるのではないでしょうか。
当然12ヶ月後の時点ではそのタイミングで新しく定期購入を始めるお客様もいるわけですから、
12ヶ月後の会員数が上記の人数になるというわけではないですが、
入ってきてもすぐいなくなってしまう、穴の空いたバケツ状態ということがわかりますね。

とはいえ現実的に解約率が0%になることはないので、どれだけの大きさの穴を許容するかという話になりますが、売り方や見せ方でこのあたりの数値はそこそこ動くため、まだまだ伸びしろあるね、ということで改修対象になっています。

商品とサービスの改善

このような話をしていると「解約率を低くするのは本質的に商品の改善によってなされるべきであり、その他の手法で行うのはどうなんだ」という話をされることがあります。
弊社の場合はパンやパスタなどをもっと美味しくすることですね。これはもっともなご指摘です。（日々開発・改善を行っておりますので2021年もご期待ください。）
一方でサービスとしては、「かんたんに」健康になるという意味で購入までの体験のストレスを減らすとか、購入後の食べ方といったところまでサポートをして、より習慣化して続けやすくなるように改善をしてゆこうと考えております。

弊社のケース

弊社では3つのドメインを利用してwebサービスを展開しております。
1.basefood.co.jp
ここはECサイトのトップページとしての役割を担っています。
裏側はLaravelが動いており、ニュースページでは一部WordPressを利用して、記事の管理などを行っています。

2.shop.basefood.co.jp
商品の一覧ページ、商品の個別ページ、カートページなど、回遊しつつカートに商品を入れるところまでを担っています。
Shopifyでホスティングされており、商品の登録などをshopifyのCMSを経由して行っています。

3.payse.basefood.co.jp
決済のための情報の入力、購入完了するところまでと、マイページでの各種情報の確認・変更する部分を担っています。裏側は Laravel + Nuxt.js で動いており、LaravelがAPIサーバーとして動作して、shopifyなどと連携しつつ決済・注文情報の登録などを行います。（ちなみにpayseというのはこのシステムの名前です。）
また、当初のshopifyには定期購入の機能が存在しなかったため、いつ次回の購入をするのかなどの情報もpayseで管理しており、日々バッチ処理にて定期の注文を行っています。

よいところ

shopifyの良い部分はそのまま使える

• ロジとの連携
• 商品管理（CMSなど）
• 様々なshopifyアプリ
  など、用意されているECサイトでよく利用されるような部分はまるっとまかせています。（ちょっとサポートに時間がかかるというのはありますが）このあたりの機能について不備があれば公式で対応してもらえるので便利ですね。

自前でいろいろチューニングできる

• 友達招待
• ロイヤルティ機能（累計購入個数でのインセンティブ）
• ポイント
  などは実は社内で開発しています。このあたりもshopifyのアプリを使えば対応できると思いますが、社内でいろいろ仮説を立てつつ、細かくトライアンドエラーを行うためには社内で作って運用するのがよいと判断しています。

つらいところ

割とメリットの部分と表裏一体になっているので一概に「どうにかせねば」というわけではないのですが。

SaaSに乗り切っていない部分のコスト問題

• APIなど、連結部分のチューニングコスト
  SaaSを一部だけ利用することになると連結部分を運用し続けるコストがあります。いろいろな部分をいろいろなSaaSに任せていると、それだけのカウンターパートを相手にしながら対応することになります。
• CSサポートコスト
  CSチームが問い合わせる窓口が社内エンジニアになることが多くなり、そのために工数をかけることとなります。（これは内部でタイムリーに対応できる強みとも言えますが）
• 無段階に増加する負荷への対応
  ありがたい悲鳴ではありますが、お客様が増えることによって今までは問題なかったシステムが「実行時間的に大丈夫？」みたいな話になってきます。このあたりも全て任せられていれば考えなくて良い部分ですね。

おわりに

少し前までは問題なかったけど半年後はわからないというような状況がしばしば起こり、なかなかエキサイティングな体験ができています。
これを読んで共感してくださった同業の方々、興味を持ったエンジニアの方々、ぜひお茶でもしましょう。（オンラインでもどうぞ）