SFA導入が「負の遺産」になる理由──ツール導入支援と収益の仕組み構築は別物

多くの企業は、「ツール導入支援」と「収益の仕組み構築」の違いを意識していない。SFA・CRMを導入しさえすれば、それだけで営業・マーケの課題が解決すると期待してしまうからだ。

しかし実際には、導入後に現場の実態にフィットせず、誰も使わない「負の遺産」と化すケースが非常に多い。ツール自体は動いているのに、そのパフォーマンスを活かしきれず、収益にはまったく繋がっていない——この状態に陥っている企業は少なくない。

結論から言えば、SFA・CRMのプロジェクトは3つのレイヤーでできている。①ツールを動く状態にする「ツール導入支援」、②顧客管理のあるべき姿とデータ構造を描く「収益の仕組み設計」、③その図面を実装に落とし、運用と意思決定に乗せて収益に接続する「収益の仕組み構築」である。発注として買っているのは①だけなのに、期待しているのは③の成果——この食い違いが、負の遺産を生む。

理想的なのは、導入の段階からこの3つを一続きのものとして組み込んでおくことである。そして、すでにSFA・CRMを導入済みの企業であっても、この構造への再構築は可能だ。パフォーマンスを出せないまま放置されている企業が大半である以上、一刻も早く着手すべきテーマだと言える。

多くの現場は、ツールが動かないから失敗するのではない。ツールは動いているのに、仕組みとして繋がっていないから失敗する。

ツール導入支援・収益の仕組み設計・収益の仕組み構築——3つのレイヤー

①「ツール導入支援」——ツールを動く状態にする

「ツール導入支援」とは、SFA・CRM・MAといったツールを、要件定義・設定・データ移行・現場へのトレーニングを通じて稼働状態に持っていく支援である。担当するのはツールベンダーや実装専門のSIerが中心で、成果物は「動くシステム」だ。

このレイヤーには明確な終点がある。ツールが本番稼働し、現場が最低限の操作を覚えれば、契約上のゴールには到達する。裏を返せば、稼働後にその仕組みが収益にどう繋がるかは、契約範囲の外に置かれやすい。

②「収益の仕組み設計」——顧客管理のあるべき姿を描く

「収益の仕組み設計」とは、リード獲得から受注・継続契約に至る一連のプロセスを、どんな顧客データの構造の上に載せるかを描くことである。企業・人・案件・活動をどう関係づけるか、何を正となる情報源とするか、どのKPIで意思決定するか——建築でいえば図面にあたる。

ここで問われるのが、顧客管理の「あるべき姿」を持っているかどうかだ。図面のないまま①へ進めば、出来上がるのは現場の要望の寄せ集めになる。3つのレイヤーのなかで、担い手による差がもっとも大きく出るのがこのレイヤーである。

③「収益の仕組み構築」——設計を実装に落とし、運用に乗せる

「収益の仕組み構築」とは、②の図面を実際のツール設定・データ構造・システム連携に落とし込み、現場の運用と意思決定に乗せて収益に接続するところまでを指す。誰が最終責任を持ち、どのデータを判断基準にするかの取り決めも、ここに含まれる。CRMアーキテクトと呼ばれる専門家が、データ構造の設計とMA・SFAの連携正常化を通じてこれを担う。

このレイヤーに終点はない。ツールが稼働した後こそが本番であり、意思決定の精度と再現性を継続的に高め続けることそのものが成果になる。

なぜこの違いを見誤ると失敗するのか

ツール導入止まりのプロジェクトが失敗する理由

失敗の多くは、ツールの性能不足が原因ではない。②の設計レイヤーが丸ごと抜け落ちていること——つまり、支援する側に「顧客管理のあるべき姿」、すなわち思想がないことだ。

思想がなければ、提案は必ず「御社の要件を教えてください」から始まる。顧客が語った要望を漏れなく拾い、そのとおりに構築する。一見すると誠実な進め方だが、ここには決定的な欠落がある。挙がってきた要件が、そもそもあるべき姿に照らして正しいのかを、誰も判定できないのだ。

プロジェクトの本来の目的は、SFAを動かすことではなく収益を拡大することである。であれば、一つひとつの要件は「それは収益の拡大に効くのか」で取捨されなければならない。その判断基準を持たないまま要件を積み上げれば、出来上がるのは現場の要望の集合体であって、収益の仕組みではない。「導入した後、誰がその仕組みを運用し、意思決定に落とし込むか」が最後まで決まらないのも、元をたどれば同じ原因に行き着く。

