サブスクモデルサービスにおける施策の例と実装上の考慮点

これは何？

かつて筆者が設計、実装、運用等に関わったサブスクモデルサービスの事業プロダクトにおいて、実際に行われた施策とその実装上の考慮点に関するお話です。ほとんど自分用メモの様相を呈していますが、これから同様のプロダクトを設計する人の参考にもなれば嬉しいです。

筆者が関わっていたのは実際に商品をお届けするタイプの事業ですが、デジタルで完結するサービス（動画視聴やファンクラブなど）にも共通する内容だと思います。

サブスクモデルサービスって何？

定期的な周期ごと（多くは月次）にサービスが受け取れたり、サービスを受け取れる権利が更新されたりするタイプの事業のことで、Netflix、Youtubeのプレミアム会員、Amazon Prime、缶詰やお肉が家に届くものなど様々です。

施策例

決済方法に関するもの

クレジットカード決済

定期的な支払いをクレジットカードで行えるようにする施策で、施策とは言ったものの、サービス開始時点から必須となるものだと思います。お客様の会員登録時などにクレジットカード情報を入力してもらい、以後の支払いはそのカード情報行うようにします。

考慮すべき点としては、あるお客様に紐づくクレジットカード情報を複数登録できるようにすべきかどうか、お客様がマイページ上で削除したカード情報を内部ではどこまで記録しておくべきか、クレジットカードでないカード（デビットカードやプリペイドカード）を許容するかどうか、などです。

筆者は、お客様の利便性向上のためにクレジットカード情報は複数登録でき、さらにデフォルトで使用するカードにフラグが立てられるべきだと考えています。クレジットカードには有効期限があり、その切り替わりのタイミングではまだ有効期限内の旧カード情報を残しつつ、新カード情報をあらかじめ登録しておきたいものだからです。そうしておくだけでも、お客様自身の手で決済エラーを防ぐことを自然と促せます。

また、削除済みのカード情報は物理削除せず論理削除し、あとから自社システム内だけでも紐づく情報を追えるようにしておきましょう。とくにお金に関する情報は、問い合わせに対して「わかりません」では済まされない場面が多くあります。 かといって、リスク管理の観点から、お客様のカード番号やセキュリティコードそのものを自社DB内に保持しておくわけにもいきませんし、そもそも入手できないことがしばしばです。多くは決済代行サービスのAPIを利用するでしょうから、そこで発行されるカードIDなどを保持するにとどめておきましょう。

最後に、クレジットカードのような他のカード種別であるデビットカードやプリペイドカードについてどう扱うべきかも検討しておく必要があります。多くの場合は決済代行サービスのAPIを利用してカード種別を判定できるのですが、じつはこれは万能ではなく、代行サービスから「不明」と返ってくることがあります。どうしてもクレジットカードだけに限定したかったとしても実現できない場合もあることを確認しておきましょう。それに関連して、クレジットカード登録時には、与信情報の確認として1円や10円で決済して即座にキャンセルするという実装がよくあると思います。しかしカードによっては決済時にお客様に通知が飛ぶことがあり、それがお問い合わせにつながることもあります。デビットカードやプリペイドカードについては最低決済可能金額が設定されていて、1円や10円では引き落とせないこともあります。また、とくにプリペイドカードに関しては引き落としのキャンセルができないこともあります。カード種別による実装の分岐が必要になるでしょう。

キャリア決済

定期的な支払いを携帯通信会社の提供する決済手段を利用して行えるようにする施策です。クレジットカード等を持っていない層にリーチすることができるようになります。

考慮すべき点としては、自社システムでのサービス提供が確定されるタイミング（場合によってはお客様ごとに異なる）と、キャリア決済でのお客様への課金が行われるタイミングのズレがあります。

たとえば月次で提供するサブスクモデルサービスで、毎月25日に商品の発送が行われ、キャリア決済が26日に課金されるものだった場合には、26日の課金分を当月ではなく来月の商品発送に充てる必要が出てきます。

また、お客様自身の手で月次のスキップ（後述）が行えるタイプのサービスの場合にはさらに複雑で、スキップが行われたタイミングとキャリア決済の課金タイミングによっては、キャリア決済の課金をキャンセルする必要が出てきます。またその場合、キャリア決済の再課金はできないため、スキップの取り消しはできません。 さらにキャリア決済もまたお客様に通知が飛ぶ場合があるので、課金操作やキャンセル操作はたとえそれが障害対応のためだったとしても、サービスそのものへの不信につながるおそれがあり慎重になるべきです。

さらに、キャリア決済の多くは月次支払いのため、週次でのサブスクモデルサービスとは決済タイミングが合ないことから、さらに考慮点が増えてしまいます。

