サブスクリプションビジネス支援アプリケーションZuoraのサービス全体像（その2）

はじめに

前回の（その1） の続きです。

Zuoraのサービス全体像をまとめ中でした:

1. まず、サブスクリプションビジネスを回していく上での一連の業務の流れを説明し、
2. 続いて、Zuoraの中心サービスであるZuora Centralの役割を説明し、
3. 最後に、Zuora Centralの各アドオンの役割、外部システムとの連携について説明します。

前回1,2について説明しました。今回は3についてです。

Zuora Centralと各種アドオンおよび外部システムとの連携

サブスクビジネスにおける業務と、Zuora Central（+ Zuora Billing）の機能の対応関係を見ました。

では実際にZuoraでサブスクビジネスを回していくとして、具体的にZuoraをどう操作していくのか。もちろん、Zuora CentralのUIからポチポチとデータを入力することもできますが、基本的に、外部システムとの連携 は必須です。Zuora Central単品で使うサービスではないです。また、Zuora Centralだけでは機能的に弱い個所もあり、そのあたりをアドオンで補う形になります。

前回にも掲載した以下の図について、順に説明してきます:

中央の円の内側がZuora Centralの領域です。左右に配置されている箱のうち、"Zuoraなんとか" という名前のものがアドオン、それ以外が外部システムです。なお、アドオンは、Zuora Centralと対比してか、"Zuora Products" と総称されているようです。

各アドオンの機能概要・オンラインマニュアル・リリースノート

前々回に書いたとおり、Zuoraまわりのマニュアルとリリースノートは Knowledge Center にまとめられています。

以下説明していく各アドオンの機能概要は、Zuoraのエディション紹介ページ に記載されています。（ちなみに、ここ見ると分かりますが、Zuora Billing以外のアドオンは全部有料です）

また、各アドオンのマニュアル・リリースノートはこのあたりから参照できます:

アドオン: Zuora CPQ

図ではZuora CPQとSalesforceが別枠になっていますが、現状、Zuora CPQは Salesforceとの連携用 のアドオンのみ提供しています¹。なので一緒に扱います。

なお、Zuora CPQは、エディションページに 💲 とあるように有料アドオンです。Zuora CentralのUIから30日間の無料トライアルを申し込めるので、Zuoraご利用中で気になる方は試してみるといいでしょう²。

Zuora CPQは、主に3つの機能から成ります:

• 1. Quotes
  • Salesforce上のデータをZuoraに連携する機能。Saleforceにアドオンとしてインストールします。
    インストールすることで、Zuoraのオブジェクトと対応するカスタムオブジェクトがSFDCに作成されます。オブジェクト間の関連図。
  • これにより、以下が可能となります:
    • Salesforceの顧客データをZuoraに同期する。
    • Salesforce上で新規契約や契約変更の見積り（カスタムオブジェクトの"Quote"）を作成する。
      • Zuora上で作成した商品マスタを（次で述べる360 Syncで）Salesforceに移し、その商品マスタから契約するプランを選択する形になります。
      • このとき同時にWordまたはPDFの見積書を作成可能。
    • 見積り作成後、（必要ならば承認ルートを通した上で）Zuoraにデータを飛ばし、Zuora上に契約データや契約変更データを生成します。
      • 契約データがZuora上に作られたら、それ以降の請求や決済はZuoraの仕事。ここは役割分担されている感じです。
  • つまり、Salesforce→Zuoraという方向のデータ連携 を担うのがQuotesです。
• 2. 360 Sync
  • Zuora上のデータをSalesforceに連携する機能。Saleforceに（Quotesとは別途に）アドオンとしてインストールします。
  • これにより、以下が可能となります:
    • Zuoraに登録した商品マスタをSFDCに同期する。
    • （Zuora側で変更された）顧客データをSFDCに同期する。
    • Zuoraが生成した請求データや決済データをSFDCに同期する。
  • つまり、Zuora→Salesforceという方向のデータ連携 を担うのが360 Syncです。
