戦略コンサルティング

STP策定支援

ペルソナ / CJM /UXフロー策定支援

プライシング再設計支援

KGI / KSF / KPI / ミッションツリー策定支援

SaaSモデル / クラウド化転換支援

新規事業立ち上げ支援

ITコンサルティング

ビジネス部門支援

経営企画・事業企画チーム立ち上げ支援

カスタマーサクセスチーム立ち上げ支援

CS ヘルススコア構築支援

カスタマーサポート対応自動化支援

サービスサイト / ランディングページ構築 / リニューアル支援

オウンドメディア立ち上げ支援

プロダクト部門支援

グロースハック施策企画 / 実行支援

プロダクトロードマップ策定支援

プロダクト開発体制支援

プロダクト運用体制支援

プロダクト組織の強化 / 育成支援

開発部門支援

インフラ(クラウドサーバー)コスト削減支援

開発パートナー会社見極め・選定伴走

CTO採用支援

データ支援

データ基盤(DWH)構築支援

Tableauダッシュボード構築支援

GA4導入 / 活用支援

データ活用人材育成・トレーニング

サービス

RevOpsとは|AI時代の営業戦略を部門横断で立て直す仕組み

2026/7/28

リンクをコピー

  • # 営業マネージャー

  • # ワークフロー

マーケティング・営業・カスタマーサクセスを分けて数値を追ってきたものの、直近ではリードの質・受注率・売上の伸びに違和感を持ち始めた営業・マーケ管理職の方も多いのではないでしょうか。

近年、顧客の購買行動は、営業に会う前にほぼ完結する形へと変わったと言われています。
部門ごとに数値を分けて追う戦略では、この変化を捉えきれない構造になってきています。

そこで注目されているのが、売上に関わる部門をデータで横断して束ねるRevOps(Revenue Operations)です。

本記事では、定義・構成要素から、顧客行動の変化と分業モデルの限界という背景、実装ステップ、AI時代におけるRevOpsの役割の変化までを整理します。

RevOpsとは、部門横断での売上最大化を目指す営業戦略

RevOps(Revenue Operations)とは、マーケティング・営業・カスタマーサクセスなど、売上に関わる部門を横断してデータと業務プロセスを統合し、収益を最大化するという営業戦略の1つです。

RevOpsの定義

RevOpsは「Revenue Operations(収益に関わるオペレーション)」の略称です。

主要な調査会社やSaaSベンダーはそれぞれ次のように定義しています。

Gartnerは「人・プロセス・技術を統合し、部門を横断して顧客体験を一元化するエンドツーエンドのモデル」。

Salesforceは「マーケティング・営業・カスタマーサクセス・財務を1つの傘の下に揃え、収益に関わる活動を一体化する戦略的なフレームワーク」。

HubSpotは「営業・マーケティング・カスタマーサクセスを、共通のデータ・プロセス・ゴールで揃え、予測可能でスケーラブルな収益成長を実現するビジネス機能」と定義しています。

三者に共通するのは、RevOpsを単なる分析部門やレポーティング機能ではなく、経営レベルで複数部門を接続する仕組みとして扱っている点です。

RevOpsの構成要素

RevOpsは、人・データ・プロセスの3要素を統合する枠組みとしてよく整理されます。

  • :マーケ・営業・カスタマーサクセスなど、収益に関わる部門と役割

  • データ:MA・SFA・CRM・CSツールに分散する顧客情報

  • プロセス:リード獲得から受注、契約継続までの業務工程

各要素を単独で強化するのではなく、3要素を一体で機能させる点にRevOpsの特徴があります。分析人材を採用する、SFAを刷新する、といった単発の施策では、他の要素との噛み合わせで詰まりやすい構造を解消できません。

RevOpsとTHE Model、2つの戦略の違い

日本のSaaS・BtoB企業では、営業組織を語るときに 「THE Model」 が参照されるケースが多くあります。

THE Modelは、マーケティング/インサイドセールス/営業(フィールドセールス)/カスタマーサクセスの4部門に業務を分業し、それぞれの工程を明確に区切ることで生産性を高める設計です(『THE MODEL』翔泳社 特設ページ)。

RevOpsは、THE Modelを置き換えるものではありません。

THE Modelが「顧客の購買プロセスに沿って業務をどう分けるか」という業務プロセスの設計であるのに対し、RevOpsは「分けた部門を、どのような共通ゴール・データ・意思決定の仕組みで束ねるか」という部門横断の運営設計です。

したがって、両者はどちらかを選ぶ関係ではありません。
THE Model型の分業で立ち上がった組織が、部門間の分断が見え始めた段階でRevOpsを組み合わせるという順序が現実的な流れになります。

なぜ今RevOpsなのか、顧客行動の変化と分業モデルの限界

