RevOpsAF 2026 参加レポート：リクエストを捌く役割から設計図を書く役割へ

6月10〜11日、ロンドンで開催されたRevOpsAF Europeに参加してきました。RevOps Co-opコミュニティが運営する、現場のオペレーター同士のカンファレンスで複数トラックがありましたが、,共通してRevOpsは誰かの決定の尻拭いをする仕事ではなく、意思決定の場に入る仕事になったと言う点が繰り返し強調されていました。興味深かったセッションをご紹介します。
‍

課金モデルが変わるたびに後始末をしてきたのはRevOpsだった

オープニングキーノートの登壇者は、Salesforce Billingの元責任者で、自身が創業し買収を経てSalesforce CPQ/Billingを率いたManoj Ganapathyしでした。「CPQやNetSuiteの突合作業に苦しんだことがある方は？」という問いかけには、ほぼ全員が手を挙げており、「今日は私の謝罪行脚です」という切り出しで会場を沸かせていました。Ganapathy氏はこれまでのプライシング時代を以下のように分類しました。

• 買い切りライセンスの時代：
  価格表も値引きも契約管理も、すべてが巨大なExcelの上で回っていた時代。そしてそのExcelの仕組みを理解しているのは多くの場合社内にひとりだけで、その人が退職した瞬間に見積も請求も止まる。会社の収益業務が、特定の個人のスプレッドシートに依存していた時代です。
• シート課金SaaSの時代：
  ユーザー数に応じて料金を払うモデルになった結果、「誰が本当に使っているのか」を把握する仕事が生まれた時代。たとえば2年前に退職した社員のアカウントを解約したいのに、その人の名義で何個ものダッシュボードが動いているせいで消すに消せず、ライセンス費用だけ払い続ける。誰がどのアカウントを何に使っているのかを突き止める棚卸し作業は、もはや調査の域でした。
• CPQ/Billing専用ツールの時代：
  Excel脱却のために見積・請求の専用ツールを導入したものの、「この商品はいくらで売るべきか」という素朴な問いに答えるために、今度は何百個ものカスタムフィールドと複雑に絡み合った入力規則をメンテナンスし続けることになった時代。道具は変わっても、複雑さは消えませんでした。
• 従量課金の時代：
  APIコール数やデータ量など「使った分だけ」課金するモデルに移った結果、請求書が400行に膨らみ、顧客から「先月と金額が違うのはなぜですか」と聞かれても即答できる人が社内にいなくなった時代。シート数の数え方に悩んでいた問題が、利用量の数え方に悩む問題に置き換わっただけでした。

そして、どの時代にも共通することがひとつあります。価格やビジネスモデルはいつも経営層と財務だけで決められていて、RevOpsは蚊帳の外だったということです。決まったものが降りてきて、現場でなんとか運用に落とし込むのがRevOpsの役割。この構図が30年続いてきました。

エージェントの時代は、この構図が通用しなくなる転換点です。これからは、社員6〜7人の会社が数千のAIエージェントを走らせて事業を回す、ということが普通に起こる。人間の数で課金するシート課金のままでは、実際の利用の大半を占めるエージェント分が無料になってしまい、ほとんどタダで製品を配っているのと変わりません。かといってトークン消費量での従量課金にすると、出来の悪いエージェントほど無駄にトークンを消費して、ベンダーの売上が伸びるという本末転倒な構造になってしまう。そのため行き着く先はアウトカム課金、つまり使った量ではなく「解決したチケット数」や「設定された商談数」といった、顧客が本当にお金を払いたい成果の単位で課金するモデルだ、という整理でした。実際、Claude、Lovable、Clayなどの急成長企業はこの方向に動きつつあります。

では、その「成果」を何にするかは誰が決めるのか。
顧客が何に価値を感じていて、自社のプロダクトが現場でどう使われているのかを一番よく知っているのはRevOpsであり、だからこそ価格設計に最も貢献できるのもRevOpsのはずだ、とGanapathy氏は主張します。「これまで課金モデルは、いつもRevOpsのいないところで発明されてきた。今回は、作る側に回ろう」。そのための宿題として挙げられたのは3つでした。

• 自社のレベニュープロセスのどこにAIやエージェントが入り込んでいるかを棚卸しすること
• 顧客がお金を払いたくなる成果は何かを言語化すること
• 価格を決める会議に呼ばれていないなら、呼ばれるように動くこと。

プライシング戦略にもRevOpsが積極的に入っていく必要性が強調されたセッションでした。

‍

リクエストは営業がリードを見極めるように見極めろ

こちらはRevOpsのコンサルティング会社、RevOps AutomatedのCEO、Natalie Furness氏のセッションで、彼女は「RevOpsはつい、飛んでくるリクエストを次々と捌くことに追われてしまう。けれども、リクエストの文面どおりに対応することと、問題を解決することは別物だ」と語ります。

