EC・POSレジのプラン購読の仕組みをZuoraに移行した話

はじめに

はじめまして。STORES でエンジニアをやっている id:shu-suzuki-1124 です。

競馬では例年より早く宝塚記念が開催されたため春のG1もすべて終わり、新馬戦や夏競馬が本格的に始まってきました。未来への可能性に期待膨らむ新馬戦、波乱万丈で刺激的な夏競馬、私はG1も好きですがこの季節もまた別の趣があってとても好きです。

思えば私が STORES に入社したのも去年の夏頃でした。そして STORES で働いたこの1年はまさしく未来に胸踊らせつつ刺激的な1年だったと感じています。なのでこの1年に郷愁を感じつつ、その中でも今年の1~3月で参画した STORES ネットショップ、STORES POSレジのプラン購読を Zuora に移行したプロジェクトについて書いていこうかと思います。

プロジェクトについて

プロジェクトの概要

新プラン

STORES は STORES 予約、STORES POSレジ、STORES ネットショップなど、店舗運営に必要な複数のプロダクトを提供しています。3月27日には、それらのプロダクトをより柔軟かつ横断的に利用できるようにするあたらしいプラン体系をリリースしました（STORES の新プラン）。

このあたらしいプランは、STORES 全体のプロダクトを一つの体験としてつなげるための大きな一歩でもあります。

新プランリリース前のSTORES プロダクトとしての課題

この新プランの統合的な体験を実現するにあたっては、各プロダクトでバラバラに存在していた課金・購読の仕組みをどう整理し、一元化していくかという課題がありました。

新プランをリリースする前、 STORES の各プロダクトは統合が進みながらも、プラン購読の仕組みに関しては各プロダクトで管理をしていました。

そのため、

例えば STORES ネットショップと STORES 予約を利用したいとなった場合は別々でプランを申し込む必要がある
複数プロダクトを利用するときに割引などを適用できない
社内の請求業務も各プロダクトでバラバラになっている

といった問題がありました。

そこで各プロダクトでバラバラだったこのプラン購読の仕組みを統一しようというのが今回のプロジェクトで達成したい目標でした。

Beforeの世界	Afterの世界

各プロダクトが別でプランを管理	プランの管理を集約する/ 複数プロダクト利用時に割引を適用する

プロジェクトの詳細

Zuora について

このプラン購読の仕組みを統一するという目標を達成するために、Zuora¹というプロダクトを使うことになりました。 Zuora はサブスクリプション（継続課金）や請求業務を自動化・効率化できるクラウド型の「課金管理プラットフォーム」です。

実は2024年の時点で STORES 予約には Zuora が導入されていました。なので STORES ネットショップと STORES POSレジもプラン購読の仕組みを Zuora に移行し、Zuora で管理できるようにしようというのが私たちのチームの任務になりました。（社内実績があったこと、Zuora に詳しいエンジニアがいたことはこのプロジェクトの救いでもありました。）

STORES の Zuora に導入に関しては以下の記事も参照してください。

プロジェクトを進める上の課題 / 難しかったところ

既存の仕様のキャッチアップ/洗い出し

STORES ネットショップ / STORES POSレジの仕様キャッチアップと MongoDB との出会い今回のプロジェクトメンバーはエンジニア4人（途中から5人）という構成でしたが、その多くが STORES ネットショップや STORES POSレジの実装にはほとんど触れたことがない状態でした。そのためまずは、STORES ネットショップと STORES POSレジそれぞれの現行プラン購読周りの仕様をキャッチアップするところからスタートしました。

少し余談になりますが、STORES ネットショップと STORES POSレジはどちらも Rails で実装されているものの、データベースには MongoDB が使われています。ふだん MySQL や PostgreSQL に慣れていた私にとっては、MongoDB の操作感はあたらしく、「なるほどこういう感じなのか……！」と試しに触ったときはけっこう驚きがありました。 MongoDBのドキュメント指向な設計は、構造の柔軟さやクエリの自由度もあって、慣れてくるとけっこう面白く、学びも多かったです。

ちなみに、MongoDB関連については過去に社内ブログでも取り上げている記事があります（ちょっと前のものですが、参考になります）：

