どの CRM Migration にも、システムが「プロジェクト」ではなく「チームがこれから共に生きるプロダクト」に変わる瞬間があります。たいてい Go-live の 1 週間ほど前に起きます。Pipeline は設定済み、プロパティはマッピング済み、Workflow は Sandbox で予定どおりに起動する。実装パートナーが Champion にデモを見せます。すべてが動きます。
そこで Champion がこう言うのです。この一言は、すべての RevOps チームにとって警告シグナルであるべきです。これをユーザーに自信を持って説明する自信がありません。
ビルドが間違っていたからではありません。いくつかのフィールドに、どのトリガーに由来するのか追跡できない値が入っていたからです。システムの展開を担う人間がシステムの挙動を説明できないなら、ユーザーに説明できるはずがありません。
なぜこれが繰り返されるのか
「システムが動く」と「チームがシステムを信頼する」のあいだのギャップ、ほとんどの CRM Migration が静かに失敗するのはここです。ローンチが延期されて請求書が争われるような派手な失敗ではありません。静かな失敗です。Adoption が 40% で横ばいになり、VP of Sales が Go-live から 2 週間でシャドウスプレッドシートを作り始めるような。
Harvard Business Review は最近、これを「ラストマイル」問題として捉えました。技術的な能力は揃っているのに、組織設計が追いついていない（Lakhani, Spataro, and Stave, HBR, March 2026）。CRM 版のラストマイル問題は具体的で、予測可能です。実装はデータモデル、Automation、Integration を届けます。スコープを切り、見積もりを出し、デモできる 80% です。多くの場合、届かないのは「なぜこのフィールドが変わったのか？」という問いに対する答えです。ユーザーが画面上で予想外のデータを見たときの。
Forrester の 2026 年 Enterprise Software 予測も同じパターンを裏づけています。ツールが進化しても、ビジネスプロセスの標準化が根強い障壁として残る（Naik Lopez et al., Forrester, November 2025）。CRM も例外ではありません。Adoption のリスクは、システムが「できるかどうか」にはありません。ユーザーがシステムの挙動を予測できるかどうかにあります。
クレバーな Automation vs. 透明な Automation
私たちが CRM ビルドに Embedded で入っているとき、Automation の設計判断のたびに 2 つの哲学が競合します。クレバーにするか、透明にするか。同じゴールに聞こえます。違います。
クレバーな Automation はユーザーの手間を最小化します。フィールドを自動入力し、他のオブジェクトから値を導出し、Deal Stage をまたぐ条件ロジックを走らせ、レコードのオーナーシップを黙って更新します。紙の上ではエレガントです。デモでは見栄えがします。問題は、クレバーな Automation がユーザーの依頼していないアウトプットを生み出し、多くの場合ユーザーが説明できないことです。
透明な Automation はやることが少ない。しかし、ユーザーは常に「なぜ」を答えられます。Close Date が更新されたのは、自分が Deal を Closed Won に動かしたから、自分がやった、理解できる。Next Meeting フィールドが入ったのは、システムがカレンダーを読んだから、自分で確認できる。一方の設計は手間の削減を最適化します。もう一方は予測可能性を最適化します。
だから私たちはこのフレーミングに何度も立ち返ります。ユーザーが説明できない Automation は、ユーザーが迂回する Automation です。
Adoption ギャップが本当にどこにあるか
Adoption ギャップはプロジェクト計画には現れません。ビルドが技術的に完了した後の、3 つの具体的な瞬間に現れます。
1. Champion ウォークスルー
ロールアウトを担当する人物が、実装パートナーなしで初めてシステムに向き合います。説明できないフィールドに出くわしたら、日付のはずが数値で表示される、目に見えるトリガーなしにオーナーが変わっている、エンドユーザーが 1 人もログインする前にシステムの信頼が失われます。
最近、Salesforce から HubSpot へ移行するグロースステージの B2B 企業と仕事をしました。社内の Champion は技術的に鋭く、プロジェクト全体を通じて深く関与し、毎回の Sprint Review で的確な質問をしていました。しかし、新しいレイアウトをチームに見せる段になると、自信が持てなかった。ビルドが間違っていたからではありません。いくつかの自動フィールドに、Workflow まで追跡できない値が表示されていたからです。
2. テストされなかったエッジケース
Automation は Happy Path では完璧に動きます。それがビルドされたパスだからです。信頼を壊すエッジケースとは、デモでは決してカバーされないケースです。
たとえば、ある Embedded 実装で、Account オーナーシップの Automation が Deal Stage の進行に応じてオーナーをローテーションする設計でした。Lead オーナーから Account Executive へ、Account Executive から Customer Success へ、Customer Success から Account Manager へ、各遷移は Deal が前に進むことでトリガーされます。新規 Deal が Pipeline を通過するケースではすべて正しく動きました。しかし、チームが失注案件をまとめて再配分したとき、Lead オーナーを再アサインしてセカンドパスを試みたとき、Automation は黙って失敗しました。Lead オーナーフィールドは更新されましたが、Account オーナーフィールドは追従しませんでした。再配分された失注 Deal は誰もテストしていませんでした。Happy Path がきれいに見えていたからです。
この種のサイレントな失敗は、バグよりも高くつきます。「システムは自分が言うとおりに動いている」というチームの信念を壊すからです。
3. 「賢い」つもりのシステム
あるクライアントの Champion が、どのコンサルタントよりもうまく言い表しました。システムは賢くあろうとする。でも賢くない。そして、それは最初から賢くないよりもたちが悪い。
ユーザーが手動プロセスを期待し、実際に手動であれば、何をすべきかわかります。ユーザーが Automation を期待して間違った値を受け取ると、修正すべきか、無視すべきか、エスカレーションすべきかわからなくなります。そしてシステム全体を信頼しなくなります。これが Adoption ギャップです。壊れているか動いているかの差ではなく、予測可能か不透明かの差です。
透明な Automation チェックリスト
Go-live 前に、Automation レイヤーに対して 5 つのチェックを実施します。動くかどうかではなく、ユーザーが説明できるかどうかのチェックです。
- すべての自動フィールドを、ユーザーアクションまたは文書化されたシステムイベントに紐づける。ユーザーが「これは自分が X をしたから変わった」または「これはデータウェアハウスとの夜間同期で更新される」と言えないなら、その Automation は不透明です。トリガーを見える化するか、Automation を外してください。
- Unhappy Path をテストする。再配分された Deal、再オープンされたチケット、手動でオーバーライドされたステージ、関連企業のない Contact。デモでは決してカバーされず、ユーザーが 3 日目に直面するパスです。
- Champion にソロウォークスルーをさせる。実装パートナーは同席しません。同僚にすべての非自明なフィールドを説明できないなら、その Automation はこのチームの現在の成熟度に対してクレバーすぎます。もちろん鵜呑みにしすぎてはいけません、すべてのフィールドに説明が必要なわけではありません。ただし、Deal や Contact のプライマリビューに表示されるものには必要です。
- フィールド説明に Automation 名を記載する。HubSpot も Salesforce もフィールドレベルの説明をサポートしています。「Updated by [Workflow: Deal Stage Progression]」と書くだけでコストはゼロ、質問が出る前に答えを示せます。
- トレーニング用に 1 ページの Automation マップを作る。完全な Workflow ダイアグラムではなく、平易なテーブルです。このフィールド、このトリガー、この期待される挙動。テーブルが 15 行を超えたら、Automation レイヤーはおそらくチームの成熟度に対してクレバーすぎます。
成熟度の問い
これはチームの現在地に少し依存します。CRM を 3 年使い、専任の RevOps 機能を持つ企業は、よりクレバーな Automation を吸収できます。予想外の挙動をデバッグするコンテキストがあるからです。初めて Migration するチーム、あるいは RevOps の成熟度を自ら「機能しているが本格的ではない」と評するチームには、デフォルトとして透明な Automation が必要です。
これは評価ではありません。ステージングの判断です。信頼が確立された後で、いつでもクレバーな Automation を重ねられます。しかし、初日からチームが追えない Automation を出して失った信頼は取り戻せません。
そして実践的なテストがあります。ユーザートレーニングの担当者が Workflow ダイアグラムを読まずにシステムの挙動を説明できないなら、Automation はチームの準備度に先行しています。一段戻してください。透明が先。クレバーは後。
出典
- Lakhani, K. R., Spataro, J., & Stave, J. "The 'Last Mile' Problem Slowing AI Transformation." Harvard Business Review, March 2026. hbr.org
- Naik Lopez, A., Medhora, F., Cicman, J., Leggett, K., & Martorelli, B. "Predictions 2026: AI Agents, Changing Business Models, and Workplace Culture Impact Enterprise Software." Forrester, November 2025. forrester.com
Noah Charak