RevOps RACI: Revenue Operationsのオーナーシップマトリクス

著者: Tara Minh · 更新日: 2026年6月9日

RevOpsは、その仕事が重要だと全員が同意していても、誰がその意思決定を所有するかで誰も合意していないときに破綻します。

新しいライフサイクルステージは誰が承認するのか。ソースフィールドは誰が所有するのか。リードルーティングルールを変更するかどうかは誰が決めるのか。マーケティングのアトリビューションと財務のレポーティングの対立は誰が解決するのか。

RevOps RACIは、これらの問いが政治的になる前に答えを出します。

基本モデルが必要な場合は、RACIマトリクスとRACI対RASCI対DACIをご覧ください。

PMIはRACIについて、責任と説明責任を明確にし、仕事がチーム間でこぼれ落ちないようにする方法だと説明しています。RevOpsでは、仕事がマーケティング、営業、カスタマーサクセス、財務、データ、システムを横断するため、この明確さが重要になります。

ForresterのRevOps責任モデルは、RevOpsが本質的に幅広いものであることを思い出させてくれる有用なものです。RACIはその幅広さが曖昧さになるのを防ぎます。

運用上の重要事実

• RevOps RACIは、プロジェクトタスクだけでなく繰り返し発生する意思決定をマッピングすべきです。難しい問いは通常、定義、データのオーナーシップ、システムの変更、forecastルール、引き継ぎ、エグゼクティブレポーティングに関するものです。
• 各意思決定には1人の説明責任者が必要です。共有のインプットは健全です。共有の説明責任はしばしば遅延と政治的なエスカレーションを生みます。
• RevOpsは権限なしに成果の説明責任を負わされるべきではありません。RevOpsがデータ品質を所有しているなら、フィールドやワークフローの変更を承認、却下、エスカレーションできなければなりません。
• RACIは採用のミッションと組み合わされたときに最もうまく機能します。最初のRevOps採用には、オーナーシップマトリクスに合致した意思決定権が必要です。

RevOpsにおけるRACIの意味

RevOpsは、別のチームがローカルな実行に責任を負っている場合でも、システムに対して説明責任を負わなければならないことがよくあります。

この区別は重要です。営業マネージャーは、担当者に次のステップを入力するようコーチングする責任を負っているかもしれません。RevOpsは、それらの次のステップを有用なものにするステージ定義、必須フィールド、ダッシュボードルール、点検の頻度に対して説明責任を負っているかもしれません。財務は、同じオポチュニティデータがプランニングに使われるため相談対象になるかもしれません。

だからこそ、RevOps RACIの設計には通常のプロジェクトRACIよりも多くの注意が必要です。成果物は1つのプロジェクトの納品だけではありません。恒常的なオペレーティングモデルです。意思決定権がどこに落ち着くかは、中央集権型対組み込み型RevOpsのどちらを運用するかにも依存します。

コアとなるRevOps RACI

この表は出発点です。自社の組織構造に合わせて調整してください。

RevOps RACIの構築方法

部門ではなく意思決定から始めてください。

弱いRACIはチームのリストから始まり、「各チームは何を所有しているか」を問います。それは通常、既存の政治力学をそのまま反映してしまいます。より強いRACIは、摩擦を生む繰り返し発生する意思決定から始まります。

• 何が資格あるリードとみなされるか
• ディールはいつステージ3に入れるか
• 誰が新しい必須フィールドを作成できるか
• どのレポートがパイプラインの正データなのか
• 誰がルーティングの変更を承認するか
• 誰がforecastカテゴリーを決めるか
• どのデータが営業からCSに渡らなければならないか
• 誰がchurn理由の分類法を所有するか

意思決定をリストアップした後、役割を割り当ててください。

各意思決定について、1人の説明責任者を選んでください。次に、誰が作業を行い、誰がインプットを提供しなければならず、誰が情報共有を必要とするかを特定してください。説明責任者が2人いる場合は、そこで止まって解決してください。共有のインプットは問題ありません。共有の説明責任は通常、誰も最終判断を下せないことを意味します。

まず意思決定インベントリを構築する

最も有用なRevOps RACIは、意思決定インベントリから始まります。

混乱を生む繰り返し発生する意思決定をリストアップしてください。

このインベントリは理論的な網羅性ではなく、実際の摩擦に基づくべきです。前四半期の例、つまり争いになったレポート、失敗した引き継ぎ、乱雑なフィールドリクエスト、forecastの意見の相違、ルーティングの例外、ダッシュボードの再構築を取り上げてください。それらが、RACIが最初に明確にすべき意思決定です。

