RevOps憲章とは：マンデート、スコープ、意思決定権限の定義方法

RevOps憲章とは、Revenue Operationsがあらゆることに責任を負わされながら、何一つ変更する権限を持たないという事態を防ぐための文書です。

憲章がなければ、RevOpsはその週に最も声の大きいステークホルダーが必要とするものに姿を変えてしまいます。ダッシュボードチームになったり、CRM管理の窓口になったり、フォーキャスト整理係になったり、部門間の不満を吸収するエスカレーション先になったりします。

憲章は、この機能にマンデートを与えるものです。

Forrester社によるRevOpsオペレーティングモデルの調査は、核心となる課題を明確に示しています。RevOpsの成功は、チーム名ではなくオペレーティング設計次第だということです。Gartner社によるレベニューイネーブルメントの複雑性削減に関するガイダンスも、セールス側から見た同じ問題を指摘しています。誰かが共有モデルを管理しない限り、バラバラな施策はノイズを生むだけだということです。

憲章は、そのモデルを平易な言葉に落とし込みます。RevOpsが何を所有し、何に影響を与え、何を所有しないのか、そして意思決定がどう行われるのかをリーダーに示します。

運用における重要事実

• RevOps憲章は、マンデート、スコープ、意思決定権限、ガバナンスの運用リズム、システム権限、指標、エスカレーションパスを定義します。
• 憲章は、RevOpsがあらゆることに責任を負わされながら、何一つ変更する権限を持たないという事態から守るためのものです。
• 強力な憲章は、機能ごとのパフォーマンスオーナーシップと、共有オペレーティングシステムのオーナーシップを明確に切り分けます。
• 憲章は、会社のGTMモーション、システム、リーダーシップ、レポーティングニーズ、RevOps体制が変化した際に見直すべきです。

RevOps憲章に含めるべき内容

憲章は、リーダーが読める程度に短く、かつ議論に決着をつけられる程度に具体的である必要があります。

RevOpsに憲章が必要な理由

RevOpsは多くの場合、混乱したシステムの中に秩序を見出すのが得意な一人の人材から始まります。レポートを整理し、フィールドを修正し、マーケティングとセールスの間を通訳し、ファネルで何が起きているかを財務部門が理解できるよう手助けします。

その有用性が需要を生みます。やがて、あらゆる部署がRevOpsに何かを求めるようになります。

マーケティングはアトリビューションの整理を求め、セールスはテリトリー変更を求め、CSはより良い引き継ぎフィールドを求め、財務はフォーキャストの信頼性を求め、リーダーシップはダッシュボードを求め、システム部門は急な依頼の削減を求めます。それぞれの要求は理にかなっているかもしれませんが、これらが積み重なるとRevOpsは単なる依頼待ちの窓口になってしまいます。

憲章はこの漂流を防ぎます。

憲章は次の5つの実践的な問いに答えます。

• RevOpsはここで何を改善するために存在するのか
• 収益システムのどの部分を所有するのか
• どの意思決定を行えるのか
• どの意思決定に経営陣の承認が必要か
• RevOpsが機能しているかどうかをリーダーはどう把握するのか

これらの答えがなければ、RevOpsは権限のない責任だけを負うことになります。これが、優秀なチームであってもこの機能が失敗する一因です。

憲章の意思決定テーブル

憲章は、よくある意思決定を容易にするものであるべきです。

ここが憲章の実践的な部分です。RevOpsを大まかな言葉で説明するだけでは不十分です。普段から摩擦を生みがちな意思決定を、リーダーが解決できるよう手助けするものである必要があります。

ミッションステートメント

有用なRevOpsのミッションステートメントは、次のような文言になります。

RevOpsは、マーケティング、セールス、カスタマーサクセス、財務、データ、システムをまたいで収益を予測可能にするオペレーティングシステムを所有する。

このミッションは、Revenue Operationsとは何かと直接つながっています。RevOpsをタスクの窓口ではなく、システムオーナーとして位置づけるものです。

