CRM go-live：プロジェクト計画が見落とすものを見つけるdry run

ほとんどのCRM移行はタスクリストとして管理されます。データをマッピングし、workflowを構築し、トレーニングを予定し、launchの日付を決める。リストが緑になり、誰かがプロジェクトを完了と宣言し、go-liveの朝、顧客と接する担当チームは、誰も実際にend-to-endで使ったことのないシステムにログインします。まさにその瞬間に欠陥が現れます。本番環境で、レコードの中に実在の顧客がいる状態で、です。

問題は、タスクリストが作業の完了を確認しても、フローの機能を確認しないことです。workflowは構築されていても、誤ったtriggerで発火し得ます。propertyはマッピングされていても、repが決して開かないviewに着地し得ます。pipelineは設定されていても、leadが入るstageから、dealが成約するstageまでの経路が無いこともあります。そのいずれもstatus sheetには現れません。実在のレコードがjourney全体を通ろうとする最初の一回で現れます。そしてその最初の一回がgo-liveであれば、人々がその上で売ろうとしている最中に、収益インフラをデバッグすることになります。

かつてはシステムに、荒いlaunchを吸収する余裕がありました。数名が壊れたworkflowを1週間消火し、adminが本番で手当てし、チームはなんとかadoptionにたどり着きました。そのクッションはほぼ無くなりました。SaaStrの2026年GTM分析によれば、今年、中央値の企業はRevOpsのheadcount成長をゼロパーセントと見込み、GTM組織は以前より20〜30パーセント筋肉質で、はるかにフラットです。失敗したcutoverを吸収していた人々は、もう組織図に存在しません。

反対側のリスクも高くなっています。試行回数は多くありません。SaaStrが2026年のCRM lock-inに関する記事で述べているように、移行は通常、二度行うには「正当化するには痛みが大きすぎる」ものであり、CRMの上にagentや自動化を配線していくほど、乗り換えは面倒から「事実上不可能」へと変わります。CRM go-liveは、ほぼ一方通行のドアです。dry runは、そのドアが正しい部屋に開くことを確かめる方法です。

すべての移行計画に焼き付けたい区別はこれです。確認には2種類あり、チームは決まって最初の一つを集め、二つ目を飛ばします。

最初はタスクの確認です。データがマッピングされ、workflowが構築され、viewが設定され、トレーニングのデッキが書かれている。これは必要であり、プロジェクト計画が追うものです。二つ目はフローの確認です。実在の顧客が始める場所から始まる実在のレコードが、成約したdealまで通り抜け、その途中で触れるすべてのstage、property、workflow、viewが、あるべき動作をする。二つ目に時間を確保する人はほとんどいません。これはCRM go-liveの前に買える最も安価な保険であり、launchの日付がきつくなると切られる工程です。

dry runはデモではなく、adminがhappy pathをクリックして回るsandboxでのUATでもありません。launchしようとしているシステムで、各パートを担当する人が実際に行う、customer journey全体の時間を区切ったend-to-endのリハーサルであり、何が壊れるかを的確に探すものです。

私の推奨はこうです。2時間を確保し、画面にレコードを1件置き、チーム全員の前で、最初の接点から成約したdealまで通します。leadが入る。正しいpipelineに着地するか。発火すべきworkflowは実際に発火するか。repがcontactを開いたとき、同僚と同じviewが見えるか、それとも5種類の異なるレイアウトがあって誰も同じデータを見ていないのか。dealがstageを進めたとき、次のアクションは生成されるか。成約したとき、onboardingやserviceへのhandoffはtriggerされるか。パーツが存在するかをテストしているのではありません。パーツが繋がるかをテストしているのです。

それを実際に、一緒に、声に出して行う理由は、欠陥が人それぞれの作業のつなぎ目に潜むからです。lead-routingのworkflowを作った人と、deal stageを作った人は、それぞれ自分のパーツを単独でテストし、各パーツは合格しました。journeyはその両方を横断し、破綻はほぼ常に接合部にあります。接合部が見えるのは、1件のレコードが一度の着座で全体を通ったときだけです。

最近、DACH地域のSeries BのB2B SaaS企業と仕事をしました。SalesforceからHubSpotへ移行する企業で、確定したgo-liveの日付があり、顧客と接するチームは新しいsetupに一度も触れていませんでした。プロジェクト計画は良好な状態でした。データmappingのscope策定、workflow構築、トレーニング予定が組まれていました。