例えば「CRMデータが汚いから、なんとかしてほしい」という依頼でした。文面どおりに受け取れば、打ち手はデータクレンジング、フィールドの追加、入力規則の強化、といったあたりに落ち着きます。でも、そもそもなぜこの依頼が来たのかを掘っていくと、景色が変わってくる。CROは「フォーキャストが信用できない」と感じていて、CEOは「成長と市場シェアの数字に確信が持てない」、営業マネージャーは「誰が売れていて誰が売れていないのか分からない」と困っている。「データが汚い」という依頼は、こうした経営上の不安が形を変えて表に出てきたものにすぎず、本当に解くべき問題は「経営が信頼できる数字を持てていない」ことのほうにあるわけです。データをいくら綺麗にしても、入力のばらつきという原因や、その先にある経営の不安に手を打たなければ、同じ依頼がまたやってきます。

そこで提案されていたのが、依頼をロードマップに載せる前に、6つの観点で吟味するROQUOVというフレームワークです。

• Reality：実際に何が起きているのか（依頼の文面ではなく現実）
• Outcome：どんな成果が必要なのか
• Quantify：その問題は金額にしていくらの話か
• Urgency：なぜ今なのか。放置すると何が起きるか
• Ownership：そのプロセスのオーナーは誰か。誰が反対しうるか
• Validation：どの指標が動けば成功と言えるのか

彼女は ”Qualify tickets like salespeople qualify leads. The request is merely the work — it's only clues" （営業がリードを見極めるように、依頼を見極めろ。依頼の文面は単なる作業指示であって、本当の問題への手がかりにすぎない）と語ります。営業は、入ってきたリードを片っ端から商談化したりしません。同じようにRevOpsも、入ってきたリクエストに片っ端から取り掛かるのではなく、深堀りをして優先順位を立てた上で戦略的なロードマップを描くことの必要性を強調していました。
‍

AIは戦力になったのか、混乱の元になったのか

ドイツのHRテック企業Personio（従業員1,300人、RevOps組織30人超）のセッションは、AIファースト企業の生々しい失敗談でした。

まず失敗談から。Personioでは、社員が誰でも自分用のAIアシスタント（特定の業務を手伝わせるチャットボットのようなもの）を作れる環境にしていました。あるときAIツールを別のプラットフォームに切り替えることになり、「社内のアシスタントは多くて50〜100個くらいだろう」と見積もって移行計画を立てたところ、蓋を開けると450個以上見つかったそうです。誰が何のために作ったのか分からないものが大量にあり、管理もガバナンスも追いついていなかった。

この「野良AI」の問題は、会議の風景も変えていました。15年前は、会議になると各自が自分で集計したスプレッドシートを持ち寄り、数字が合わないという光景がどの会社にもありました。それが今は各自が「AIに分析させたらこう出ました」という結果を持ち寄る。しかも、その中にはAIがもっともらしく作り上げただけの誤った数字も混ざっている。

一方で、成功事例も具体的でした。Personioでは新規顧客を営業から導入支援チームへ引き継ぐ際、営業が引き継ぎシートを書く運用になっていたものの、実際に記入されているのは40%だけでインプリチームは情報がないまま顧客対応を始めることになっていました。そこで、営業に書かせることを諦め、商談の録画・文字起こしツールであるGongに溜まったデータから、引き継ぎ用のサマリーをAIで自動生成する仕組みに変えた。結果、引き継ぎ情報が揃っている割合は75%まで改善したそうです。

この18ヶ月の学びとして挙げられていたのは3つです。
1つ目は、ツールから入らず問題から入ること。「この製品、こんな機能があるらしい」から検討を始めると、導入してみたら思っていたものと違った、ということを繰り返すことになる。
2つ目は、人の仕事のやり方を変えるときの段取りを甘く見ないこと。先ほどの引き継ぎ自動化も、リリースしたのがQ4のクロージング直前で、営業の邪魔をしたくないからと、Slackで「裏側で自動で動く仕組みを入れました。皆さんの作業は変わりません」と一度告知しただけで済ませた結果、活用が思ったほど進まなかったそうです。
3つ目は、ルールや判断基準が曖昧な業務をそのまま自動化しないこと。曖昧なプロセスや汚いデータの上にAIを載せても、間違った答えが高速に、しかも大量に出てくるだけだからです。

組織としてのAIの広げ方も参考になりました。原則は「アイデアは現場から、標準化は中央から」。
現場での草の根の実験は自由にやらせつつ、複数チームに広がりそうなものはGTMエンジニアリングの専門チームが引き取って、誰でも使える形に磨き込む。検証を通ったワークフローには、SNSの公式アカウントのような認証マークを付けて社内のAIハブで公開し、会社のお墨付きがあるものと個人の実験段階のものが一目で区別できるようにしているそうです。

‍

まとめ

AIとエージェントの波は、RevOpsから定型業務を奪うと同時に、価格設計・GTM設計・ガバナンスという上流の椅子を初めて空けました。その椅子に座りに行くのか、それともこれからも依頼を捌き続けるのか。日本のRevOps界隈にも、そのまま当てはまる点だと思います。

むしろ日本では、RevOpsという役割自体がまだ立ち上がり期だからこそ、この椅子は欧米以上に空いているはずです。「捌く人」としてのRevOpsが定着してしまう前に、価格やGTMの設計に関わる役割として根づかせられるかどうか。学びの多い数日となりました。