インベントリができたら、意思決定をリスクごとにグループ化してください。低リスクの意思決定は、RevOpsとシステムオーナーで迅速に進められます。高リスクの意思決定には財務、機能別リーダーシップ、またはエグゼクティブの承認が必要です。

このリスクの視点は、あらゆる小さな変更でRACIが動きを遅くするのを防ぎます。また、影響の大きい変更が何気ないリクエストを通じて起きるのも防ぎます。

収益ライフサイクル別のRACI

有用なRevOps RACIは、ライフサイクル全体にわたるオーナーシップをマッピングします。

このビューは、リーダーがなぜRevOpsを単なる営業支援機能にできないかを理解するのに役立ちます。同じオペレーティングシステムがジャーニー全体に及ぶのです。

CRMとレポーティング変更のRACI

CRMの変更は、曖昧なオーナーシップが高くつく領域です。

システム変更には別のRACIを使ってください。

これにより、最も一般的な間違い、つまりどの機能でもローカルなニーズのために共有データ構造を変更させてしまうことを防げます。

対立解決のルール

優れたRACIであっても、すべての対立を取り除くことはできません。

エスカレーションルールを追加してください。

• 対立が1つの機能にのみ影響する場合、機能別リーダーが決定する。
• 対立が共有データに影響する場合、RevOpsが決定するか推奨する。
• 対立がforecast、プランニング、取締役会向けレポーティングに影響する場合、RevOpsと財務は展開前に整合しなければならない。
• 対立がチームを横断する顧客体験に影響する場合、CROまたはCOOが決定する。
• 対立が企業レベルのトレードオフに影響する場合、エグゼクティブスポンサーが決定する。

エスカレーションルールが重要なのは、RevOpsがしばしば正当なニーズを持つ強力なリーダーの間に立たされるためです。RACIは、対立が個人的なものになる前に意思決定経路を可視化すべきです。

RACIを使うためのルール

説明責任者は1人。 複数の相談対象者は問題ありません。複数の説明責任者はデッドロックを生みます。

機能別リーダーは依然としてパフォーマンスを所有する。 RevOpsはシステムを所有できますが、営業リーダーは依然として営業パフォーマンスを所有し、CSリーダーは依然としてリテンション実行を所有します。

意思決定権は責任と一致しなければならない。 フィールドガバナンスを強制できないなら、RevOpsをデータ品質の説明責任者にしないでください。

組織変更後にレビューする。 チーム、システム、GTMモーションが変わると、RACIは古くなります。

よくあるRACIの間違い

説明責任者が多すぎる。 これは最も一般的な失敗です。2人のリーダーが説明責任を負っている場合、どちらもクリーンなミッションを持てません。

RevOpsが実行責任は負うが権限がない。 フィールドの却下、ステージ基準の変更、引き継ぎルールの強制ができないなら、RevOpsをデータ品質の説明責任者にしないでください。

財務への情報共有が遅すぎる。 ある指標が取締役会向けレポーティングに登場するなら、定義が変わる前に通常は財務に相談すべきです。

埋め込み型オペレーションチームが異なるルールに従っている。 Marketing Ops、Sales Ops、CS Opsはそれぞれの機能の近くに留まって構いませんが、共有の定義には1つのガバナンスモデルが必要です。

RACIが受付に使われていない。 リクエストが依然として「これを作ってもらえますか?」という形で届くなら、RevOpsはチケットキューになってしまいます。受付では、そのリクエストがどの意思決定に影響し、誰が説明責任を負うのかを問うべきです。

レビューの頻度

RevOps RACIは四半期ごとに、また大きな変更の後にはより早くレビューしてください。

トリガーには次が含まれます。

• 新しいCRO、CMO、CSリーダー、CFO、COO
• 新しいGTMモーション
• 新しいCRMまたは大きなシステム変更
• 買収または事業ユニットの分割
• 新規ビジネス重視から拡張重視への移行
• 同じオーナーシップ領域についての対立の繰り返し

RACIは静的な文書ではありません。作業上の合意です。リーダーがそれを使わなくなれば、オーナーシップは非公式な力関係と繰り返される議論に戻っていきます。

ミーティングモデル

RACIは、フォルダに保管されるのではなく、繰り返し行われる運用ミーティングで使われるべきです。

次で使ってください。

• RevOpsロードマップレビュー
• システム変更レビュー
• forecastガバナンスレビュー
• ファネル定義レビュー
• リード品質レビュー
• 受注後の引き継ぎレビュー
• ダッシュボード定義レビュー

各ミーティングは、同じオーナーシップに関する問いに答えるべきです。