スコープ

RevOpsが所有すべきもの:

• 収益ライフサイクルの定義
• 部門横断的な引き継ぎ
• 共有の収益ダッシュボード
• CRMおよび収益データのガバナンス
• フォーキャストプロセスのガバナンス
• 収益運用リズム
• 収益ワークフローに関するシステム変更管理

RevOpsが所有すべきでないもの:

• マーケティング戦略
• セールスコーチングと商談の実行
• カスタマーサクセスの関係構築
• 財務計画のオーナーシップ
• プロダクトロードマップの意思決定

憲章はこれを明示すべきです。RevOpsは戦略を運用に落とし込む役割であり、機能別のリーダーシップに取って代わるものではありません。

スコープの境界線

憲章を書く上で最も難しいのは、RevOpsが「やらないこと」を決めることです。

RevOpsが「収益成長」を所有すると書かれた憲章は範囲が広すぎます。収益成長は、戦略、市場需要、プロダクト、価格設定、セールス実行、カスタマーサクセス、財務計画が生み出す結果です。RevOpsはその結果を支えるシステムを改善できますが、あらゆる商業的成果に対して説明責任を負うべきではありません。

より明確な境界線は次のようになります。

この境界線は両側を守ります。機能別リーダーはパフォーマンスのオーナーシップを保持し、RevOpsは共有オペレーティング層に対する権限を得ます。

意思決定権限

意思決定権限は、憲章の中で最も重要な部分です。

誰が何を承認できるかを定義します。

• 新しいライフサイクルステージ
• CRMフィールドの変更
• ダッシュボード指標の定義
• ルーティングルールの変更
• フォーキャストカテゴリールール
• 引き継ぎ要件
• 新しい収益系ツールや連携

詳細なオーナーシップ設計については、RevOps RACIを参照してください。

意思決定権限テンプレート

意思決定権限は、段落の中に埋もれさせるのではなく、表として明記すべきです。

具体的な名称は変わっても構いませんが、原則は変わりません。RevOpsは、システム品質に影響する変更に対する承認権限を持って初めて、システム品質を所有できるのです。

運用リズム

憲章は、RevOpsが主導または支援する会議も定義すべきです。

一般的な運用リズムには次のようなものがあります。

• 週次パイプライン点検
• 週次または隔週のフォーキャストレビュー
• 月次ファネルレビュー
• 月次データ品質レビュー
• 月次システム変更レビュー
• 四半期ごとのライフサイクル・ダッシュボード定義レビュー
• 四半期ごとのRevOpsロードマップレビュー

目的は会議を増やすことではありません。目的は、その場しのぎのエスカレーションを減らすことです。

運用リズムがなければ、あらゆる意見の相違が特別な会議になってしまいます。運用リズムがあれば、リーダーはどこに問題を持ち込むべきか、どのように意思決定が行われるか、いつ変更がレビューされるかを把握できます。

より広い運用リズムについては、Revenue Cadenceを参照してください。

システムガバナンス

多くのRevOps憲章が失敗するのは、システムガバナンスの規定が不十分だからです。

CRMが運用の中核であるなら、フィールドの変更、ワークフロー、連携、必須データ、リードルーティング、ステージルール、ダッシュボード定義は安易に変更できません。小さな変更が下流に影響を及ぼすことがあります。

憲章は次を定義すべきです。

• 誰が変更をリクエストできるか
• リクエストに含めるべき情報は何か
• RevOpsがどのように影響を評価するか
• 誰がリスクの高い変更を承認するか
• 変更をどう記録するか
• ユーザーにどう通知するか
• リリース後にアダプションをどう確認するか

これは、複数のチームが同じオブジェクトを共有している場合に特に重要です。マーケティングのセグメンテーションに役立つフィールドが、セールスの入力を遅らせるかもしれません。セールスのルーティングに役立つワークフローが、CSの引き継ぎに影響するかもしれません。CROに役立つダッシュボード定義が、財務のレポーティングと衝突するかもしれません。

