部門横断的な仲介：Opsが組織の結合組織になるとき

木曜の午後4時47分。VP of SalesからSlackのDMが届きます。「ちょっと電話に出られる？SalesとCSがまたアップグレードのクォータ・クレジットでもめてるんだ」

あなたはSalesチームの一員ではありません。CSチームの一員でもありません。報酬プランを所管しているわけでも、更新の動きを所管しているわけでもありません。それでもあなたはその通話に90分付き合うことになり、87分目に誰かがこう言うのです。「よし、Opsが解決策をまとめて回してくれる？」

誰もあなたを雇った覚えのない仕事へようこそ。

Operations Managerの職務記述書には、プロセス設計、ベンダー管理、KPI、ダッシュボードのことが書かれています。そこに書かれていないものの、リーダーシップチームの全員がひそかに期待しているのは、あなたが、直接は口をきかないあらゆる部門のあいだの結合組織だということです。SalesとCS。FinanceとSales。ITとMarketing。ProductとCS。あなたは、明確な担当者のいないあらゆる部門間の争いに引っ張り込まれ、あなたの人事評価には「会社はこれらの傷からの出血を止められたか」がひそかに含まれます。

このプレイブックは、その役割を、他人の所有者なき仕事の常設の便利屋にならずにこなす方法についてです。

仲介者のマインドセット

私が実際に腹落ちさせるのに3年かかった発想の転換はこれです。あなたは決定者ではありません。あなたは翻訳者です。

Salesはパイプライン・カバレッジとクォータ達成の言葉で話します。CSはNRR、GRR、リスクのあるアカウントの言葉で話します。FinanceはGAAP、繰延収益、監査証跡の言葉で話します。ITはチケット、変更ウィンドウ、そして「これステージング環境で誰かテストした？」の言葉で話します。Productはロードマップの重みとエンジニアリングのキャパシティの言葉で話します。

5つの部族、5つの語彙、5つの動機づけのセット。ほとんどの部門横断的な争いは、実は事実についての意見の相違ではありません。それは、誰もある方言を別の方言に変換していないために、2つの部門がすれ違って話しているのです。

その変換があなたの仕事です。そして、あなたがどちらかの側につく瞬間、あなたはその仕事を失います。

クォータ・クレジットの争いでSales側につけば、CSはあなたのワーキンググループを信頼しなくなります。収益認識の問題でFinance側につけば、Salesはあなたを迂回するようになります。仲介者の主導権は中立性から生まれます。あなたは、たとえ内心ではどちらかがばかげていると思っていても、各部門の立場を他の部門に公平に代弁すると信頼される人物でなければなりません。

これには戦術的なバージョンがあります。プロセスは引き受けるが、決定は決して引き受けない。あなたは会議を運営します。ドキュメントを作ります。議事録を書きます。しかし結果は所有しません。結果は、実際にP&Lを背負っている2人のVPのものです。あなたの仕事は、彼らが決定を避けられないほどクリーンな道筋を確保することです。

「これは誰が所有しているのか？」のマッピング

何かを仲介する前に、あなたは1つの問いに対する徹底的に具体的な答えを必要とします。チームの境界をまたぐ各定常ワークフローを、誰が所有しているのか？

ワークフローごとにRACIを作りましょう。1ページ。5列。曖昧さはなし。もし2つのチームがどちらも同じワークフローのAccountable（説明責任者）だと思っているなら、あなたは今まさに本当の問題を見つけたのです。しかも、次の午後4時47分のSlack DMより前に見つけたのです。

リード・トゥ・オポ（lead-to-opp）の引き継ぎの実例を挙げます。

1行につきAccountableは1人。常に。Accountableの列に名前が2つあるなら、争いが起きるのを待っている状態です。火事になる前に表に出しましょう。火事の最中ではなく。

定常的な部門横断ワークフローのそれぞれについて、これを1つずつ作ります。