Zuora のキャッチアップと Zuora 上でいかに仕様を表現するか

まずは既存のプラン仕様を洗い出すところから始めました。そのうえで、今回導入する Zuora についても、チーム内に経験者がいなかったため、完全にゼロからのキャッチアップが必要でした。

特に難しかったのは、STORES ネットショップや STORES POSレジなど、それぞれのプロダクト特有のプラン体系を Zuora 上でどう表現するかという部分です。たとえば、STORES POSレジでは「初回契約30日間無料」²のような条件があり、STORES ネットショップでは「月払い」「6ヶ月まとめ払い」「12ヶ月まとめ払い」³といった複数の支払いパターンが存在します。これらすべてを、Zuora のプロダクトカタログやサブスクリプションモデルを使って正確に再現する必要がありました。

Zuora 自体は非常に柔軟な設計になっていて、機能やAPIも豊富に用意されています。そのため大半の要件は再現可能でしたし、リファレンスやチュートリアルも充実していたため、情報をキャッチアップしながら着実に前に進めることができました。もちろん、学ぶべきことの量は膨大で大変でしたが、手を動かしながら徐々に理解を深めていけたと思います。

（個人的には今回はじめて Zuora を使ってみたのですが、もっと広まってほしいプロダクトだなと思ってます）

Zuora のデータと各プロダクトのデータをいかに同期させるか

以前の世界線の場合、プラン購読は各プロダクトで情報を持っていたので、かんたんではないとはいえ各システムに閉じて管理することができました。

beforeの世界線

では Zuora 移行後の世界ではどうなるでしょうか。まずプラン購読を Zuora に移譲するため Zuora との連携が必要です。また弊社では各システムが組織管理基盤とつながっており、その組織管理基盤ともデータを連携する必要があります。そのため各システム間でどうデータを同期するかを吟味しなければなりません。

※ 組織管理基盤についてはこちら: Go と GraphQLで作る組織管理基盤 - STORES Product Blog

そしてデータを連携するタイミングも様々あります。例えばオーナーさんがプランを購読/キャンセルをしたとき、Zuora 上で行われる定期購読のとき、Zuora 上で支払いに失敗したとき、新プランを適用する際に1回のプラン購読で複数プロダクトをプラン購読状態にしたいとき、etc...。。

とても多くの状況を考える必要があり、あらゆる想定パターンをチームで洗い出し、Zuora にはapi⁴やwebhook⁵, またはdataquery⁶などのデータ連携する仕組みがありますので、これらを組み合わせて最善の解決方法を考え出しました。

※ プロジェクト当時の3月の話です。このプロジェクトのあとも社内では Zuora の知見高まってどんどん良いアーキテクチャに進化していってるので変わっている部分もあります。

afterの世界線

改めてプロジェクトを振り返る

良かったところ

このときは私のチームは基本リモートで働いていましたが、みんなで知識をキャッチアップするときは合宿的なノリで出社したり、設計を吟味したいときもみんなで出社してホワイトボード囲んだり状況に合わせて働きました。出社にもリモートにもメリットがあるとは思ってるので、それをチームで柔軟に取り入れて働けたのはとてもよかったです。
とりあえずわからないことだらけだったのでいろんな人に相談/質問しました。同じチームだけでなく別のチームの人や、別の職種の関係者ともたくさん会話しました。Slackとかで気軽に質問できますし、初見の人でもみんな真剣に相談にのってくれたり。。このプロジェクトに限らず STORES のいいところだなと個人的に思ってます。
個人的には難易度の高い課題を紐解くのが好きなので、やりがいをもって働けたと思ってます！

改善できそうなところ

キャッチアップしたことを資料に残していったのだが、複雑なこともありプロジェクト以外のメンバーが使用するのがちょっと難易度が高いかなと感じています。ちょうど社内でNotionを導入したのがこの時期で、Notion使い慣れてなかった部分もあり、今ならもっと網羅的にdocument整備はできたんじゃないかなと思っています。

※ Notionへの移行に関してはこちらの記事も参照してください: 10万ページ以上のナレッジをNotionに移行しました (スクリプト編) - STORES Product Blog