cutoverの前にdry runを強く求めたことから、二つのことが出てきました。第一に、1件のレコードをjourneyに通したとき、いくつかのworkflowは単独では正しく構築されていたものの、実際のcustomer journeyが生み出すtriggerに一度も配線されておらず、contactが入っても次の一歩がないまま留まり得ました。status sheetならそれらのworkflowを「完了」と示したでしょう。dry runはそれらを行き止まりとして示しました。第二に、チームは古いシステムからの過去のノートや活動を移行する予定がなく、オープンなレコードだけでした。一見、合理的に思えます。しかし初日、repが稼働中のアカウントを引き継ぎ、履歴が見えず、それを探すためにこっそり別タブで古いCRMを開く、と気づくまでの話です。人々が旧システムを開いたままにした瞬間、adoptionはすでに失われ、一つを動かすために二つのCRMに支払うことになります。私たちはjourneyを通したからこそ、チェックリストではなく、両方をlaunchの前に捕まえました。

1. dry runをgo-liveの前の独立したイベントとして予約する。2時間、チーム全員、status callではなくworking sessionとしてカレンダーに入れます。明確なownerと共にカレンダーに無ければ、launchの日付に押し出されます。nice-to-haveではなく、go-liveが通過すべきgateとして扱ってください。
2. 実在のレコード1件を、最初の接点から成約まで通す。代表的なシナリオを選び、最後まで追います。lead作成、routing、クオリフィケーション、すべてのstage、クローズ、そしてクローズ後のhandoff。面白い部分に飛ばないでください。退屈な移行部分にこそ行き止まりが隠れています。
3. パーツではなく、つなぎ目をテストする。すべてのhandoffで、次のものが発火するかを問います。workflow、タスク、通知、viewの切替、アサインメント。個々のオブジェクトは、作った人がすでにテスト済みです。dry runでのあなたの仕事は、それらの間の接続です。
4. オープンなレコードだけでなく、履歴を移行する。どの顧客履歴を持ち込むかを明示的に決めます。ノート、過去の活動、これまでの文脈。repがgo-liveの前に何があったかを見られなければ、彼らは古いシステムを開いたままにし、それがadoptionを失う最も速い道です。すべてを持ち込めないなら、どのrepも古いCRMを再び開く理由を持たない程度には持ち込んでください。
5. viewはlaunchの後ではなく前に標準化する。レコードを共有したとき全員が同じデータを見られるよう、共通でロールに適したview。私のルールは、誰が見ているかではなく、レコードがlifecycleのどこにあるかでviewを変えることです。顧客になる前のcontactは、顧客であるcontactとは違って見えるべきです。初日に5つの個人レイアウトがあれば、最初の週に5人が噛み合わない会話をします。
6. 動くバージョンからドキュメントを書く。dry runを録画し、たった今確認したフローからユーザーガイドを構築します。実際の手順のscreen grab付きで。システムが確認される前に書かれたドキュメントは、まだ存在しないシステムを文書化します。
7. dry runは1日の早い時間に置き、その後に修正の時間を予約する。dry runは欠陥を見つけると想定してください。実際に見つかります。そしていくつかは新しいworkflowの構築を要すると想定してください。朝に行えば、修正する人にまだ午後が残ります。後に修正の時間を予約していないdry runは、今や知っているがlaunchの前に解決できない問題のリストにすぎません。

これに形式的なプログラムは要りません。要るのは2時間、1件のレコード、部屋にいる適切な人々、そして自信のある部分だけでなくjourney全体を追う規律です。dry runは、launchの1週間前にカレンダーに入れたworking sessionで欠陥を見つけるか、顧客が電話口にいる本番環境で見つけるかの違いです。一方は安価です。もう一方は、go-liveと、adoptionの一部を失わせます。

CRM go-liveを計画していて、cutoverの前にdry runを行うパートナーをお探しなら、それはまさに私たちの仕事の形です。移行のscopeを定め、workflowを配線し、誰かがその上で売る前にcustomer journey全体をリハーサルします。launchの後に開くCRMのadoptionギャップに関する関連記事をお読みください。または、私たちがrevenue operationsにend-to-endでどう取り組むかをご覧ください。

• SaaStr.「The Modern GTM Org in 2026: Leaner, Flatter, and More Revenue Per Rep.」SaaStr、2026年1月。saastr.com
• SaaStr.「Which CRM Should You Use in 2026/2027? Follow the Agents.」SaaStr、2026年2月。saastr.com