RevOpsは変更を止める必要はありません。ただ、何かを壊す前に変更を可視化する必要があるのです。

憲章のロールアウト

憲章を完成した文書として公開し、それだけで浸透を期待してはいけません。

ロールアウトはリーダーシップの合意形成プロセスであるべきです。

1. RevOpsが現在の課題を基に憲章の草案を作成する
2. 機能別リーダーがスコープと意思決定権限をレビューする
3. 財務が指標定義と計画上の接点をレビューする
4. システムまたはITがプラットフォームガバナンスをレビューする
5. エグゼクティブスポンサーが対立を解決する
6. 最終版の憲章を収益系マネージャーに共有する
7. RevOpsが受付、優先順位付け、ロードマップレビューで憲章を活用する

憲章は、実際の意思決定で使える程度に短くあるべきです。公開後に誰も開かないようなら、それは理論的すぎるということです。

憲章の文言例

シンプルな言葉を使いましょう。

RevOpsは、マーケティング、セールス、カスタマーサクセス、財務、システムをまたぐ共有の収益オペレーティングシステムを所有する。RevOpsは、ライフサイクル定義、引き継ぎ、CRMデータ品質、正データソースのレポーティング、フォーキャストプロセス、収益運用リズム、システム変更の影響を統治する。機能別リーダーは、チームのパフォーマンス、戦略、コーチング、顧客対応を所有する。RevOpsは、共有の収益データ、ワークフロー、ダッシュボード、引き継ぎに影響する変更を承認または却下する権限を持ち、トレードオフが全社的な優先順位に影響する場合は経営陣にエスカレーションする。

この一節がすべての対立を解決するわけではありませんが、会社にとっての出発点にはなります。また、この機能を具体的なものにします。RevOpsは「アライメント」という抽象概念ではなく、定義されたオペレーティング層のオーナーなのです。

指標

RevOpsは、チケット件数ではなくシステムの健全性で測定されるべきです。

良い指標には次のようなものがあります。

• 予測精度
• SLA遵守率
• 引き継ぎの完全性
• 必須フィールドの入力完全性
• ソースから収益までの可視性
• ダッシュボードへの信頼度
• 手作業レポーティングの削減
• ステージ滞留の削減

指標のベースにはRevOps Metricsを活用してください。

憲章承認ワークフロー

RevOps憲章は、これから統治する対象と同じ部門横断的な視点で承認されるべきです。

この承認プロセスが重要なのは、憲章が権限を伴う文書だからです。共有の収益上の真実に影響する変更を誰が承認または却下できるかを定義します。RevOpsだけがこれを承認した場合、他のチームは会社の運用方針ではなく単なる内部的な好みとして扱ってしまうかもしれません。

実際のリクエストで憲章をどう使うか

憲章は、日々の行動を変えるものであるべきです。

憲章がこうした一般的なリクエストに答えられないなら、それは曖昧すぎます。プロセスを増やす前に、意思決定権限を引き締めましょう。

憲章を最新に保つ方法

RevOps憲章は、会社が変化するときに変わるべきです。

次のタイミングで見直してください。

• 会社が新しいGTMモーションを追加したとき
• マーケティング、セールス、CSが組織再編したとき
• RevOpsのレポーティングラインが変わったとき
• 新しいCRMや主要な収益系システムが導入されたとき
• 財務が計画モデルを変更したとき
• 会社が新規獲得重視から更新・拡大重視へと軸足を移したとき
• リーダーシップが同じオーナーシップの対立を繰り返しエスカレーションし始めたとき

憲章を毎月書き直す必要はありません。しかし、古い運用モデルの遺物にしてしまってもいけません。古びた憲章は、憲章がない状態より悪い結果を招きます。人々に誤った明確さを与えてしまうからです。

優れた憲章は、ロードマップレビュー、システムガバナンス、受付の意思決定、部門横断的な対立の場面で参照され続ける、生きたツールです。

受付ルール

憲章は、RevOpsが業務をどう受け取るかを変えるべきです。

