RevOpsを組織のどこに置くべきか

RevOpsを営業配下に置くべきか、CEO直轄に置くべきか。この問いに単一の正解はありません。大切なのは、いま自社で RevOps に何を担わせたいのかです。組織図だけ先に決めても、役割が曖昧なら機能しません。

前提としてのRevOps

RevOps は、営業・マーケ・CS にまたがる売上プロセスを、KPI・データ・運用でつなぐ機能です。だから置き場所を考えるときも、「誰が管理しやすいか」より「どこなら部門横断の論点を動かせるか」を見る必要があります。役割の輪郭は RevOpsとはが土台です。

フェーズごとに答えは変わる

立ち上げ期は、営業配下や営業企画の延長で始めるのが現実的なことがあります。現場の入力品質や商談管理を整えるほうが先だからです。一方、部門が分かれ始めた拡大期では、MQL 定義、引き継ぎ、受注後の接続など、営業だけでは決めにくい論点が増えます。この段階では CEO や COO に近い横断機能のほうが強いことが多いです。

失敗しやすい配置

CEO直轄なのに現場に入れず、会議資料部署になる。営業配下で、他部門から営業都合の部署だと見られる。名前だけ RevOps で、実態は便利屋になる。よくある失敗はこの三つです。だから置き場所と同時に、責任範囲と権限を決める必要があります。

評価指標は何を見るか

見るべきは活動量ではなく接続改善です。営業受け入れ率、商談化までの流れ、引き継ぎ漏れ、定義の再現性、オンボーディング開始の手戻り減少。こうした「売上の流れが滑らかになったか」を見るほうが、RevOpsの評価としては自然です。

社内異動か採用か

初期段階では、自社の流れを知っている人を社内異動で育てるほうが成功しやすいことがあります。マーケからの移動ならマーケターからRevOpsへ移るにはが近いルートです。実装まで強く求めるなら、別途 GTM Engineer のような人材が必要になることもあります。

30日・90日の動き方

30日では、RevOps に何を担わせたいかを書き出し、今もっとも摩擦が大きい接続点を一つ選びます。90日では、その論点をどの配置なら最も動かせるかを仮置きし、小さく運用を始める。完璧な正解より、「どこなら今の問題を動かせるか」で決めたほうが実務的です。

まとめ

RevOpsの置き場所に一つの正解はありません。立ち上げ期は営業管轄、拡大期は横断機能、成熟期は設計と実装を分ける、といった形で変わりえます。重要なのは、どこに置くかではなく、その位置で部門横断の責任を本当に持てるかです。

個人にとって何が見えるようになるか

RevOpsを組織のどこに置くべきかは組織向けのテーマに見えますが、個人のキャリアにも直結します。組織のどこに責任が置かれるかを読むと、自分が次にどの経験を積むべきか、どの会社でその役割が伸びやすいかが見えます。

RevOpsに関わる組織設計では、肩書きよりも責任の置き方が重要です。誰がプロセスを設計し、誰がデータを管理し、誰がAIや自動化のリスクを見て、誰が現場運用を直すのか。この線引きが曖昧な会社では、新しい役割が必要になりやすい一方で、入社後の期待値もぶれやすくなります。

個人としては、組織図そのものより「自分が入ったら何を任されるのか」を見る必要があります。採用票、面接、社内異動、上司との会話で、責任範囲を具体的に確認できるとミスマッチを減らせます。

面接や社内提案で見るべき論点

面接で確認したいのは、役割名ではなく意思決定の場所です。RevOpsに近い仕事を任されるとして、誰が優先順位を決めるのか。営業、マーケ、CS、PM、情シス、経営のどこにレポートするのか。どの部門と合意しないと進まないのか。ここを聞くと、実際の仕事の難しさが見えます。

次に、成果物を確認します。求められているのが資料作成なのか、CRMやワークフローの実装なのか、KPI設計なのか、AI運用ルールなのかで必要なスキルは変わります。成果物が曖昧なまま入ると、何でも屋になりやすいです。

社内提案では、組織論を大きく語るより、小さな摩擦から入る方が通りやすいです。受注後の引き継ぎ、権限管理、営業とマーケの定義ズレ、AI出力の確認ルールなど、具体的な詰まりを一つ選び、誰が責任を持つべきかを提案します。

失敗しやすいパターン

よくある失敗は、役割を置いたのに権限がないことです。改善責任はあるが、CRM項目を変えられない。AI運用を見ると言いながら、ログや権限に触れられない。部門横断を期待されるが、各部門の優先順位に介入できない。これでは成果が出にくくなります。

もう一つの失敗は、専門職を採用すれば自然に解決すると考えることです。RevOpsに近い役割は、個人の能力だけでなく、組織の受け皿に左右されます。誰が意思決定し、どの会議で扱い、どの指標で見るのかが決まっていないと、改善は続きません。

個人としては、この失敗パターンを知っておくと、転職や異動で見るべき会社を判断しやすくなります。責任範囲、権限、成果物、関係部門を確認するだけで、かなりのミスマッチを避けられます。

30日・90日の進め方

30日では、自分の組織で曖昧になっている責任を一つ見つけます。営業とマーケの引き継ぎ、AIエージェントの権限、RevOpsの配置、GTM Engineerの採用要件など、テーマは狭くて構いません。

90日では、その曖昧さに対して小さな運用案を作ります。誰が判断し、誰が実装し、誰がレビューし、どの指標を見るのかを一枚にまとめます。組織設計は大きな話に見えますが、最初の一歩は責任境界を明文化することです。

RevOpsを組織のどこに置くべきかを読むことで、組織側の論点だけでなく、自分がどの環境で力を出しやすいかも見えてきます。