※本記事はDarsana ID会員記事です。記事の続きは会員登録（無料）の上、ログインしてご覧ください。

　うまく使えば業績アップのための強力な武器になるが、実装や運用の方法を誤るとせっかくの機能が宝の持ち腐れになってしまう──。CRM（Customer Relationship Management）・SFA（Sales Force Automation：営業支援システム）ツールのデファクトスタンダードとして知られるSalesforceは、そんな風に言われることもしばしばだ。

　AnityA（アニティア）が2021年5月に開催したイベントの前半では、元セールスフォース・ドットコムの営業部長として数多くのSalesforce導入・運用プロジェクトを間近で見てきた株式会社digsasのFounder＆CEO 石井友規氏が「可燃性の高いCRMを安全に取り扱うために知っておきたいこと」と題したプレゼンテーションを行い、導入失敗の具体的なパターンや、導入を成功させるために欠かせないポイントについて解説した。

　イベントの後半ではこのプレゼンテーションの内容を受けて、HR Techベンチャー企業においてSalesforceの導入・運用を長年リードしてきた祖川慎治氏と、AnityA 代表取締役 中野仁氏、それに石井氏を加えた3人によるパネルディスカッションと、イベント参加者からの質問に答えるQAセッションが行われた。本記事では、その内容をダイジェストで紹介する。

　なお、石井氏のプレゼンテーションの内容は、別途「『ぼくがかんがえたさいきょうのCRM』は、だいたい失敗する──元“Salesforceの中の人”が伝授する「導入の失敗を避ける8つのポイント」と題した記事で紹介しているので、そちらを一読いただきたい。

ベンダー側担当者の行動原理を理解した上で交渉に臨む

中野氏：　私はこれまでSalesforceの導入や再立ち上げのプロジェクトを何度か経験してきましたが、石井さんのプレゼンテーションを聞いてあらためて、CRMの概念を正確に理解することの大切さが分かった気がします。

　「CRMはインプットとアウトプットが不明確」「業務にシステムを合わせがち」という話も、CRMプロジェクトが炎上しやすい理由としてとても腑に落ちましたね。ちなみに祖川さんも、これまで数々のSalesforce立て直しプロジェクトを担当してきたんですよね？

祖川氏：　そうですね。導入後2、3年経ってもなかなか活用や定着が進まない状態のSalesforceを引き継いで、あらためて有効活用できるようにするためのさまざまな取り組みを進めてきました。

　引き継いだ当初は、ようやく顧客情報のデータベースが出来上がって、商談の情報もこれから蓄積していこうかという段階でした。そこからさまざまな部署の業務をヒアリングしながら、より実務で役立つ使い方を模索しながら少しずつ定着化を図っていきました。

中野氏：　先ほどの石井さんのプレゼンテーションでは、炎上しやすいCRMプロジェクトの典型例が幾つか挙げられていましたが、やはりセールスフォース・ドットコム社の営業の立場から見ても、「これは炎上するな」というプロジェクトは分かるものなのでしょうか。

石井氏：　セールスフォース・ドットコムの営業は、短期間のうちに最大の売上を上げるよう会社から命じられているので、どうしても成約した後の導入プロジェクトのフォローまで手が回らないんですね。かといってインプリを直接支援するチームやサービスが充実しているわけでもないので、自ずとパートナー企業に任せきりになりがちです。

　一方、パートナー企業の担当者は技術寄りの方が多いので、セールスフォース・ドットコムの営業がお客様に提案したビジネスプランをなかなか理解しきれず、どうしても理想と現実の間のギャップが生まれて炎上しやすくなります。

中野氏：　セールスフォース・ドットコムに限らず、外資系ベンダーの営業は大体同じような動き方をしますよね。短期間のうちに最大規模の契約を勝ち取って、なるべく早期にインセンティブボーナスを得ようとする。逆にいうとユーザー側としては、ベンダー側のそうしたインセンティブ体系や行動原理を理解しておいた方が交渉を有利に運ぶことができますね。

ベンダーやSIerに頼りきりになるのではなく自社で主体性を持って取り組む

石井氏：　ちなみにイベント参加者の方からは、「セールスフォース・ドットコムにはカスタマーサクセスの部隊がありませんでしたっけ？　営業よりはそちらに期待したいです」というコメントをいただいています。