受付ルールがなければ、あらゆるリクエストが同じくらい緊急に見えてしまいます。

• 「このフィールドを追加してもらえますか」
• 「このダッシュボードを作ってもらえますか」
• 「ルーティングを直してもらえますか」
• 「取締役会向けにこのレポートを抽出してもらえますか」
• 「このフォローアップを自動化してもらえますか」

RevOpsには、サポート業務と運用上の意思決定を切り分ける仕組みが必要です。

シンプルな受付フォームでは次を尋ねるべきです。

憲章は、明確なオーナー、意思決定、アダプションの道筋がないリクエストについて、RevOpsが却下または保留できるようにすべきです。これはRevOpsが非協力的になるという意味ではありません。この機能が低品質な変更からシステムを守るという意味です。

アンチパターン

次のような憲章の失敗パターンに注意してください。

憲章がミッションステートメントに過ぎない。 ミッションステートメントは有用ですが、権限を定義するものではありません。憲章には、スコープ、意思決定、指標、エスカレーションが必要です。

RevOpsがあらゆる収益上の問題を所有する。 これは反感と失敗を生みます。機能別リーダーは依然として戦略と実行を所有します。

意思決定権限が曖昧である。 憲章に「あらゆることに関してRevOpsが協働する」と書かれていると、いつRevOpsがノーと言えるのか誰にもわかりません。

システムガバナンスが抜け落ちている。 フィールド、ワークフロー、ダッシュボードの変更こそ、運用品質が壊れやすい場所です。

憲章がRevOpsだけによって承認されている。 憲章には経営陣の後ろ盾が必要です。そうでなければ単なる願望リストです。

ロードマップのトレードオフで憲章が一度も使われない。 リーダーが憲章を承認しても、その周辺のあらゆるリクエストを依然としてエスカレーションし続けるなら、憲章には何の力もありません。

実践的な最初の憲章

最初のRevOps憲章は、あらゆるエッジケースを網羅する必要はありません。

グロースステージの企業であれば、最初のバージョンは2ページの運用合意書で十分です。

• ミッション
• 所有するシステムとプロセス
• 所有しない責任範囲
• 意思決定権限テーブル
• 受付ルール
• エスカレーションパス
• トップ5のヘルス指標
• 四半期レビューの日程

これで始めるには十分です。RevOpsが実際の対立の所在を学ぶにつれて、文書は改善していくべきです。

重要なのは初日から完璧なガバナンスを実現することではありません。部門横断的な収益業務を、いつまでも非公式な善意だけで回せると装うのをやめることが重要なのです。

憲章の準備状況チェックリスト

憲章を完成とみなす前に、実際の運用上の対立に答えられるかを確認してください。

• データ品質を損なうフィールド要求に対して、RevOpsはノーと言えるか
• どのダッシュボードが正データソースなのか、リーダーは判別できるか
• 計画指標がどこから来ているのか、財務は把握できるか
• セールスとマーケティングは、特別なエスカレーションなしにライフサイクル定義の対立を解決できるか
• CSは商談ごとに交渉することなく引き継ぎデータを要求できるか
• システムチームは、どの収益ワークフローの変更にレビューが必要かを把握できるか

答えがノーであれば、憲章はまだ甘すぎる可能性が高いです。ロールアウト前に意思決定権限テーブルを引き締めましょう。

よくある質問

RevOps憲章は誰が書くのですか。

RevOpsが草案を作成すべきですが、CRO、CEO、財務、マーケティング、セールス、CSのリーダーがレビューし承認すべきです。

RevOps憲章はどのくらいの長さにすべきですか。

通常は2〜4ページです。法律文書のようにではなく、具体的であるべきです。

どのくらいの頻度で更新すべきですか。

四半期ごと、または会社がGTMモーション、レポーティングライン、システム、主要な収益プロセスを変更するたびにレビューしてください。

関連記事

• RevOps Team Structure
• Why RevOps Fails
• Revenue Cadence
• CRM Change Management