サブスク新規事業のシステム開発｜先に決める6つのこと
サブスクリプション（定額課金で継続的にサービスを提供する形態）を新規事業で始めるときは、画面や機能の前に、お金と契約の扱い方を決めておくと手戻りが減ります。この記事では、サブスクのシステム開発で先に決めておきたい6つのことと、決めきれない部分を動くプロトタイプで確かめる進め方を整理します。
サブスクは「作ってから考える」と手戻りが大きい
サブスクは、一度きりの販売と違って、契約が続くことを前提にしたビジネスです。売った瞬間で取引が終わらず、翌月も、その次の月も、お金と契約の状態が動き続けます。システムの側から見ると、次のような処理が常に動いていることになります。
- 毎回の課金と、その結果の記録
- 更新日の管理
- プラン変更や解約の受け付け
- 支払いに失敗したときの対応
これらは、後から付け足すのが難しい部分です。課金のしくみは、会員データや画面、管理画面、問い合わせ対応の流れとつながっているためです。たとえば「月の途中でプランを変えたら料金はどう計算するか」が決まっていない状態で開発を進めると、会員データの持ち方まで作り直しになることがあります。
もうひとつ、サブスクならではの事情があります。新規事業の段階では、価格も、プランの数も、お試し期間の有無も、まだ仮説にすぎません。仮説を検証するたびにシステムを大きく作り直すのでは、事業の判断が遅れてしまいます。
そこで大切になるのが、次の2つを分けて考えることです。
- 先に決めておかないと作り直しになること（お金と契約の骨格）
- 後から変えてよいこと（価格の数字、画面の文言、プランの名前など）
骨格を先に固め、変えられる部分は変えやすく作っておく。この整理が、サブスクを新規事業として始めるときの出発点になります。
先に決めておきたい6つのこと
1. 何に対して課金するか（課金単位とプラン）
最初に決めたいのは、「お客様は何に対してお金を払い続けるのか」です。課金単位には、たとえば次のような形があります。
- 利用者の人数（1人あたり、1アカウントあたり）
- 利用量（件数、容量、利用時間など）
- 機能の範囲（基本プランと上位プランなど）
- 定期的に届く商品やサービスそのもの
課金単位は、データの持ち方に直結します。利用量に応じて課金するなら、利用量を正確に記録し続けるしくみが要ります。人数課金なら、アカウントの追加や削除が料金にどう反映されるかを決める必要があります。
ここで気をつけたいのは、最初から複数のプランを用意しすぎないことです。プランが増えるほど、プラン変更の組み合わせが増え、計算のルールも増えます。新規事業の最初の版では、プランを1つか2つに絞り、反応を見てから増やす進め方のほうが、確かめやすくなります。
機能の絞り方の考え方は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準でも整理しています。
2. 契約の状態をどう定義するか
サブスクのシステムの中心にあるのは「契約の状態」です。画面や機能はこの状態をもとに動くので、状態の種類を先に言葉にしておきます。たとえば次のような状態が考えられます。
- お試し中
- 契約中
- 支払いに失敗している（猶予期間中）
- 解約手続き済みで、期間の終わりまで利用できる
- 解約済み
- 休止中
そのうえで、「どの状態のときに、何ができるか」を決めます。解約手続きをした人は、いつまで利用できるのか。支払いに失敗した人は、すぐに使えなくなるのか、猶予があるのか。こうした決めごとは、契約の状態と機能の利用可否を結ぶ表にしておくと、関係者の間で認識を合わせやすくなります。
決めておかないと、開発の途中で「この場合はどうするのか」という質問が次々に出てきます。そのたびに判断が必要になり、進行が止まります。状態の一覧は、要件定義の中でも抜け漏れが出やすい部分です。要件定義の進め方については、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方が参考になります。
3. 更新・変更・解約・支払い失敗のルール
契約の状態を決めたら、状態が変わる場面のルールを決めます。サブスクでは、次の場面が検討の中心になります。
更新のタイミング
- 課金日は、申し込んだ日にそろえるのか、月初にそろえるのか
- 月末日に申し込んだ場合、翌月の課金日はどうなるのか
プラン変更
- 上位プランへの変更は、すぐ反映するのか、次回更新からなのか
- 月の途中で変更したときの差額を、日割りで計算するのか
解約
- 解約の申し込みは、利用者自身が画面から行えるのか
- 解約後、いつまで利用でき、データはどのくらい保管するのか
支払い失敗
- カードの有効期限切れや残高不足で決済が失敗したとき、再請求を何回、どの間隔で行うのか
- 利用者への連絡は、メールで行うのか
このなかで、とくに新規事業の立ち上げ時に後回しにされやすいのが、解約と支払い失敗です。契約を増やす流れから考え始めるため、終わらせる流れの優先度が下がります。しかし、解約の流れが分かりにくいと、問い合わせの増加につながります。支払い失敗への対応が弱いと、本来は続くはずだった契約が途切れてしまいます。
また、解約方法や契約条件の表示の仕方には、法令上の決まりもあります。通信販売で定期的な契約を扱う場合は、特定商取引法に基づく表示や、申し込み前の確認画面の作り方などを確認しておく必要があります。画面の設計にも影響するため、開発を進める前に、専門家や所管官庁（消費者庁）の公開情報で最新の内容を確認しておくと安心です。
4. 決済と請求を、どこまで外部に任せるか
継続課金の処理を、自社で一から作るのか、外部の決済サービスに任せるのか。この判断は、開発の量とリスクの両方に大きく影響します。
一般的には、カード情報を自社のサーバーに保持しない方針（非保持化）をとり、継続課金の機能を持つ外部の決済サービスを使う形が主流です。カード情報の管理には高い安全性が求められ、自社で抱えるほど責任と負担が重くなるためです。
ただし、外部サービスに任せる場合でも、決めることは残ります。
- 外部サービス側で管理する情報と、自社のデータベースで持つ情報の分け方
- 外部サービスから届く「決済成功」「決済失敗」「解約」といった通知を、自社のシステムにどう反映するか
- 外部サービスが対応できない料金体系を、自社でどう補うか
- 将来、別のサービスに切り替える可能性をどう考えるか
とくに「自社の契約状態」と「決済サービス側の状態」がずれないようにするしくみは、サブスクの品質を左右します。決済の分け方の考え方は、新規事業の決済システム開発｜外部サービスと自作の分け方で詳しく扱っています。
5. 運用する側の画面と業務の流れ
サブスクは、始めてからの運用が長く続きます。利用者向けの画面だけでなく、運用する側が使う管理画面も、最初に考えておきたい対象です。たとえば次のような作業が日常的に発生します。
- 契約状況の確認（どのお客様が、どのプランで、どの状態か）
- 問い合わせへの対応（請求内容の確認、解約の相談など）
- 返金や、個別の料金調整
- 支払い失敗のお客様への連絡
- 売上や契約数の集計
管理画面を最初から充実させる必要はありません。ただ、「運用で何をするのか」を書き出しておかないと、問い合わせが来たときに、データベースを直接見ないと答えられない状態になりがちです。最初は、契約状況の確認と、最低限の操作だけに絞ります。
管理画面で最初に作る範囲の見極め方は、新規事業の管理画面開発｜最初に作る範囲の見極め方にまとめています。
6. 事業として見る数字（検証指標）
サブスクの新規事業では、「契約が何件入ったか」だけでは、事業の健康状態を判断できません。継続して使われているかを示す数字が必要になります。一般的に、次のような指標がよく使われます。
- 解約率（チャーンレート）：一定期間に解約した割合
- 継続率：契約を続けている割合
- お試しから本契約への移行率
- 1契約あたりの月間の売上
- 利用の頻度（契約はしているが使われていない状態を見つけるため）
大切なのは、これらの数字を「あとで出せるようにする」のではなく、「最初から記録しておく」ことです。解約の理由や、利用の記録、契約状態が変わった日付は、あとから取り直せません。何を見て事業の継続を判断するのかを決めたうえで、そのために必要なデータをシステムが残すように作ります。
指標の決め方については、MVP検証の指標を先に決める方法｜判断基準の作り方が役に立ちます。
決めきれないことは、動くプロトタイプで確かめる
ここまで6つのことを挙げましたが、新規事業の初期に、すべてを机の上で決め切るのは現実的ではありません。そもそも、お客様がどのプランを選ぶのか、お試し期間があれば申し込みやすくなるのかは、やってみないと分からない部分だからです。
そこで有効なのが、動くプロトタイプ（実際に操作できる試作品）で確かめる進め方です。企画書や画面の絵だけでは、次のような点が見えにくいものです。
- 申し込みから契約までの流れが、利用者にとって分かりやすいか
- 解約の導線が、不親切に感じられないか
- 運用する側にとって、契約状況の確認が負担にならないか
- 決済で失敗したときの案内が、利用者に伝わるか
実物を触りながら「ここはこう変えたい」と指摘できると、言葉だけで要件を決めたときの認識違いを早い段階で見つけられます。経営陣と現場の間でも、同じ画面を見ながら話せるため、判断の材料がそろいます。プロトタイプの位置づけや、MVP・モックとの違いは、プロトタイプとMVP・モックの違いを整理｜新規事業の使い分けを参照してください。
動くものを見ながら確かめる進め方は、新規事業のアイデア検証方法｜動くシステムで確かめる手順でも紹介しています。小さく作って確かめ、結果を見てから次の投資を判断する考え方は、新規事業の開発は小さく作って確かめる投資判断の進め方にまとめています。
プロトタイプで確かめたい観点の例
サブスクの場合は、次のような観点を持ってプロトタイプを見ると、確認が漏れにくくなります。
- 申し込みから初回の課金まで、迷わず進めるか
- プラン変更や解約が、利用者自身で完結するか
- 支払い失敗のとき、利用者への案内と運用側の対応が成り立つか
- 運用側の画面で、問い合わせに答えるための情報が見られるか
- 事業判断に必要な数字が、データとして残っているか
最初の版に入れないものを決める
先に決めることが多いサブスクでは、最初の版に入れないものを決めることも大切です。何もかもを最初から作ろうとすると、開発の期間も、確認の量も増えてしまいます。後回しにしやすいものの例は次のとおりです。
- 多数のプランや、細かな割引の組み合わせ
- 法人向けの請求書払いや、複数拠点での一括契約
- 高度な分析画面（まずは必要な数字を書き出せれば十分なことが多い）
- 他システムとの細かな連携
後回しにするものは、「やらない」と決めたものではありません。「検証が進んでから判断する」と位置づけ、一覧にして残しておきます。仕様が変わったときの扱い方は、システム開発の仕様変更への対応｜追加要望の扱い方が参考になります。
また、サブスクを含むSaaS型の事業での最初の範囲の考え方は、SaaS新規事業の開発｜最初に作る範囲の決め方でも解説しています。
システムは、作って終わりではなく、事業の変化に合わせて育てていくものです。納品後の改善の考え方は、システムは納品後の改善で育てる｜新規事業の考え方で触れています。
まとめ
サブスクを新規事業で始めるとき、システムで先に決めておきたいことは、次の6つです。
- 何に対して課金するか（課金単位とプラン）
- 契約の状態をどう定義するか
- 更新・変更・解約・支払い失敗のルール
- 決済と請求を、どこまで外部に任せるか
- 運用する側の画面と業務の流れ
- 事業として見る数字（検証指標）
サブスクは、契約が続くことを前提にした事業なので、お金と契約の骨格を後から作り直すと、手戻りが大きくなります。一方で、価格の数字やプランの名前は、事業が動き出してから見直すことになります。骨格は先に決め、変えてよい部分は変えやすく作る。この切り分けが、新規事業としてサブスクを始めるときの基本になります。
そして、机の上で決め切れない部分は、動くプロトタイプで確かめるのが現実的です。実際に触れる形にすると、申し込みや解約の流れ、運用の負担、必要な数字が具体的に見えてきます。
JustFitは、構想をもとに約1ヶ月で、実際に動くプロトタイプを先に開発する受託開発サービスです。実物を見てから契約するかを判断でき、仕様が固まっていない段階や稟議の前の段階でも相談できます。サブスク型の新規事業で、どこまでを最初に作り、何を確かめるのかを整理したいときは、JustFitのサービス紹介もあわせてご覧ください。