RevOps は、営業・マーケティング・カスタマーサクセスを収益という一つの流れとして設計し、部門をまたいでデータと指標を共通にする進め方です。読み方はレブオプス、Revenue Operations の略になります。統合という言葉の大きさに反して、実際に決めるのは権限・データの出口・通知の宛先・記録の定義という具体物です。
RevOpsとは何か
RevOps は、収益に関わる部門の取り組みを横断して管理する機能または組織を指します。営業支援ツールの名前ではなく、部門の設計と運用の話です。
対象になるのは、マーケティングが見込み客をつくり、営業が商談にし、カスタマーサクセスが継続を支えるという一続きの流れです。従来はこの三つが別々の目標と別々のシステムで動いてきました。RevOps はこれを一つのプロセスとして扱い、同じ顧客情報と同じ指標で判断できる状態を目指します。
この状態を誰が設計し、誰が維持するかを決めるのが RevOps の実務です。組織を新設するか、既存の部門が兼務するかは後から決まります。
日本語では収益オペレーション、レベニューオペレーションと訳されます。表記が揺れるのは概念が米国発で、国内での定訳が定まっていないためです。検索では RevOps、レベニューオペレーション、Revenue Operations のいずれでも同じ内容に行き着きます。
SalesOps・MOps・BizOpsとの違い
名前が似た概念があり、混同されやすいところです。違いは対象範囲にあります。
呼称 | 対象範囲 | 主な担当 |
|---|---|---|
SalesOps | 営業部門の業務設計と数値管理 | 営業企画 |
MOps | マーケティング部門のツール運用と効果測定 | マーケティング |
CS Ops | 契約後の顧客対応と継続率の管理 | カスタマーサクセス |
RevOps | 上記3つを収益の流れとしてまとめて見る | 横断組織または兼務 |
BizOps | 収益以外も含む全社の業務改善 | 経営企画 |
RevOps は SalesOps を置き換えるものではありません。部門ごとの最適化が進んだ結果、部門の境目で情報が落ちるようになったときに必要になります。
境目で何が落ちているかを説明できない段階では、RevOps という名前を使わずに済むことも多くあります。逆に、同じ顧客について部門ごとに違う数字が出てくるなら、対象はすでに揃っています。
統合が止まる4か所
ここからが、定義の解説では扱われない部分です。
営業支援ツールやマーケティングツールの公開レビューには、部門をまたいでデータを扱おうとしたときに何で止まったかが具体的に残っています。ここでは ITreview に公開されている利用者の声を整理しました。diver の顧客の事例ではなく、市場の利用者が書いた内容です。
整理の対象にしたのは、RevOps に関わる領域のツール9製品に付いた ja-JP のレビューです。内訳はAI商談解析と音声解析、自動化と連携の基盤、マーケティングオートメーション、営業支援、Web接客です。製品が違っても、書かれている詰まりの種類は重なります。
止まる場所は、おおむね次の4つに集まります。いずれも製品を横断して現れ、部門をまたぐ段階で表面化する項目です。
どれか一つでも塞がっていると、残りを設計しても動きません。順番の話は後半で扱います。
1. 権限 — 組織単位でしか切れない
一つのテナントを全社で使うとき、他部署のデータが見えないように閲覧権限を分けられるかが問題になります。会議解析ツールの利用者は、AI の抽出設定やフィードバック設定をテナント単位ではなく利用部署ごとに指定したいと書いています。
連携ツール側でも同じことが起きます。ある利用者は、組織で使うにはアクセス権限を細かく設定できず、アプリの権限さえあればユーザーが何でもできてしまう点を挙げています。別の利用者は、個人情報が連携サービス側のサーバに残る点を懸念し、触れる人を一定の範囲に絞るのが現実的な解だとしています。
セルフホスト型の自動化ツールでは、一つのインスタンスを複数ユーザーで共有できないために、小さな社内利用や部内利用に留まったという声もあります。ユーザーごとにワークフローを設計できるようにしてほしいという要望も出ています。
海外製ツールでは、画面とFAQが英語であることと認証方式の弱さが同時に問題になった例もあります。ある利用者は、Google アカウントなどと接続することを考えると当時はセキュリティに不安を感じたと書いています。公式の日本語リソースがないという指摘も別のツールで出ています。
権限は導入時の設定項目に見えますが、実際には展開できる範囲の上限を決めます。全社に広げる前に、部署単位で切れるかを確認します。
2. データの出口 — 画面で見える数字が取り出せない
部門横断の集計は、各ツールからデータを出せることが前提になります。ここが塞がっていると、統合は設計の前で止まります。
マーケティングオートメーションの利用者は、エクスポートできるデータに制約が多く、他システムとの連携やクロス集計をしたい場面で行き詰まると書いています。画面で見えている情報の生データをそのまま出せれば助かる、という要望です。
別の利用者は、サイトのアクセス分析に GA4 を使っているため、ツール側のデータと掛け合わせたいが手間がかかると述べ、GA4 や Looker Studio への連携を求めています。分析基盤に出せるかどうかが、そのまま部門横断の可否になります。
営業支援ツールでは連携先の顔ぶれも条件になります。ある利用者は、Salesforce や HubSpot とは API 連携があるものの、グローバルではメジャーでなくとも国内シェアの高いツールとは連携していない点を指摘しています。国内の構成で使う以上、連携先の一覧は国内前提で確認します。
3. 通知の宛先 — 送る側と受け取る側で管理部門が違う
連携が止まったときに誰が気づくかは、部門をまたいだ瞬間に難しくなります。同じ部署の中であれば担当者が見ていますが、部門をまたぐと見ている人がいなくなります。
連携ツールの利用者は、エラー通知先のメールアドレスを複数登録できるようにしてほしいと書いています。理由は明確で、送る側と受け取る側で管理部門が異なるため、両方の部署が同時に検知する必要があるからです。
別の利用者は、エラー発生時に問題を特定したりテストしたりすることが大変だと述べています。通知がループして鳴り止まなくなった経験を挙げる声もあります。通知は多ければよいものではなく、宛先と条件を設計する対象です。
RevOps を始める前に決めるのは、統合の理想形ではありません。連携が止まったとき、どの部署の誰に、どの条件で届くかです。
4. 記録の定義 — 誰が・どこで・何を記録するか
ツールを入れる前に運用の定義が要る、という指摘は複数のレビューに共通します。
商談支援ツールの利用者は、ツール経由で問い合わせが入ると担当者名や引き継ぎの前提情報が文脈に依存しやすく、初動で確認コストが発生し得ると書いています。そのうえで、運用マニュアル側で担当者の定義、初回対応テンプレート、引き継ぎルールを固定する必要があるとしています。
ここで固定すべきなのは、誰が・どこで・何を記録するかの3点です。これが決まっていないまま統合すると、データは集まっても意味が揃いません。
認証方式も同じ段階で確認します。ある利用者は、SAML 認証に対応していないため自社の IDaaS と連携できず、セキュリティ面で不安があると述べています。認証が社内の基盤に合わないと、全社展開はその手前で止まります。
共通の指標をどう決めるか
RevOps が目指すのは、同じ顧客情報と同じ指標で判断できる状態です。ツールをつなぐだけでは、この状態にはなりません。
部門ごとのKPIを足しても全体の指標にはならないためです。マーケティングは獲得件数、営業は受注金額、カスタマーサクセスは継続率を見ています。三つとも正しく達成されていても、同じ顧客がどの段階で落ちたかは誰も見ていない、という状態が起こります。
共通指標を置く前に、次の3点を先に決めます。いずれも計算式ではなく、定義の問題です。
受注をいつ計上するか: 契約書の締結日か、初回請求日か、サービス提供開始日か。部門ごとに違うと、同じ月の数字が三通り出ます
どこからを有効な商談と呼ぶか: 商談化の条件が営業側の主観で決まっていると、マーケティングの獲得件数と接続できません
顧客を何で一意にするか: 法人番号か、CRM の組織IDか。表記揺れや重複が残ったままでは、部門をまたいだ集計が合いません
この3点が決まって初めて、LTV や ARR といった全体指標に意味が出ます。分子と分母がどのシステムのどの項目から来るのかを、指標ごとに書き出しておきます。
指標の定義は会議で決め、ツールの設定はその後に合わせます。順番が逆になると、システムの都合で定義が決まり、後から業務のほうを合わせることになります。
着手の順番
RevOps の設計は、組織図を描くところからは始まりません。今あるツールで何ができないかを確認するところから始めます。
順番には理由があります。前の項目が塞がっていると、後ろの項目は設計しても動きません。
順 | 決めること | 確認する場所 | 塞がっていたときに起きること |
|---|---|---|---|
1 | データを出せるか | 各ツールのエクスポート画面と API 仕様 | 集計が手作業になり、担当者以外に引き継げなくなる |
2 | 誰が触れるか | 権限設定の粒度が組織単位か部署単位か | 全社に広げる段階で止まる |
3 | 何を記録するか | 運用マニュアルの担当者定義と引き継ぎルール | データは集まるが、意味が部門ごとに違う |
4 | 誰に知らせるか | 連携エラーの通知先設定 | 止まったことが記録に残らない |
1を最初に置くのは、ここだけが自社側で変えられないためです。エクスポートの範囲と API の仕様はツールの提供元が決めています。契約後に判明すると、選び直すか手作業で埋めるかの二択になります。
2は設定で変えられますが、変えられる粒度には上限があります。テナント単位でしか切れないツールを全社共通の基盤に据えると、部署ごとの運用が作れません。利用部署が複数になる前に確認します。
3と4は自社で決める部分です。決めるのに費用はかかりませんが、決めないまま統合すると後から遡って直せません。担当者の定義と引き継ぎルールを先に文章にし、連携が止まったときの通知先を部署をまたいで設定します。
この4つが揃った後で、どのツールをどうつなぐかの設計に入ります。順番を逆にすると、つないだ後に前提が変わって作り直しになります。
数年後に効いてくるもの
導入直後には問題にならず、運用が続いた後に効いてくるものがあります。
マーケティングオートメーションの利用者は、導入して4年弱でタグなどの情報が溜まりすぎ、整理が難しい状況になっていると書いています。タグが重要な起点になっているにもかかわらず検索ができない点に困っており、製品数や施策が多い会社では定期的に全て出力して整理する努力が必要だとしています。
別の利用者も、タグが増えすぎて管理しにくくなっている点と、数字を細かく出せれば他部署への連携もスムーズになるという見込みを同時に挙げています。属性情報の棚卸しと部門横断の集計は、同じ問題の裏表です。
計画の立て方についても、実測に基づく指摘があります。ある利用者は、導入から実際の運用まで1か月ほどかかったため、オンボードの段階で自社に合わせた具体的な活用提案がほしかったと書いています。計画は契約日や導入日ではなく、運用開始日を起点に引きます。
棚卸しは運用に組み込みます。溜まってから整理しようとすると、どの属性が今も使われているかを判定する作業から始めることになります。四半期に一度、使われていない項目を落とす時間を運用の予定に入れておきます。
関連する設計は AIエージェントとRevOps｜業務フローに定着させる実装方法 と iPaaSとは で扱っています。
自社でやるか、社外チームと進めるか
RevOps を回す体制をどう持つかは、支援をどれだけ受けられるかで決まります。ツールの機能の多さとは別の軸です。
公開レビューには、支援の受け方に関する声がまとまって出てきます。ある利用者は、契約しているプランの全ての機能を使いこなしている実感がないと述べ、追加機能の案内はメールで届くものの、個別具体的なサポートを求めていると書いています。
カスタマーサクセスが受け身で、こちらからのオーダーに対してのみ動くという指摘もあります。多機能な分、幅広く深く使うにはサポートに伴走してもらう必要があると感じたという声も出ています。判断の軸は、社内に設計できる人が何時間割けるかです。
少人数の組織では、タグの埋め込みなどのセッティングを自分で行う必要があり、任せられれば助かるという声もありました。社内で設計を担える人がいるかどうかで、外に出す範囲が決まります。
部門ごとの数値の揃え方は 営業・マーケティング・CSのデータを揃える、営業側の定着は セールスイネーブルメントとは を参照してください。
向かないケース
RevOps の枠組みが合わない状況もあります。次に当てはまるうちは、名前を先に置かないほうが早く進みます。
部門が分かれていない段階では、境目そのものが存在しません。営業とマーケティングを同じ担当者が見ている規模であれば、統合すべき対象がまだできていない状態です。
ツールの入れ替えが進行中の場合も、いったん保留にします。移行の途中はデータの持ち方が固まっておらず、統合の設計が二度手間になります。移行後の構成が確定してから着手します。
担当できる人がいない場合も、着手を急ぎません。設計を担う人が決まらないまま統合を進めると、つないだ後の運用と障害対応の持ち主がいない状態になります。誰の業務時間をどれだけ充てるかを先に決めます。
数字の定義で合意が取れていない場合は、そちらが先です。受注をいつ計上するか、どこからを有効な商談と呼ぶかが部門ごとに違うまま統合すると、揃った数字が揃って間違う状態になります。定義の合意は、ツールの設定ではなく会議で決める項目です。
よくある質問
RevOpsの読み方は何ですか
レブオプスと読みます。Revenue Operations の略で、日本語ではレベニューオペレーション、収益オペレーションと訳されます。
RevOpsとSalesOpsは何が違いますか
SalesOps は営業部門の中の業務設計と数値管理を担います。RevOps はマーケティング、営業、カスタマーサクセスの3領域をまとめて収益の流れとして扱います。置き換えではなく、対象範囲の違いです。
Revenue OperationsとRevOpsは同じものですか
同じものです。Revenue Operations が正式な呼称で、RevOps はその略称です。Revenue Ops、レベニューオプスという表記も同じ対象を指します。
RevOpsの構築は何から始めますか
使っているツールから、画面で見えている数字をエクスポートできるかの確認から始めます。ここが塞がっていると後続の設計が手作業になるため、組織や役割を決めるより先に置きます。エクスポートの範囲と API の仕様は提供元が決めているため、自社側で変えられない唯一の項目です。
専任の組織が必要ですか
不要です。部門の境目で情報が落ちている箇所を特定し、そこの権限と記録の定義を決めることから始められます。専任を置くかどうかは、扱う範囲が広がった後の判断です。
小さい組織でも意味がありますか
部門が分かれていない段階では、RevOps という枠組みを使う必要はありません。同じ顧客について部門ごとに違う数字が出るようになった時点が、着手の目安です。
ツールを統一すれば解決しますか
解決しません。公開レビューで挙がっている詰まりは、権限の粒度、エクスポートの可否、通知の宛先、記録の定義に集まっています。いずれもツールを揃えるだけでは決まらない項目です。
導入にどのくらいかかりますか
ツールの導入と運用の開始は別の日付になります。公開レビューには、導入から実運用まで1か月ほどかかった例が出ています。計画は運用開始日を起点に引きます。
途中で止まったときはどこを見ますか
連携のエラー通知が、止まった側と受け取る側の両方の部署に届いているかを確認します。通知の宛先が片方にしか設定されていない状態では、止まっていること自体が記録に残りません。
業務フローの設計から相談する
RevOps を名前から始めるのではなく、今の業務フローとデータの持ち方を整理するところから進めます。
参照元
本文で扱った利用者の声は、ITreview に公開されている市場の利用者によるレビューを要約したものです。diver の顧客の実績ではありません。
記事情報
著者: diver編集部
レビュー: diverチーム
更新日: 2026年9月16日