RevOps入門｜マーケ・営業・CSを一本の数字でつなぐ

マーケは今月のリード目標を達成しました。営業は未達です。

それなのに会議では、どちらも自分たちの数字は問題ないと主張する。見覚えのある光景ではないでしょうか。

原因は、たいてい誰かの怠慢ではありません。部門ごとに違うものを測っているだけです。

RevOps（Revenue Operations、レブオプス）は、この状態をほどこうとする役割です。マーケティング・営業・カスタマーサクセス（CS、契約後の顧客の活用を支援する部門）にまたがる数字と業務を、一本の流れとしてつなぎ直します。

この記事では、言葉の定義を並べるより、明日から手をつけられる順番を中心に書きます。

読み終えたときに、来週の定例で何を最初の議題に載せるかが決まっている。そこを目標にします。

RevOpsは、部門の隙間に落ちた数字を拾う仕事

RevOpsとは、収益に関わる部門の指標・データ・業務フローを横断して設計し、運用する機能のことです。GTM（Go-To-Market、製品を市場に届けるための一連の活動）全体の裏方だと考えるとイメージしやすいと思います。

専任チームを置く会社もあれば、事業責任者やマーケ責任者が兼務している会社もあります。肩書きより、誰が部門間の定義を決めるのかが決まっているかどうかが本質です。

なぜこの役割が必要になるのでしょうか。答えは単純で、部門ごとに最適化すると全体では損をすることがあるからです。

たとえばマーケが資料ダウンロード数を追いかけると、ダウンロードのハードルを下げる施策が正解になります。件数は増えますが、営業が電話をかけると検討すらしていない人が並んでいる。

これは誰かが悪いのではなく、構造の問題です。それぞれの部門が、自分の指標に対して正しく行動している結果として起きます。

RevOpsが見ているのは、部門の中ではなく部門の間です。リードが渡る瞬間、商談が失注する瞬間、契約後にCSへ引き継がれる瞬間。

そこには、たいてい誰の担当でもない空白があります。

部門ごとの最適化がぶつかる典型

具体例を三つ挙げます。どれかは思い当たるはずです。

• マーケは件数、営業は商談化率を追う → 質の低いリードを増やすほど営業の数字は悪化する
• 営業は今月の受注、CSは継続率を追う → 無理な期待値で契約すると半年後に解約が出る
• 広告はCPAで評価、事業は粗利で評価 → 安く取れるが利益の薄い層に予算が寄る

共通しているのは、個々の指標が正しいのに、合成すると事業がずれるという構図です。指標をひとつに統一しろ、という話ではありません。

必要なのは、上位の一本の数字に対して各部門の指標がどう効くのかを、全員が同じように説明できる状態です。

この状態に気づく方法は単純です。各部門が今月の資料に載せている数字を並べて、同じ言葉が何通りの数え方で使われているかを確かめてみてください。

三通り以上出てくるようなら、会議が噛み合わないのはむしろ自然です。そのずれを一覧にすること自体が、RevOpsの最初の成果物になります。

最初の仕事は、指標の定義をそろえること

RevOpsを始めるとき、いきなりツール導入から入ると失敗します。ほぼ確実に、最初にやるべきは定義のすり合わせです。

同じ言葉で違う数字を出している状態でツールを入れても、食い違いが自動化されるだけだからです。

よくあるずれを並べてみます。CRM（顧客と商談を管理するシステム）の入力ルールと直結する話なので、営業側の担当者を同席させてから読んでください。

表を眺めると当たり前に見えます。ところが実際には、この四つがそろっている会社のほうが少ない。

定義をそろえる作業は地味です。それでも、ここを飛ばした自動化はほぼ確実にやり直しになります。

食い違いが起きる仕組みと直し方はKPI定義のすり合わせ｜同じ指標なのに数字が食い違う理由にまとめました。

すり合わせの場は、全員を集めた大会議にしないほうがうまくいきます。関係する部門から決められる人を一人ずつ呼んで、45分あれば足ります。

進め方はシンプルです。ずれている言葉を一つ選び、それぞれの部門が今どう数えているかを口に出してもらうところから始めます。

正しさを議論する前に、現状を並べる。ここを飛ばすと、たいてい過去のやり方の擁護合戦になります。

そのうえで、どちらが正しいかではなく、どちらなら両部門が毎月出し続けられるかで決めます。運用できない厳密な定義より、続けられる定義のほうが仕事をします。

決まったことは、その場でドキュメントに書き込んでしまうのが確実です。あとで清書しますと言って解散した合意は、翌月に記憶の食い違いという形で戻ってきます。

定義は、集計できる形まで書き切る

言葉で合意しても、来月には解釈が割れます。だから最初から、そのまま集計に落とせるところまで書いてください。

指標名: 商談化リード数
定義: 営業が初回打ち合わせを実施し、CRMステージが「初回商談実施」以上になったリード数
発生日: 打ち合わせを実施した日（設定した日ではない）
除外: 既存顧客からの追加相談、社内テスト、競合・学生からの問い合わせ
集計単位: 月初〜月末（JST）／ 部門別・流入元別に内訳を出す
所有者: RevOps（定義変更はマーケ責任者と営業責任者の合意が必要）

