私が呼ばれる revenue システムには必ず単一障害点があり、それはほとんど常にソフトウェアではありません。一人の人です。pipelineのstageを作り、あの奇妙な automation がなぜ存在するのかを知り、どのフィールドが本物でどれがただの飾りかを覚えている人。その人に二週間の退職予告を出せば、失うのは従業員ではありません。地図を失うのです。
これは誰も保険をかけていない静かなリスクです。チームは forecast やセキュリティ、uptime のストレステストは行います。しかし、モデル全体を頭の中に抱えた admin がドアの外へ出ていったときに何が起きるかを、ほとんど誰もストレステストしません。そしてスリムでAIによって加速されたGTM組織では、そのモデルの多くが以前よりも一つの頭の中に宿っています。
その人がドキュメントそのもの
問題はこうです。数百人未満のほとんどの企業では、CRMはそれを運用する人の振る舞いの中以外、どこにも文書化されていません。wikiはありません。スキーマ文書もありません。あるのは、何年分もの意思決定が積み重なった Salesforce か HubSpot のインスタンスと、そのうちどれが意図的でどれが誰も片づけなかった事故なのかを教えられる、ちょうど一人の人間だけです。
SaaStrは今年、その飾らない現実をうまく言い表しました。ほとんどのB2B revenue チームは「一つの deal を閉じるために七つの tool を動かしている」、そしてCRM自体はしばしば半分しか埋まっていないフィールドの「墓場」だ、と。tool は増えます。それらをつなぎ合わせる知識は増えません。一人の人に集中します。そして集中した知識こそが、ownership リスクの姿そのものです。
AIは集中を悪化させた、改善ではなく
AIならこの知識を再び分散させると思うかもしれません。実際には逆のことが起きます。Forresterはいまやこのパターンに名前をつけています。「Claude Cowboy」、つまり公式なプロセスが追いつかないために、自分自身の automation・prompt・データ変換を組み上げてしまうオペレーターです。彼らの言葉を借りれば、「forecast のロジック、セグメンテーションモデル、営業向けのレコメンデーションが、ある人によって作られ、別の人に使われ、さらに三人目によって実行されることがある。それが ownership を曖昧にする」。
それが罠です。仕事が速くなるのと同時に、ownership が曖昧になります。かつて Salesforce 開発者を必要とした permission set が、いまやAIエージェントとの五分間の会話で片づくため、ticket化も、レビューも、記録も一度もされません。ロジックは実在し、production で動いています。ただ見えないだけです。それを書いた人が去ると、自分が何を知らないのかさえ分からなくなります。
三つのものがドアの外へ出ていく
唯一の admin が退職を告げると、三つの異なるものが一緒に去っていきますが、ほとんどのチームは最初の一つにしか気づきません。
- アクセス。文字どおりの super-admin ログイン、APIキー、その人の個人アカウントで認証された連携。これは気づかれるもので、たいてい退職チェックリストのどこかに入っています。
- コンテキスト。なぜ pipeline のstageが五つではなく七つなのか。三つある「closed lost」の理由のうち、実際にどれが使われているのか。これはチェックリストには決して載りません。必要になるまで、それが欠けていることを誰も知らないからです。
- 判断。平日の遅い時間にどの変更なら安全に出せて、どれが静かに forecast を壊すのか、というその勘。これは文書では引き継げません。予算に入れていなかった時間をかけてしか移せません。
現場ではこう見える
最近、DACH地域のシリーズBのB2B SaaSチームと仕事をしました。唯一のCRM adminが後継者の当てもなく退職を告げ、しかもちょうど二つのシステム間の移行の真っ最中でした。opportunity の設定は、彼ら自身の言葉で言えば混乱状態でした。重複レコード、誰も信用していない lifecycle stage、歴史の中に理由が失われた automation が発火し続ける。すべてがちょうど一人にだけ意味を成し、その人の最終出社日は二週間後でした。
問題は採用が下手だったことではありません。問題は、そもそも ownership が最初から分散されていなかったために、通常の人員の入れ替わりが売上リスクになったことです。それがパターンであり、企業のステージはそこから守ってくれません。十人のチームが最も強く感じるのは、adminがしばしば創業者だからです。シリーズB企業が最も強く感じるのは、そのシステムがいまや数字を支える存在になっているからです。
プレイブック：必要になる前にownershipを分散させる
私が勧めるのは「すべてを文書化する」ことではありません。それは決して実現せず、実現しても腐ります。ひと握りの意図的な動きで、ownership を共有され、読み取れるものにすることです。
- ownershipの地図を描く。一ページに、すべてのオブジェクト・連携・重要な automation について、主担当の owner と、一か月なら回せる backup を挙げます。そこで見つかる空白こそ、あなたの本当のリスク台帳です。
- identityとアクセスを分ける。個人ログインで認証された連携をなくし、共有の super-admin パスワードをなくします。サービスアカウントとロールベースの permission set にすれば、人が去ることはHRの出来事であって、障害ではなくなります。
- 「何を」ではなく「なぜ」を書く。フィールド辞書は飛ばしてください。有能な新任 admin を戸惑わせる十の意思決定を文書化します。なぜこのstageなのか、なぜこの重複排除ルールなのか、なぜ一見明らかに消したくなるものが実はシステムを支えているのか。
- AIの作業をticket化する。ある automation が production で動かす価値があるなら、それが何をして誰が所有するかを一行で記録する価値があります。それが見えないロジックという問題の解毒剤であり、その都度やれば、ほとんどコストはかかりません。
- bus factorテストを実施する。四半期に一度、最も重要なシステムを選んで問います。もし owner が今日いなくなったら、誰がそれを生かし続け、最初の一週間で何が壊れるのか。複雑にしすぎないでください。その演習自体に価値があります。
これらのどれも、持っていない人員を必要としません。必要なのは、ownership を、pipeline や permission モデルを設計するのと同じように、意図して設計するものとして扱うことです。たまたま最初にそこにいた人の周りに積み上がるものとして放置しないことです。
もしいまあなたのCRMの継続計画が、一人の記憶とその退職予告期間だけなら、それはあなたが直す中で最も安上がりな売上リスクです。次の退職があなたの代わりに決断を下す前に、ownershipが実際どこにあるのかを可視化することもできますし、空白に第二の視点が欲しければ私たちに相談することもできます。
出典
- Forrester.「The Rise of the Claude Cowboy in RevOps.」2026年7月。forrester.com
- SaaStr.「The $500M Bet That Your Entire GTM Stack Should Be One Platform.」2026年。saastr.com