はじめに
こんにちは。リンクアンドモチベーションの間嶋です。
元々アプリエンジニアとしてリンクアンドモチベーションに中途入社をして複数プロダクトの開発を経験した後、今は社内CRMの利活用促進を担当しています。
「RevOpsって結局何なの？」
これは私が長年感じていた疑問です。RevOps（Revenue Operations）とは、マーケティング・営業・カスタマーサクセスを横断して売上に関わる業務全体を最適化する考え方のことですが、その境界線が曖昧になり、データドリブンな営業組織の必要性が叫ばれる中で急速に注目を集めています。しかし、その実態は組織によってバラバラで、「RevOpsチーム作ったけど、結局何をやってるの？」という声も少なくありません。
一方で、私自身がエンジニア出身ということもあり、RevOpsの課題を見ていると「これってDevOpsで解決してきた問題と本質的に同じではないか？」と感じるところがありました。
なぜDevOpsに注目したのか
きっかけは、自社でRevOpsの仕組み作りに取り組んでいた時のことです。月次の振り返り会議で、マーケティング、インサイドセールス、フィールドセールスの各チームが同じ指標について議論していたのですが、話が全くかみ合いませんでした。
同じ言葉を使っているのに、各チームで定義も計測方法も全く違う。当然ながら数字も結論もバラバラで、「どの施策が効いているのか分からないし、改善の方向性も決められない」という状況がしばらく続いていました。
各部門が独自の定義と測定方法で動いているため、全体最適どころか、部分最適すらできていない状態。データはあるのに、部門を横断した意思決定ができない状態でした。
（これって開発組織では起こりにくい問題だな...と思いました）
DevOpsの世界では、Four Keysなど開発生産性を計るメトリクスの定義は統一され、計測は自動化され、全てのチームが同じダッシュボードを見て意思決定をします。なぜRevOpsの世界には、このような考え方が浸透していないのでしょうか？
DevOpsが解決しようとしている根本的な課題は、RevOpsが取り組んでいる課題と似ています。守備範囲は違えど、両者とも「価値が顧客に届くまでのリードタイムを短縮し、品質を向上させる」ことを目指しているのです。
そこで今回は、RevOpsの本質的な概念を改めて整理し直した上で、DevOpsの原理原則をRevOpsに応用することで、RevOpsの取り組みをより良いものにできないか考察してみたいと思います。
RevOpsとはなにか
改めて整理すると、RevOpsは「マーケティング・営業・カスタマーサクセスが共通の目標と指標を持ちながら、売上に関わる業務全体を効率化する考え方」です。
要するに、各部門がそれぞれ違う目標を追うのではなく、売上や顧客満足度といった「会社全体の重要指標」を皆で共有しながら、お客様により早く良いサービスを提供していこうという考え方です。
RevOpsが解決しようとしている課題は、まさに冒頭で触れた問題そのものです。
- 基準の違い: 同じ数字でも部署によって測り方が全然違う
- 情報がバラバラ: 各部署が別々の資料や画面を使って作業している
- 引き継ぎの問題: 部署をまたぐ時に情報が抜けたり遅れが生じる
- 個別最適の罠: 各部署は頑張っているけど、会社全体で見ると効率が悪い
RevOpsの要は以下の4つです。
- プロセスの策定と運用: 目標設計、プロセス設計、ビジネスアーキ、標準化
- データマネジメントと分析: データ統合・可視化、仮説検証と意思決定支援
- RevTechマネジメント: MA/CRM/CS/データ基盤の選定〜運用、連携と自動化
- イネーブルメント・文化醸成: ナレッジ・マニュアル整備、現場への教育/定着化
これらを通じて、RevOpsは「お客様に良いサービスをより早く届ける」ことを目指しています。
DevOpsのおさらい
では、RevOpsが抱える課題を解決するヒントとして、DevOpsがどのような問題をどう解決したのかを振り返ってみましょう。
DevOpsが生まれる前、システム開発チームと運用チームの間には大きな溝がありました。開発は「新しい機能を早く世に出したい」、運用は「システムを安定させたい」と、それぞれ違う目標を持ち、違う基準で評価されていました。その結果、新機能のリリースは遅れ、システム障害は頻発し、お互いに責任をなすりつけ合うことが当たり前でした。
DevOpsはこの問題を以下のやり方で解決しました。
- 共通の目標設定: リリース回数、リリース失敗率などの共通した開発生産性指標
- 小さく始めて改善: 全体を一度に変えず、小さな改善を積み重ねて全体を最適化
- 作業の自動化: テストやリリース作業を自動化し、継続的な改善を実現
- 状況の見える化: 共通ダッシュボードで皆がリアルタイムに状況を把握
- 文化づくり: 失敗を責めない文化作り、学習する組織
つまり、DevOpsは「部門同士で共通の言葉と測定方法を作ることで、サービス提供の流れを良くした」のです。これは、まさにRevOpsが目指すべき方向性と同じではないでしょうか。
RevOpsにDevOpsの原理を適用する
ここまで見てきたように、RevOpsとDevOpsは本質的に同じ課題に取り組んでいます。では具体的に、DevOpsの原理をRevOpsにどう適用すればよいのでしょうか。
1. 皆で同じ言葉を使うようにする
DevOpsのアプローチ:
- リリース回数、リリース失敗率などの共通の基準で開発と運用を評価
RevOpsへの適用:
- 全部署で共通の基準を作る（例：MQL、アポ獲得数など）
- 測り方を統一して、データの出どころも揃える
- 定期的に基準を見直して、認識のズレが起きないようにする
2. 皆で同じ画面を見るようにする
DevOpsのアプローチ:
- ダッシュボードを統一し、全チームが同じデータを見る
RevOpsへの適用:
3. 小さく始めて継続的に改善する
DevOpsのアプローチ:
- 一気に全部を変えるのではなく、小さな改善を重ね、フィードバックを基に継続的に改善する
RevOpsへの適用:
- まずは一つのプロセスや部門から改善を開始し、効果を素早く測定
- 成功事例を他部門に横展開して、全体の流れを段階的に良くする
- 定期的な振り返りで学んだことを組織の資産にし、失敗を学習機会として活用する
さいごに
DevOpsがシステム開発と運用の間に作った共通の言葉と測定方法を、RevOpsでもマーケティング・営業・カスタマーサクセスの間に作ることで、本当に価値のあるRevOpsを実現できるのではないでしょうか。
大切なのは、完璧を目指すのではなく、小さく始めて継続的に改善していくこと。DevOpsが時間をかけて文化として根付いたように、RevOpsも地道な積み重ねが強いチームを育てるのです。