ポイントは最後の二行です。所有者と変更手順が書かれていない定義は、静かに書き換わります。

そして定義を変えた月には、必ず一行のメモを残す。数字が落ちたのか定義が変わったのか判断できない状態は、社内の信頼をいちばん早く失います。

引き継ぎの基準は、感覚ではなく条件で書く

定義がそろったら、次は部門をまたぐ受け渡しです。マーケから営業へリードを渡す基準、いわゆるMQL（Marketing Qualified Lead、マーケが営業に渡してよいと判断したリード）の設計になります。

ここで揉める理由もはっきりしています。渡す側と受け取る側で、良いリードの定義が違うからです。

解き方は、感覚の議論をやめて条件式にすることです。仮の数字で考えてみます。

月間の問い合わせが400件あり、そのうち営業が初回商談まで進められたのが80件だとします。商談化率は20%です。

ここで、価格ページを2回以上見た人だけに絞ったらどうなるでしょうか。仮に該当が150件、そのうち商談化が60件だったとします。

商談化率は40%へ上がり、営業が触る件数は400件から150件へ減ります。取りこぼす商談は20件、代わりに250件分の架電工数が浮くという計算です。

この20件と250件のどちらを取るかは、営業リソースの状況で変わります。大事なのは、好みの言い合いではなく数字で比べられる形にしたことです。

もうひとつ効くのは、条件を一度に複雑にしないことです。まずは行動の条件をひとつだけ足して、翌月の商談化率がどう動いたかを見るくらいで十分です。

条件を五つ同時に入れると、効いたのがどれか分からなくなります。基準は育てるものだと考えて、月に一つずつ触るほうが結果的に早く仕上がります。

条件の設計と合意の取り方はMQLの引き継ぎ設計｜マーケと営業が揉めない基準づくりで詳しく扱っています。

差し戻しの経路を必ず用意する

基準を作ると、必ず外れ値が出ます。条件を満たさないのに明らかに有望なリード、その逆も。

だから引き継ぎには、戻せる導線をセットで作ってください。営業がこれは違うと判断したリードを、理由つきでマーケへ返せるようにします。

返された理由が溜まれば、基準の見直し材料になります。戻せない仕組みは不満だけが溜まり、やがて基準そのものが無視されます。

返却の件数は、月に一度まとめて眺めてください。仮に月40件渡して8件返ってきているなら、基準が緩すぎるか、営業側の期待値が高すぎるかのどちらかです。

数字が出ていれば、その会話は感情の話になりません。

土台がないと、自動化もAIも空回りする

ここまでが人と定義の話でした。ここからはデータの話に移ります。

ここで決めておきたいのが順番です。先に土台を作り、その上に自動化を載せるという向きを守れるかどうかで、あとから発生する手戻りの量が変わります。

土台とは、具体的にはこの三つを指します。

• 全社共通のKPI定義と、その計算を一箇所に置いたセマンティックレイヤー（同じ指標が誰の集計でも同じ数字になる仕組み）
• 顧客・商談・行動のデータが、同じIDでたどれる状態
• 判断の根拠になる社内ナレッジが、検索できる形で置かれていること

順番を逆にすると、どうなるか。定義がずれたまま自動化すれば、間違った数字が速く大量に配られるだけです。

土台づくりの具体的な進め方はGTMデータ基盤｜AIが正しく動くための土台づくりにまとめています。

サイト側の行動は、別の層として設計する

顧客データの多くはCRMやMA（マーケティング活動を自動化するツール）に入っています。一方で、契約前の見込み客がサイトで何を見たかは、そこには入っていません。

この匿名の行動データが、意外と抜けがちです。どの流入元から来たのか、価格ページを見たのか、事例を読んだのか、フォームのどこで止まったのか。

Strideが担当できるのは、この層です。サイト上の匿名の行動を、Cookieを使わず個人情報も集めない形で測ります。

個人を特定してリードに紐づけたり、メールを送ったり、商談を管理したりはできません。CRMやMAと組み合わせて使う前提の道具だと考えてください。

流入元を検索・広告・メール・SNSといった単位で正しく分ける方法は流入元の正しい見方｜検索・広告・メール・SNSを分けて計測するで解説しています。

AIを入れるなら、人間の承認をどこに残すか

土台が整うと、自動化やAIエージェントの出番になります。ここでも、先に押さえておきたい型が二つあります。

一つは、AIをチャット画面の中に閉じ込めないこと。CRMの更新、Slackへの通知、ヘルプデスクの起票といった業務の流れの中に、イベントをきっかけに動く仕組みとして埋め込みます。

もう一つは、人間のトップパフォーマーの手順を先に言語化すること。うまい人がどんな順番で何を見て、どこで判断を変えているのかを書き出してから、それをエージェントに写します。

順番が逆だと、何をやらせたいのか決まらないまま出力の良し悪しを議論することになります。

そして最大の論点が、承認をどこに残すかです。すべてに人を挟むと自動化の意味がなく、すべてを任せると事故が起きます。