祖川氏：　実は一度、弊社のカスタマーサクセスチームのベンチマークのために、セールスフォース・ドットコムのカスタマーサクセスチームの業務をヒアリングさせていただいたことがありました。そのときにうかがった話では、少数の大規模クライアントを担当する「ハイタッチ」のチームと、その他のクライアントをまとめて担当する「ロータッチ」のチームがあるとのことでした。

石井氏：　ちなみにハイタッチチームのメンバーは精鋭ぞろいで、外部からコンサルタントを雇うのと同等レベルの高品質な支援を提供しています。でもハイタッチの対象となるクライアント企業は、それこそ年間何億円ものライセンス料を支払っているほんの一握りの大規模ユーザーに限られます。大多数のユーザー企業はこの恩恵にあずかることはできないので、カスタマーサクセスに過度な期待はしない方がいいですね。

　むしろ外に頼るのではなく、「自分たちでやるんだ！」という主体性を持たないとSalesforceをうまく使いこなせるようにはならないと思います。

祖川氏：　初期構築時こそSIerの支援を仰ぐのはいいと思いますが、Salesforceは導入後の運用フェーズでの改善が最も重要ですから、運用までSIerに丸投げしてしまうと改善スピードがなかなか上がらず、結局現場になかなか定着しません。

石井氏：　SIerはSalesforceのライセンスを卸すだけではほとんど儲かりませんから、導入時の開発工数をなるべく膨らませようとする傾向にあります。その結果、本来はSalesforceの標準機能だけでできるはずの機能も独自開発を提案し、その結果、とてつもないコストが掛かってしまいます。もちろん、実際の構築作業をSIerに任せるのは全然アリですが、上流工程まで丸投げするべきではありません。

祖川氏：　同感ですね。ちなみに私が手掛けるプロジェクトでは、パートナー企業のエンジニアに手助けしてもらうこともありますが、基本的には設計と運用を内製しています。

大抵のユーザー要件は「Salesforceの標準機能だけ」で実現できる

石井氏：　「本来はSalesforceの標準機能だけで作れるはずなのに、カスタマイズを大量に行ったせいで保守が大変になって困っています」という質問もいただいています。おそらく、いわゆる「カスタム商談」と呼ばれるカスタマイズを行っているものと想像しますが、こういう場合は思い切って腹を決めて、標準オブジェクトに戻すことをお勧めします。

　でないと、Salesforceのエコシステムの恩恵を受けられなくなってしまいます。Salesforceはパートナー企業のさまざまなアプリケーションとの連携ソリューションを提供していますが、これらはすべて「標準オブジェクトを前提に」設計されていますので、カスタム商談のままではこれらが一切使えません。

祖川氏：　カスタム商談では、MA（Marketing Automation）との連携もできませんからね。

　また「いろんな部署から要望を受け付けているとSalesforceがキメラ化してしまいます。ハンドリングはどの部署がするべきでしょうか？」という質問もいただいていますが、個人的にはすべての要望を叶える必要はないと考えています。

　もちろん要望をいったんは受け付けますが、ただ言われるがままに作り込むのではなく、まずは標準機能だけでできる範囲をデモで見せて「本当にこれ以上が必要なの？」と聞くようにしています。

石井氏：　「その機能がなぜ必要なのか？」ということを詳細にヒアリングして、ほかの手段で実現可能かどうかを検討してみると、7〜8割の要望は消えます。もし、対応する場合も、Salesforce独自の開発言語であるApexでプログラムを書くことはなるべく避けるべきです。

　大抵の機能は標準機能で実現できますし、どうしてもApexで書かなくてはいけない要件が上がってきたら、プレゼンテーションでも話しましたが、その要件は「自社都合なのか、それともお客様の要望なのか」を聞いてみてください。そうすれば、大抵の場合は書かなくてもよくなるはずです。

祖川氏：　それでもなお、どうしても書かなくてはならないケースというのは出てくると思います。そんなとき私はよく、「分かりました、プログラムを書きます。でもその代わり出来上がったら、現場での利用と定着を絶対に推進してください」と約束を交わします。

