はじめに
こんにちは。 STORES でエンジニアをやっている asibi3Q です。
週末は山に登って下界から離れる生活を送っています。
今回は去年1年を通して、STORES 予約の契約管理をサブスクリプション管理 SaaS である Zuora に移行した話について書きます。
移行の背景
STORES には多くのプロダクトが存在しますが、元々は別々の会社で作られたプロダクトで契約管理方法も異なります。 そのため、
- プロダクト毎に請求方法やオペレーションが異なることで、オペレーションコストや開発コストが大きい
- 請求業務の属人化と手作業の多さによる人的リソースの負担増加
といった運用上の課題が多くありました。
また将来的に契約管理を Zuora にまとめることで、それぞれのプロダクト毎に管理されていた契約を一元化し、1つの STORES のプランとして提供することを目指していました。
数あるプロダクトの中で STORES 予約を最初に Zuora へと移行した理由は、イレギュラー対応や数多くの契約体系、プラン・オプションが存在しており、複雑度が高かったためです。
課金基盤チーム
課金基盤チームはエンジニア5名・PM1名で構成されており、 STORES 予約の複雑な契約管理を AM・アドミニチームと連携しつつ主に下記の移行作業を実施しました。*1
- 別の請求管理SaaSで管理していた請求書払いの請求データ
- アプリケーション内で管理していた請求書払い・クレカ払いの契約情報
- 古くから存在する10以上のプラン・50以上のオプションのアプリケーションで管理する必要のない金額などの情報
- そのほか STORES 予約アプリケーション内で管理している課金情報や未払い情報
移行の登り方
Zuoraへの移行は
- 請求書払いの契約管理の移行
- クレカ払いの契約管理の移行
の順で進めていきました。
請求書払いから移行を進めた理由は
- クレカ払いの契約の方が圧倒的に多いため、請求書払いの方が条件に沿った段階的な移行が簡単なこと
- 万が一失敗しても元の状態に戻しやすいことで、リスクを最小限に抑えることが可能
- 少ない件数で段階的に検証しつつ試行できることもあるため、 Zuora 移行のノウハウを集めやすい
- 先述した元々利用していた別の請求管理 SaaS の契約期限が差し迫っていたこと
が主な要因となります。
データ移行を行いながら、アプリケーション内で管理していた契約管理周辺の関心事も Zuora へと移行していきました。
移行中であっても新規契約は増えていくため、新規分に関しては最初から Zuora で契約管理がされるようにしました。
スケジュールが後ろになるにつれて、対応内容が増えているように見えますが、 Zuora の操作に慣れたことや Zuora API を叩くための土台や移行前後で同じ動作を担保する仕組みをあらかじめ用意していたことで完遂することができました。
データ移行
STORES 予約の契約管理にはイレギュラーなケースが多かったこともあり、データを表に書き出して必要に応じて修正を行いました。
その後、整理した全ての契約管理データをスクリプトを走らせて段階的に移行していきました。 移行作業は Zuora API を叩くためのモジュールを用意して、直接 Zuora 上にアカウント作成・サブスクリプションのデータを作成していく形をとりました。
アプリケーション内での契約管理の変化
移行したのは請求・契約情報だけではなく、プラン・オプションの金額など移行後にアプリケーション内で保有する必要のない情報も Zuora に移行しました。
アプリケーション上ではオーナー様が何をいつまで、どのような契約形態で契約しているかを把握する必要なく、純粋に Zuora 上でその時点で契約している状態だけを持つようにしました。*2
振り返り
良かったこと
STORES 予約の Zuora 移行後の他プロダクト移行への見通しが立てやすかったこと
かなり多くのつまづきポイントを1年を通して踏み尽くしたこと、 Zuora の操作に慣れたことが大きな要因となります。
イレギュラー対応のためにエンジニアのリソース割当てが減ったこと
毎月月初の経理からの依頼やイレギュラーな契約によるアプリケーション内でのデータ不整合の修正はなくなりました。
アプリケーション内での契約管理の関心事が格段に減ったことにより保守性が高まったこと
毎日 Zuora と同期をすることで、最新の契約情報をアプリケーションにpullしています。
本記事では紹介していませんが、未払い情報や従量課金等の関心事も全て Zuora 上に移すことができました。
将来的なプラン・オプションの拡張を容易にする設計にできたこと
Zuora上のマスタにデータを追加するだけで、アプリケーション側の変更はかなり微小となりました。
改善していきたいこと
毎日走らせている Zuora との同期バッチ終了までの所要時間の短縮すること
DataQuery という Zuora 上で SQL を走らせる仕組みを利用して改善できることがわかっています。
EC・POSレジのプラン購読の仕組みではすでに DataQuery を利用しています。
従量課金の影響による Zuora 同期バッチのロジックの複雑になったこと
STORES 予約には月々の予約数に応じて請求金額が変動する仕組みがありますが、従量課金の対象となる予約数を Zuora 上にアップロードするためのデータに制約が多いためです。 自動アップロード時に Zuora の制約に引っ掛かることなくアップロードを成功させるために同期バッチだけではなく、毎日の予約数のカウントバッチも複雑になっています。
ドキュメントを充実させること
Zuora に関する契約管理のナレッジが属人化してしまっているため、STORES 全体へと共有していく必要があります。
苦労したこと
個人的・チーム的に一番苦労したのは従量課金の再設計でした。
今までは契約した時から1ヶ月間を予約数の計上期間としていましたが、 Zuora 移行後は月初 ~ 月末を計上期間となるように変更しました。シンプルな設計になったことで、移行前に比べるとかなり運用が楽になりましたが、既存オーナー様に影響がないようにかなり苦労して設計しました。
また件数は少ないですが、いまだにイレギュラーな契約期間を Zuora に登録することがあります。 その結果、自動での使用量アップロードが失敗し、契約情報を確認したり、場合によっては手動でアップロードする必要があります。
しかし、こういったイレギュラー対応というものはどうしても存在してしまうものです。
今はこうした対応をドキュメントにまとめて認知してもらい、取り掛かるまでの心理的なハードルを下げていくことで、属人化を無くすことに焦点を当てています。
おわりに
去年の話ではありますが、長期間に及ぶ STORES 予約のZuoraを用いたサブスクリプション管理の移行について書かせていただきました。
複雑な契約管理を整理してイレギュラーな対応ができるような柔軟な構成にするために悩むことも多かったですが、とてもやりがいのあるプロジェクトであっという間に駆け抜けた1年でした。 膨大なデータ移行を段階的に実施して、既存の動作を担保しつつ大きな障害を起こすことなく完遂できたことで、成功体験を得られました。
この記事を読んで、 STORES 予約以外の Zuora 移行が気になった方はぜひとも下記の記事も覗いてみてください。