その帰結は、自社調査にも数字として表れている。BtoB事業に従事する営業・マーケティング職400名に組織の整備状況を4段階で聞いた『レベニューオペレーション調査レポート2026』では、ツール領域10項目のうち最下位が「レポート活用」の2.26だった。「MA/SFA導入」は2.42。ツールは入れたところまでは進んでいて、そこから出てくるデータを意思決定に使う段階がいちばん遅れている、という並びである。

仕組みが繋がっている場合の成果

一方、Demandbase Labsの分析では、CRM・MA・予測スコアリングを連携させている組織のMQA（マーケティングが有望と判定したアカウント）転換率は3.62%で、連携が限定的な組織の2.37%を53%上回った。同社プラットフォームの利用企業を対象とした分析であり、母集団はそこに限られるが、繋がっているかどうかが転換率の差として観測できることは示している。

海外ではこの違いがすでに方法論化されている。Winning by Designが提唱する「Revenue Architecture」は、これを体系化した概念だ。核となる原則は、「運用基盤とプロセス設計の確立は、自動化やAI導入に先行すべきである」というものである。

4つのパートナー類型は、どのレイヤーまで担えるか

営業コンサル・SIer・ツールベンダーの役割分担

ツールベンダーは「How＝どう実現するか」に強く、実装の巧拙が稼働の安定性を左右する。SIerは大規模なカスタマイズや複雑な要件定義に対応できるが、契約範囲はやはり実装に軸足がある。この2つが担うのは①ツール導入支援だ。

一方、営業コンサルが立つのは②収益の仕組み設計のレイヤーである。「Why・What＝何のために、何を」を描き、収益プロセスとKPIを設計するのがその役割だからだ。問題は、そこから①へ手が届くか、そして③まで面倒を見るかである。図面だけを納品して実装は別会社に引き継ぐ契約形態であれば、レイヤーの継ぎ目は残ったままになる。

なお、近年よく聞く「RevOpsコンサル」は、名前こそ新しいが、分類としてはCRMアーキテクトと同じ側にあたる。3つのレイヤーを通すことを前提に置いた考え方だからだ。看板に書かれた言葉ではなく、実際にどこまで担うのかで見たほうがいい。

必要なのは、3つのレイヤーを1本で通せる相手だ。そのうえで、もう一段だけ本質的な分岐点がある。同じ②を名乗っていても、顧客管理のあるべき姿を先に持っている会社と、持たないまま要件を聞きに来る会社とでは、出てくる図面がまったく違う。パートナー選定で見るべきは、看板の類型ではなくこの一点である。

「AIエージェント」は万能の第5の選択肢になり得るか

近年、SFA・CRMにAIエージェントを組み込む動きが急速に広がっている。Gartnerは、タスク特化型AIエージェントを組み込むエンタープライズアプリの割合が、2025年の5%未満から2026年には40%に達すると予測している。自律的に判断し実行するAIエージェントは、一見②や③まで代替してくれる存在に見える。

しかしGartnerは同時に、エージェント型AIのプロジェクトの40%超が2027年末までに中止されるとも予測している。理由はコストの膨張、ビジネス価値の不明確さ、そして不十分なリスク統制である。突き詰めれば、どんなデータ構造の上で、どこまでの判断をAIエージェントに委ねるのかという設計の欠如だ。これは、ツール導入止まりのプロジェクトが陥る罠と、構造的にまったく同じである。AIエージェントは①の選択肢を増やすが、②の図面を描くという仕事そのものを肩代わりしてはくれない。

見極め方——パートナー候補の「思想」をどう確かめるか

責任範囲を問い詰めても、判断材料にはならない

まず、あまり意味のない問いを外しておきたい。「稼働後、KPIが未達だった場合、どこまで踏み込んで見直してくれますか」という類の質問である。支援する側にも事業があり、人が動けばコストが出る。契約範囲を超えて無制限に伴走するパートナーは存在しないし、その場で「もちろん最後まで見ます」と答えが返ってきたところで、判断材料にはならない。ここは精神論で詰める場面ではない。

見るべきは「顧客管理のあるべき姿」を持ち込めているか