　それも単なる口約束ではなく、「1カ月後にこれだけの数値が達成できていなかったら、開発したプログラムを消します」と宣言します。こうしてユーザーにもコミットしてもらうという手法はよく使っていて、実際に目標値が達成されなかったのでプログラムを消したこともあります。

アドミン人材をどうやって確保すればいいのか？

石井氏：　「現在、営業とアドミンを1人でやっている状況です。アドミンアシスタントやアドミンの後継人材を雇用したいと考えているのですが、年収相場などありますか？」という質問もいただいています。

　個人的には「600万円スタート」ぐらいの印象を持っていますが、どうでしょう？

祖川氏：　そうですね、まあ500万円以上なら間違いないかと思います。ただ、単にシステムの管理を行うだけではなく、社内の業務改善を自ら率先してリードしていけるような人材となると、もうちょっと高くなるかもしれません。

石井氏：　他のイベント参加者の方から「営業事務上がりの人に要件定義はハードルが高いので、SIerからパートナーのコンサル上がりを引っ張ってくるのが現実的なのでは？」というコメントをいただきましたが、それはその通りだと思います。

　大手SIerの20代の若手SEやPM見習いぐらいの人は年収600万ももらっていないですから、それぐらいの人を引っ張ってくるのが妥当な線なのかもしれません。

　ただ、個人的には、「とにかく外から人を引っ張ってくればいい」という考え方には賛同しかねます。それまで社内でアドミンを育成する取り組みを全く行っておらず、アドミンのジョブディスクリプション自体が決まっていない状態で、いきなり外から人を連れてきても、恐らくは機能しません。

　確かに、営業事務をしていた人が要件定義をするのは難しいでしょうが、その代わり社内のコンセンサスを取り付けるのはうまかったりします。一方、SEは要件定義はできても、社内の根回しは苦手だったりしますから、両者がタッグを組むのがいいような気がします。1人の人間にすべてを求めようとするから、なかなか人材が見付からないのではないでしょうか。

祖川氏：　「役割をちゃんと分割して割り振りましょう」ということですね。

石井氏：　「営業担当の執行役員の直下にパートナー上がりのコンサルレベルを主アドミンとして置かないと回りませんよ」というコメントもいただきましたが、確かにそういう優秀な人材を雇える会社はそういうやり方がベストでしょうね。

　ただ、ここで重要なのは「執行役員の直下に」というところではなくて、アドミンに「執行役員の権限を委譲する」という点ですね。偉い人に皆の前で「この人がアドミンとして行うことに文句がある人は、私に直接言いに来てください」と宣言してもらえば、皆、面白いようにアドミンの言うことを聞いてくれるようになります。

　でも、そうやって「俺がケツを持ってやる！」という気概を示してくれる人は、実際にはなかなかいませんね。むしろ、Salesforceを買ったとたんに逃げ出してしまう上の人の方が多いような気がします。

中野氏：　外資系ベンダーの製品・サービスは、会社の上の人同士で商談を決める、いわゆる「トップセールス」が多いのですが、そうやって話を決めた当人が逃げ出してしまうと「この製品、そもそもな何のために入れるんだっけ？」「いや、上の人が決めた話だから……」みたいな状態になって、ほぼ確実にプロジェクトが炎上してしまいますね。

導入・運用は外部に丸投げするのではなく内製をベースにすべし

石井氏：　とあるイベント参加者の方から「Salesforceですら追加開発が必要で運用が大変なのに、なぜシェアでは他社より売れているのでしょうか？　ほかの機能がひどすぎるから？　スクラッチで開発する方がまだましなように思えてきました」という率直な意見もいただいています。

祖川氏：　むしろ「容易に機能拡張できる柔軟性があるからこそ売れている」というのが正しいような気がしますが。

石井氏：　ちなみにセールスフォース・ドットコムの社内では、項目や設定や表示を変更するだけの、ノンコーディングで機能を拡張できる範囲を「カスタマイズ」と呼んでいて、Apexでコードを書いたり外部サービスをAPI経由で呼び出したりするような拡張を「開発」と呼んでいます。

　この定義に従って説明すると、90％以上の要件は開発は不要で、カスタマイズだけで実現できます。ただ、問題は、そのカスタマイズの作業すら外部のパートナーに丸投げしてしまう企業が多いところにあります。