こういったことからキャリア決済は、スキップができないサブスクモデルサービスを基本としつつ、基本から離れることによる実装の複雑さを許容するかどうかによって、導入するかどうかを慎重に検討したほうが良いでしょう。

無料お試し期間

多くは限定された期間内において、支払いを行っていないお客様へもサービスを提供する施策です。無料期間が過ぎても、気に入ってくれたお客様は支払手段を登録してくれるかもしれません。

考慮すべき点としては、そもそもサービスの提供の確定と決済の確定とをイコールの関係にしないこと（受注情報のモデルと決済情報のモデルとを密結合にしないこと）、お客様が支払い方法の情報を必ず登録していることを前提とした実装を行わないことです。

具体的には筆者の場合、サービスの提供の確定を行うための引換券という概念を導入しました。毎周期（毎月や毎週）ごとにサービスの提供タイミングでお客様の持つ引換券が消費されるようにします。そのタイミングで引換券が0だった場合には、支払い方法が登録されていればそれを使って課金を行うことで、引換券を補充します。

このように、間に別の概念を導入して支払いとサービス提供とを疎結合にしておけば、引換券を付与するだけで無料お試し期間を追加することができるようになります（フロント側には会員登録時の支払い方法登録画面をスキップできるようにする対応なども必要ではありますが）。

受け取り方に関するもの

スキップ

定期的なサービス提供のうち将来のものについて、指定してスキップできるようにする施策です。たとえばマイページからお客様自身で将来の受け取り予定一覧から選んでスキップを行う、というようなものです。その回の分の課金は行われませんし、お客様へのサービスも提供されません。

考慮点としては、「スキップされている」という情報の持ち方と、スキップへの切り替えを許容する期間、継続期間の計測方法です。

筆者の場合は、月次のサービス提供を管理するモデル（受注）のステータスに「スキップされた（skipped）」を追加して管理することにしました。この場合、以後のフローでは「skipped」なモデルを除外して扱う必要があります。サービス提供の可否を判定する際には、有効なサービス提供の情報があるかどうかで判定することになるでしょう。あるいは「スキップ」を表すモデルで管理するようにしても良いかもしれません。

サービス提供の方法によっては、スキップへの切り替えは特定のタイミングで禁止されるべきです。いずれのタイミングにするかについては、業務フローと密接に関係していることでしょう。

継続期間（LTV）の計測において、スキップをどのように集計すべきかも考慮しておくべきです。スキップありでの値となしでの値の両方を出す必要があるかもしれません。

お届け先の変更

実際に商品を届けるタイプのサービス提供を行う場合、「この月には実家に帰ってるからそちらに送って欲しい」などのニーズが発生します。その場合、特定の回の提供についてのみお届け先住所を変更する必要があります。

こういった要望に対応するための方法として、発送作業者への申し送り事項欄を設けておいてそこに記入しておくという方法もありますが、フェイルプルーフのためには、毎回の発送先をお客様情報とは別にそれぞれ保持しておくべきでしょう。実際に筆者はそうしました。

さらに、ひとつ上の「スキップ」を実現するためにも、未確定状態の月次サービス提供モデル（受注）をつねに1年先まで用意しておくことにしました。これで1年先までの受注についてスキップしたり、個別の受注の宛先住所を変更したりすることができます。

しかし問題が発生しました。受注作成時点でお客様情報の住所を宛先住所に入れていたため、マイページからお客様が住所変更を行った際、未来の受注の住所をすべて変更しなければならなくなったのです。では住所変更に連動して、受注の宛先住所も一括で変更しましょう。……でも待ってください。その中にはあえて変更してあるお届け先住所も含まれているのです。

そういうわけでこの設計を採用する場合には、未確定の受注作成時点では宛先住所を埋めず、確定時点でお客様情報の住所を宛先住所に設定すべきです。もちろん、未確定時点で宛先住所が埋まっている場合には、上書きしません。

商品種別に関するもの

不定期発送商品

定期的な商品発送とは別に、不定期な発送を行いたい場合があります。毎月25日発送だったとしても、2月には14日に間に合うよう12日には発送したいかもしれませんし、12月には25日に手元にほしいのに、25日発送では遅すぎます。

この施策は業務フローへの変更も大きいため、システム設計側からの「とにかくこうすれば良い」という方法がない種類の問題です。考慮すべきは、サービス提供に関わるスケジュールの日数がすべて可変であったとしても、お客様の操作、バッチ処理、外部決済サービス側の動き、自社側の作業などが順番通りに動くようにすることです。これらについてのタイムスケジュールを一覧にしておき、発送日を変更することによる各部分への影響を逆算して考えられるようにしておきましょう。各工程のカウンターパートを巻き込んだ打ち合わせも必須です。

自由選択商品

