3. ビジネスプラン合意 - AppExchange体験記
AppExchangeのプログラム、そしてリクルーティング活動について話してきました。今回はそのリクルーティングで最も重要な話題である、ビジネスプランの議論とレベニューシェア（売上共有）の仕組みについてお話したいと思います。
Salesforceの課金方法
ビジネスプランを話す前にSalesforceの課金の基本を理解しておかないといけません。こういう「Salesforceのことを知っておく」のはとても重要で、課金だけではなく、3P (* 後述)と呼ばれる People (人)、Product (製品)、Process (やりとりの決まり)はビジネスとしておつきあいする上に重要なので、パートナー様には必ずSalesforceのことをどこまで知っているのか、をこの3点で確認していました。
Salesforceの課金は1ユーザー月額での固定料金（ユーザー課金と言っています）を基本にしています。これを英語でper user per monthと言っていたので、よくpupmと省略していました。
固定料金の対称にあるのが従量課金です。使った分によって値段が変わっていく。AWS, GCP, AzureなどのIaaS (Infrastructure as a Service; イアース：インフラストラクチャー・アズ・ア・サービス）では「使った分だけ払ってください」という従量課金が多いです。身近な例でいけば、携帯の通話料金は通話時間で課金されていれば重量課金、自宅でのインターネット接続料が毎月いくらで使い放題になっていると固定料金ということになります。
このユーザー課金方式をパートナー様にも基本は踏襲していただきます。特にOEM（前回を参照のこと）では必須になります。パートナー様がアプリをお客様に提供する価格をユーザー単位の月額料金にしてもらわないといけません。
レベニューシェアの基本的考え方
レベニューシェアとは直訳すれば「売上を共有すること」になります。上記のように年間600,000円の売上があったとすればそこから契約に掲載された%に準じてSalesforceへ発注（その後請求書に基づき支払うことになります）するわけです。私が入社した当時はこの受注業務を自分の部門でやっており、四半期末や年度末になると、他の業務と兼務している受注担当者は兼務の作業が止まるということを想定して動いていました。業務の遂行上は懸念点ではありましたが、それもベンチャーっぽくで私は好きでした。
レベニューシェアはSalesforceのドキュメントによるとOEMでは25％となっているので、年60万円のうち15万円をSalesforceへ支払い、45万円が手元に残ることになります。この利用料の収入がSalesforceの社員から見た受注額になるわけで、それはお客様担当の営業 (Account Executive)にも成績がつきました。AppExchangeのチームはこのレベニューシェアの数字を上げたいわけですが、それを上げるためにはどんなにSalesforceを訴求してもダメで、パートナー様のアプリを訴求するしかないわけです。ここで頭が綺麗に切り替わり、パートナー様アプリを販売することしか考えなくなります。つまり「思考がパートナー様と同化する」とでもいうのでしょうか？Salesforceの担当者が「パートナー様の売上をあげて、ビジネスを伸ばすことしか考えなくなる」究極のカスタマーサクセスの仕組みがここにあると思っています。
SalesforceのAppExchangeプログラムはパートナー様がお客様と契約し、それをもとにSalesforceへ報告する仕組みです。例えば1ユーザー月額5,000円（¥5,000 pupmと書きます）のアプリがあれば、それがパートナー様の売り上げになります。10ユーザーに販売されれば月額50,000円、年間600,000円の契約です。なお、契約はOEMの場合は提示は月額ですが、年間契約一括前払いというSalesforceの請求方法と同じことをお願いしています。（財務モデルとして重要な点なので、どこかでまとめてお話します。）
このレベニューシェア率をPNR (% of Net Renenue)といいました。Net Revenueは売価のことなので定価ではありません。例えば年額600,000円のものを400,000円に値引きして販売したときは、その400,000円が計算の基本であるNet Renenueになるので、25%は100,000円になります。ただし、いくらでも安くされても困るので、最低支払金額（Floor price;底値）だけは合意しておきました。例えば「年額50,000円は最低支払う」としておけば年間100,000円でもしお客様へ提案したとしても50,000円（半額！）を支払います。
このFloor Price方式は非常に好評でした。なぜならお客様の前で多少の値引きを社長さんが行いたい場合、その場で決済できてしまうからです。これまでのソフトウェアの再販の仕組みでは、この値引きをベンダーとの交渉で引き出すことが多かったため、社長でも決済できず「ベンダーへご相談」という形で持ち帰っていました。AppExchangeパートナー様の多くはこのようにお客様の目前でも価格提示を自分の判断でできる仕組みがあるわけです。
契約締結から支払いまで
契約時から請求、売掛金回収までの流れは以下のようになります。OEMは再販モデルなので、お客様とSalesforceは直接契約をしていません。パートナー様はSalesforceの基盤に関してもお客様に説明して、MSA（Master Subscripution Agreement）をお客様に理解していただく必要があります。
価格設定
価格は一番悩む要因です。それも安ければいいものでもありません。「早い、安い、うまい」はあくまでもある業界またはある企業でのことであって、適切な価格を設定し、それを価値の対価としていただき、継続的にバージョンアップを行い、アプリの価値を向上させることはお客様のためでもあるのです。それがSaaSに期待されていることでもあります。
適切な価格、というのは難しいものです。これには様々な議論があるかと思います。すでに同様のサービスがあれば、それも1つの基準になるでしょう。それの違いを意識して値付けすることもあります。
初めて登場するアプリの場合はどうすればいいのでしょうか？
そんなときにお願いしていたのは、「2社でいいので、アルファまたはベータ版を試行していただき、そのフィードバックのなかでUIや機能だけではなく、価格まで探っていく。」というものです。この2社もできれば同じセグメント（「業種が同じ、企業規模が同じ」である自社が一番狙っている市場）のものを選んでもらっていました。
ところが最初のバージョンから適正価格になるなどということはありません。例えばSalesforceでは$150 pupmになっているSales Cloud Enterprise Editionですが、この位置の製品は当初$30程度でした。そもそもEditionもなかったのです。
私がオススメしていた価格設定は以下の2通りです。
1) バージョン3で値付け、しばらくはキャンペーンで値引き
最初は製品チームと営業チームでしっかりと製品プランを練り、バージョン3（3年後の姿）くらいは議論しておいて欲しいものです。その機能を前提に価格をつけ、それをお客様に提示し、その結果、バージョンアップまではキャンペーンを適用するなどして、値下げしておく。
2) 2社からのフィードバックで値付け、バージョン3から新機能を有償化
こちらは先が見えにくいアプリの場合、まずは今のところは今の機能で値付けしておき、将来のバージョンアップ時にいくつかの機能を有償化し、売上増を狙う方法です。その機能がよいものであるほど購入率があがり、顧客単価があがります。（有償化がびっくりするほどのものでないなら）お客様満足度もあがるでしょう。
ビジネスプランの策定
売上を想定しないとビジネスプランができません。ここではレベニューシェアと価格を議論してきました。では例えば¥5.000 pupmからどうやって計画を練って、¥20,000,000の売上ができるかできないかを見ていたのでしょうか？
最初に考えたことは値付けのところでも書いた
「自社のアプリが最も適用しそうな2社を選んでください」
ということです。
「その2社でのユーザー数はどれくらいだと思っていますか？」
例えば30ユーザーだとしたら、1社あたりの単価がでます。そうしたら次に「2社の次には何社やりましょうか？」
こうするとどんどん時間軸を進めていくと、翌月には何社というように数字が書かれていきます。その社数に平均ユーザーをかけていくと、トータルのACV (Annual Contract Value; 年間契約額 これからよくでてきます。)を計算できるようになります。
「1年分が作れたのでその調子で3年分くらいまで作ってください。でも1つ注意事項があります。」
このときにChurn Rate（解約率）の基礎を覚えてもらいます。1年目の契約額があって、それをサブスクなので2年目も収入と考えることができますが、
「2年目には1年目の契約の何社くらいが継続してくれると想定していますか？」
それによって2年目と3年目のサブスクの数字を減額します。ここではこのあとに説明するカスタマーサクセスについての理解と対策を求めているのではなく、あくまでも「そういう考え方をしないといけないのだな」と覚えてもらうくらいの感覚でいいと思います。
下記のケースも簡略化して2年にしましたが、非常に綺麗にできています。ちょっと数字が良すぎるので、単価1/5くらいがちょうどいいかもしれません。これはあくまでも机上の試算であり、実際には採用や資金調達やマーケティング、そしてカスタマーサクセスなどがうまくいっての総合的な結果がこういう数値に表れるのは言うまでもありません。ここでは、少しでもいいので積み上げていくことのサブスクのインパクトを感じていただければそれで十分とも言えます。
投資判断
ビジネスケースをまとめることができればそこからはビジネスの話ができます。ここで1点だけ抜けているのはアプリの話をしていないので、その開発にかかるコストと期間が明示されていないことです。それはかなり個々のアプリの仕様にも踏み込むので、どこまで書いていいのか、を確認してからにしたいと思います。
ところで、新しいパートナーシップを締結するときの投資に関してSalesforceが提供している支援は、
① 開発環境、テスト環境は無料
② 開発支援に関してもプログラムコードを書くと著作権の問題がでるが、ウォークスルー（コードを一緒に読んでいくこと）までは支援可
③ 販売成功時にのみレベニューシェアが発生
という3項目を理解いただいた上で、判断するためのデータを集めていただくことになります。アプリ開発に関する設計、開発、テスト、販売が自己責任となってしまうため、特に設計と販売部分での協業をしていくことが議論の対象となりました。
ここまでで合意ができればデューデリジェンスチェック（信用審査）をグローバルへ申請して通れば、契約できることになるため、開発作業へと進みます。このデューデリジェンスチェックでの大きな関門は主な株主や役員に公務員（つまり政治家など）がいないか、という点だったのでほぼ大丈夫でしたが、いわゆる粉飾決算や汚職で逮捕などが起きているとひっかかることがありました。「日本人は大丈夫！」と思っていましたが、日系企業も世界中ではいろいろなことが起きていてひっかかるケースもありました。
これで晴れてビジネス的にはパートナーへの道が開けることになります。次回は「アプリの検討」として、どのようにアプリを評価していったか、を書ける範囲でまとめてみたいと思います。
3P (People, Product, Process)
この3P自体は私は転職活動のときに教わりました。3つともよく知っている会社にいくと、自分の経験を最大限に生かせる代わりに、ひょっとすると今と経験としては変わらないかもしれない。
3つとも知らない、つまり全部が新しくなるということは、「知らない製品を知らない人たちと一緒に、知らない社内ルールを経験しつつ売っていく」ということになります。こちらはリスクが高くなるわけです。
私がSalesforceからDatabricksに転職したときはPeopleはほとんど知らなかったですが、Prodoctは古い製品とはいえデータベースを売っていた経験はあるし、Processという意味ではSaaSとグローバルプロセスという意味で、経験もその対応もIBM含めて2社で体験していた、という状態でした。2つがOKと思っていましたが、やはりいろいろ苦労があります。