RevOpsが注目される背景には、顧客の購買行動が変わり、既存の分業型営業戦略では捉えきれなくなっているという構造変化があります。

顧客は営業に会う前に、購買判断のほとんどを終えている

Gartnerが2026年3月に公表した調査では、B2B購買者の67%が営業を介さない購買体験を望むと回答しました(Gartner 2026-03-09 プレスリリース)。

併せて、購買時に使うチャネルも増えています。
McKinseyのB2B Pulse 2024では、B2B購買者は購買プロセスで平均10チャネルを利用しており、2016年の5チャネルから倍に増えていると報告されました。

国内でも同じ方向の変化が確認されています。
アイティコミュニケーションズが2025年5月に実施したBtoB購買行動調査(n=517)では、購入検討時に比較する対象を3社以内に絞ると回答した人が81.4%に達しました。(BtoB購買行動調査2025)。

購買者は営業に会う前に自分でチャネルを渡り歩き、候補を3社以内に絞ってから接触してきます。
この状態で営業側が最初に会うタイミングでは、案件の主導権はすでに購買者側にあります。

THE Model型分業は、供給・引き継ぎのつなぎ目で綻ぶ

工程を分けて部門ごとに数値を追う運用は、部門間のつなぎ目に副作用を生みやすいことが指摘されています。

パーソル総合研究所のシニアコンサルタント河村亨氏は、THE Model型の運用がうまくいかない典型を3つに整理しています。

  • 読まない:営業が、マーケティングの獲得したリード情報やスコアを深く読み込まない

  • 追わない:営業が、引き継がれた案件よりも自分で開拓した案件を優先する

  • 引き継げない:受注後の引き継ぎが不十分で、顧客対応がフィールドセールスに戻ってくる

リブ・コンサルティングの松本氏は、原典『THE MODEL』の一節「インサイドセールスからの商談供給が減ってくると、営業はまだ『柔らかい状態でもいいからパスしてくれ』と言い始める」を引きながら、部門KPIの最適化が全体最適を損なう「負のループ」を指摘しています。

これらの副作用は、分業そのものの欠陥というより、分業した部門を束ねる共通のゴールとデータが欠けた状態で起こります。
「マーケティングはリード数を達成している」「営業の受注率も維持している」のに全社の売上が伸びない、という冒頭の違和感は、部門別の数値管理だけでは全体の状態を捉えられなくなっているサインです。

日本ではRevOps自体がまだ浸透していない

構造の変化と分業モデルの綻びは把握されつつある一方で、日本ではRevOpsの浸透は遅れています。

バーチャレクス・コンサルティングが2023年3月に実施した「RevOps 実態調査」では、RevOpsという言葉の全体認知度は約10%にとどまっています。(バーチャレクス 2023年 RevOps 実態調査 第1弾)

顧客行動が変わり、分業モデルの限界は日本国内でも指摘され始めているにもかかわらず、RevOpsはまだまだ認識されていません。

この浸透の遅れが、いま営業戦略の主軸を見直す動機の1つになっています。

RevOpsでデータに基づいた意思決定を

RevOpsが担う機能は、共通ゴールの設計・部門横断の業務プロセス管理・データに基づく意思決定に集約されます。

組織全体で追う共通ゴールの設計

RevOpsがまず手がけるのは、部門ごとに分かれたKPIを「収益」という共通のゴールに接続する設計です。

マーケティングはリード数、インサイドセールスは商談化数、フィールドセールスは受注率、カスタマーサクセスは継続率と、部門別のKPIを積み上げる管理は、「各部門のKPI達成が全体の売上増につながる」という前提の上に成り立っています。
購買行動が変わり、部門間の連携の質が成果を左右するようになると、この前提が崩れます。

RevOpsでは、部門KPIを廃止するのではなく、ARR(年間経常収益)や既存顧客からの収益維持率のような全部門共通のゴールを設定し、部門KPIをその下に位置づけ直します。

部門をまたぐ数値を意図的に持たせ、部門間の連携を促す設計です。

リードから受注、継続までを一貫して管理する業務プロセス

2つ目の役割は、リード獲得から商談、受注、契約継続までの業務工程を、1つの流れとして管理することです。

分業の下では、マーケティングはMA、営業はSFA、カスタマーサクセスはCSツールと、工程ごとにシステムも分かれます。
顧客はこの工程を順に通過していきますが、工程間の引き継ぎは担当者間の連絡に委ねられがちです。

RevOpsは、誰がどのタイミングで顧客情報を更新し、次の工程へ渡し、渡した後の結果をどう前の工程へ戻すか、という運用を部門横断で設計します。

データに基づく意思決定

3つ目の役割は、部門ごとのツールに分散した顧客データを統合し、意思決定に使える状態を保つことです。