基本的におまかせで届く商品の内容を、ある程度自分で決められる施策です。商品選択の責任をお客様自身が担うことで、「希望の商品が届かなかった」というお問い合わせが減ることが期待できます。

システムの設計の例としては、受注に紐づくモデルとしての発送と、さらに発送に1対多で紐づく商品マスタデータとの中間モデルという形があります。中間テーブルの商品マスタIDは null を許容しておき、「未決定だが何か入れる必要がある」ことが表現できるようにします。こうしておくことで、いざ商品を割り当てるとなったときに商品マスタIDが null になっているものについて機械的に商品を設定すれば良いのです。あとから見て手動で設定されたのか自動的に割り当てたのかを判別するために、 type_to_set_item のような値を追加して auto set_by_user のようなenumで管理すれば良いでしょう。

UXや事業的な考慮点としては、「事業的に見て本当に顧客に商品を自由に設定してもらいたいのか」ということです。自由に設定できるようにすることと、それを促すことは別です。サブスクモデルでサービスを展開しているからには、そこで提供するサービスの種類が増えることは、仕入れや人的なコストに直接影響があります。 もし本当は自由に選んでほしくないのであれば、顧客に提供する自由の範囲を絞ったり、一部ユーザーに限定したり、「おすすめ」を表示したりすることで、自由選択の機会を減らしましょう（ややEvilですね）。

「本当に自由に設定してもらいたい」？ であれば何も問題ありません。

価格の異なる複数のサービスタイプ

たとえば月々100円のライトプランと1,200円のプレミアムプランを用意しておいて、それらを任意のタイミングで切り替えることを許容するなどの施策により、お客様が定期的に支払う決済金額が変動するものです。

考慮点は、利用可能な決済手段で金額を都度変更することができるかどうかです。たとえば前述のキャリア決済では、一度解除しなければ金額を変更することができません。また、タイミングによっては当月分の支払いが完了してしまっているので、キャンセルの考慮が必要になる場合がありますが、キャンセルしてから再度決済登録を行った場合の次回決済タイミングについても確認が必要です。

決済手段に応じてプラン変更のタイミングを制限するのもひとつの手でしょう。親切のために、決済手段登録時に案内しておきましょう。

購入方法に関するもの

複数購入

実際に商品を送るタイプのサブスクモデルサービスでは、一人のお客様が複数の商品を購入することがドメインの構造的には可能で、筆者の関わっていたプロダクトの場合でも実際にそういう要件がありました。

設計上は、お客様と定期購入のモデルが1対多で紐付けられる構造になっていれば問題ありません。

ただし、上記の「価格の異なる複数の〜」と同じ問題に突き当たります。つまり、キャリア決済では決済金額の途中変更ができないため、お客様の定期購入の数の増減によって、キャリア決済の解除と再登録が必要になります。複数購入できるのは新規登録時だけとしてしまって一部のキャンセルはできないようにするとか、決済手段に応じた制限を設けるとか、類似した対応が必要になるでしょう。

一括購入

3ヶ月分、半年分、1年分などで決済を一括で行う施策です。

もうおわかりだと思いますが、キャリア決済との相性はよくありません。本来支払いの発生しない月の決済をキャンセルするなどで無理やり実装することは可能ですが、一時的にお客様の決済利用枠を占有してしまいますし、通知が飛んでしまうこともあるでしょう。

設計上は、先述した引換券の仕組みを使えば実現可能です。まとめて支払われた周期ぶんの引換券を発行し、お客様に紐づけます。引換券がある間の決済処理は行われません。途中でスキップが行われたとしても、引換券が消費されなければ決済処理が先延ばしにできるので、同様に問題ありません。

後払い購入

後払いでの定期購入契約を行う施策です。支払手段の登録を後回しにできるため、お客様の会員登録フローを短縮し、成約率（CVR）を向上することが期待できます。

これも「無料お試し期間」と同様に、支払い方法の情報とお客様の情報とを疎結合にしておけば問題なく実装可能でしょう。

というわけで

サブスクモデルサービスの設計で考慮すべき施策の例でした。一口にサブスクと言っても内容は千差万別で面白いですね。

もしあなたが設計担当者なら、「たとえ今は要望されていなくても今後はあるかもしれない」ということを検討し、ある程度柔軟な設計にしておくと幸せになれると思います。施策会議などの場において気をつけるべきワードTOP3は以下です。

• スキップ
• キャリア決済
• 特別便、スペシャル便、不定期便、などの「不定期発送商品」を指す類語

これらのワードが出てきたら「ちょっと待った！」と声をかけ、既存の実装に無理なく盛り込めるかどうか、特に慎重な検討が必要になるでしょう。

補足：キャリア決済に関する情報をアップデートしていないので、もし陳腐化している問題があったらごめんなさい。

おしまい。