はじめに

Zuora Central Platform（Zuora社が提供するサブスクリプションプラットフォーム名。以降 Zuora と記載）を利用する機会があったため、ナレッジをまとめます。

サブスクリプションのプラン設計・プライシング設計などの販売戦略的な話は今回触れませんのでご了承ください。

続編が公開されました:

Zuora連載2：Zuora REST API 利用と開発環境構築

サブスクリプションとは？

サブスクリプション（略してサブスク）。様々なところで聞く言葉だと思います。直訳すると「購読」。ITの分野では「定期購読」として説明されることが多いです。

簡単に言うと「ある商品（モノ・コト・サービスなど）を、定期的に利用する契約を結んで提供する仕組み」です。今までと異なる売り方やサービスができ、バラ色の世界が待っているよという謳い文句もよく聞きます。しかしいざ自分たちでやろうとすると、何らかの専門的なプラットフォームサービスを利用することが必要な事が多いでしょう。

その中でも世界的にも有名な「Zuora」というサブスクプラットフォームをガッツリ使い倒す機会がありました。サブスクのプラットフォームとはどのようなものか、利用者視点で解説します。

Zuora Central Platformとは？

Zuoraの公式ページを見ると、 サブスクリプションのプラットフォーム と記載されています。

様々なガイドがありますが、私は当初、以下の3点を理解するまでイニシャルコストを掛けたので、この点を中心にまとめます。

何ができるのか

1-1. オブジェクトモデル
1-2. 画面

Zuoraを利用したシステム構築では、何を行えばよいのか？
システムが受ける制約事項

1-1. 何ができるか（オブジェクトモデル）

サブスクリプションで扱う商品を管理できます
サブスクリプションで扱う商品のプラン・価格を管理できます
サブスクリプションを買う人を管理できます
サブスクリプションの購入方法（銀行払い・クレジット払いなど）を管理できます
サブスクリプションの請求・消込管理ができます

システムを考える場合、オブジェクトモデルをみると機能の見当が付きやすいように思うので、以下にポイントをまとめます。
zuora business object model（公式より転載）

商品(Product)

商品(Product)が複数のプラン(Product Rate Plan)を持ち、プラン(Product Rate Plan)が複数の料金(Product Rate Plan Charge)を持つことができます（例えば、プランに初期費用を持つ場合、料金が別れます）。
一番下のTier(Product Rate Plan Charge Tier)は料金が階段状のTireになる場合に利用されます。

顧客（Account）

顧客(Account)は複数の契約（subscription）を持つことができます。顧客(Account)は複数の請求方法（Payment method）を管理できます。請求（invoice）は顧客(Account)に紐づきます。

契約(Subscription)

契約(Subscription)は商品(Product)が持つプラン(Product Rate Plan)をコピーして作られます。したがって、商品(Product)を変更しても契約済みのサブスクリプションは影響を受けません。

1-2. 何ができるか？（画面）

オブジェクトと合わせてみるとわかりやすいのではないでしょうか？
※画面は正式に契約したときに見えるものと異なる場合があります。

顧客

サブスクリプションを契約する顧客、顧客の請求先住所、請求方法を管理できます。また、顧客が契約するサブスクリプションもここから作成します。

プロダクト

サブスクリプションで購入可能なプロダクトを定義します。ここでデータモデルのプロダクト・プラン・チャージ（ティア）の定義を作成します。

請求

請求情報（明細含む）の作成と請求情報作制の実行タイミングを制御可能です。従量など、使用量が金額に反映されるプランを用意している場合、「使用量（※）」のメニューから確認できます。

※使用量はAPI・FileなどでZuoraに登録する必要があります。

回収

請求に対しての回収業務になります。クレジット会社・銀行との接続も含めて請求の消込まで可能（※）です。

※全てのパターンは網羅できていないので、利用時はZuoraさんに確認してください。

ファイナンス/レポート

冒頭に記載しましたとおり、ここは今回あまり深く触れることができていない部分になります。
詳細は公式ページを御覧ください。

マーケットプレイス

Salesforceとの接続機能（顧客情報はSaleforceとも連携可能です）や、インテグレーション用の機能（Workflow）など、Zuoraに機能を追加する場合に利用します。

プラットフォーム

インテグレーション用の機能が提供されています。
次章参照ください

（2）Zuoraを利用したシステム構築では、何を行えばよいのか？

Zuoraを利用する場合、サブスクリプションの情報をZuoraと通信することになります。この通信部分を実装する場合、以下の機能に触れる必要があります。おそらく、これらの機能を抑えることで、構築されるシステムとのつなぎ込みを実現できるでしょう。

Data Model: Zuoraが持つオブジェクトを拡張できまず（新しいオブジェクトを作ることも、Fieldを追加することも両方可能です/制約あり）
- https://knowledgecenter.zuora.com/BB_Introducing_Z_Business/D_Zuora_Business_Objects_Relationship
Events: Zuora上のオブジェクト変更をEventとして管理できます。直下の通知機能と合わせて使います
Notifications: EventをTriggerに外部APIのコール・Workflowのコール・メール通知行うことができます。
Workflow: Zuoraのリソース変更に合わせて各種処理が実行できるで、Zuoraと接続したシステムを構築する場合、必ず触る機能です。タスクの定義と、それを繋げたフローを作ることで、基本機能が持たない作り込みを可能とします。
- https://jp.zuora.com/products/developer-platform/workflow/
Data Query: Zuoraのオブジェクトに対してQuery（API可能）でデータを参照する機能です
- https://knowledgecenter.zuora.com/Central_Platform/Query/Data_Query
Settings API: データの登録参照を実行するためAPI群です
- https://knowledgecenter.zuora.com/Central_Platform/API

（3）システムが受ける制約事項

Zuoraを含むシステム構築を実施しましたが、以下がシステム制約になると感想を持ちました。

サブスクリプション商材のマスタをZuoraに持つ必要がある
サブスクリプション情報をZuoraに持つ必要がある（当然ですね…）
顧客情報をZuoraに持つ必要がある
請求・消込まで行う場合、Zuoraでこれらの管理を行う必要があり
Zuoraが標準で用意する入力チェック・機能制約は少々ゆるいため、業務 or システムで吸収する必要がある

仮に、契約日に業務上の制約を付ける場合以下の対応が必要になります。

Zuoraが持つ標準画面で入力: 手動入力の運用で回避する
外部システムで入力チェックを実現する: 要件に応じた入力チェックを外部システムで実現する

さいごに

少しでもZuoraの使用感が伝われば幸いです

より構築の目線で、API・Workflowなどの紹介は次回以降にバトンを渡します。

次の記事はZuora連載2：Zuora REST API 利用と開発環境構築です。

Zuora連載１：Zuora Central Platform概要