判断の目安は、間違えたときに誰が損をするかで分けることです。

社外に出ていくもの、金額が動くもの、取り消せないもの。この三つには人を残すのが無難です。

この線引きは、一度決めたら固定というものでもありません。運用して事故が起きなかった領域から、少しずつ自動の側へ寄せていく前提で置いてください。

何を評価するのかを先に決める

エージェントを入れるとき、動いたかどうかだけを見て終わりにしがちです。それでは良くなっているのか判断できません。

現実的なのは、シャドーモードから始めるやり方です。実際には実行せず、AIならどう判断したかだけを記録して、人の判断と突き合わせます。

過去の事例を50件ほど用意してテストセットにするのも有効です。正解が決まっている問い合わせに対して、分類が一致した割合を見ます。

見るべきは精度だけではありません。間違え方の質、つまり見逃しと誤検知のどちらが多いかまで確かめると、閾値の調整ができます。

本番投入後も、週に一度は出力をサンプリングして人が読む枠を残してください。放置された自動化は、静かにずれていきます。

浮いた時間の使い道まで決める

自動化の成果は、削減できた工数そのものではありません。浮いた時間を何に使ったかで決まります。

入力作業から解放された営業が、そのぶん商談準備に時間を使ったのか、単に別の雑務に吸われたのか。ここを決めずに導入すると、成果を説明できません。

もうひとつ、地味に効く副作用があります。入力の手間をなくすと、記録されるデータそのものが増えるという順番です。

面倒で書かれなかった商談メモが残るようになれば、翌四半期の分析材料が増えます。自動化はデータを貯めるための手段でもある、という視点は持っておく価値があります。

着手は、狭く深くから

最後に順番の話です。RevOpsは全社改革のように語られがちですが、一斉にやると必ず頓挫します。

選ぶ基準は三つ。頻度が高い、手順が再現できる、遅れると損が大きい業務から入ります。

たとえば問い合わせへの初回返信、リードの割り振り、商談後のCRM入力。どれも毎日発生して、うまい人の手順が説明できて、遅れると機会損失が出ます。

逆に、月に数回しか起きない業務や、担当者ごとに正解が変わる業務は後回しで構いません。労力に対して効果が小さいからです。

最初の一つが動いたら、結果を社内へ短く共有しておくと次が進みやすくなります。うまくいった話より、どこでつまずいたかのほうが他部門の判断材料になります。

もうひとつ決めておきたいのが、この整理を誰が担当するかです。兼務でも構いませんが、部門横断の決定を持ち込める人でないと、定義の変更ひとつで止まります。

肩書きよりも、決裁者に話を通せるかどうか。ここが曖昧なまま始めると、資料だけが増えていきます。

最初の90日で狙う範囲を、仮に並べるとこうなります。

• 1〜30日目：主要な指標の定義を一枚にまとめ、所有者と変更手順まで決める
• 31〜60日目：引き継ぎ基準を条件式にし、差し戻し経路と週次の見直し枠を作る
• 61〜90日目：頻度の高い業務をひとつ選び、シャドーモードで自動化を試す

三ヶ月で全部は終わりません。それでも定義がそろい、引き継ぎが説明でき、自動化の検証が一本回っている状態になれば、その次の議論はぐっと楽になります。

数字を出す手間を下げておく

RevOpsが形骸化する原因のひとつは、集計が面倒すぎることです。毎週30分かかる作業は、忙しい週から順に飛ばされます。

StrideはMCPに対応しているので、先月の流入元別に価格ページへの到達率を出して、といった依頼をClaudeなどのAIへ自然言語で投げられます。定例の前に数字をそろえる作業が数分で済むなら、見直しの頻度そのものを上げられます。

定例で使う数字は、誰でも同じ手順で再現できる形にしておくのが基本です。手元の表計算ファイルに秘伝の加工が入っていると、担当が変わった瞬間に数字の意味そのものが失われます。

集計が誰か一人の善意で回っている状態は、その人が休んだ週に止まります。

RevOpsが効きにくい場面

万能ではありません。組織が小さく、全員が同じ会話に参加できているうちは、部門間の定義をわざわざ文書化する必要は薄いです。

商材が単純で、問い合わせから受注まで一人で完結しているならなおさら。引き継ぎが存在しないなら、引き継ぎの設計も要りません。

必要になるのは、部門が分かれて、誰の担当でもない領域が生まれてからです。その兆候は、部門をまたぐ数字の食い違いという形で先に表れます。

まとめ

RevOpsは、部門の間に落ちた数字と業務を拾い直す役割です。新しいツールを入れることではありません。

順番は、定義をそろえる、引き継ぎを条件で書く、データの土台を整える、そのうえで狭く深く自動化する。遠回りに見えて、この順番がいちばん早いです。

AIを入れるときは、社外に出るもの・金額が動くもの・取り消せないものに人間の承認を残す。そして何をもって良しとするかの物差しを、先に決めておく。

全部を一度にやる必要はありません。まずは主要な四つの言葉の定義を、一枚の紙にそろえるところから始めてみてください。