サブスクリプション・システムの生活史
はじめに
この記事は、筆者が2018年から関わり続けているあるサブスクリプションモデルのサービス（詳細は後述）で、それを実現・継続するための運用やシステムがどのように変化していったかを述べ、さらにこの先にどのようなことが待っているのかを予測しようというものです。あくまで筆者の個人的な振り返りであり、その他のシステムにとって一般的でない内容を含む場合もありますが、参考にできる部分もあると思います。
サービスについて
筆者の関わっているサービスの概要は以下です。
- サービス開始は2016年ごろ
- 定期購入モデル
- 月に1度、商品4〜6品が詰められた箱が届く
- 商品の内容は、お客様の属性（性別やアレルギー情報、ご要望など）によって変わる
- 定期購入契約を解除せずに、商品を届けない月を選ぶことができる（お届けをスキップできる）
ここでは具体的に名前を出さず、仮に「フェノックス（以下、略称POX）」と呼ぶことにします。
POXの概略図
お客様にとっての流れ
※図はTBD
- 購入画面でPOXを注文する
- しばらくすると、1箱目が届く
- 箱を開けて楽しむ
- またしばらくすると、2箱目が届く
- 箱を開けて楽しむ
運用者にとっての流れ
※図はTBD
- POXを受注する
- 1箱目の発送を行う
- 継続した受注を作る
- 2箱目の発送を行う
POXの運用の流れ
上の図をそのまま書き出したようなものですが、大まかに以下の作業の流れによって、フェノックス（POX）は運用されています。
- 企画
- 商品の仕入れ
- （新規／継続）受注
- 決済完了
- 受注ごとに詰め込む商品を決める（商品割り当て）
- 商品箱詰め
- 発送
- お問い合わせ対応
- 会計処理
POXのこれまで
サービス開始から自社システム化まで（2016年〜2018年7月）
サービス開始当初、お客様からの受注は社内開発したシステムではなく、外部のカートシステムを利用していました。一部顧客情報の管理（個人情報以外）はGoogleSpreadSheet上で行い、社内に設置したNASに保存した個人情報と紐付けて、商品を発送していました。
つまりこういう状態でした。
※図はTBD
- 企画：なし
- 商品の仕入れ：GoogleSpreadSheetなど
- （新規／継続）受注：外部カートシステム
- 決済完了：外部カートシステム
- 受注ごとに詰め込む商品を決める：GoogleSpreadSheet
- 商品箱詰め：社内で手作業
- 発送：社内で手作業
- お問い合わせ対応：電話やメール
- 会計処理：GoogleSpreadSheet
初期には月間の出荷数が10箱未満の月もあり、これでも全く問題なく作業が行えていました。しかし、お客様や受注が少しずつ増えていくにつれて、GoogleSpreadSheetでの管理が厳しくなっていき、月間300箱を超える頃には、運用担当者（当初1名、その頃には2〜3名）の残業が常態化してしまっていました。
担当者が増えているにも関わらず作業時間がなかなか減少しないのは、受注ごとに箱の内容物を決定する「商品割り当て」の作業が、商品の在庫が共通であるために複数の人員で分担しづらく、また箱数に応じて純増していき、しかも割り当てに考慮する情報が多く複雑であることが理由です。最終的にこの作業は受注数が月6000件（！）になるまでSpreadSheet上で行われることになりましたが、その頃になるとひとつひとつの割り当てに対して連動する関数の処理に時間がかかりすぎ、もはやまともに作業が行えなくなっていました。
サービス開始から1年以上が経過した2018年4月ごろになり、月間の発送箱数が300件ほどになってきたころ、POXのさらなるサービス拡大という事業目標に対して、他社カートシステムのカスタマイズ性の低いカートシステムや、運用コストの大きさがふさわしくないことが認識されはじめ、5月には自社開発のシステムへ移行が検討されました。
自社システム化検討期（2018年5〜6月）
先述の理由から進められてきた自社システム化の検討ですが、この時期に考えられていたことには誤算もありました。
当時は「サービス開始当初は運用フローが決まっていなかったために、SpreadSheetと外部カートシステムの利用のほうが都合が良かった。しかしながらフローが固まってきたために、多少柔軟性を失ってでも自社システム化したほうが良い」と考えられていました。しかし、実際には自社システム化した後にも運用フローは大きく変化しています。それは、以下の理由によると思われます。
SpreadSheetと外部カート（と人力）の場合
- マーケティング施策は運用フローに直接影響する
- 運用フローはシステムの制限を受ける
- システムの制限がゆるければ、運用フローにもマーケティング施策にも課される制限がゆるくなる
- 運用フローは問題なく変化する
自社システムの場合
- マーケティング施策は運用フローに直接影響する
- 運用フローはシステムの制限を受ける
- システムの制限が比較的厳しく、運用フローにもマーケティング施策にも課される制限が厳しくなる
- しかしマーケティング施策の検討自体はシステム担当者不在のもとで（あるいはあえて考慮せずに）行われるため、システムの制約を受けない
- マーケティング施策に合わせたシステムの変更が検討される
- コストなどが見合うと判断されれば、むしろより柔軟なシステム変更が余儀なくされる
- 運用フローも変化する
ご覧の通り自社システム化することによって起こったことは、4番目の「マーケティング施策の検討はシステムの制約を受けない」ということが明らかになって、自社システムであることを理由にむしろより柔軟な変更を要求されるようになるということでした。むしろそうして柔軟な変更が行えるということが自社システム化のモチベーションでもあるため、考えてみれば当たり前の話です。
具体的にPOXの場合では、当初は月一回だけ行うとされていた箱の発送作業とそれに付随する割り当てなどの作業が、月に複数回行われるよう変化していきました。また、自社開発の商品が登場し、割り当て作業時などでの特別な取り扱いを要求されるようにもなっていきます。
つまり、自社システム化することで運用フローをある程度固定し効率化できる部分もある一方で、運用フローが完全に固定されることはありえず、その変化に合わせて、すでに実装された運用フローを変更するためのコストのほうが増えてしまうのでした。
これに対応し続けていくためには、外部サービスの使用・自社システムの開発に関わらず、受注や定期購入や商品などのモデルを、なるべく柔軟に取り扱える状態を用意し続けることが必要だろうと思います。変化のない事業などありえず、事業が変化していくのであれば、システムもまた変化していくしかないのです。
自社システムリリース（2018年7月〜12月）
自社システム化すると言っても、いきなりすべてが実装完了して、これまで使っていた道具が一気に入れ替わるというわけではありません。
自社システム化の目的は「カスタマイズ可能なカートシステム（＝新規顧客獲得）」と「運用コストの削減」でした。これらはまったく異なる目標であり、実装の対象も前者がお客様向けのWebアプリケーション、後者が運用者向けのそれと、まったく別物です。いずれかを選択するしかありません。そしてここで優先されたのは、「カスタマイズ可能なカートシステム」のほうでした。
その後、お客様側におよそ40日間、運用側（いわゆるオペ画面）に60日間をかけて並行した開発が行われ、それぞれ無事にリリースが行われました。ここで用意されたのは、いずれの実装もあくまで必要最低限を満たしたものであり、現実的には「頑張ればカスタマイズできないこともないカートシステム」と「最小限度の情報が見られるオペ画面」と呼ぶべきものでしたが、カスタマイズ性のほうはたしかに良くなっており、その後購入画面のABテストやその結果としての改修、お客様自身で契約の情報を確認する画面（マイページ）を充実させるための実装が行われることになります。
そしてそれが功を奏したのか、10月には月約1000箱、12月には月約2500箱が出荷されるまでに規模が拡大していきました。
※図はTBD
- 企画：なし
- 商品の仕入れ：GoogleSpreadSheetなど
- （新規／継続）受注：外部カートシステムと自社システム
- 決済完了：外部カートシステムと自社システム
- 受注ごとに詰め込む商品を決める：GoogleSpreadSheet
- 商品箱詰め：社内で手作業
- 発送：社内で手作業
- お問い合わせ対応：電話やメール
- 会計処理：GoogleSpreadSheet
しかし規模が拡大する一方で、運用コストもまた増大していました。カート部分を自社システム化したものの、外部のカートシステムで継続契約してくださっているお客様もそのまま残っていたため、運用担当者としては外部と自社との2つのシステムを使った作業を行う必要がありました。また、発送する箱数の増加にあわせて自然とお問い合わせの件数も増加しており、そちらに時間を奪われてしまうこともしばしばでした。
また、お客様側画面の改修とそれに伴う運用フローの変更に対してシステムの改修を行うにあたり、実装上の問題点に突き当たることが多かったのもこの時期でした。以下に具体例をふたつ挙げます。
密結合すぎる購入処理の実装
さきほど書いた通り、当初は箱の発送とそれに関わる作業とが月に1回行われると想定されていました。そのため、実装も当初は月1回の発送で固定されていました。また、購入時の情報入力の順番も一方通行で、非常に変更が入れづらい構造になっていました。
より具体的な実装は以下のようになっていました。
- Controllerクラスがリクエストを受け取る
OrderPresenterクラスをnewしただけで、お客様の登録が完了して与信が取られて契約が完了してしまうのです。それはつまり、newするためにそれらの処理が要求する情報をすべて用意する必要があるということでもあります。
業務フローが固定的であればそれでも（まあギリギリ…）許容できなくもないのですが、固定的でない現実を前にこれではあまりにも密結合すぎました。また、決済処理モデルクラスが受注の情報を直接書き換えるようになっていることも、責任範囲を明らかに逸脱しています。
ということで、Presenterとして実装するには違和感がありすぎたこともあり、OrderPresenterクラスは廃止して、Controllerがビジネスロジックを表現する実装に変更しました。また、決済処理モデルクラスの行っていた責任範囲の逸脱も是正されました。ここは購入という重要な機能だということで、実装工数がかかったことももちろんですが、検証にも多くの時間がかけられました。
購入画面は文字通り購入に直接影響するため、マーケティング施策の都合から大きめの変更が入る可能性が非常に高い箇所です。高い可用性を確保しておきましょう。
ところで、Presenterは本来こういう任意のビジネスロジックを表現するための実装パターンではありません。もし何らかの理由から購入処理をControllerクラスに書きたくない場合には、Concernsに逃がすのが良いのでしょうか。今のところその必要性は感じていません。
確定受注と未確定受注の存在
POXは、受け取らない回を選ぶことのできる（スキップのできる）定期購入です。それを実現するため、契約時内部では初回の確定している受注と、その後に続く未確定な受注を作成するようになっています。未確定な受注にはそれぞれ発送日が決められており、発送日にもとづいた締日に未確定受注は確定受注へと切り替わります。基本的に未確定受注の情報についてはお客様自身で変更することができますが、確定受注の情報はすでに発送作業に入っている可能性があるため、変更することができません（お問い合わせでの対応はできます）。
そんな未確定受注は、当初の意図通りにスキップ受注を表現することに使われています。また、受注は宛先住所などの情報も持っているため、一部の回だけ別の住所にお届けすることもできるようになります（年末は実家に帰っているのでそちらへお願いしますなどの要望がある）。さらに、スキップ分を含めた受注を数えるときなどの実装がシンプルになります。
しかし、むしろ未確定受注にはデメリットのほうが多くありました。実装する人にとってもお客様にとっても、仕様が複雑になりすぎるのです。
たとえばお客様が配送先住所を変更した場合に、未確定の受注については一緒に変更されていても、確定済みの受注は変更されず、変更前の住所に届いてしまいます。確定済み受注があることを強調して画面で伝えたとしても、実際にはそういった文言はあまり注意して見てもらえません。結果としてお客様の意図しない宛先に発送されてしまい、お問い合わせにつながってしまいます。
この宛先の情報が定期購入と受注とに分かれているのですが、未確定受注の情報は定期購入と連動して変更されるべきである一方で、確定受注の情報は変更しても大丈夫な場合と、変更してはいけない場合とがあり、実装者にとって大きな混乱のもととなりました。とはいえ冗長的に情報を持っていることはメリットとなる場合もあり、かんたんに切り捨てることもできずに残っています。
これに関してはあまり良い解決策が思い浮かびません。未確定受注という実装を活かしきれていないのかもしれません。
決済手段の追加と運用限界（2019年1月〜2月）
自社システム化から半年近くが経ちましたが、まだ運用コストの増大が本格的に顧みられることはなく、購入者数の増加を意図した施策が採られ続けました。「初回後払い購入」と「キャリア決済」の導入です。
まず「初回後払い購入」とは、初めてPOXを購入する人に限り決済情報の入力を後回しにして、まず購入を確定するという施策です。1つ目の定期購入が未決済のときに2つ目を購入しようとすると、決済情報の入力を促されて購入をすすめることができなくなります。また当初は、決済情報の入力がされていなくても1つ目の定期購入の1箱目のPOXを送付し、2箱目以降については締日に決済情報を確認してから送付するかしないかを決定するという流れになっていました。これは後に見直され、1箱目についても決済が完了していなければ発送しないようになりました。それでも8割を超えるお客様が決済を完了してくださっており、問題とはなっていません。
続いて実装された「キャリア決済」とは、ドコモ払い・auかんたん決済・ソフトバンクまとめて支払いでの決済が行えるようにする機能です。実装当初はじつは懐疑的だったものの（筆者はほとんど使ったことがなかったもので…）、現在は全お客様のうち3割以上が利用してくださっており、結果的にやってよかった施策でした。
ただ、キャリア決済は非常にコントロールするのが難しい性質のものでもありました。例えば決済対象の月と発送回数とが一致しない問題があります。キャリア決済では継続利用が始まった月からお支払いが発生するので、継続利用を開始した月に初回の発送がある場合（例：12月1〜10日までが受付期間で、25日に発送が行われる）では問題にならないのですが、継続利用を開始した次の月に初回の発送がある場合（例：11月26日〜12月5日までが受付期間で、12月25日に発送が行われる場合の、11月26〜30日にキャリア決済で購入された場合）には、開始月と翌月の2回の決済が行われた後に初回の発送が行われることになってしまいます。
問題ない場合
- 12月2日に購入（12月分の支払いが発生） → 12月25日発送分に当たる
問題ある場合
- 11月26日に購入（11月分の支払いが発生）
- 12月分の支払いが発生 → 12月25日発送分に当たる
このような二重決済を防ぐため、現在は一度行われた決済を取り消す処理を行っていますが、仕組みとして無理やりな感じは否めません。運用上でも実装上でも障害対応中にも常に「どの決済がどの受注分なのか」を意識しながら対応を行う必要があり、複雑さが足かせとなってしまっています。
また、先述の通りPOXは受注をスキップすることもできるので、対応する受注分の継続決済も取り消す必要があります。お客様の決済に関わる箇所ということが、さらにシビアな対応を要求してきます。利用者の割合が大きく実りの多い施策ではありますが、安易な気持ちでは手を出さないほうが良いと思います。
さらに注意点として、キャリア決済は、サブスクリプションモデルにありがちな一括購入（最初に一括で半年分や一年分の利用料を支払ってもらうことで、値下げを行いつつ継続率を上げる施策）との相性が非常に悪いということも留意しておくべきでしょう。各キャリアの継続決済では、初回に一括で支払って一定月間請求しないということができないはずです。
一定期間の請求を取り消すこともたしかにできますが、取り消す前に一度請求がかかってしまうため、一時的なお客様の負担が大きくなってしまいます。予期しない請求にお問い合わせも増加することでしょう。一括支払い分を分割して継続請求していくこともできますが（それはもはや一括購入なのかと思いますが）、途中でお客様がキャリア側の継続利用契約を解除することができるため、結果的に割安で購入されてしまうリスクが生まれてしまいます。一括購入は、キャリア決済では行えないようにするのが良いでしょう。
さて、立て続けに採られてきた購入者数増加施策の結果、この頃には月間の発送数が5000箱を越え、これまでGoogleSpreadSheetで行ってきた発送に関わる作業に本格的に限界が見えてきました。ここに来てようやく運用コスト削減が意識され始めました。
商品割り当て作業のシステム化（2019年3月〜10月）
運用コストのうちの大半を締めていた発送関連の作業は、以下の流れで行われていました。
- 受注の情報を集めてくる（自社システム、外部カートシステム、その他）
- 発送作業に使用する商品を決定する
- 各受注に商品を割り当てる
- 箱詰め作業
- 発送作業
- 発送伝票番号の取得
中でも商品の割り当ては、各受注の詳細情報（コース種別、アレルギー、要望など）を考慮しながら行うもので、すべてを機械的に割り振るのが難しい部分でした。とはいえ9割方の受注についてはパターンに当てはめられるものだったので、残り1割は人間の作業として割り切ってしまい、半自動的な商品割り当て機能を目標に実装を進めることにしました。
そうなると当然ながら、割り当てに使用する商品と在庫状況の管理も自社システムで行わなければなりません。また在庫を共有している都合上、外部カートシステムの受注もCSV形式で自社システムへ取り込む必要が出てきます。まずはそこからということで地道に実装していき、やがて4ヶ月後の7月ごろには自動商品割り当てロジック、手動で割り当てを行う画面、発送作業用CSVの出力機能などが出揃ったことで、少しずつ作業担当者の残業時間も削減されていきました。
こうして当初の目論見は果たされたわけですが、ついでに嬉しい効果もありました。実装上、受注とその情報を持った別のモデル（「発送」と呼んでいるもの）を用意していたのですが、受注情報から発送を作成することで、「この受注はすでに発送作業に入っている」という意味合いを与えてやることができました。また、有効な全受注を対象に作業を行わず、作成された発送モデルだけを対象に作業を行えばいいので、予期せぬ情報の更新（お客様によるマイページでの変更など）が起こることもありません。さらに作業を行うタイミングで新規作成しているため、作成時期ごとに分割してCSV出力してやることで、実際の発送作業側への依頼を分割して出すことも可能になりました。この頃には外部の倉庫会社へ梱包作業を委託していたのですが、「いっぺんに1万件の依頼が来るよりも、分割して少しずつ依頼をかけてくれたほうが嬉しい」といった要望に応えやすい構造になっていました。
ともあれ、こうしてPOXの発送作業は今や月間3万箱の発送に耐えるものとなったのです。
- 企画：GoogleSpreadSheetなど（自社オリジナル商品の企画）
- 商品の仕入れ：GoogleSpreadSheetなど
- （新規／継続）受注：外部カートシステムと自社システム
- 決済完了：外部カートシステムと自社システム
- 受注ごとに詰め込む商品を決める：自社システム
- 商品箱詰め：外部倉庫に依頼
- 発送：外部倉庫に依頼
- お問い合わせ対応：自社システムの問い合わせフォームと電話、メール
- 会計処理：自社システム出力のCSVとGoogleSpreadSheet
実装の効率化とお掃除の期間（2019年11月〜）
さてここまでで、運用フローはかなりの部分が自社システムで締められるようになってきました。残るは企画、仕入れ、お問い合わせ対応、そして会計です。このうち、発送箱数の増加に比例して作業が大幅に増加するのはお問い合わせ対応です。また、少しの工夫で大きな効果が出やすいのも、お問い合わせにつながってしまうようなわかりにくさの改善でした。2019年の11月から年末にかけては、こういった細部の改修や、今まで細やかに対応できてこなかったアラート、あるいはインフラ面での心配事などに（やっと）工数を割くことができました。
運用担当者が、発送作業にかかる工数がある程度減少したことで、現状を冷静に分析できるようになってきたのもこの頃からです。そういったモチベーションを支え続けるために、お客様の行動やお問い合わせの内容に関する情報を提供することも、運用改善のために重要なシステム側の対応として行うことができました。それ以前にも情報を出すことはあったのですが、ほか作業で手一杯の忙しいときに情報を出されても、考える時間を持てないのは残念ながら当たり前ですよね…。
ともあれ、次の運用改善やシステム改修に向けた準備期間を、自社システム化から1年半が経ったここにきてやっと、しっかりと持つことができたのでした。
そのほかPOXでやってきたこと
歴史を振り返ったところで、その他にやってよかったことなどを紹介していきます。
やってよかったこと
FAQページの充実
当たり前の話ですが、FAQページが救うことができるのは、FAQページを見てくれるお客様だけです。たまに喧嘩腰でのお問い合わせをされるお客様もいます。しかし、そういった方々の中にも、FAQがあればそちらを見てくださる人がいます。FAQページには、そういった人たちが喧嘩腰になるのを防ぐ効果があります。
また、お問い合わせを受けた際に「FAQページのこちらの内容になっておりまして…」という案内を出すようにして、対応をある程度パターン化することもできます。こうすることで対応工数を減らすことができ、さらに対応のサイクルが見えることで改善の糸口を掴むことにもつながります。
このように良いことずくめなので、FAQページはぜひ用意しましょう。
お問い合わせページ
お問い合わせページを自社ドメイン内に持つこともまた重要です。外部アンケートフォームや自社ポータルの問い合わせフォームを利用しても良いのですが、そちらではお客様や定期購入の情報と、お問い合わせとを紐付けることが難しくなります。定期購入などのIDをお客様に入力してもらうこともできますが、とくにお怒りであるお客様は、入力してくださらないことのほうが多いでしょう。もし入力してくださったとしても、番号を自社システムのOPEで検索する必要があります。それよりは、最初からお客様のお問い合わせ情報から直接リンクされていることのほうが、毎回のお問い合わせ対応の手間は減るはずです。
大きな手間でもないので、ぜひお問い合わせページも個別に用意したいですね。
操作ログ
お客様や運用作業者が、定期購入や受注などの情報をいつどこから変更したのかという情報は、お問い合わせ対応の担当者から要望されることが多いものです。実際、お客様が自身で変更したことを忘れてしまってお問い合わせをいただくこともしばしばあります。そういった場合に「システムのほうで記録が残っておりまして」という言葉は非常に強力なキラーワードとなるようです。そしてそれを言うためには、「誰がいつどこで操作したのか」の記録は閲覧できるようにしておく必要があります。
とはいえ、そのときのたった1件（としかエンジニアからは見えない）のために、全顧客の全操作をログに残すのはナンセンスだなあ、とエンジニアは考えがちです。筆者もそう考えていました。
しかし実際に実装してみると、払った工数に対してお問い合わせ対応の時間削減効果は多大でした。またそれ以外に、お客様の行動が記録されているということは、マーケティング担当者にとっても有意義なことだったようで、システムが送信しているメールのログと一緒に閲覧できる画面を用意してあげることで、メール受信が与えるお客様への影響を測ることができるようになりました。また、障害対応を行う際の材料として、エンジニアが利用することもあります。
ということで見た目には地味ですが、一石三鳥の効果を持つのが操作ログでした。これにはまだまだ利用シーンがありそうな気がします。
処理の非同期化
sidekiq や delayed_jobs で行う背後処理の実装は当初はありませんでしたが、最終的にOPE画面にとっては必須のものとなりました。たとえば受注などの情報を出力する際に、その件数が増えてくるとどうしてもタイムアウトしてしまうようになります。制限秒数の上限を延ばしたとしても、それは一時的な対応にしかなりません。素直に背後処理にしてしまうのが良いでしょう。
背後処理にしてしまうと、いつ何が始まって終わったのかがわかりにくくなってしまいます。そのため、POXでは運用担当者のチャンネルに背後処理の開始終了を連絡するbotを追加しました。こうすることで、操作を行った人がフィードバックを受け取れるようになり、安心感につながります。また、なかなか開始しない背後処理について自主的に気づき、システム担当者へ連絡してくださるようにもなりました。システム担当者が自分でそれに気づくこともあります。
背後処理の実装時には、ぜひSlackなどへの通知もあわせて追加してみてください。
未だにできていないこと
できていなくてもまだなんとかやってこれていること。
テストの充実
めちゃくちゃ怒られそうですが（誰から？）、POXには、クリティカルな部分以外のユニットテストが存在しません。しかし、コード量の増加に伴ってそのことによる弊害が増えてきたのもまた事実です。やっと守りの対応ができている今の時期に、思い切ってユニットテストを追加していくべきなんだと思っています。
ブラウザでの自動テストもまた存在していません。こちらは開発に並行して改修し続ける運用を回せる未来が見えていないために、2020年も着手できない気がしています。重要性はわかってはいるんですが…。
会計系機能
こちらに関しても、発送した箱の数や各商品の在庫数をCSV形式で出力する機能だけにとどまっています。
まとめ
いかがでしたか？ サブスクリプションモデルのシステム開発の一例をご紹介しました。じつはこの記事は、社内のWikiに書き残した個人的な振り返りがベースになっています。公開用に書き直す上で細かいことや退屈な内容はなるべく記載しませんでしたが、そういったものも含め、何が必要で、何が必要でないのか、また何をやるべきで、何をやらないほうが良いのかを整理する意味でも、個人的には有意義な振り返りができたと思います。次に同じようなシステムを用意する際にはもっとうまくやれることでしょう。読んでくださった方の何らかの参考になれたなら幸いです。良い2020年にしましょう。それでは。