　カスタマイズ自体は決して難しい作業ではなく、Excelに毛が生えた程度のものなので、ぜひユーザーが自ら行うことをお勧めします。この部分をパートナーに丸投げしてしまうと、以降は自社でSalesforceを一切触れなくなって、パートナーの言いなりになってしまいます。

　もし、パートナーの支援を仰ぐとしても、内製を前提とした上で、もし分からないことが出てきたらアドバイスを求めるような付き合い方がいいと思います。

中野氏：　特にプロジェクトの初期では、絶対に「自分たちで手を動かした方がいい」ですね。実際に自分たちでやってみないと中身は理解できませんし、パートナーやベンダーが提示する見積もりの妥当性を評価することもできなくなってしまいます。従ってパートナーさんには、技術アドバイザリーのような形で入ってもらうのがいいと思います。

石井氏：　「会社の統廃合で、2社それぞれのSalesforce組織を1つに統合しなければならない可能性があるのですが、注意点はありますか？」という質問もいただいています。

　データのクレンジングと移行がかなり大変な作業になるので、ある程度の「覚悟」と「諦め」が必要ですね。すべてのデータを移行しようとするのではなく、むしろ「どれだけデータを捨てられるか？」に目を向けるべきです。

祖川氏：　移行後も旧環境にアクセスして過去データを参照できるように、1ライセンスだけ残しておくことをお勧めします。これを忘れていると、ライセンス削除後に一定期間が過ぎると「データがすべて消えてしまう」ので、その点には注意が必要ですね。

石井氏：　ただ、1ライセンスだけ残しておく際には、データストレージの容量オーバーで規約違反になる恐れがある点には注意しておかなければなりません。従って理想としては「外部システムにデータを退避させる」か、もしくは思い切って消してしまうことをお勧めしたいですね。

Salesforceに基幹システムの機能を載せようとするのは炎上必至！

石井氏：　先ほどの話とも関連するのですが、「もう1つ環境を新たに契約して、すべてをまっさらな状態から始めたいという衝動に定期的に駆られます」というコメントもいただいています。

　これは全くその通りですね。Apexまみれでぐちゃぐちゃになってしまった環境を無理して改修するより、もし可能であれば一から再構築した方が絶対にきれいな環境になりますから。

祖川氏：　ただ、実際に旧環境を捨てるとなると、データ移行をはじめさまざまな課題が出てきますよね。ここで思い切って旧環境のデータを捨てられればスムーズに移行できるでしょうが、現実的には現場ユーザーからかなりの抵抗が予想されます。

石井氏：　そうですね。ただ、「再構築を検討する」ということは、「そもそも旧環境の設計に失敗している」ということですから、まずはその点を自覚してもらうことが重要です。その上で、再構築の意義を「SaaSはオンプレミスと違って、いったん導入したからといって5年間使い続ける必要はないんですよ。思い立った時点で捨ててやり直せるのがメリットなんですよ」と、各ステークホルダーを説得して回るしかないと思います。

祖川氏：　忙しい現場の人たちを含め、そこに価値を見いだしてくれるかどうかが勝負ですね。あと「Salesforceに商品在庫管理の機能を持たせようと思うのですが、どんな作り方をするのがお勧めでしょうか？」という質問もいただいているのですが……これは絶対にやめた方がいい！

石井氏：　Salesforceはデータベースの構造上、月や期といった単位でざっくりした統計データを参照するのは得意なのですが、在庫管理のように日々変動するデータの正確性を担保するような使い方には全く向いていません。

　「Sales Cloudの環境に勤怠管理や経費精算、電子稟議機能を乗せるのはいかがです？」という質問もいただいていますがこれも「餅は餅屋」で、Sales Cloudの機能だけで無理やり実現しようとするより、最初からTeamSpiritなどのSaaSを使う方が絶対にいいです。

祖川氏：　Salesforceのワークフロー機能は欧米企業の組織体制を前提に作られているので、兼務をはじめとする日本企業特有の組織体制とは決して相性がいいとは言えません。ですから、特定のグループや業務の中で小さく運用するようなワークフローなら使えますが、全社レベルの共通ワークフローとして運用するとなると正直なところ、あまりお勧めはできませんね。