RevOpsマネージャーの一日：職務記述書には書かれていないこと
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
あなたのRevOpsマネージャー職の職務記述書は、おそらく*「予測精度を所有し、セールスのリーダー陣と連携し、部門横断のアライメントを推進する」といった文言で始まっています。本物で、技術的には正しく、役に立ちません。そのどれもが、午前7時42分にCROから届く次のSlackのDMに備えさせてはくれません。「ねえ、なんでdashboardでACVが18%下がってるのか確認してくれる？スタンドアップの前に聞いておきたくて」*
そのDMこそが本当の仕事です。パニックを数字へ、数字を根本原因へ、根本原因を、CROがスタンドアップであたふたしている印象を与えずに繰り返せる一文の答えへと翻訳すること。それをスタンドアップが始まるまでの17分のうちにやり切るのです。職務記述書はそのDMについて教えてくれません。そこで、最近私が過ごしたある火曜日を、名前は変えつつデータ品質の問題はそのままに、1時間ごとに紹介します。
この職を検討している候補者なら、これがあなたが引き受けようとしているものです。着任して半年で、これは普通なのかと思っているなら、普通です。採用マネージャーとしてこの職を設計しているなら、これを読んで職務記述書を見直してください。
午前7時42分：コーヒーの前のSlack DM
スマホが震えます。CROです。ACVの質問です。スマホでLookerを開き、コホートをちらっと見て、すぐにわかります。これは本物のACV下落ではありません。定義の下落です。2日前に誰かが、dbtモデルでのAnnual Contract Valueのロールアップ方法を変え、いまや複数年契約の案件が初年度の契約額を取る代わりに年数で平均されています。数字は動いていません。計算が動いたのです。
私は返信を打ちます。「本物じゃないです。金曜のdbtモデル変更で、複数年契約が平均化されてます。9時までに修正します。スタンドアップでは先週の数字を使ってください」。1通のメッセージで危機回避です。さあ、本当に一日を始める時間です。
午前8時00分：パイプラインのスキャン
コーヒー、2台目のモニター、2つのタブ：SalesforceとClari。私はパイプラインを見ているのではありません。パイプラインで夜のうちに動いたものを見ているのです。
これは、誰も鍛えろと教えてくれない筋肉です。静止しているパイプラインは無意味です。動いているパイプライン(ステージが変わったもの、クローズ日が後ろ倒しになったもの、金額が編集されたもの)にこそ、真実は宿ります。私は保存済みのレポートを実行します。過去24時間に変更された商談、ステージ変更でグループ化。63行です。
ほとんどはノイズです。3つは違います。
1つ目は、3度目のクローズ日後ろ倒しをしたばかりの18万ドルの案件です。Q3からQ4、Q4からQ1、Q1からQ2。これは3度目の滑りパターンであり、私の経験ではこれは、案件が死んでいるのにAEがまだ気づいていないか、気づいていてダメージを負いたくないかのどちらかを意味します。予測（forecast）会議で取り上げるため、ノートに印をつけます。
2つ目は、NegotiationからProposalへひっそり後退した案件です。ステージの後退は、ほぼ常に、本物の信号（チャンピオンの交代、予算の見直し）か、CRMの整備の問題（間違ったドロップダウンを選んだAE）のどちらかです。アクティビティログを確認します。チャンピオンが月曜に退社していました。本物の後退です。AEは案件の説明を更新していないので、これは予測（forecast）会議では見えなかったはずです。リストに加えます。
3つ目は、AEが11日間アカウントに何のアクティビティもないまま金額を20%引き上げた4万ドルの案件です。怪しいです。アクティビティを伴わない金額の編集は、サンドバッグか引き伸ばしのサインです。これは予測（forecast）会議ではなく、明日の1on1で聞きます。CROの前でAEを名指しするのは、AEを失う方法です。
午前9時30分：予測会議の準備
午前10時の予測（forecast）会議は、私の仕事が最も目立ち、最も脆くなる場です。一致するはずなのに決して一致しない3つの数字を、30分で照合しなければなりません。
- CROが昨日の1on1でのAEの読みに基づいて口にする数字。
- 担当者が入力したcommitとbest caseを、AIモデルで重みづけしてClariが示す数字。
- いままさにCRMにあるものに基づいて、SalesforceがAEごとにロールアップして示す数字。
この3つの数字は、たいてい互いに8〜15%ずれています。CROの数字はたいてい最も高いです（1on1からの近接性バイアス）。Clariはたいてい中間です。Salesforceのロールアップはたいてい最も低いです。AEの半分が先週木曜から案件を更新していないからです。
その30分での私の仕事は、CROが問いただされる3つの案件を特定し、答えを事前に書き、根底のデータ品質の問題を今日指摘するか待つかを決めることです。今日の問題は、誰かが2024年に設定したZapierのフローが、インバウンドリードのStageの値をひっそり書き換えていることです。Zapが間違ったトリガーで発火しているせいで、本来Stage = Qualificationにあるべき42件の商談が、いまStage = Discoveryにあります。これは数か月に一度見つかります。記録し、会議のあとで修正し、会議では触れません。CROは午前10時にZapierの診断を必要としていません。
午前11時00分：システム修正の依頼
予測（forecast）会議が終了しました。受信トレイを開きます。Slackが4件。重要なのはAEからの1件です。「Outreachが新しいシーケンスのタスクをSFに記録してくれません。これはバグですか？」
バグではありません。決してバグではありません。マーケティングが2週間前にキャンペーン名を変更し、Outreachのキャンペーンとシーケンスのマッピングがひっそり壊れ、いまやそのキャンペーン由来のどの案件でもタスクの記録が失敗しているのです。診断に40分（OutreachのAPIログを読み、SFのキャンペーン履歴と突き合わせ、名称変更を見つける）。修正に10分（マッピングを更新し、変更を反映し、3件のテストタスクが正しく記録されることを検証する）。感謝はゼロです。AEにとってそれは「またOutreachが壊れた」だけだったからです。
これは仕事の中で積み重なっていく部分です。あなたが運用するすべてのシステムは、マーケティングの1つの名称変更、Salesloftの1つのシーケンス変更、Salesforceの1つのフィールド廃止で壊れる一歩手前にあります。私が知る優れたRevOpsマネージャーは皆、私的なwikiを持っています。上流で何が変わるとどの連携が壊れるか。私のものには31件のエントリがあります。それは私が所有する最も価値のあるドキュメントです。
午後1時00分：データ品質をめぐる非同期の論争
机でランチです。SDR3人とAE2人がLead Sourceが空白になることについて交わすSlackスレッドがあります。これは繰り返し起きる論争で、これに勝つ唯一の方法は、そのコストを私ではなく彼らの問題にすることだと学びました。
私はチャンネルに投稿します。「データを引っ張りました。先四半期、closed-wonの案件の31%にソース帰属がありませんでした。だからマーケティングは報酬プランで取り分を削られているんです。報酬がインバウンドを正しく重みづけしてほしいなら、すべてのリードにソースを入力する必要があります。このフィールドを好きになれとは言いません。これがあなたのスピフの計算がずれている理由だと言っているんです」
5分で3件の返信があります。AE2人は反論します。SDRが1人*「もっともです、直します」*と言います。それが勝ちです。全員に同意してもらう必要はありません。誰も存在しないふりができないほど計算を見えるようにする必要があるのです。データ品質の論争は、説教ではなく報酬への影響で勝つものです。
午後3時00分：3人のステークホルダー、1つのデータセット
午後の半ばは、依頼が積み上がるときです。今日は次のとおりです。
- CFOは取締役会の資料用にセグメント別のネットレベニューリテンションを欲しがっています。金曜に必要です。
- CMOはキャンペーンの事後検証用にチャネル別の帰属を欲しがっています。明日に欲しいです。
- CROはCOOとの1on1用に担当者別のパイプライン・カバレッジを欲しがっています。2時間以内に欲しいです。
同じソースデータ。3つの異なる切り口。3つの異なる締め切り。今日出せるのは1つです。
私はCROのものを出します。彼が最も重要だからではなく、締め切りが最も短く、切り口が最もシンプルだからです。担当者別のパイプライン・カバレッジは、90秒のLooker exploreのフィルタです。CFOには保留のメールを送ります。「NRRをセグメント別で作業中です。木曜の終業時にドラフトをお渡しできるので、金曜を修正にあてられます」。CMOにはSlackします。「チャネル帰属の事後検証は水曜の午後にお出しします。先に一緒にチャネルを絞り込みますか、それとも前回のブリーフをデフォルトにしましょうか？」
埋もれないコツは、すべての依頼を、納品した成果物か、期日つきで範囲を定めた約束のどちらかに変換することです。開いたままの依頼は腐ります。範囲を定めたものは腐りません。
午後5時30分：commitとbest caseの照合
チームのほとんどがログオフします。私はSalesforceを開き、その日のパイプラインの動きを1タブのGoogleスプレッドシートに引っ張り出します。3列：AE、Commitの変化、Best Caseの変化。
私は2つのパターンを探しています。Commitはほとんど動かないのにBest Caseが膨らみ続けるAEは、過剰commitです。会議に向けてクッションを置きつつ、カバレッジで見栄えをよくするために楽観的な案件をBest Caseに詰め込んでいます。Commitは下がるのにBest Caseが横ばいのAEは、サンドバッグです。天井は変えずにひっそり床を下げています。両者は異なる方向に嘘をついています。両者とも、来月のquota計画にとって重要です。
今日はそれぞれ1人ずついます。私はノートに2行のサマリーを書きます。「Sara：Best Caseで過剰commit、3案件が引き伸ばしに見える。Marcus：Commitが正当な理由となるアクティビティなしに9万ドル下落、サンドバッグ候補」。それだけです。その2行が、明日の予測（forecast）会議のアジェンダになります。
午後9時00分：夕食。そしてdbtモデル。
妻が今日はどうだったかと尋ねます。私は*「いつも通り」*と言います。彼女はそれが何を意味するか知っています。なんとか夕食を乗り切ります。
午後9時、私は机に戻っています。CROが明日午前8時に開くLookerのdashboardが、いまや壊れているとわかっているdbtモデルから引っ張っているからです。朝のACVの問題は症状でした。原因は、上流のopportunities_enrichedモデルでの列名変更で、それに合わせて下流のrevenue_metricsモデルが更新されていなかったことです。
dbtプロジェクトを開きます。問題の列を見つけます。旧名はacv_first_year、新名はacv_year_oneです。上流の変更をした者が伝播させなかったのです。2つのモデルにまたがる3つの参照箇所で、下流のSQLを修正します。ローカルでdbt testを実行します。今夜は追いかける時間のない無関係なnullの問題で2つのアサーションが失敗するので、当初の問題だけを範囲を絞って修正し、PRをプッシュし、明日の朝レビューするよう私たちのアナリティクスエンジニアにpingを送り、モデルが本番できれいに再ビルドされたことを検証します。
午後11時14分。Lookerを開き、dashboardを更新します。ACVが正しい数字に戻っています。ノートパソコンを閉じます。予測（forecast）会議は午前8時です。
職務記述書が言わないこと
職務記述書は肩書きを描写します。予測精度を所有し、部門横断のアライメントを推進すると書いてあります。それらのフレーズが実際に何を意味するかは書いていません。
あなたは翻訳者です。CROはパイプラインを話します。CFOはマージンを話します。CMOはMQLとCACを話します。AEはコミッションを話します。あなたの仕事は、毎日、次の会議に間に合うように、4つすべての数字を同じ根底の真実へと一致させることです。たいていの日は誰も気づきません。気づく日は、何かが壊れていて、その理由を見抜けるのがあなただけだからです。
あなたはまた、他の誰も考えないシステムのデバッガーです。Salesforceのフィールド名変更、Zapierのフロー、dbtの列のずれ、Outreachのキャンペーンマッピング、Lookerのexploreキャッシュ。これらはあなたの天気です。AEは天気をバグとして見ます。あなたはそれを火曜として見ます。
そしてあなたは、肩書きのない政治家です。あなたより上位の役職者たちの意見対立を、彼らが求めてもおらず全面的には信頼してもいないデータを使い、あなたのものではない締め切りで仲裁するのです。
6か月時点で良い状態とはどういうものか
着任して間もないなら、これらはあなたがやり遂げられる先行指標です。
- 組織で最大のデータ品質の漏れを3つ挙げられます。声に出して、メモなしで、売上への影響の順に。
- 誰も読まなかった定例レポートを少なくとも1つ廃止しました。それが見栄えだけのものだと判明したCROお気に入りなら、ボーナスポイントです。
- 予測（forecast）会議が、始めたころより15分短く終わります。質問が会議中ではなく会議前に答えられるからです。
- 少なくとも1人のAEが、自分で解決できることであなたにSlackするのをやめました。あなたが保存済みのレポートを作り、そのレポートが答える内容のDMに答えるのをやめたから、彼らは学んだのです。
- 財務があなたのパイプライン・カバレッジの数字を信頼しています。ここでの信頼とは、彼らが*「これは本物か」と尋ねるのをやめ、「これは何を示唆するか」*と尋ね始めることです。
6か月時点でこの5つのうち3つを達成しているなら、順調です。ゼロなら、職が壊れているのではありません。あなたの範囲が壊れているのです。あなたが実際に何を直すために雇われたのか、何を火消ししてきたのかについて、マネージャーと話しましょう。
毎日触れることになるスタック
ツールは2年ごとに変わります。カテゴリは変わりません。500万〜2億ドルのARRのB2B SaaSで、RevOpsマネージャーがたいてい携える道具がこれです。
- CRM：SalesforceまたはHubSpot。アカウント、コンタクト、商談のシステム・オブ・レコード。Salesforceはカスタマイズとステージロジックで勝り、HubSpotはセットアップの速さとマーケティング連携で勝ります。いずれにせよ、あなたのデータ品質の論争の60%が起きる場所です。
- 予測（forecast）の層：ClariまたはBoostUp。CRMの上に乗り、AI信号で案件を重みづけし、リスクを浮かび上がらせます。その数字を信頼するより検証する時間のほうが長くなります。真実のソースではなく、仮説エンジンとして扱いましょう。
- セールスエンゲージメント：OutreachまたはSalesloft。シーケンス、ダイヤラー、タスク記録。マーケティングがキャンペーン名を変更したときに最初に壊れる場所です。連携の健全性のdashboardをピン留めしておきましょう。
- チーム横断の実行：Rework。CRMのアクティビティを実際のデリバリー（導入、オンボーディング、サクセス）に結びつける、案件・タスク・プロジェクトの層を必要とするB2B SaaSチーム向け。セールスがCSやサービスチームに引き継ぎ、その作業がCRMの外のどこかに存在する必要があるときに、よく合います。チームが中規模（20〜500人）で、3つのツールを継ぎ接ぎせずに部門横断のオペレーションが必要なときに有用です。
- トランスフォーメーション：dbt。生のウェアハウスとBIの間のモデリング層を所有します。dbtを知らないなら、学びましょう。知っているなら、あなたはもう午後11時のオンコール要員です。
- BI：LookerまたはTableau。役職者が実際に開くもの。explore主導のセルフサービスにはLooker、役職者向けdashboardにはTableau。どちらもdbtの下流です。dbtが壊れていれば、BIも壊れています。
- Slack：実際の仕事の大半が起きる場所。DM、スレッド、非同期の論争。Slackの整備が下手なら、あなたの一日は下手になります。
ExcelとGoogleスプレッドシートにも、認めたくないほど触れることになります。ときには、3つの数字を照合する最速の方法は、それらをシートにダンプし、差分を目で見て、先へ進むことです。それを謝る必要はありません。
おわりに
このある火曜日(診断、仲裁、午後11時のSQL、CFOへの保留メール、SDRとの報酬影響をめぐる議論)に活力を感じるなら、あなたはこの職に向いています。仕事は楽ではありませんが、首尾一貫しています。一日のどの部分にも理由があり、その部分が積み重なっていきます。
それが罰のように聞こえるなら、職務記述書があなたに嘘をついたのです。次の予測（forecast）会議の前に身を引くことに恥はありません。RevOpsは殉教者を必要としていません。眠れる翻訳者を必要としているのです。
この記事が正体を暴く職務記述書については、対になるレベニューオペレーションマネージャーの職務記述書をご覧ください。職務記述書とこのある火曜日とのギャップこそ、ほとんどのRevOps採用者が最初の90日で失敗する場所です。両方を読んでください。判断してください。
さらに詳しく