• 3. Zuora Developer Kit
  • "Order Builder" と "Zuora CPQ Component Library" から成ります。
  • Order Builderは、Zuora APIのApexラッパーです ³。Quotesで提供される機能で足りない場合は自前でApexクラスを作って、その中にOrder Builderのメソッドを埋め込んでZuoraと連携してください、という感じ。
    • QiitaにZuora関連の記事は無いだろうなと検索したら、Order Builderのテストをする方法の記事があってビビった⁴。
  • すみません、Zuora CPQ Component Library の方は詳しくないです。

外部システム: ECサイトやポータルサイト

Zuora CPQを使ってSFDC上で契約データを作成するのは、基本的には、企業の営業の人たちでしょう。対面での商談が確約されたら契約データを作る。インバウンドというやつ。
一方、たとえばサブスクビジネス用のECサイトを用意し、ネット経由で新規契約を受け付けるやり方もあります。アウトバウンドというやつ。
また、そのECサイトに会員用ページを作るとか、別途にポータルサイトを用意するとかして、顧客の自由なタイミングで各種の契約変更を受け付ける仕組みもあった方がいいでしょう。
そのような場合には、ECサイトやポータルサイトに、Zuoraの（REST）APIをコールする仕組みを埋め込むことになります ⁵。

外部システム: 課税エンジン

税計算を行う機能はZuora Billingに含まれています。税の定義（税の名前・税率・適用期間・適用される地域）をZuoraに設定することで、請求データ作成の際に自動的に税額が計算されます。

日本の場合は、計上するべき税は消費税くらい、かつ日本国内で一律、かつそんなに頻繁に税率が変わるわけではない。そのためあんまりピンと来ないのですが、たとえばアメリカの場合、州ごとに税の種類・税率が異なり、しかも頻繁に改訂されるそうです。
税の定義が変わるたびにZuoraの設定を変更するのは面倒くさい。そのあたりの「税の定義」を管理して、変更があったときに通達してくれるシステムを 課税エンジン と呼ぶみたいです。Zuoraは、Avalaraという課税エンジン、およびvertexという課税エンジンと接続するコネクタを提供しています。税の定義に変更があったときに自動的にZuora側の設定を書き換えてくれるみたいです。

外部システム: Payment Gateway