判別できるのは、提案の中身のほうだ。こちらが要件を語る前から、顧客管理のあるべき姿を型として持ち込めているか。具体的には、次のような論点が提案側から先に出てくるかを見るといい。

• 顧客データがSSOT（Single Source of Truth＝唯一の正となる情報源）として設計されているか
• 企業・人・案件・活動の関係が、リレーショナルデータベースとして正しく構造化されているか
• 属性のような静的データと、行動履歴のような動的データを、どう結びつけて使うかの考えがあるか
• これから本格化するAI活用を、そのデータ構造の上でどう成立させるかを描けているか
• こちらが説明する前に、自社の顧客管理のどこがボトルネックになっているかを推察して言い当てられるか

いずれも理念的な話ではなく、②の初手で必ず決めることになる具体的な判断である。思想を持っている相手は、初回の提案からこの前提で話し始める。

逆に、初回から「御社の課題は何ですか」「まずは要件整理から始めましょう」という言葉が出てくる相手は、難しいと考えたほうがいい。丁寧に聞いてくれているように見えて、実際には持ち込むべき型がないということだ。要件を聞いてから考える会社は、その要件が正しいかどうかを判定できない。

AIエージェントを検討している場合も、見るところは変わらない。「このエージェントは、どのデータを正として判断するのか」と聞いてみるといい。SSOTが定まらないまま自律的な判断だけを載せれば、誤った前提のまま高速に誤り続けることになる。

CRMアーキテクトとして3つのレイヤーを一気通貫で担う、という選択肢

本来、この3つのレイヤーは分断されるべきものではない。ツールの設定値ひとつが、意思決定の質を左右するからだ。CRMアーキテクトとしてプロジェクトに参画し、顧客管理のあるべき姿を図面として先に置き、データ構造の設計とMA・SFAの連携正常化を実装と同じ手の中で担い、稼働後の意思決定に乗るところまで見届ける。それが、レイヤーの継ぎ目でも思想の不在でも失敗を生まないための、もうひとつの選択肢である。

よくある質問

Q. 「ツール導入支援」と「収益の仕組み構築」は何が違うのですか？ A. SFA・CRMのプロジェクトは、①ツールを動く状態にする「ツール導入支援」、②顧客管理のあるべき姿とデータ構造を描く「収益の仕組み設計」、③図面を実装に落とし運用と意思決定に乗せる「収益の仕組み構築」の3層でできています。①だけを買って③の成果を期待すると噛み合いません。

Q. なぜこの違いを見誤ると失敗するのですか？ A. ②の設計レイヤーが抜け落ち、支援側が顧客管理のあるべき姿（思想）を持たないまま、聞いた要件をそのまま構築してしまうためです。その要件が収益拡大に効くのかを誰も判定できないまま進むため、ツールは動いても意思決定には使われません。

Q. 営業コンサルやRevOpsコンサルに頼めば「収益の仕組み構築」まで任せられますか？ A. 営業コンサルが立つのは②「収益の仕組み設計」のレイヤーで、図面のみを納品し実装は別会社という契約形態も多くあります。「RevOpsコンサル」は分類としてはCRMアーキテクトと同じ側にあたりますが、実際に①〜③のどこまで担うか、そして思想を持っているかは会社によって異なります。

Q. AIエージェントを導入すれば、この課題は解決しますか？ A. しません。Gartnerは、エージェント型AIのプロジェクトの40%超が2027年末までに中止されると予測しています。理由はコストの膨張・ビジネス価値の不明確さ・不十分なリスク統制で、どのデータを正として何を委ねるかという設計の欠如という点で、従来の「ツール導入止まり」と同じ構造です。

Q. パートナー候補が3つのレイヤーを担えるか、どう見極めればいいですか？ A. 「顧客管理のあるべき姿」を先に提示できるかで判別できます。SSOT・リレーショナルな構造化・動的データと静的データの結合・AI活用まで含めた型を持ち込み、聞く前にボトルネックを推察できる相手かどうかを見てください。「まずは要件整理から」で始まる相手は難しいと考えたほうがよいでしょう。

Q. すでにSFA・CRMを導入済みの場合は、どうすればいいですか？ A. 導入済みでも、収益の仕組みへの再構築は可能です。むしろパフォーマンスを活かしきれていない企業の方が多いため、放置せず早期に着手することを推奨します。