• リードの引き継ぎ（Marketing → SDR → AE）
• 更新の予測（CS → Finance → Sales）
• チャーン防止（CS → Sales → Product）
• 請求に関する係争（Finance → CS → Sales）
• システム変更依頼（IT → 影響を受ける各部門）
• 新入社員のオンボーディング（HR → IT → マネージャー → Ops）
• 顧客オンボーディングの引き継ぎ（Sales → CS。下記参照。これが典型例）

中規模企業には通常、こうしたものが8〜12個あります。これを自分のサイドプロジェクトにすれば、四半期でセット全体を片づけられます。他の誰もやりません。そして12個すべてをマッピングし終えた日が、あなたの仕事が変わる日です。

部門横断ワーキンググループの運営

部門をまたぐ何かが現に壊れているとき、あなたは会議に引っ張り込まれます。その会議は、デフォルトではこうなります。

• 60分、毎週の定例
• 8〜12人、うち4人は会ったこともない人
• 各部門からのステータス報告
• 決定なし
• 来週木曜にフォローアップ会議を設定

これは、何も解決しないことを保証するフォーマットです。これを拒否しましょう。

実際に機能するフォーマットはこれです。

最大60分。 適切な人を部屋にそろえて60分で決定に至れないなら、それはワーキンググループではなくステータス会議です。ステータスはカレンダーではなく非同期のドキュメントに属します。

最大3人。 影響を受ける部門ごとに1人。Consultedが必要な人には事前にドキュメントを、事後に議事録を渡します。Informedが必要な人には議事録を渡します。会議には呼びません。

「決定するか中止か」ルール。 55分目までに決定に至らなければ、会議は中止し、問題はVPにエスカレーションします。「また集まりましょう」ではありません。「チームに確認させてください」でもありません。中止。エスカレーション。エスカレーションという脅しこそが、決定を迫るものです。

決定が下されるまで定例枠は設けない。 ワーキンググループは特定の問題を解決するために存在し、その後は解散します。毎週カレンダーに載った瞬間、それはステータス報告の劇場になります。

付箋1枚に収まるワーキンググループのアジェンダ。

ワーキンググループ：サイクル途中アップグレードのクォータ・クレジット
日付：2026-05-02
出席者：VP Sales、VP CS、RevOps（仲介者）

1. （10分）問題を1文で述べる。合意できているか確認する。
2. （15分）各部門が立場を述べる。各5分。割り込みなし。
3. （20分）テーブルに3つの選択肢。長所、短所、誰が何を負担するか。
4. （10分）1つ選ぶ。あるいはエスカレーションする。
5. （5分）議事録、担当者、期限。完了。

「決定するか中止か」ルールを適用。55分目に結論を出すか、明日CROとCCOに上げるか。

このフォーマットは、デフォルトと比べて部門横断的な課題1件あたり約4時間の会議時間を節約します。1年で、こうした課題が8〜12件あるとして、リーダーシップチームの会議を32〜48時間削減でき、決定のサイクルタイムを3週間からおよそ4日に短縮できます。

エスカレーションの優先度の振り分け

すべての火事があなたの火事ではありません。この仕事を失う最速の方法は、DMに飛び込んでくる部門間のあらゆる失敗を引き受けることです。2番目に速い方法は、すべてを押し返して「手伝ってくれないOpsの人」として知られるようになることです。

優先度の振り分けのルールはこれです。プロセスは引き受けるが、決定は決して引き受けない。

Slack DMが届いたら、自分に2つの問いを立てます。

1. この決定について、明確にAccountableな部門が1つあるか？
2. 彼らはそれを下すのに必要な情報を持っているか？

両方ともイエスなら、押し返しましょう。丁重に、具体的な理由とともに、そして前に進む道筋を添えて。

「これは報酬プランに関するSalesとCSの決定です。私はクォータ方針を所管していません。あなたとMike（VP CS）で明日15分取れますか？3つのシナリオをまとめたドキュメントをお送りするので、決められる準備を整えて臨めますよ。」