クレジットカードやPayPalなどの電子決済にまつわる取引を司るシステムを Payment Gateway と呼びます。
扱える決済方法の違いや対象地域の違いにより、世界中に数多くのPayment Gatawayが存在します。
Zuoraと連携可能なPayment Gatawayのリスト → [こちら] (https://knowledgecenter.zuora.com/CB_Billing/M_Payment_Gateways/Supported_Payment_Gateways) このリストのうち、日本をターゲットとするPayment Gatawayは現在のところ以下2つです:

• GMO Payment Gateway
• Sony Payment Services Gateway

顧客が電子決済の情報（クレカ番号とか）を登録していれば、Payment Runを実行した際に、裏でPayment Gatewayと連携されます。ざっくり以下の流れで処理が進みます:

1. ZuoraからPayment Gatewayに対して決済の申し込みが飛ぶ。
2. Payment Gateway側でクレカのオーソリ（期限切れてないかとか、限度額超えてないかなどのチェック）が行われる。
3. 問題なければ、OKっすとPayment GatewayからZuoraへ返答が来る。
4. Zuora上に、請求データに対する消込という形で決済データが作成される。

外部システム: プロビジョニング

たとえば、クラウドサービスを提供してサブスクビジネスを行うとします。そして、その契約の管理にZuoraを使うとしましょう。
このとき、Zuoraに契約データを作ったらクラウドサービスが自動的にアクティベートするかというとそんなことはなく、Zuora上の契約データのステータスとサービス側のステータスを紐づける仕組み が、Zuoraとは別に必要となります。

"Zuora上の契約データのステータスとサービス側のステータスを紐づける"とは、こういうイメージ:

• Zuora上に契約データが新規に作成された → サービス起動!
• Zuora上の契約データが更新された⁶ → サービス利用期間延長!
• Zuora上の契約データが解約された → サービス停止!

サービスのステータスを司るシステムを プロビジョニングシステム と呼びます。
世の中、様々なプロビジョニングシステムが存在するでしょうが、Zuoraと連携するプロビジョニングシステムとして、上図に記載されているように、Flexera が推されています。
後述するZuora Connectのマーケットプレイスに Flexera Connector というZuoraとFlexeraとのコネクタが用意されています。

また、Flexeraは（というかプロビジョニングシステムなら一般に?）、顧客がそのサービスをどれくらい利用したのかをカウントする機能を備えています。Flexera Connector経由でその使用量をZuoraにインポートすることができるようです。

アドオン: Zuora Collect

顧客都合で決済に失敗したときの処理を自動化するためのアドオンです。
Payment Gatewayの節で書いたように、Payment Runを実行することで自動的に決済処理が行われます。このとき、たとえば、クレカの期限が切れているとか、カードの利用限度額がいっぱいとかの理由で決済できないことがありえます。
Zuora Centralの標準機能として、

• 決済失敗時に顧客にメールを飛ばす。
• 決済失敗した場合に時間をおいて何度かリトライする。

これらの機能はありますが、やや貧弱です。
Zuora Collectを使うと、たとえば以下のような拡張機能が使えるようです:

• Payment Gatawayから返ってくるエラーコードに応じてリトライのロジックを変更する。
• 延滞日数や延滞額に応じて顧客への督促方法を変える。
• 決済失敗した時点で顧客の契約を停止し、支払いが行われたら再開する。

アドオン: Zuora RevPro

"Rev"はRevenue、収益のことを指します。売上と考えて差し支えないです。
一般に、たとえば1万円の商品が売れたら、1万円の売上としてカウントされます。一方、サブスクビジネスの場合はやや微妙なところがあります。年契約で1万円のサービスを顧客が利用開始して、1万円を前払いとして受け取ったとしましょう。これを「1万円の売上」として即計上して大丈夫でしょうか。半年後に顧客が解約を求めてきて5千円を返金する可能性もあります。そのあたりを鑑みて、サブスクビジネスでは、収益を2種類に分けて考えます: Deferred revenue（前受収益）と Realized Revenue（実現収益⁷）。
前受収益は、本当の意味での収益ではなく、「このまま穏当にいけば収益になるけど、まだ分からんからグレーにしておく」ための勘定科目です。実現収益は本当の意味での収益。前受収益を実現収益に振り替える操作をRevenue Recognition（収益認識）と呼びます。
上の例の場合、顧客から受け取った1万円をいったん前受収益と見なしておいて、その後、たとえば1日経過するごとに10,000円/365=27円ずつとか何かしらのルールで実現収益に振り替えていく。"ルール"は色んなやり口が考えられ、たとえばサービス利用から2カ月経過したら解約不可・返金不可という利用規約を定めているならば、サービス利用から2カ月経過した時点で前受収益の全額を実現収益に振り替えるなども可です。
収益認識の厳密なルールは、割と最近、国際的な会計基準（IFRS第15号とかASC第606号という名前）に策定されました。アメリカでは2017/12/15から、ヨーロッパでは2018/01/01から適用開始されたそうです。（日本でもこのあたりの会計基準が制定されている途中で、2021年の4月から適用されるそうです: リンク）

さて、RevPro。すいません、実際に触ったことないのでいまいち分かっていません。
収益認識まわりの機能自体は、Zuora CentralのSubscription Accounting Engineに含まれています。RevProのマニュアルを読む限り、より厳密に、国際会計基準に則った収益認識を行うためのアドオンのようなのですが、具体的に何ができるのかよく分からん。

アドオン: Zuora Insights

前回 書いたように、サブスクビジネス特有の指標の計算、およびそれらをエクスポートする機能はZuora Centralに搭載されています。しかし、CSVに吐き出すことができるだけで、それ以降の操作（可視化とか予測とか）は皆さんの手でやってくださいねという方針です。

Zuora Insightsを使うと、たとえば以下のような拡張機能が使えるようです:
可視化、予測、外部データの取り込み、レポートの共有など。

すいません、これも実際に使ったことはないのでこれ以上は分かんないっす。

サードパーティ製アドオン: Zuora Connect

ここまでに解説したアドオンは、いずれも、Zuora社謹製の"Zuora Products"と呼ばれるアドオンでした。
一方、サードパーティが作成したアドオンは"Zuora Connect"と呼ばれます。それらアドオンは Zuora Connect Marketplace で公開され、また購入することが可能です。SFDCのAppExchangeと同じ感じですね。
Connectアプリの作成は誰でもできるようです。詳しい情報はDeveloper Centerの こちらのページ に記載されています。

まとめると

まとめてみましょう。

まず、Zuoraに対する入力を担うのは、CRMやECサイト, ポータルサイトであると言えます。顧客データ・新規契約データ・契約変更データをこれらの外部システムから受け付けます。

ここからしばらくZuoraのターン。アドオンが使われたり、外部システムとの相互の連携をしますが、処理の中心にはZuoraがいます:

• Zuora上の契約データのステータスと実サービスのステータスをプロビジョニングシステムが結びつける。サービスの使用量をプロビジョニングシステムが監視し、Zuoraにインポートする。
• 請求データはZuoraが作成する。課税エンジンが税の情報をZuoraに連携することで正しく税計算が行われる。
• 電子決済はPayment Gatewayと連携する。決済が成功すれば、Zuoraに消込データが作成される。リアルマネーの操作はPayment Gatewayがやる。決済が失敗した場合の処理をやりやすくしたいならZuora Collectを利用する。
• Zuora上の取引データから仕訳が作成される。国際会計基準を満たす厳密な処理を行うならばZuora RevProを利用する。

そうして作成された仕訳は、（Zuoraは他の仕訳を受け入れたり決算したりする機能はないので）ERPに対して出力される。

つまり、データは、CRM→Zuora→ERP の順に流れていきます。この様相を指して、「（Zuoraは）CRMとERPを結びつける組織（the connective tissue between your CRM and ERP）」と表現されているようです⁸。

ここまでを図でまとめるとこんな感じでしょう:

おわりに

Zuoraと、Zuoraを取り巻く各システムの関係を整理しました。
次回はどっぷりZuoraに浸かって、Zuoraのオブジェクト構造をまとめていきます。

（2018/11/01追記: ちょっと業務的に一時的にZuoraを離れることになったので、続きの投稿はだいぶ先になりそうです。すみません）

1. Zuora CPQは、かつては "Zuora for Salesforce (Z4SF)" という名前でした。 ↩

2. Zuoraのトライアル版（Test Drive）でもZuora CPQのトライアルを申し込めるのかどうかは未確認です。すみません。 ↩

3. 前々回に書いたように、ZuoraにはSOAP APIとREST APIが用意されており、SOAPは開発終了していて使用非推奨です。……が、Order BuilderはどうもSOAPを使っているようです。 ↩

4. しかも俺がCommunityに上げた投稿が引用されとる! @atskimura さん、ありがとうございます、非常に参考になりました。 ↩

5. 前々回に書いたように、ZuoraにはSOAP APIとREST APIが用意されており、SOAPは開発終了していて使用非推奨です。 ↩

6. この"更新"は、CRUDのUpdateという意味の更新ではなく、たとえば1年間の契約を更新して向こう1年間の継続利用を決定したという意味の更新です。 ↩

7. Deferred Revenueを前受収益と訳すのは間違いないですが、Realized Revenueを実現収益と訳すのが適当かどうか微妙です。すいません。 ↩

8. もちろんこれは象徴的な書き方で、上で見たようにCRM以外にもECサイトやポータルサイトからの入力も受け付けられるし、ERP以外の会計システムで仕訳の整理・決算を行っている場合にはそちらのシステムに仕訳を渡すことになります。 ↩