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日で失敗する場所です。両方を読んでください。判断してください。
さらに詳しく