あなたは手伝うことを拒否しているのではありません。決定を所有することを拒否しているのです。あなたは準備作業をやると申し出ています。それこそが仲介者の本当の付加価値です。

問い1がノーなら（本当に所有者がいない、あるいは2つの部門がどちらも所有権を主張している場合）、そのときこそ引き受けます。ただしプロセスだけを引き受けます。

「わかりました、ワーキンググループは私が回します。木曜の午後2時、60分、あなたとSarahで、決定するか中止か。火曜に準備ドキュメントを送ります。決定はお二人のものです。私はアジェンダを進めるだけです。」

このパターンは、彼らが決定しやすいようにする、というものです。彼らに代わって決定はしません。VPに代わって決定し始めた日が、あなたがあらゆる悪い部門間の結果にとって都合のよいスケープゴートになる日です。

「顧客オンボーディングの引き継ぎを誰も所有していない」典型例

これは、私がこれまで見てきたなかで最もよくある部門横断的なブラックホールで、今あなたの会社で壊れているほうに100ドル賭けてもいいくらいです。

問題のかたちはこうです。

• AEが金曜の午後5時30分に契約をクローズ。ハイタッチ。
• 顧客は「来週」キックオフ通話があると期待している。
• CSがアカウントを引き継ぐのは、正確には、いつ？AEがCRMのステージを更新したとき？Financeが最初の請求書を発行したとき？顧客がサポートに「キックオフはいつ？」とメールしてきたとき？
• 「契約クローズ」から「CSMが所有」までの72時間は、誰のものでもありません。

その72時間のあいだに、顧客の熱意はピークを打ち、減衰し始めます。彼らは金曜の午後5時30分には興奮していました。水曜になると、もう他の優先事項に移っています。キックオフ通話は、本来そうあるべきだったよりも冷えた部屋に着地します。

この引き継ぎを修正した企業は、90日リテンションが8〜15%向上し、初回価値到達までの時間が測定可能なほど改善します。これは、私が宙から取り出したマーケティングの数字ではありません。このワークフローをマッピングし、単一窓口の所有権を割り当てた4社の中規模SaaS企業で、私自身が目にした範囲です。

修正の仕方はこうです。

ステップ1：引き継ぎを90分刻みでマッピングする。 0時間目（契約締結）から168時間目（クローズ1週間後）まで。各ウィンドウについて、誰がAccountableか？どんな成果物が存在しなければならないか？顧客はどんな体験をするか？多くの企業は、12時間目から60時間目が完全に所有者不在だと気づきます。

ステップ2：単一窓口の所有権を割り当てる。 名前は1つ。たいていは、いるならCustomer Onboarding Manager、いなければ指名されたCSMです。彼らは、AEが商談をClosed-Wonにした瞬間から、キックオフ通話が行われるまでAccountableです。

ステップ3：SLAを計測可能にする。 キックオフ通話はクローズから48時間以内に設定。最初の顧客向けメールは4時間以内。CRMとオンボーディングツールの同期は1時間以内。ダッシュボードを作る。SalesとCSのリーダーシップと毎週レビューする。SLAを本物にするのは会議ではなくダッシュボードです。

ステップ4：設計を確定するためにワーキンググループを開く。 60分、3人（VP Sales、VP CS、あなた）、決定するか中止か。マップと3つの所有権オプションを持って臨む。1つを持って出る。

これは、ほとんどのB2B SaaS企業において最もレバレッジの高い部門横断的な修正です。このプレイブックから他に何もしないとしても、これだけはやりましょう。

ポストモーテムのプレイブック

部門間の失敗は必ず起きます。しくじった製品ローンチ。誰かが見ているはずだと全員が思い込んでいた、見逃された更新。リードルーティングを6日間壊したSalesforceの更新。問題は、それらが起きるかどうかではありません。そこから何かを学ぶかどうかです。

非難なしのポストモーテムを5営業日以内に実施しましょう。30日ではありません。「来四半期」でもありません。5営業日、記憶が新鮮で、関係者がまだ気にかけているうちに。

