6. 海外アプリの売上を伸ばせ
おかげさまでだいぶNoteに慣れてきました。絵の挿入やリンク貼り付けたり。でも、文章の長さとか、太字のタイミングとか、まだまだ手探りです。改善方法などご指摘いただけると助かります。
さて、これまで日本のアプリを一緒に開発して伸ばしていく話をしてきました。一方、ソフトウェアに国産、外国産(SAP, Microsoft, Oracleなど)があるようにSalesforceのAppExchangeの中でも海外勢の存在があります。今回はそんな海外勢のお話をしていきたいと思います。
AppExchange営業の評価の仕組み
Salesforceの営業の評価はACV (Annual Contract Value; 年間契約額) です。1 ID 年間10万円のものを100 ID契約できたら、10万円 x 100 = 一千万円 になります。AppExchangeではこれがパートナー様の契約額だとするとPNR (% of Net Revenue) でレベニューシェアされるため、例えばPNR 20%となると 一千万円 x 20% = 200万円 となるわけです。実際、この金額がSalesforceから請求され、支払います。これがAppExchange営業の売上になります。またこの金額がAE (Account Executive)にも適用されます。
このAppExchange契約はGlobal契約です。どういう意味か、というと自国で契約していれば世界のどこでも販売できるというものです。日本のベンチャーは海外でも新しい契約なしに展開できるので、これは1つのメリットです。日本語の契約書で契約しておいてビジネスの展開を国外でも可能なプログラムはあまりありません。（多いのは現地では英語での再契約をするというもの）
Salesforceでは、この、「自国で育てたAppExchangeパートナーのACV」が「自国で売上がたつ」とTake Offといい、「他国」ではLandingと言っていました。このうち、AppExchangeの営業評価の基本はTake Offです。つまり自国でアプリを作り、海外含めて売り上げれば成績が伸びます。日本から見るとハードル高いのですが、米国から考えるとなかなかいい仕組みです。AppExchangeにおけるアカウント（お客様）の考え方は「パートナー」なのです。通常AEはアカウントでの売上が計上されます。AppExchangeでのパートナーの売上が（世界のどこでもいいので）増えるとAppExchangeの営業成績になったのです。
DocuSignはご存じでしょうか？米国契約なので、米国のDocuSign担当AppExchangeの営業は日本で売れても自分の成績になります。この日本で販売されたケースをLanding ACVと言いました。飛行機になぞらえたのですね。
なぜこんな区別をしたのか？
背景にはマークベニオフの強い想いがあります。彼は徹底した現場主義の人です。AppExchangeの元になったカスタマイズを考えたり、アプリのプラットフォームという仕組みを考えたのも、現場にある要望をうまく汲み取れたからです。その彼はSalesforceには「もっとその国の現場に即したサービス」が必要と考えていました。そこでAppExchangeのチームを世界展開したのです。
ところが事件がおきます。当時、LandingもTake Offもなかったときは「どちらも売っても成績になる」という状況です。
ここでは2つのアプローチがあります。
・Take Off - アプリを作れるベンダーを探して開発、トレーニングしてSaaSベンダーとして育てて、数字をあげる
・Landing - 米国で生まれたもの（当時は他国のものは多くない）を自国で販売できるようにして売る
特に英語がビジネスで使える国からすれば、どちらが「今の数字を上げやすいか」は明白です。
車でいえば、これから創るのか（デザインも設計もない）、もう走れるのか（できあがってあとはガソリン入れるだけ）くらいの差がありました。そこでLandingだけを販売して数字を上げるという動きがヨーロッパで顕著になりました。会社として、1営業として数字を最大化する一施策ではあったと思います。
ところが、あるときヨーロッパのレビューをした彼が、「何のためにAppExchangeチームがヨーロッパにいるのか理解していない。これなら米国だけで十分。」ということで、このやり方を完全に否定。「他国のものを基本AppExchangeチームに計上しない」ことを決めました。このときTake OffとLandingという単語が造られました。それから各国のAppExchangeチームは自分の担当地域でのアプリの発掘、売上向上へと注力していくことになりました。
海外AppExchangeアプリの先駆け Veeva Systems
海外アプリが成績にならないといっても、それは社内のことであって、彼らは日本にも市場があると判断すれば日本語対応もすれば、日本の現地法人も作り、市場参入してくるのは自然なことです。世界第2位のIT投資国日本でのビジネスが欲しいこと、オラクルやSalesforceなどがうまく行っていることも大きな影響を与えています（このときの体験が今のDatabricksへ転職する1つのきっかけともなっています。）
日本での販売といえば、先輩格としてはやはりVeeva Systemsでしょう。もともと米国でも当初から協業してきました。「CRMを造らない」という暗黙の了解のようなものがあるなかで、製薬のMR (Medical Representative: 製薬営業, お医者さんに薬を説明して販売するのが役目)向けのCRMです。ある特定業界向け（Virtical;バーチカルとも書かれる）のCRMであるVeevaはSalesforceと2017年に10年にわたる協業を発表しました。2007年に創業したVeevaは2013年にNYSE（ニューヨーク証券取引所）にわずか6年で上場しています。
上場直前に日本市場へ参入したVeevaは外資系製薬企業を中心にビジネスを拡大し、大きく日本でのSalesforceビジネスに貢献し続けていると言ってもよいと思います。ある意味ニッチな市場である製薬業の中でVeevaが選ばれているのは
1) MRに特化、徹底的に無駄を省く
MRという職業はアメリカでは車を使って病院を訪問します。前日にその訪問場所を調べ、資料を準備（以前は印刷）し、それを説明、面会を数カ所すればもう夕方です。オフィスに戻って、訪問先お医者様ごとに薬の説明資料をファイルする。これらをタブレットを使って、資料はタブレットで見せて、自動的に訪問先医師の資料に保存される、医師に自動的にお礼メールと資料を送る、という形に変わりました。
2) ワークスタイル変革を提案
1)の機能の大きな波及効果として、「オフィスへ戻って資料を保管する」という業務がなくなったことがあります。これにより毎日残業のような状況が改善され、ほぼオフィスへ行かずに、訪問を繰り返せるようになりました。翌日の計画も自宅で作業ができます。
3) 米国電波事情を考慮
米国では携帯の電波が届かないところもありますが、オフライン機能（当時Sales Cloudでは持っていなかった）も提供されており、事前に資料をダウンロードしておけば、電波なしに使うこともできました。電波が届いたらオンラインになり、自動的にサーバーへ情報が更新されます。
という3点でお客様の業務改革を推進したからです。
これらの採用前後を比べると我々でもわかりますが、お客様は元の業務に戻りたくないため、Veeva CRMの継続率は非常に高かったですし、ほぼ全社導入で一気に展開するというモデルができあがりました。お試しで一部門からはじめて、というよりも「効果がわかるので展開は確定」というケースが多かったようです。
ここでのシナリオで面白いのは、「ITだけを考えてアプリを造っていないこと」です。ITの周りにある、現場の不満や悩みを改善することで、非常に魅力的なアプリになりました。
MRの資料保管が重要な訳
製薬業に特有な要件だと思いますが、「医師に説明した資料を保管する」ということは「将来、薬剤訴訟などが起きたとき、医師がどの情報を知っていたのかという、重要な証拠になる」ことを意味します。「服用指示をしたとき、副作用をどこまで知っていて処方したのか」が裁判で問われることになります。このような事故が起きることは決してよいことではありませんが、事実は事実として正しく記録する必要があります。以前は車で廻っていて、事務処理が追いつかなくなると、複数バージョンの書類が社内で混在し、「見ていない事項が見たことになる」事案が発生しないとも限りません。そのようなリスクを排除できていることも法令遵守の観点で重要なことになります。
後続の海外勢
このトピックは様々なケースがありましたので、特殊なケースは1回を使ってお話したいと思います。ここでは全般的な傾向として、どういう動きをしていたか、を書き留めたいです。
1) 海外アプリを勉強して日本進出を提案する
2) 提案した中から日本進出を決めたところを支援する
3) それらを支援していく中でモデルケースを造り、横展開する
というものが当初造った案です。日本進出プラン、"Plan Japan"みたいなものです。このあと話が進んでいくとわかるのですが、
a) いつごろ日本へ上陸するべきか、という議論がなされるのか、パートナー視点での考察が足りなかった
b) 上場前の会社なので、財務状況を考察に入れられず、1)は自分たちの好き嫌いという感覚に頼った判断になった
c) SalesforceによるAppExchangeパートナー買収に翻弄された
という点でこのプランは反省が多かったです。
Plan Japanを実施するには米国での信頼度を上げたい、ということで、以下の2点を実施しました。
・（Spring Approach）
"Launch Japan Market" イベントを実施。ISVを招いて、先輩AppExchangeパートナーから話を聞き、実際に日本進出プランを建てる。できればその実現を支援する。招待制で、売上Top20くらいから日本でもニーズがあるものを選んで勧誘。
・（Fall Approach）
Dreamforceではブースを歩いて、情報収集。これによりどんなアプリか、デモなどを見て、次の候補を探します。
年に2回定期的に行くことをコミットして各社とのリレーションを造り、そこから日本進出の促進を図るものでした。JETRO（日本貿易振興機構）にも協力いただいて、日本進出への支援策なども紹介いただきました。
アプローチは悪くなかったと思うのですが、実際にこれで日本上陸してきたのはほぼなかったと思います。もはや改善点を実行するのは私にはできませんが、今からやるなら
・Spring Approach改善点
自分から各社に積極的に働きかけ、10社を集める。その10社には1年間定期的にコンタクトすることとして、対応するが、前向きはGroup Aと、受動的なGroup Bに分け、頻度や対応を変えていく。
・Fall Approach改善点
事前の交渉で各ブースでExecutiveとアポを取っておく。実際これができたところは次の話が早かったし、ブースでデモした人に名刺をもらっても、その後Executiveまでたどり着いたことはなかったから、アプローチを変えるべきだった。
そして双方に共通するのがもっと米国上司（私が日本代表なので、彼/彼女はGlobal Business Unit Leaderになる）へお願いして、きちんとこれらのイベントをAuthorize（権威付け；彼らにKey AppExchangeパートナーへ日本のイベントはいいぞ、きちんと対応してね）と動いてもらうべきだったな、と。みんな日本へ来てくれたりしていたので、このあたりの話を相手にも理解してもらうとともに一緒に考えていけばよかった。また、自分自身も忙しさにかまけて注力できないこともあり、それも実行力に影響してしまったのか、と思っています。
（現役のころにNoteを書いていたら、ちょっと別視点が生まれて、この発想が生まれていたかも、とちょっと反省。）
最初に日本進出を交渉した相手はApptus（アプタス;現在はCongaを買収してCongaの名前を使っている）でした。Dreamforceに出席した2014年、ApttusはTop3のパートナーで、会場脇のSan Francisco Marriott Marquisを借り切って自社ブースを構えていました。（このとき斜め前のビルは前年まで出展していたMarketoが紫色にビルを染めて存在感を出していたのをよく覚えています。）
そこの最上階のラウンジではExecutive Meetingが催されていたのですが、当時の日本の上司を一緒に呼ばれて出席したところ、彼らのJapan Planを提示され、「まずは2名でスタート、そこで実績ができれば3名を追加」と提案されました。「これで大丈夫かな？」と訊かれたので、「最低5名。3年は頑張って欲しい。」といい、
・カントリーマネージャー（日本語ができてお客様にコミットできる人）
・営業リーダー（できれば大手B2B営業経験あり）
・技術リーダー（プリセールス経験あり、Salesforce経験あり）
・マーケティング（日本語翻訳が必須）
・オペレーション、法務（アウトソース可能）
とロールまで決めて、提案したのです。非常に印象的だったのはその場にいたCEO & Founderが「わかった！じゃ5人でやろう！」と言っていきなり2から5にプランが変わったんです。このスピード感は自分のビジネス体験の中でもなかなかないものでしたので、驚きました。「会社を創った人」にはIBM時代には会うことがほとんどなかったので、発想が異なることすら想像していなかったのです。（これはその後日本のベンチャー創業者の方とお話する上でも生きた経験だったと思います）
また製品、日本法人としての要望は
・日本語対応（営業が使うツールなので日本語化が必須）
・契約書の日本語化、法務の日本対応（法律と所轄裁判所）
・日本円での支払い（銀行口座開設）
・（オプションとはいいながらプログラムとしては必要な）パートナー再販制度
を上げておきました。
その場にはApptusの日本法人社長として採用が決まっていた方も同席しており、我々の支援（彼は日本語の話せるアメリカ人だったのですが、本社を説得仕切れていなかったのかも）にはとても感謝していただきました。ここから日本上陸を果たしてビジネスが始まります。
海外Top 3が日本に来てくれれば、彼らのビジネスを伸ばして、翌年はその次の3社を、3年で10社くらいになれば売上はどんどん伸びる、という（正に）皮算用をはじいていたわけです。
Top 3のもう1社、ServiceMaxは日本で1名、外資出身の方をコンサルとして採用し、着々と日本進出を準備してきました。私が認識したときにはすでに商談が複数あり、日本法人社長も採用されて、プレスリリースとともにお客様事例が発表されました。パートナーも複数公開されました。
Veeva, Apptus, ServiceMaxと、当時のTop 3がすべて日本へやってきて、描いたプランが実現していきそうなので、「この方法でやっていけば自分たちのプランがうまく廻るはず」と思ってしまったのですが、ここからが大変でした。
Apptus, ServiceMaxにはSalesforce自体も投資していましたし、その市場性はある意味Salesforceが保証していたとも捉えることができました。しかし、あまり詳細は書けないのですが、ここでいろいろなイベントが発生します。
Apptusは当時としては言葉として珍しかったCPQ (Configure, Price, Quote；見積もり構成機能)をSalesforce上で提供していました。オンラインで構成を組むから間違ったものを発注、受注しなくなる、というものです。（Salesforceの面接の過程でこの言葉を知り、頭にたたき込みました 笑）
構成アプリの重要性
私がPCでの製品責任者だったときに「誤発注」で悩まされたのはメモリーです。「このPCにはこのメモリー」と決まっているのに、箱は同じようなもの。同じ容量で安い方を選ぶと実はマシンに刺さらない(DIMMの形状が異なる）とか、よくありました。それによって「本来は認めていない返品処理」が発生して例外対応するという事務作業が多く発生していたのです。
例外を適用したのは、「御社の営業が見積もってそれを発注したら使えない」というお客様の指摘に抗弁できなかったからです。何ともお粗末なものでしたが、ツールもなく、現場も混乱していたのでしょう。大きな技術的な変更もときおり（3年周期くらいだったか）起きていたという時代でした。
iPhoneのケーブルがDockからLightingになったり、USBケーブルがUSB-Cになったりして買い間違えたことがある方なら、この話を感覚的にわかっていただけるかもしれません。
正しい構成により価格も決まるので、正しいワークフローで社内承認を済ませ、お客様へ提示していくのがCPQ。これを使わないと見積もりできない仕組みに会社を変えるので、「社内承認なしにお客様に価格がでる」というコンプライアンス違反のようなこともなくなります。Salesforce社内でも使っていたくらいです。（現在使用しているか、は未確認）
ApptusにはライバルBig Machinesがありました。双方で切磋琢磨してアプリを改良してきましたが、あるとき、このBig machinesがリンクを見ていただくとわかる通り、オラクル社に買収されました。買収後にもよくある話ですが、創業チームが結局オラクル社を退社しました。会社を売却したので資金があることから、「再度CPQを作り直そう」と再びSalesforceプラットフォームで作り直し、Steelbrick社を立ち上げました。当然、Apptusの競争相手になりますし、製品に過去のしがらみがなく、もう1回やり直せるのだからUI/UXなどが改善された、最新技術の優れものになっていました。2015年、そのSteelbrick社がSalesforceに買収されました。Apptusと日本でビジネスを立ち上げようとして1年経ったところです。Salesforceから見ればApptusという会社が中心になり、3つほどの大きなCPQアプリが生まれ、市場を形成していたので、自分でも積極的に投資してビジネスを伸ばす方向に動いたのでしょうが、Apptus側はたまりません。
でも日本にはまだ時間がありました。Steelbrickには日本語版もなく、Salesforce自体でもそれを販売していくノウハウもありませんでした。そのころ製造業を中心にパイプラインができていたApptus Japanは売上を伸ばしていきました。ただ、Apptusは2016年に上場を目指していたのにそれが達成できず、2018年には経営がThomas Bravoへと引き継がれ、日本含めた会社の方針が変わっていくことになります。その後のお話は別の回でお話しましょう。
注）アプリ自体は非常によいものですのでユーザーの方もご安心ください。ここでは事業としてやっていく上での苦労話をしています。
ServiceMaxもなかなかの試練がありました。まずはSalesforceの中で（こういうと叱られますが）曖昧な位置づけだったService CloudにSalesforce自身が本腰を入れ始めたことです。Click Softwareからライセンス提供されたField Service Lightning機能を2016年に発表、そこまで「販売プロセスまでがSales Cloud、販売後はServiceMax」のような組み方をしていた現場を揺さぶります。Salesforceの営業にとっては、自社製品がどんどん先行するServiceMax社に追いついていき、また、ロードマップも入手できて明確でした。SalesforceのService Cloudはこのあたりからコンタクトセンター向けアプリとして、Sales Cloudとは違う進化を始めます。これによりServiceMaxからは完全に敵視されるようになりました。また、この後にServiceMax自身がGEに買収され、経営陣が入れ替わります。このときからSalesforceとは距離をおいて「自分たちだけでやる」と言った動きになり、日本でも協業しにくくなりました。それでもお客様にServiceMax商談が生まれたときはSalesforce Japanは自社製品を提案したりせずに、その商談を尊重していたのですが、海外では違ったケースも多かったようです。そのため、英国から日本法人社長になった方にご挨拶に行ったときは、最初から「何をしに来た？」と責められたりしました。あの態度と言動は海外でもなかなかやらないアプローチだと思いますが、それだけSalesforceとの競合が厳しくなっていたことだったと思います。
注）アプリ自体は非常によいものですのでユーザーの方もご安心ください。ここでは事業としてやっていく上での苦労話をしています。
「Top 3を立ち上げて次の3社にいく」というプランは、こうして3社のうちVeevaを除いた2社が微妙な形になり、「次の3社にいく」前に「この2社をどうするか」に時間が割かれることになりました。その間、Salesforceから転身された福田さん率いるMarketoが急成長しているのを見ていました。比べてみれば、ApptusやServiceMaxは結局本国含めて経営が安定しなかったので、日本での成功というところまではたどり着くことができなかったのかなぁ、と思いました。また、SalesforceパートナーにはSalesforceの卒業生がいたほうが圧倒的に物事が早くすすむのも感じるようになりました。
では他のアプリはどうだったか、というと、我々の優先度とは別に様々なアプリが上陸を果たしたり、または、そのプランニング（プラン作成のための情報収集）に来るようになりました。幸い、私はそのほとんど機会に参加でき、米国や欧州から日本上陸目指して活動しているSaaSを、普通の人より先に情報を得られるようになりました。box、dropbox、DocuSign、GaInsight、GLOVIA、Overcast、zuora、asanaなど数えれば多くのパートナー様とお話し合いをさせていただきました。日本でのユーザーも多くなり、SaaSの普及とアプリによるメリットを享受していらっしゃると思います。そんな状況に少しでも寄与できたのであれば、私としては嬉しいです。
まとめ
最初に掲げた毎年3つずつアプリを上陸させる方針がうまくいかなかった下記3点。
a) いつごろ日本へ上陸するべきか、という議論がなされるのか、パートナー視点での考察が足りなかった
b) 上場前の会社なので、財務状況を考察に入れられず、1)は自分たちの好き嫌いという感覚に頼った判断になった
c) 経営陣の交替やSalesforceによるAppExchangeパートナー買収に翻弄された
長く説明してきましたが、a) b) ともにもう少しいろいろ調べるべきだったと思っています。b) からになりますが、CBInsightsやStrainer、Newspicksでの米国情報など今では調べる方法も思いつきます。もちろんSalesforce社内で担当のものから事前情報ももっととれたはずです。a)は米国での事業が安定高成長を続ける前提で、EMEA (Europe, Middle East and Africa; 欧州、中東、アフリカ)が立ち上がってからアジアへ来るのが普通です。理由は日本の方が参入障壁が高い（最もビジネス状況が複雑）から。EMEAと言っても地域では中東やアフリカより欧州が先なので、英語でまずは試せることが2番手の理由でしょう。アジアに5億円年間投資するには100億円規模のアメリカでの売上が必要でしょうし、「3年我慢する」にはそれくらいの体力が必要です。5億円投資してても翌年は100億円の30%成長できている体力があれば会社の経費としては補えます。
なかなか難しかったのはこれを専任で自分で頑張れなかったことです。7割以上はTake Offの仕事をしていく中でのLandingという仕事の優先度でした。この仕事って専門の会社を創ってもできるんじゃないかなぁ、と思っていたら、Japan Cloudという会社をアレン・マイナーさんが創設してやられていました。Salesforceという制約もなく、今は多くの会社に投資して、日本でも成長企業が生まれています。Databricksもこれらの会社に負けないように成長させていきたいです。
この記事が気に入ったらサポートをしてみませんか？