MAのリード情報、SFAの商談履歴、CSツールの利用状況は、部門ごとに独立して更新されるため、横断して見ようとすると「同じ顧客が別々のIDで登録されている」「指標の定義が部門で異なる」という段階で止まります。

RevOpsは、共通の顧客ID、必須項目、指標の定義といったデータ運用のルールを整え、部門をまたいだ分析ができる状態を維持します。

3つが束なった結果、部門横断の意思決定が実データで立てられる

この3つの役割が揃うと、経営会議と部門会議が同じデータで議論できるようになります。

マーケティング費用の増減がいつ商談化に反映され、どれだけ受注につながったかを1つの時系列で追えるため、「マーケティング予算を増やすか、解約防止に振り向けるか」という部門をまたぐ投資判断を、実データで比較しながら行えます。
そして、この統合されたデータは、後述するAI活用の前提条件にもなります。

AI時代、RevOpsは営業戦略の前提になる

RevOpsは、AI活用の前提だった

AIを営業・マーケ・カスタマーサクセスで活用しようとしたとき、成果を左右するのは、部門横断の統合された顧客データの有無です。

生成AIやAIエージェントに顧客対応の要約、商談の優先順位付け、次の一手の提案などを任せようとしても、参照できるデータが部門ごとに分断された状態では、AIが読み取れる文脈が限定的になります。
マーケ側の接触履歴、営業側の商談経緯、カスタマーサクセス側の利用状況が1つの顧客像として結ばれていなければ、AIの出力も部分最適な提案に留まります。

RevOpsが整える「共通の顧客ID・揃った項目・一致した指標定義」は、そのままAIが読み取れるデータの条件と一致していまます。

RevOpsを取り入れることは、AIがより機能するための前提そのものだったと言えます。

AIがデータ分析のハードルを下げ、RevOpsのハードルを下げた

これまでRevOpsは、統合データを整えたあとの分析・意思決定を実運用するために、専門人材のコストが必要でした。
データを揃えても、そこから意思決定に使える示唆を引き出すために、データアナリストやデータエンジニアといった役割が不可欠だったからです。

この状況を変えたのが、AIによるデータ分析のハードル低下です。

分析人材を新たに採用しなくても、統合されたデータ層の上で、要約・優先順位付け・成約予測をAIに任せられる。

この変化が、RevOpsを「構想はしたが実践できなかった」段階から、「専任のデータ人材がいなくても実運用できる」段階へ移しつつあります。

営業の役割は、AIの分析を検証し意思決定を支える側へ

購買者側のAI利用も、営業の役割を変えつつあります。
Gartnerが2026年5月に公表した調査では、B2B購買者の69%が、AIが生成したインサイトを検証するために営業担当者に確認を依頼していると回答しました(Gartner 2026-05-20 プレスリリース)。

購買者は、AIの分析を出発点にして候補を絞り込みますが、その分析を鵜呑みにするわけではありません。
最終的な意思決定の前に、「この分析は正しいのか、自社の状況に本当に当てはまるのか」を人間の営業担当者に検証してほしいというニーズが、明確に表れています。

営業の役割は、情報を伝える役割から、AIの分析を検証し意思決定を支える役割へ移りつつあります。
この変化を受け止めるためには、ただマーケから渡されたリードに対応するのではなく、営業側でも顧客の状況を統合的に把握できていなければなりません。

RevOpsが整えたデータ基盤の上で、全体共通のゴールを達成するために、営業はより深い判断業務に集中することができる、というのがAI時代のRevOpsです。

RevOpsを実践するための5ステップ

現状の分業構造を活かしつつ、次の順序で段階的に導入できます。

  1. 現状分析と課題整理

  2. 共通KPIの設計

  3. データ統合と整備

  4. 教育と社内浸透

  5. 継続改善

ステップ1:現状分析と課題整理

出発点は、既存のマーケ・営業・カスタマーサクセスそれぞれのKPI、業務プロセス、使用ツール、データ格納先を洗い出すことです。

洗い出しは、部門ごとの活動を可視化する目的ではなく、次の観点で「部門を横断して見たときの課題」を掴むために行います。

  • 部門間で情報が分断している箇所(同一顧客が別IDで管理されている、更新責任者が不明確、など)

  • 部門KPIが達成されているのに全体売上が伸びていない工程

ステップ2:共通KPIの設計

現状分析で見えた綻びを踏まえ、全部門が接続する共通ゴールを1〜2つ立てます。

新しい指標体系を作る必要はありません。
経営会議で見ている売上目標(ARRや年間売上)が、そのまま共通ゴールの候補になります。
共通ゴールと部門KPIの因果関係を明示し、各部門のKPI達成が共通ゴールの達成につながる形に紐付け直すのが、この段階の中心作業です。