3つの問いを、この順番で。

1. 決定の経路はどうだったか？ 誰が、いつ、どんな情報に基づいて何を決めたか？タイムラインを再構成する。具体的に。
2. どこで壊れたか？ それは決定の欠落だったか、誤った決定だったか、それとも正しい決定が拙く実行されたものだったか？壊れ方が違えば、必要な修正も違います。
3. 誰が修正を所有するか？ 名前1つ、期限1つ、具体的な成果物1つ（更新されたRACI、新しいSLA、システム変更、トレーニング）。

骨子のテンプレート。

ポストモーテム：{インシデント名}
インシデント発生日：2026-04-12
ポストモーテム実施日：2026-04-17
所有者（仲介者）：Camellia（Ops）
出席者：{直接関与した3〜5人}

タイムライン（具体的に、可能ならタイムスタンプを使う）：
- 04-12 09:14: ...
- 04-12 11:30: ...
- 04-12 14:02: ...

決定の経路はどうだったか？
{誰が何を決めたかを再構成した2〜3段落。}

どこで壊れたか？
- 決定の欠落？ はい／いいえ。詳細。
- 誤った決定？ はい／いいえ。詳細。
- 実行の失敗？ はい／いいえ。詳細。

変更すること：
1. {具体的な修正}（所有者：{名前}、期限：{日付}）
2. {具体的な修正}（所有者：{名前}、期限：{日付}）

変更しないこと（とその理由）：
{人々が尋ねてくるが、あえて手をつけなかったこと。}

非難なしルール：このドキュメントは決定に名前を付け、人には付けない。名前は明確さのためにタイムラインに現れるのであって、「何が壊れたか」のセクションには現れない。

このドキュメントは共有フォルダに置きます。誰かのDMの中ではありません。Slackのスレッドの中でもありません。一貫したファイル命名規則を持つフォルダに置き、リーダーシップチームの誰もが、同じ問題が再び起きそうな6か月後に見つけられるようにします。

非難なしの枠組みが重要です。ポストモーテムが魔女狩りになった瞬間、人々は正直でなくなり、あなたは何も学べなくなります。要点は、誰がしくじったかを突き止めることではありません。あなたのプロセスの何が、1つのしくじりにこれほどの被害をもたらすのを許したのかを突き止めることです。

仲介は本物の仕事である

私がこの仕事を始めたとき、誰も教えてくれなかったことがあります。仲介は本物の仕事だということです。それは間接費ではありません。「ソフトな部分」でもありません。中規模企業において最もレバレッジの高い役割であり、うまくやると仕事が目に見えないために、ほとんどいつも評価されません。

うまくやると、仲介は何でもないように見えます。会議は短い。決定は下される。部門間の争いは再発しない。オンボーディングの引き継ぎは滑らか。更新予測には「待って、このアカウントは誰が所有してるの？」という瞬間がない。みんな、会社はただそういうふうに回っているのだと思い込みます。

下手にやると、仲介は、毎週木曜の午後4時47分のSlack DM、3か月の決定サイクル、そして互いをひそかに恨み合うリーダーシップチームのように見えます。

これを習得したOps ICは、すべてのVPが信頼する人物になります。あなたは戦略の部屋に引っ張り込まれます。そこに属すると示す肩書きがあるからではなく、システム全体を見渡し、それを5つの異なる方言で説明できる唯一の人物だからです。それが、Operations ManagerからDirector of Operationsへの道筋です。その道はまっすぐ仲介の役割を貫いていますが、ほとんどの人は、それが自分の仕事ではないと思っているために見落とします。

それはあなたの仕事です。これで、そのためのプレイブックが手に入りました。

さらに詳しく

• Operations Managerの職務記述書
• Revenue Operations向けRACIテンプレート
• 本当に決まる意思決定会議の運営
• リード・トゥ・オポ引き継ぎのSLA設計
• Ops ManagerからDirector of Operationsへの道筋