• どの意思決定を行っているのか
• 誰が説明責任を負うのか
• 意思決定の前に誰に相談すべきか
• 意思決定の後に誰に情報共有すべきか
• どのデータや証拠が必要か
• 意思決定の後、システムの何が変わるのか

これによりRACIは実践的なものになります。リーダーは文書を暗記する必要はありません。収益システムが変化するときにオーナーシップの言葉を使う習慣が必要なのです。

例：リードルーティングの変更

営業がエンタープライズリードをシニアAEに直接ルーティングしたいと考える一方、マーケティングは資格判定のためにまずSDRにルーティングしたいと考えているとします。

RACIがなければ、これは好みをめぐる議論になってしまいます。

RACIがあれば:

• RevOpsはルーティングロジックとSLAへの影響のマッピングに実行責任を持ちます。
• CROは収益ワークフローの意思決定に説明責任を持ちます。
• マーケティング、SDRリーダーシップ、営業マネージャー、財務が相談を受けます。
• SDR、AE、マーケティングキャンペーンオーナーは変更後に情報共有されます。

RevOpsはその後、対応時間、受け入れ率、コンバージョン率、オーナーのキャパシティ、レポーティングの変化といった運用上の影響をテストできます。RACIは戦略を決めませんが、意思決定の経路をクリーンにします。

例：新しい必須フィールド

必須フィールドは、摩擦のよくある原因です。

営業はフィールドが担当者のワークフローを遅くするという理由で抵抗するかもしれません。マーケティングはより多くのセグメンテーションデータを望むかもしれません。CSは引き継ぎの文脈を必要とするかもしれません。財務はよりクリーンなレポーティングを必要とするかもしれません。

RACIは、フィールドの価値とフィールドのオーナーシップを切り分けるのに役立ちます。

• リクエストしたチームは、そのフィールドが支える意思決定を説明する実行責任を負います。
• RevOpsはフィールドガバナンスの説明責任を負います。
• システムは設定の実行責任を負います。
• 関連マネージャーは相談を受けます。
• ユーザーは明確な展開ノートとともに情報共有されます。

RevOpsは、そのフィールドが実際の意思決定またはワークフローを支える場合にのみ承認すべきです。単なる時折の好奇心を支えるだけなら、オプションのままにするか、別の取得ポイントに移すべきです。

権限は説明責任と一致しなければならない

RACIは紙の上ではきれいに見えても、権限が欠けていると失敗することがあります。

よくある不一致:

マトリクスを公開する前に、権限のギャップを修正してください。RevOpsがガバナンスの説明責任を負うなら、リーダーはRevOpsが価値の低いリクエストを一時停止し、定義を要求し、対立をエスカレーションできることを受け入れる必要があります。機能別リーダーが行動を所有するなら、自分たちのチームでそれを点検しなければなりません。財務がプランニング指標について相談を受けるなら、指標が公開される前に発言権を持つ必要があります。公開された後ではありません。

RACIは、説明責任者が決定しない場合に何が起こるかも明記すべきです。例えば、ライフサイクルの対立がレポーティングを2週間以上ブロックしている場合、CROまたはCOOが最終判断を下す必要があるかもしれません。エスカレーションがなければ、RACIはオーナーシップを名指しするだけで停滞した意思決定を解決しません。

RACIが憲章とどうつながるか

RevOps憲章はミッションを定義します。RACIはそのミッションの中で誰が行動するかを定義します。

憲章を使って「これはRevOpsの範囲か?」に答えてください。

RACIを使って「誰が決め、誰が作業を行い、誰がインプットを提供し、誰が通知を受けるのか」に答えてください。

両者を組み合わせることで、運用上の規律が生まれます。別々では弱くなります。RACIのない憲章は広すぎます。憲章のないRACIはタスクを明確にできても、機能の目的を見失うかもしれません。

小規模チーム向けの軽量版

小規模な企業は巨大なオーナーシップマトリクスを必要としません。

5つの意思決定から始めてください。

• ライフサイクル定義
• リードルーティング
• オポチュニティステージルール
• forecastカテゴリー
• 受注後の引き継ぎ要件

それぞれについて、1人の説明責任者と1つのRevOpsの役割を指定してください。これで、企業のスピードを落とすことなく混乱を減らすには十分です。

企業がセグメント、モーション、システム、オペレーションスペシャリストを追加するにつれ、RACIを拡張してください。モデルは複雑さとともに成長すべきです。

RACI準備状況チェックリスト

マトリクスを公開する前に、最近の対立に照らしてテストしてください。