たとえば、マーケのMQL数を単独で最大化しても、営業の受注率が下がってしまえば全体売上は伸びません。
共通ゴールと部門KPIを明示的につなぐと、この構造が経営会議レベルで見えるようになります。

ステップ3:データ統合と整備

共通KPIが決まったら、部門をまたいで数字を見るために必要なデータ統合に着手します。

いきなり大規模なデータ基盤を構築する話ではありません。
まず、次の水準の整備から始められます。

  • 同じ顧客が全ツールで1つのIDに紐付いていること

  • リード獲得日・商談化日・受注日・解約日など、時系列で追うための必須項目が全ツールで揃っていること

  • 部門間で意味の揺れがある指標(「商談」の定義、「アクティブユーザー」の定義など)に共通の言葉を与えること

大規模なデータ基盤やRevOpsプラットフォームの導入は、この段階を経てから検討するで十分です。運用ルールの整備が先で、技術の刷新は後、という順序です。

ステップ4:教育と社内浸透

共通KPIとデータ運用ルールを設計しても、部門の管理職・現場が日常業務の中で守り続けなければ機能しません。

バーチャレクスの調査でRevOpsの認知度が約10%にとどまるという事実(バーチャレクス調査 第1弾)は、日本企業で共通ゴール型の枠組みが浸透していない状態を示しています。
RevOpsを導入する側は、部門管理職に対して「既存の部門KPIをなくすわけではなく、その上に共通ゴールを載せる」ことを伝える必要があります。

ここで語られる「教育」は、新しい方法論を暗記する研修ではなく、「なぜ共通ゴールを追う必要があるのか」を各部門の現場が自分の言葉で説明できる状態を作ることを指します。
共通ゴールと部門KPIの因果関係を、各部門管理職が自部門のチームに説明できる、というのが最初のラインです。

ステップ5:継続改善

RevOpsは、一度設計して終わりの仕組みではありません。
顧客の購買行動は今後も変わり続けるため、共通ゴール、データ運用、部門役割の割り付けを継続的に見直すサイクルが必要になります。

共通ゴールと部門KPIの因果関係が実データで確認できているか、部門間のつなぎ目で新しい綻びが出ていないかを点検します。
この点検自体を業務として位置づけると、単発の見直しで終わらず、営業戦略の主軸として機能し続けます。

まとめ

RevOpsは、マーケティング・営業・カスタマーサクセスなど売上に関わる部門を横断し、共通ゴール・業務プロセス・データ統合を経営レベルで束ねる枠組みです。
THE Model型の分業設計とは異なり、両者は並行して機能させられる関係にあります。

顧客の購買行動は営業に会う前にほぼ完結する形へ変わり、部門KPI最適化と全体売上の乖離が国内でも指摘され始めているにもかかわらず、日本ではRevOpsの認知度が約10%にとどまっています。

これからの営業戦略は、データ基盤を整え、AIを活用したRevOpsを取り入れていく方向に移っていき、同時に、営業の役割は顧客への情報伝達から、顧客の判断の支援へと重心が移ってきています。

The Modelという営業戦略を見直すタイミングは、すでに来ています。

知見・コラム

  • コラム

考えながら動き、動きながら考える:未知を扱うプロジェクトの進め方

プロジェクトは立ち上がり、担当も決まり、メンバーはそれぞれのアクションを着実に進めている。定例会議では毎回、各担当から進捗が報告される。それなのに、プロジェクト全体として前に進んでいる感じがせず、狙っていた数値も動かない。私はデータとAIの領域で複数の会社の新規の取り組みを支援する中で、この状態を何...

2026/8/17

  • コラム

「使うたびに賢くなるAI」は、待っていても来ない

AIは使えば使うほど賢くなる、という言い方をよく見ます。私はこれを、半分だけ本当だと思っています。モデルは確かに進化します。ただ、自分の会社のやり方や、自分の文章の癖を、AIが使っているうちに勝手に覚えてくれることはありません。昨日直したことを、今日もまた直す。AIを業務で使っている方なら、覚えがあ...

2026/8/17

  • コラム

BigQueryのDWHを非構造化データへ拡張する:データレイクハウスの全体像

BigQueryでDWH(データウェアハウス)を構築すると、売上・顧客・広告といった構造化データを統合して分析できるようになります。そこに「議事録や過去の戦略資料からも示唆を出したい」という要望が来ることがあります。PDFやPowerPoint、音声はBigQueryのテーブルには入りません。本記事...

2026/8/12

記事一覧へ

arrow_forward

お役立ち資料

営業部門のAIエージェント活用ガイド|営業現場が変わる10の業務

ダウンロード

お役立ち資料一覧を見る

Contact

まずはお気軽にご相談ください