この記事の要約
RevOps（Revenue Operations）は「新しい肩書き」ではなく、営業・マーケティング・カスタマーサクセス（CS）を横断して売上プロセス全体を整える仕組みです。営業企画やマーケティング企画は、それぞれの部門内の計画・数値管理を担いますが、部門間の定義のズレやデータの断絶までは扱いません。RevOpsはその「部門と部門のあいだ」に生まれる問題を専門に扱う機能です。
この記事では、RevOpsの定義、営業企画・マーケティング企画との役割の違い、担当範囲、横断的に扱う典型課題、導入に必要な条件を整理します。読み終えたときには、自社にRevOpsという職種を新設して採用すべき状況なのか、それとも既存の体制のまま役割分担を見直すだけで始められる状況なのかを、自社の状態に照らして判断できるようになります。
この記事でわかること
- RevOpsの定義と、営業企画・マーケティング企画との役割の違い
- RevOpsが担当する範囲と、横断的に扱う代表的な課題
- RevOpsを機能させるために必要な導入条件
- 職種として採用が必要なケースと、既存体制のまま始められるケースの見分け方
- 導入判断を誤らないためのチェック観点
はじめに
営業部門は「今月の商談数が足りない」と言い、マーケティング部門は「リードは渡しているのに営業が追いかけていない」と言う。CSは「解約しそうな顧客の情報が、営業からもマーケからも回ってこない」とこぼす。こうした食い違いを会議の場で何度も聞いたことはないでしょうか。
それぞれの部門は自部門の計画には忠実に動いているのに、部門をまたいだ瞬間に情報も定義も噛み合わなくなる。この「あいだの空白」を放置したまま、営業企画やマーケティング企画にさらに調整業務を積み増しても、根本的な解決にはなりません。RevOpsという考え方は、まさにこの空白を担当領域として明確にするために生まれてきました。
結論：RevOpsは「部門間の売上プロセス」を担当する機能である
先に結論から整理します。RevOpsとは、営業・マーケティング・CSという異なる部門にまたがる「顧客が生まれてから収益化されるまでの一連のプロセス」を、ひとつの仕組みとして設計・運用・改善する機能のことです。営業企画やマーケティング企画のように部門内の計画立案や数値管理を担うのではなく、部門と部門のつなぎ目にある定義・データ・プロセスのズレを解消することが本来の役割になります。
この記事全体は、次の順番で確認していきます。
- RevOpsの定義と、営業企画・マーケティング企画との違い（役割の切り分け）
- RevOpsが横断的に担当する具体的な課題領域
- RevOpsを機能させるために必要な導入条件
- 職種採用が必要なケースと、既存体制のまま始められるケースの分岐
この順で読み進めることで、「うちにRevOpsは必要か」という漠然とした問いを、「どの課題を、誰が、どの体制で扱うか」という具体的な判断に変換できます。
RevOpsとは何か：営業企画・マーケティング企画との違い
3つの機能はどこが違うのか
営業企画、マーケティング企画、RevOpsはしばしば混同されますが、扱う「範囲」がそもそも異なります。次の比較で全体像をつかんでください。
| 機能 | 主な担当範囲 | 意思決定の軸 | 典型的な成果物 |
|---|---|---|---|
| 営業企画 | 営業部門内の計画・目標・案件管理 | 営業部門の売上目標達成 | 営業計画、案件進捗レポート |
| マーケティング企画 | マーケティング部門内の施策・予算・リード獲得計画 | マーケティング部門のリード目標達成 | 施策計画、リード獲得レポート |
| RevOps | 営業・マーケ・CSをまたぐ定義・データ・プロセスの整合 | 部門間で分断されない収益プロセス全体の健全性 | 顧客段階の共通定義、部門間の連携ルール、横断ダッシュボード |
営業企画は「営業がどう動けば目標を達成できるか」を考える立場です。マーケティング企画は「どの施策でどれだけリードを作れるか」を考える立場です。どちらも自部門の中で完結する計画には強いのですが、「マーケティングが作ったリードの定義と、営業が商談化と判断する基準が違う」といった、部門をまたぐ問題には手が届きにくい構造になっています。これは能力の問題ではなく、そもそもそこまでが職務範囲に含まれていないためです。
なぜ「部門内最適」だけでは限界が来るのか
たとえば、次のような仮想の状況を考えてみます。
仮想例：
あるBtoB企業では、マーケティング部門が「資料請求をした人」をすべて「リード」としてカウントし、月次で獲得件数を報告していました。一方、営業部門は「一度商談の日程が確定した人」を初めて「見込み客」として扱い、それ以前の連絡先には対応の優先度をつけていませんでした。結果として、マーケティングは目標のリード数を達成しているのに、営業からは「使えるリードが来ない」という不満が続き、双方が相手の部門の仕事の進め方を疑うようになりました。
この状況で、マーケティング企画がリード獲得数を増やしても、営業企画が商談化率の改善策を練っても、根本の「リードの定義が部門間でそろっていない」という問題は解決しません。定義そのものを両部門の外側から整理し、共通のルールとして固定する役割が必要になります。これがRevOpsの出発点です。
RevOpsが横断的に扱う代表的な課題
RevOpsの担当範囲は「なんでも屋」ではありません。扱う課題には一定の共通点があり、いずれも「単独の部門では解決できない」という性質を持っています。
課題1：顧客段階の定義のズレ
前述のリードの例のように、「リード」「見込み客」「商談」「顧客」といった段階の定義が部門ごとに異なると、レポート上の数字が一致しなくなります。RevOpsは、これらの定義を一つの共通言語として整理し、CRM（顧客関係管理システム、営業・マーケティングの顧客情報を一元管理する仕組み）上のステータスとして統一する役割を担います。
課題2：データの断絶と重複
マーケティングが使うMA（マーケティングオートメーション、見込み客への施策を自動化するツール）、営業が使うCRM、CSが使う顧客管理ツールがそれぞれ別々に運用されていると、同じ顧客の情報が複数箇所に分散し、どれが「正しい情報」なのか誰も判断できなくなります。RevOpsは、どのシステムをどの情報の正本とするかを決め、連携のルールを設計します。
課題3：引き渡し(ハンドオフ)の欠落
マーケティングから営業へ、営業からCSへと顧客が引き渡される場面で、条件やタイミングが曖昧だと、対応漏れや二重対応が発生します。「どの条件がそろったら、誰に、いつ渡すか」というルールを部門横断で設計するのも、RevOpsの典型的な仕事です。
課題4：指標の分断による経営判断の遅れ
各部門が自部門の指標だけを追っていると、経営層は「結局、売上を生む仕組み全体が健全なのかどうか」を把握できません。RevOpsは、部門横断の指標を一枚のダッシュボードにまとめ、経営判断のスピードを支える役割も持ちます。
これら4つの課題に共通するのは、どれも「誰か一つの部門の努力」では解決できず、部門の外側から全体を見る視点が必要という点です。営業企画やマーケティング企画に「もっと連携してほしい」と伝えるだけでは、この構造上の問題は解消されません。
部門間の引き渡しを売上プロセスとして設計する実務は、次の記事で確認できます。
CRMを売上プロセスの基盤として整える進め方は、次の記事で整理しています。
RevOpsを機能させるために必要な導入条件
条件を満たさないまま始めると起きること
RevOpsという役割や体制だけを用意しても、いくつかの前提条件が欠けていると、単なる「会議の進行役」で終わってしまいます。次の条件がそろっているかを、導入前に確認してください。
RevOps導入前チェックリスト
- 顧客段階（リード・見込み客・商談・顧客など）の定義を統一する権限を、誰かが明確に持っているか
- 営業・マーケ・CSのデータが、少なくとも一つのシステム上で突き合わせ可能な状態にあるか
- 経営層が、部門間の縦割りを是正する意思決定を後押しする立場にあるか
- 各部門の責任者が、自部門の指標だけでなく横断指標にも目を通す会議体があるか
- 変更(定義変更・プロセス変更)を全部門に周知し、定着させる運用フローがあるか
このうち特に見落とされがちなのが1つ目と3つ目です。RevOps担当者を置いても、定義を統一する権限が与えられていなければ、各部門の言い分を聞いて回るだけの調整役になってしまいます。また、経営層が「部門ごとの数字さえ良ければよい」という姿勢のままだと、部門間の壁を越える提案は現場レベルでは通りません。RevOpsは本質的に部門の利害調整を伴う機能であるため、経営の後ろ盾がないと機能しにくいという特徴があります。
導入の順序を間違えないための考え方
条件が整っていない段階でいきなり専任者を採用しても、権限と情報が伴わないまま孤立してしまうケースが少なくありません。そのため、導入は次のような順序で検討するのが現実的です。
- まず、顧客段階の定義のズレやデータの分散状況を棚卸しする
- 経営層を交えて、定義統一の権限をどこに置くかを決める
- 横断指標を可視化する仕組み(既存のCRMやBIツールの活用を含む)を整える
- 運用が回り始めてから、専任化や採用の要否を検討する
この順序を踏まずに「とりあえずRevOpsを名乗る人を置く」形にすると、名前だけが先行して実態が伴わない体制になりがちです。
職種採用が必要なケースと、既存体制で始められるケースの違い
判断の分かれ目はどこにあるか
「RevOpsは職種として採用すべきか、それとも既存の営業企画・マーケティング企画のメンバーが兼務すればよいのか」は、多くの経営者が悩む論点です。結論としては、部門横断の課題の量と複雑さ、そして専任で継続的に扱う必要があるかどうかで判断が分かれます。
| 状況 | 目安となる特徴 | 適した進め方 |
|---|---|---|
| 既存体制で始められるケース | 部門間の課題が特定の数点に限られる。CRMは1つに統一済み。経営層が定義統一に直接関与できる規模の組織 | 営業企画・マーケ企画の担当者が、月次などの頻度で横断課題の整理を兼務する |
| 職種採用が必要になりやすいケース | 使用システムが複数に分かれ連携が複雑。部門数・拠点数が多く調整コストが高い。横断課題が継続的に発生し、片手間では対応しきれない | 専任のRevOps担当を置き、定義管理・データ連携・横断指標の運用を継続的に担わせる |
たとえば、営業とマーケティングの2部門だけで完結し、CRMも一本化されている比較的小規模な組織であれば、営業企画の担当者が月に一度、マーケティング企画の担当者と定義のすり合わせを行うだけでも、多くの課題は解消できます。この段階で無理に専任のRevOps職を採用する必要はありません。
一方で、営業・マーケティング・CSに加えて複数の事業部やシステムが存在し、部門間の調整が常態化しているような組織では、兼務では対応しきれない量の課題が発生し続けます。このような状態になったときに初めて、専任者の採用や、外部の専門人材の活用を検討する段階に入ります。
見誤りやすい判断のパターン
現場でよく見られる誤った判断のパターンとして、次の2つが挙げられます。
- 課題が少ないのに先に採用してしまう:業務量に見合わない専任者を置き、担当者自身が「何をすればよいか分からない」状態に陥る
- 課題が積み上がっているのに兼務のまま放置する:営業企画・マーケ企画の担当者が本来業務に加えて調整業務を抱え、どちらも中途半端になる
自社がどちらの状態に近いかは、前章のチェックリストと合わせて、「横断課題が月に何件発生しているか」「対応にどれだけの工数がかかっているか」を実際に洗い出すことで、感覚ではなく事実として判断できるようになります。
まとめ
RevOpsは、営業企画やマーケティング企画の「上位互換」でも「置き換え」でもなく、部門と部門のあいだに生まれる定義のズレ・データの分断・引き渡しの欠落を扱う、独立した機能です。導入にあたっては、定義を統一する権限、データを突き合わせられる環境、経営層の後押しという条件が欠かせません。
そのうえで、横断課題が限定的であれば既存体制の兼務で始め、課題が継続的かつ複雑になってきた段階で職種としての採用を検討する、という順序で考えることが、遠回りをしない導入の進め方になります。
Q&A
- QRevOpsと営業企画は、どちらが上位の役割になりますか?
- A
上下関係ではなく役割の範囲が異なります。営業企画は営業部門内の計画と目標管理を担い、RevOpsは営業・マーケティング・CSをまたぐ定義やプロセスの整合を担うため、両者は補完関係にあります。
- QRevOpsを導入すれば、部門間の対立はすぐに解消されますか?
- A
役割を置くだけでは解消しません。定義を統一する権限や経営層の後押しといった条件が伴って初めて機能するため、体制づくりと並行して前提条件を整える必要があります。
- Q小規模な組織でもRevOpsという考え方は必要ですか?
- A
職種としての採用が必須ではなくても、考え方自体は規模を問わず有効です。部門間で顧客の定義をそろえる、データの正本を決めるといった取り組みは、小規模な組織でも横断課題が発生した時点から始められます。
専門用語解説
- RevOps（Revenue Operations）:営業・マーケティング・カスタマーサクセスを横断し、売上を生むプロセス全体を設計・運用する機能
- CRM（顧客関係管理システム）:顧客との接点や商談状況などの情報を一元管理するシステム
- MA（マーケティングオートメーション）:見込み客への情報発信やスコアリングなどの施策を自動化するツール
- ハンドオフ:ある部門から別の部門へ、顧客対応の担当を引き渡す業務上の受け渡しポイント
- ICP（Ideal Customer Profile）:自社にとって最も適合度の高い理想的な顧客像を定義したもの
