先週、ある創業者からごく当然の質問を受けました。このプロジェクトは今どこまで進んでいるのか、という質問です。その場の誰も答えられませんでした。データが欠けていたからではありません。データが2つのシステムにまたがっており、どちらもその答えを保有していなかったからです。
成長中のレベニュー組織において、これは最も高くつく質問です。そしてチームが手を伸ばす解決策は、ほぼ必ず間違っています。可視性の要求を聞くと、統合のスコープを切り始めるのです。6週間後、双方向の同期が動いているのに、創業者は依然としてその質問に答えられません。
なぜこれは改善ではなく悪化しているのか
この問題に繰り返し突き当たる理由は、真実がどこに存在するのかを市場が決めきっていないため、各社が静かに自社で決めているからです。2月のSalesforce による Momentum 買収についての分析で、Forrester の Anthony McPartlin は買い手が直面する選択をこう整理しています。「simplicity, centralized governance, and a single point of accountability」を得る CRM-as-a-platform 型か、「faster innovation and advanced specialization」を得る best-of-breed の真実プラットフォーム型か。彼の予測では、スイート製品は専門ベンダーを CRM とワークフローの間に置かせるのではなく、オーケストレーション層を取り込み続けます。
それはベンダー同士の争いです。あなたの側の同じ問題は、もっと小さく、もっと緊急です。CRM があり、実際の作業が起きる第2のシステムがあり、そして「今どうなっているのか」を一文で知りたい経営層がいます。どのシステムがその答えを出してよいのか、誰も決めていません。
誤った診断
問題はここです。誰かが可視性を求めると、反射的にシステムをつなごうとします。双方向同期、フィールドマッピング、両側でのレコードのミラーリング。開発量は膨大で、維持コストは正直に言って高く、そしてミラーがずれた日には新しい問題が増えます。2つのチームが、仕事ではなく互いのデータを指さすようになるのです。
しかも解いている対象が間違っています。可視性を求めている経営層は、他システムのレコードが欲しいわけではありません。欲しいのは3つの事実です。今どのステージか、今誰が責任者か、ブロックされているか。これは対象範囲の非常に狭いレポーティングの問題であり、フィールドを1つも動かさずに答えられます。
誰かが統合仕様を書き始める前に、私なら keep / edit / delete のフレームを当てます。Keep は経営層の質問に答えるデータ。Edit は責任の所在が明示されるようジャーニーを書き直すこと。Delete は、両方のシステムが互いのすべてを知っている必要があるという前提です。統合は可視性を買う手段の1つですが、メニューの中で最も高価な選択肢です。
ジャーニーの上にステータスレイヤーを構築する
実際に可視性をもたらすのは、カスタマージャーニーの上に置かれ、それを要約する薄いレイヤーです。新しいパイプラインではありません。あなたにとって実際の作業単位となるオブジェクト、つまりアカウント、プロジェクト、ポートフォリオの上に置く、少数のプロパティです。
ここは多くの人が飛ばす部分です。アーキテクチャの問題に見えたものへの答えとしては、ステータスレイヤーがあまりに単純に見えるからです。
4つのフィールドがほとんどの重みを担います。
- 現在のマイルストーン。6つから10程度の短い選択肢から1つ。細かい作業手順を並べるものではありません。
- 現在の担当者。前に進める責任を負う実名の人物。マイルストーンが変われば担当者も変わります。
- ブロック中。真偽値と、1行の理由。
- 次アクション日付。次に何かが起きる予定の日付。
このレイヤーは中核となるマイルストーンだけに触れ、その下の詳細は意図的に無視します。オペレーション側のシステムが50ステップのチェックリストを回していても、ステータスレイヤーは11から19番目の手順に関心を持ちません。関心があるのは、今ビルド段階にあること、実名の担当者がいること、そして止まっていないことだけです。粒度は作業が行われる場所に置き、要約は経営層が見る場所に置きます。
各ステージが使用システムを宣言する
処方箋の後半はドキュメント化であり、統合よりも一桁安く済みます。ジャーニーをステージごとにたどり、そのステージで人々がどのシステムで作業し、そこで何をするのかを明示的に書き出してください。
システム間の混乱のほとんどは、そもそもデータの問題ではありません。作業がどこで行われるかを誰も書き残さなかったため、2つのチームが互いに相手が見ているものと思い込んだ、というだけです。あるステージに「ここからはオペレーションツールで作業し、CRM が求めるのはマイルストーンの値だけです」と書かれた瞬間、曖昧さは消え、作ろうとしていた同期はフィールド1つにまで縮みます。
そのうえで、各プラットフォームを平準化するのではなく、強みに沿って使ってください。ケースのルーティング、チケッティング、受信メールは、その仕組みがすでにある CRM に属します。実行は、実行のために作られたシステムに属します。1人、たいていはルーティングのゲートキーパーが両方にまたがって働くことは受け入れてください。それは役割であって、欠陥ではありません。
ハンドオフは同期するのではなくゲートを設ける
可視性が本当に死ぬ場所はハンドオフであり、その証拠は珍しいほど明快です。最も成長の速い AI 企業がカスタマーサクセスをどう作り直したかについての SaaStr のパネルは、ハンドオーバーの成否を「the place most failure and data loss happens」と呼んでいます。そのパネルに参加したある企業は、クローズドウォンを営業側からインプリメンテーション側の閾値へと移し、契約が成立しても立ち上がらなかった案件は計上されないようにしました。その結果、チャーンは月次4%からおよそ0.5%へ下がり、その間に ARR は800万ドルから2億ドルへと拡大しています。
これは統合の話ではありません。定義の話です。ステージが何を意味するのか、そして誰がそれを宣言してよいのかを変えたのです。
同じことをゲートにも適用してください。ステージには入場条件を設け、条件が満たされるまでそのステージには入りません。前のチームに未処理の項目が残っている状態で顧客を次のチームへ渡してはいけません。まさにその瞬間に責任が曖昧になり、作業の上にいる全員から可視性が失われるからです。フェーズの内側に埋もれた二者択一の go/no-go チェックポイントがあるなら、そして多くの技術検証プロセスには2つか3つあります、それぞれを独自の担当者を持つ名前つきステージへ昇格させてください。誰にも見えないチェックポイントは、誰も責任を負わないチェックポイントです。
並行するパイプライン、並行する責任
商談側の作業とオペレーション側の作業が本当に同時に進むチームでは、1本のパイプラインでは支えきれません。2本にしてください。商談パイプラインと、その横で開くオペレーションパイプライン。それぞれ独自のステージを持ち、どちらも同じステータスレイヤーに集約されます。
責任も同じように分かれます。アカウント上に、商談側の関係とオペレーション側の関係それぞれの担当者フィールドを分けて持ち、さらにオンボーディングの担当者と受注後のアカウント担当者を持ちます。フィールドが増えるように見えます。実際には議論が減ります。どの瞬間においても、質問の種類ごとに名前がちょうど1つ立っているからです。
現場ではどう見えたか
私たちは今、20人未満の小さな DACH のチームと仕事をしています。彼らは難しいことを2つ同時に進めています。レガシー CRM からの移行と、自社の社内オペレーションツールの構築です。プログラム全体について創業者が掲げた成功基準は、最初のインバウンドリードから稼働開始まで、各プロジェクトがどこにあるかを示す単一のビューでした。
テーブルに載っていた提案は、2つのシステムをつなぐというものでした。創業者はそれでは足りないと押し返し、彼は正しかったのですが、本人が考えていた理由とは違います。問題はデータが2か所にあったことではありませんでした。複数ステップの技術検証フェーズが、それを実行するチームの外側からは誰にも見えず、どの時点でどのシステムがプロジェクトのステータスを保有するのかを誰も書き残していなかったことです。
代わりに私たちがスコープしたのは、プロジェクトレコード上の8つのマイルストーン、マイルストーンごとに1つの担当者フィールド、詳細が必要な人のための CRM レコードからオペレーションツールへの読み取り専用リンク、そして隠れた小ステップから名前つきステージへ昇格させた3つの検証チェックポイントです。双方向同期はロードマップから完全に外れました。総工数は統合のごく一部で、創業者が求めていた可視性は四半期ではなく数週間で届きます。
プレイブック
- まず質問を書き出す。経営層が言えるようになりたい文を、本人の言葉のまま、正確に取る。以下の設計判断はすべてそれに照らして評価します。
- レポーティングの居場所を決める。「今どこにあるか」に答えるシステムは1つ。通常は CRM です。ファネルビューとフォーキャストがすでにそこにあるからです。声に出して決めてください。
- 6つから10のマイルストーンを定義する。中核的な遷移だけ。10を超えるなら、それはマイルストーンではなくタスクを描いています。
- すべてのマイルストーンに担当者を置く。実名の人物を置き、マイルストーンが進むにつれて引き継がれます。
- ステージごとに作業システムを宣言する。ジャーニー資料にステージあたり1行。ここではこのシステムで、こう作業する。
- 入場条件を書き、守らせる。前のステージに未処理項目がある間はステージを進めない。隠れた go/no-go はすべて可視のステージへ昇格させる。
- ミラーリングせず、リンクする。一方のレコードから他方への読み取り専用ポインタで詳細の用途は足ります。同期するのはマイルストーンの値だけ、しかも一方向だけ。
- 毎週ステップ1に照らして見直す。経営層がまだその文を言えないなら、間違っているのはレイヤーです。直すのはレイヤーであって、統合ではありません。
ほとんどのチームは、8項目すべてを2週間ほどで実行できます。彼らが発注しようとしていた統合は、四半期を要したうえで、それでもあの質問には答えられなかったはずです。
経営チームが進捗を尋ねるたびに、聞く相手によって違う答えが返ってくるなら、それは設計上の可視性のギャップであって、ツールの問題ではありません。私たちは既存のジャーニーの上にステータスレイヤーを設計することも、第2のシステムがこれから離れる予定の CRM であれば移行から着手することもできます。いずれにしても、経営層が何を見たいのかをお聞かせください。そもそも統合が必要かどうかをお伝えします。
出典
- Forrester「What Salesforce’s Acquisition Of Momentum Means」Anthony McPartlin、2026年2月。forrester.com
- SaaStr「Lovable, Harvey and Assembly AI: How the Fastest AI Companies Rebuilt Customer Success」Jason Lemkin、2026年6月。saastr.com