月次の経営会議で、3つの数字が出てくる。マーケティング部門が報告するリード獲得件数、営業部門が報告する商談件数、カスタマーサクセス部門が報告する解約率。どれも達成しているように見えるのに、売上の着地見込みは計画を下回っている。「どこで漏れているのか」と問うと、部門ごとに違う説明が返ってくる——1,000名規模の組織で繰り返されている場面です。
この状態は、各部門が怠けているから起きるのではありません。各部門が自分の指標を最適化しているからこそ起きます。リード獲得件数を追う部門は件数を最大化し、商談件数を追う部門は着手しやすい案件を選び、解約率を追う部門は解約の兆候が出た顧客だけを見る。それぞれ合理的な行動が、全体としては収益に結びつかない。
RevOps（レベニューオペレーション）は、この構造そのものを設計対象にする考え方です。本記事では、日本の大企業でRevOpsを機能させるために何を決め、CRMにどう実装するかを、実務の順序に沿って整理します。
目次
RevOpsは、収益に関わる部門——マーケティング、営業、カスタマーサクセス——のプロセス・データ・指標を統合して管理する機能です。個別の部門改善ではなく、収益が生まれる一連の流れ全体を一つの対象として扱う点が特徴です。
この考え方が要求されるようになった理由は明確です。収益モデルが変わったからです。売切り型のビジネスでは、収益は受注時点でほぼ確定します。ところがサブスクリプション型や保守契約型では、収益の大半が受注後に発生します。受注までを営業が見て、受注後をカスタマーサクセスが見るという分業は、収益の大半を「別部門の話」にしてしまいます。
ここを最初に決めないと議論が空転します。実務上は、機能として始めて、必要になったら組織にするのが現実的です。
専任部署を作ることを目的にすると、部署の設置自体がゴールになり、既存部門からの人員拠出の交渉で数か月が消えます。一方、機能として定義すれば、既存の営業企画や経営企画の担当者が兼務で始められます。重要なのは箱ではなく、「収益プロセス全体の指標に責任を持つ人が存在するか」という一点です。
RevOpsの不在が最も可視化されるのが、AI投資の成果です。IPAが2026年7月16日に公表した国内企業のDX・AI活用動向のポイント（国内1,799社を対象、調査期間2026年4月17日〜6月12日）は、示唆的な傾向を報告しています。
AI導入は大企業を中心に広がり、多くの企業で効果が実感されている一方で、「期待どおり以上の効果」を得ている企業は限定的であり、AIの利用用途は業務効率化・迅速化が中心である、という内容です。詳細な数値はDX動向2026の報告書本体に掲載されています。
この傾向は、RevOpsの観点から読むと理由が説明できます。業務効率化は部門内で完結するため、部門の権限だけで実行できます。ところが収益への貢献は、部門をまたいだプロセスの改善を必要とします。マーケティングが生成AIでコンテンツ制作を効率化しても、そのリードを営業がどう扱うかが変わらなければ、収益は動きません。部門横断の設計主体がいないまま各部門にAIを配ると、必然的に効率化止まりになります。
概念としてのRevOpsに反対する人はほとんどいません。それでも定着しないのは、3つの構造的な障害があるためです。順に見ていきます。
最大の障害はこれです。RevOpsを掲げても、各部門の評価指標が従来のままであれば、行動は変わりません。
典型例が、マーケティング部門のリード獲得件数です。この指標が評価に紐づいている限り、質より件数が優先されます。営業から「使えないリードばかり」という声が上がっても、指標を達成している部門に改善の動機はありません。逆に質を優先させれば件数が落ち、評価が下がります。担当者の意識の問題ではなく、制度の問題です。
したがってRevOpsの導入は、指標の再設計から始めざるを得ません。ツール導入から始めると、この本質的な変更が後回しになります。
第二の障害はデータの帰属です。営業部門はExcelの案件管理表を、マーケティング部門はMAツールの配信リストを、カスタマーサポートは問い合わせ管理システムを、それぞれ「自分たちのデータ」として持っています。
この状態で統合を提案すると、抵抗が生じます。抵抗の理由は多くの場合、データの精度に対する不安です。「うちの数字が他部門に見られると、実態と違う解釈をされる」という懸念は正当です。統合前に定義の統一が必要なのは、この懸念に応えるためです。
単一の情報源（SSOT）という概念が重要になるのはここです。誰がどのデータの正を持つかを決めない限り、システム統合は「どちらの数字が正しいか」という不毛な議論を招きます。
第三の障害は権限です。RevOpsの推進を任された担当者が、他部門の業務プロセスや指標を変更する権限を持っていないケースが大半です。
結果として、推進者は「お願いする人」になります。各部門に協力を依頼し、断られ、経営層にエスカレーションし、経営層は「よく話し合って」と返す。この往復で半年が消えます。RevOpsを立ち上げる際に必要なのは組織図上の役職ではなく、「指標の定義を変える権限をどこに置くか」という明示的な決定です。
権限の議論を進めるには、責任範囲を具体化する必要があります。「収益全体を見る」という表現では、誰も動けません。分解して定義します。
| 領域 | 具体的な責任 | 成果物 |
|---|---|---|
| 定義の統一 | リード・商談・受注・更新の各段階の定義と移行条件を決める | ライフサイクル定義書、移行基準 |
| データ基盤 | どのシステムがどのデータの正を持つかを決め、統合する | データマップ、統合設計、品質ルール |
| プロセス設計 | 部門間の引き継ぎ手順・SLAを決める | ハンドオフ定義、SLA、エスカレーション手順 |
| 計測と改善 | 収益プロセス全体の指標を定義し、定例で改善を回す | 共通ダッシュボード、月次の改善サイクル |
この4領域のうち、最初に着手すべきは1行目です。定義が揃っていないデータを統合しても、出てくる数字は誰も信じません。逆に定義が揃えば、統合前でも部門間の会話が成立し始めます。
置き場所には3つの選択肢があり、それぞれ効きどころが違います。決め手は「どの障害が自社で最も重いか」です。
| 置き場所 | 強み | 弱み | 向いている状況 |
|---|---|---|---|
| 経営企画 | 指標と評価制度に手を入れられる | 現場の業務実態から遠い | 部門最適の指標が最大の障害である場合 |
| 営業企画 | 現場の実務を理解している | マーケ・CSへの影響力が弱い | 営業プロセスの改善が先行課題である場合 |
| 情報システム | データ統合を実行できる | 業務プロセスの決定権がない | システムが乱立し統合が急務である場合 |
実務上もっとも多い失敗は、情報システム部門に置いてツール統合だけを進めるパターンです。データは繋がりますが、指標が変わらないため行動が変わらず、「システムは入ったが何も変わらない」という評価に至ります。逆に経営企画に置くと、現場の実務を知らないまま指標を設計してしまい、運用不能な定義ができます。
推奨は、経営企画に主管を置き、営業企画と情報システムから実務担当者を出す混成チームです。株式会社100がCRMの全社導入を支援する際も、この3者が同席する場を作ることを最初の作業としています。同席しないまま進めた設計は、ほぼ確実に手戻りします。
ここからが実装です。順序を間違えると、正しい設計でも失敗します。以下は4段階に分けた進め方で、各段階の完了条件を明示しています。
最初に、顧客がどの状態を経て収益に至るのかを一本の線で定義します。リード、MQL、SQL、商談、受注、更新——名称は自社の慣行に合わせて構いませんが、各段階の移行条件を文章で書き切ることが要件です。
完了条件は、営業とマーケティングの担当者が同じ案件を見て、同じ段階を答えられることです。この状態に至らないまま次に進むと、以降のすべての数字が信用されません。
次に、定義した各段階のデータをCRMに集約します。ここで決めるのは「どのシステムを正とするか」です。すべてをCRMに移す必要はありません。基幹システムに残すデータもあります。重要なのは、項目ごとに正が一つに決まっていることです。
外部システムのデータを参照する必要がある場合、HubSpot Data Hubのデータ同期や、Data Studioによる外部ソースの統合が使えます。Snowflakeなどのデータウェアハウスを既に運用している企業では、CRMへ全面移行するのではなく、必要な項目だけを参照する構成が現実的です。
完了条件は、月次で報告される主要な数字が、すべて同じ画面から出てくることです。部門ごとに別のExcelで集計している状態が残っていれば、Step 2は未完です。
定義とデータが揃うと、初めて「どこで漏れているか」が測れます。ここで見るべきは各部門の成果ではなく、部門の境界です。
マーケティングが渡したリードのうち、営業が何日以内に着手したか。着手されずに滞留した件数はいくつか。営業が受注した案件のうち、カスタマーサクセスへの引き継ぎが完了したのは何%か。こうした境界の指標をパイプラインとワークフローで可視化します。
完了条件は、境界での滞留がダッシュボードで即座に見えることです。この段階に到達すると、部門間の議論が「意識の問題」から「数字の問題」に変わります。これがRevOpsの実質的な成果です。
最後の段階で自動化とAIを導入します。2026年7月に公開されたAgent HubのようなAIエージェントの基盤は、収益プロセスの一部を自律的に処理できます。
ただし順序は絶対です。Step 3までが終わっていない状態でエージェントを入れても、参照するデータが分断されているため、意味のある判断はできません。AIの精度はモデルではなくデータの整備状況で決まります。エージェントに与える前提情報はAIコンテキストとして設計する必要があり、ここでも定義の統一が前提になります。
完了条件は、エージェントの出力を人が検証せずに業務に流せる範囲が特定できていることです。全面的に任せるのではなく、任せる範囲を決めることが設計です。
指標設計はRevOpsの中核です。部門ごとの指標を並べ替えるだけでは意味がありません。境界と速度に着目した指標を追加する必要があります。
| 指標 | 何を測るか | 従来の指標との違い |
|---|---|---|
| リード滞留日数 | 渡されたリードが着手されるまでの日数 | 件数ではなく処理速度を見る |
| 段階別の移行率 | 各ライフサイクル段階の通過率 | 最終成果ではなく途中の漏れを見る |
| 受注後の引き継ぎ完了率 | CSへのハンドオフが完了した割合 | 受注をゴールにしない |
| 純収益維持率（NRR） | 既存顧客からの収益の増減 | 新規獲得と既存維持を同じ土俵で見る |
| 収益プロセスのサイクルタイム | 初回接点から入金までの日数 | 部門別のリードタイムを通算する |
5行目のサイクルタイムは、見積から入金までを含めて測ると効果が大きくなります。受注後の請求・入金が遅れている企業では、営業プロセスの改善よりこちらの短縮のほうが即効性があります。見積から入金までをCRM上で扱う構成についてはHubSpot Revenue Hubとは？旧Commerce Hubとの違いと料金で解説しています。
失敗のパターンは限られています。3つに集約できます。
第一に、ツール導入から始めるパターン。CRMを刷新すれば統合されると考え、定義と指標を後回しにします。結果として、統合されたデータの上で部門ごとに別の解釈が続きます。
第二に、全社一斉に始めるパターン。関係部門をすべて集めた大規模プロジェクトを立ち上げ、合意形成に時間を費やします。1年後に何も動いていない状態は、この型で起きます。
第三に、指標を追加するだけのパターン。既存の部門指標を残したまま、新しい共通指標を上に載せます。現場は評価に紐づく従来の指標を優先するため、共通指標は報告用の数字になります。
裏返せば、成功の条件は「定義から始める」「一つの事業部で実証する」「古い指標を降ろす」の3点です。とくに3点目は経営の意思決定が必要で、担当者レベルでは実行できません。RevOpsの立ち上げに経営のスポンサーシップが不可欠だと言われるのは、この理由によります。
公正に比較します。どちらにも成立条件があり、組織の状況によって答えは変わります。
| 観点 | 単一事業部での実証 | 全社一斉 |
|---|---|---|
| 立ち上げ速度 | 数か月で最初の数字が出る | 合意形成に半年以上 |
| 説得材料 | 自社の実績で他部門を説得できる | 他社事例に依存する |
| 投資額 | 小さく始められる | 初年度から大きい |
| 全社標準化 | 後から統合する手戻りが発生する | 最初から統一できる |
| 成立条件 | 実証する事業部の責任者が協力的であること | 経営層が指標の変更を決断していること |
最終行が判断基準です。経営層が「部門指標を降ろす」という決断を既にしているなら、全社一斉のほうが手戻りは少なくなります。その決断が未了であれば、実証で材料を作るしかありません。多くの企業は後者です。
立ち上げ期は兼務1名でも始められます。ただし定義の統一とデータ設計を同時に進める段階では、業務側とシステム側の2名体制が現実的です。人数より、指標の定義を変更する権限が付与されているかが重要です。
できます。単一ベンダーに統合することは条件ではありません。必要なのは、項目ごとに正となるシステムが一つに決まっていることと、共通のダッシュボードで数字が見られることです。ただしツールが分かれているほど、定義の統一と同期設計の負荷は上がります。
ライフサイクル段階の定義と移行条件の文書化です。ツールの選定より前に着手できますし、費用も発生しません。営業とマーケティングの担当者が同じ案件を見て同じ段階を答えられるかを、着手前に一度テストしてみてください。多くの組織で答えが割れます。
反発の理由を「隠したいことがある」と解釈しないでください。多くの場合、実態と異なる解釈をされることへの懸念です。定義の統一を先に行い、どの数字がどう解釈されるかを合意してから可視化すると、反発は大きく減ります。順序の問題です。
部門別の成果報告ではなく、境界での滞留を示してください。「マーケティングが渡したリードのうち、30日以内に着手されたのは何%か」という一つの数字は、部門別の達成率より説得力があります。これは実証段階でも計測できます。
検証目的であれば問題ありません。避けるべきは、データ基盤の整備をせずに本番の業務プロセスに組み込むことです。エージェントは参照できるデータ以上のことはできないため、分断されたデータの上では期待した判断が得られません。
削減を目的にすると失敗します。RevOpsの効果は、同じ人員で扱える収益プロセスの量と精度を上げることに現れます。削減目的で始めると、現場は情報提供に非協力的になり、データの品質が落ちます。
境界の指標が見え始めるまでが最初の節目です。定義の統一とデータ集約を並行して進めれば、単一事業部での実証であれば数か月の範囲で最初の数字が出ます。ただし指標の変更が組織の行動を変えるまでには、評価サイクルを一周する必要があります。
本記事はIPAおよび経済産業省の公表資料、HubSpot公式サイト・公式ナレッジベースの公開情報（2026年9月1日取得時点）に基づいて作成しています。IPAの調査結果はプレスリリースに記載された定性的な傾向を引用しており、詳細な数値は報告書本体をご確認ください。製品仕様・料金は変更される可能性があります。