こんにちは！freeeのエンジニアのmiyarappoです。
freeeには2019年5月に入社して、主に課金処理とサブスクリプション管理を集約したマイクロサービスを開発しています。 その中で得た知見を共有したいと思います。
この記事は freee Developers Advent Calendar 2019 の15日目です。
よろしくお願いします！
この記事の目的
「サブスクリプションビジネス未経験の人が、サブスクリプションビジネスをする時に考慮すべき最低限のユースケースを想定できるようになる」を目標とします。
誰かの落とし穴を塞げたら幸いです。
前提
この記事で取り上げるユースケースは、サブスクリプションビジネスにおける一般的なユースケースを想定しています。
freeeが辿った変遷を参考にしつつ私個人が想定したユースケースであり、現実のfreeeのユースケースと一致しないことをご理解ください。
前置きが長くなりました。はじめます。
ユースケース①: プラン変更が起こる
サブスクリプションビジネスでは、サービスそのものを売るのではなく、サービスを一定期間利用できる「権利」を売っています。 この権利は常にアップグレードやダウングレード、数量変更が可能です。
変更に耐えうるデータモデルを設計することが重要です。
具体的な例
やっていき株式会社は、経理をサポートするSassを開発しました。
サブスクリプションで販売しようと試みます。
初心者プランと上級者プランの2つのプランを用意しました。
初心者プランを購入したユーザーが、上級者プランに変更したいと言ってくれました。
初心者プランの分を返金して、上級者プランの料金を差額決済します。
按分計算が必要になります。
上級者プランから初心者プランへの変更の場合は、返金をする必要がありました。
ユースケース②: 売上は請求し回収する必要がある
当たり前ですが、売上分の金額をユーザーからいただく必要があります。 ユーザーの利便性を考慮し、支払い周期と支払い方法を増やすほど請求・回収業務が複雑になります。
スプレッドシートでの管理は、すぐに限界が訪れます。 請求業務や回収業務の自動化を進めないと、ユーザーの拡大にバックオフィスが耐えられなくなります。
具体的な例
経理をサポートするSassは順調にユーザーを獲得しました。
決済方法はクレジットカードのみ対応でしたが、新たにペイパル・銀行振込・PayPayを対応しました。
月額払だけでなく、年額払いにも対応しました。
UXは向上しましたが、「2つのプラン × 4の支払い方法 × 2つの支払い周期」のケースに対応する必要があります。
スプレッドシートも大きくなり、ユーザーの管理が大変になってきました。
登録されたクレジットカードの有効期限がきれて決済が完了出来なかったユーザーに対しては催促のメールを送る必要があります。
ある時、月額払いから年額払いに変更したユーザーに、月額の料金を請求してしまいました。
銀行振込が行われずユーザーに電話する必要がありました。
手形と楽天Payにも対応しようという話が挙がりましたが、管理コストが倍になるので取りやめざるを得なくなりました。
ユースケース③: オプションの販売が始まる
サブスクリプションビジネスでは、ユーザーのLTV(生涯価値)を最大化するべく、様々な施策を講じます。 その施策の１つが、オプションの販売です。
具体的な例
やっていき株式会社の経理作業サポートサービスは絶好調。
初心者プランに、年額1200円で電話サポートのオプションを販売することにしました。
経理が苦手なユーザーが喜んで購入してくれましたが、このユーザーは初心者プランを月払いで使っています。
初心者プランは月払いで、オプションは年払いとなり、ややこしいです。
「2つのプラン × 4の支払い方法 × 2つの支払い周期 × オプションありなし」のケースに対応する必要があります。
管理がまた複雑になりました。
ユースケース④: クーポンの発行が始まる
新規ユーザーの獲得は、とても重要です。 まずはユーザーにサービスを使ってもらい後ほど利益を出すという作戦は、サブスクリプションととても相性が良いです。 そのため、最初の採算は度外視でクーポンを発行するというケースがよくあります。
具体的な例
確定申告の時期になり、経理作業サポートサービスの問い合わせが急増しました。
やっていき株式会社は、新規ユーザーを増やすべくクーポンを発行しました。
初心者プランを1ヶ月無料で使えるクーポンを1000つ発行しました。
「2つのプラン × 4の支払い方法 × 2つの支払い周期 × オプションありなし × クーポンありなし」のケースに対応する必要があります。
新規ユーザーの獲得に成功するも、管理がまた複雑になりました。
ユースケース⑤: オフラインの販売が始まる
オンライン販売から始めたサービスも、拡大に伴いセールスが直接契約を結ぶケースが発生します。 多くの従業員を抱える会社の場合は、金額が大きくなるので、セールスが介在して請求書に直接ハンコを押して契約みたいなフローが一般的なようです。
セールスが売上分は、システムに反映する必要があります。 直接DBに書き込むわかにもいきませんから、セールス用の管理画面が必要になります。
オンライン、オフラインで同じフォーマットで管理しないとキャッシュフローを算出するのが難しくなります。
具体的な例
やっていき株式会社は、経理作業サポートサービスをセールスが直接販売するようになりました。
セールスは現場判断で、割引を行うことが出来ます。
「2つのプラン × 4の支払い方法 × 2つの支払い周期 × オプションありなし × クーポンありなし」のケースに加えて、「2つのプラン × 4の支払い方法 × 2つの支払い周期 × オプションありなし × クーポンありなし × Nパターンの割引」に対応する必要になります。
全体の売上を把握するだけでも一苦労です。
ユースケース⑥: 新プランがリリースされる
ユーザーの契約を永続的に管理することは、サブスクリプションビジネスをやる上で避けられません。 一方で、様々なパターンの契約を管理する必要があり、整理された状態でデータを保持するために一定の努力をする必要があります。
データが整理されていないと、ビジネスの意思決定（新プランのリリース等）にシステムがついていけなくなります。
データをコントロールできる状態に整理しておくことは、サブスクリプションビジネスでは特に重要です。
具体的な例
やっていき株式会社は、従来のプランを廃止し、松プラン、竹プラン、梅プランの3つに変更しようとしています。
初級者プランを梅プランに以降しようとしましたが、クーポンやオプションがついたプランのデータがうまく移行できませんでした。
その結果、新プランのリリース時は、一部のユーザーがサービスを使えなくなってしまいました。
まとめ
この半年間の業務で、サブスクリプションビジネスでは継続的に契約内容を管理する必要があり、データを整理し続けることが重要であることを学びました。 紹介したユースケースのように大変な部分もありますが、ユーザーがサービスをずっと使ってくれるのを見れるのは嬉しいです。
需要があれば、そのうち具体的なデータ構造とかシステム構成とか踏み込んだ説明をしようと思います。
そしてサブスクリプション管理の実装をしている方！是非 freee Tech Nightの懇親会 でお話しましょう！zuoraの辛みやデータモデル設計とか語りたいです。笑
一緒に開発している方もお待ちしております！ 自分のチームでは、TypeScript / React / Redux / Rails6 / EKS で開発してます！
明日はモバイルエンジニアのあべちゃんです。
それでは！