前四半期から3つの実例を選んでください。

• 争いになったリードの定義
• forecastルールの変更
• ダッシュボード指標の意見の相違
• 必須フィールドのリクエスト
• 受注後の引き継ぎの失敗
• ルーティングのエスカレーション

各例について、RACIが意思決定の経路を明確にしているかどうかを問うてください。リーダーが依然として誰が説明責任を負うのか分からないなら、そのマトリクスはまだ準備できていません。

説明責任者に行動する権限があるかどうかもテストしてください。権限を伴わない説明責任を割り当てるRACIは不満を生みます。RevOpsがフィールドガバナンスの説明責任を負うなら、フィールドの変更を承認、却下、エスカレーションできなければなりません。営業がステージの正確性の説明責任を負うなら、マネージャーには点検の頻度と乏しい衛生管理への結果が必要です。

最後のテストは使いやすさです。RACIは数ページに収まり、簡単に一覧できるべきです。マトリクスが詳細すぎて誰も使わないなら、より小さく始めて最も収益上の摩擦を生む意思決定にフォーカスしてください。

マトリクスが稼働したら、あらゆる重要なシステムまたはプロセスの変更でそれを参照してください。その繰り返しの使用こそが、オーナーシップを文書から運用上の行動へと変え、繰り返される議論を減らすものです。

RACIを軽量に保つ方法

RACIは、対立を解決できるほど詳細でありながら、誰もそれを開かなくなるほど詳細すぎてはいけません。

3つのレベルを使ってください。

この階層モデルは、小規模な企業が過剰なプロセスを避けつつ、大規模なチームに十分なコントロールを与えるのに役立ちます。軽微なレポートのクリーンアップに運営委員会は必要ないはずです。forecastカテゴリー定義の変更がチケット内で起きるべきではありません。

RACIが機能している最良のサインは、人々がそれを常に引用することではありません。全員がすでに経路を知っているため、より少ない意思決定が停滞することです。

RACI受付の質問

リクエストがRevOpsに入ってきた瞬間にRACIを使ってください。

「何を作ってほしいのか」だけを問うのではなく、受付では次を問うべきです。

• このリクエストはどのビジネス上の意思決定に影響するか
• どのフィールド、ワークフロー、ダッシュボード、または引き継ぎが変わるのか
• ビジネス上の成果に誰が説明責任を負うのか
• 実装の前に誰に相談すべきか
• 展開後にどのチームに情報共有が必要か
• 財務がこの定義をレビューする必要があるか
• この変更はエグゼクティブレポーティングやforecastに影響するか
• リクエストが却下または遅延した場合、何が起こるか

これらの質問は、弱いリクエストがシステム作業になる前に減速させます。新しいダッシュボードを求めるチームには指標の定義がないかもしれません。必須フィールドを求めるリーダーは誰がその値を所有するか知らないかもしれません。ルーティングの例外を求めるマネージャーは、キャパシティやレポーティングへの影響を考慮していないかもしれません。

受付プロセスは重くあるべきではありません。RevOpsバックログの中の簡単なフォームやチェックリストで構いません。重要なのは、意味のあるすべてのリクエストが説明責任者と意思決定経路に結びついていることです。

これはRevOpsのキャパシティも保護します。受付の規律がなければ、チームは共有の複雑さを生むローカルな修正の構築に時間を費やします。RACIに基づく受付があれば、RevOpsはなぜ一部のリクエストが迅速に動き、一部が相談を必要とし、一部が構築されるべきでないのかを説明できます。

RACIが機能しているサイン

行動の変化を探してください。

• フィールドリクエストがオーナー、定義、ビジネス上の理由とともに届く。
• ダッシュボードの対立が合意された正データルールを通じて解決される。
• forecastルールの変更が展開前に営業、財務、RevOpsを含むようになる。
• 引き継ぎの失敗が単なる注意喚起ではなくオーナーシップの変更につながる。
• チームがミーティングの前に誰が決めるかを知っている。
• RevOpsが繰り返される議論の仲介に費やす時間が減る。

RACIは、意思決定がより速く明確になったときに成功しています。ミーティング時間を減らし、手戻りを減らし、エスカレーションをより個人的でないものにすべきです。

RACI意思決定パケット

オーナーシップが争われているときは、意思決定パケットを使ってください。

これにより、RACIが静的な文書になるのを防げます。リーダーがそれを使って実際のオペレーション上の意思決定を解決するようになったとき、それは有用なものになります。

関連記事

• RevOps憲章
• RevOpsと財務
• Forecastガバナンス
• マーケティング・セールスアライメント用語集