revops-radar

RevOps Radar

RevOps／Sales Ops の情報エコシステムをキュレーションします。まず、ユーザーが実際に毎週確保できる時間に合わせた、順位付きの検証済みリンク集を簡潔に提示してください。クリック先のない名前だけのリストや、現在も有効か確認していない情報源は決して提示しないでください。

まずはこちら

媒体ごとにまとめた、検証済み情報源約20件を1行ずつ紹介します。以下の各項目には、スナップショットの日付（2026-09-08）時点で有効であることを確認したリンクがあります。これは代表的な情報源の抜粋であり、成果物そのものではありません。ユーザーに渡す前に、必ず以下の「インタビューとパーソナライズ」ワークフローを実行し、完全版スナップショットから残りの情報源を選んでください。

フォローする人

• Justin Norris - linkedin.com/in/justinnorris/ - RevOps FM のホスト。GTM／RevOps の実務に根ざした運営手法を発信しています。
• Kyle Poyar - linkedin.com/in/kyle-poyar/ - Growth Unhinged を運営。価格設定、パッケージング、GTM のベンチマークデータを扱います。
• Rosalyn Santa Elena - linkedin.com/in/rosalyn-santa-elena/ - The RevOps Collective の創設者。この分野で、最も幅広いチャネルにわたる情報を発信しています。

ポッドキャスト

• RevOpsAF - revopscoop.com/podcast - RevOps Co-op の看板番組。2026年9月のエピソードを確認済みで、現在も配信中です。
• GTM Podcast - gtmnow.com/podcast - Sam Jacobs による、長年続くGTM／RevOps実務者へのインタビュー番組です。
• Salesforce Admins Podcast - admin.salesforce.com/podcast - Salesforce 公式番組。毎週配信されており、現在も配信中であることを確認済みです。

ニュースレターとブログ

• Growth Unhinged - growthunhinged.com - Kyle Poyar が運営。価格設定、PLG、GTM のベンチマークデータを扱います。
• GTMnow - gtmnow.com - GTM実務者向けの戦術やキャリアに関するコンテンツを発信しています。
• RevOps Impact Newsletter - substack.com/@revopsimpact - Jeff Ignacio（AWS）による、実務者の視点からRevOpsとAIの戦術を毎週届けるニュースレターです。

書籍

• Revenue Operations - Stephen G. Diorio & Chris K. Hummel - この分野の基礎的な教科書に最も近い書籍です。
• From Impossible to Inevitable - Aaron Ross & Jason Lemkin - 予測可能なパイプライン創出に関する基礎的な書籍です。
• Revenue Architecture - Jacco van der Kooij - Bowtie と SPICED のフレームワークに関する情報源です。

YouTube

• Salesforce Admins (official) - youtube.com/@SalesforceAdmins - 登録者数135K人。非常に活発です。
• RevOps Co-op - youtube.com/@revopscoop - RevOpsAF のポッドキャストエピソードを動画で公開しています。
• Winning by Design - youtube.com/@WinningByDesign - レベニューアーキテクチャのフレームワークに関するコンテンツを発信しています。

コミュニティ

• RevOps Co-op - revopscoop.com - Slack、ポッドキャスト、カンファレンスを擁する中心的なコミュニティで、会員数は19,000人です。
• Pavilion - joinpavilion.com - 専用のRevOpsリーダーグループを持つ、GTMリーダー同士のコミュニティです。5,000人以上のエグゼクティブが参加しています。
• r/RevOps - reddit.com/r/RevOps - 現在も活発であることを確認済み。無料で利用できます。

カンファレンス

• GTM2026 (Pavilion) - attendgtm.com - 2026年9月28日～10月1日、ニューヨーク市、VP以上の実務者約1,000人が参加。
• Dreamforce - salesforce.com/dreamforce/ - 2026年9月15～17日、サンフランシスコ。
• MOPs-Apalooza - mopsapalooza.com - 2026年10月21～22日、オンライン開催。

ソースの完全版スナップショット

上記は一覧の一部です。ウォッチリストを作成する前に、references/sources.mdを確認してください。ポッドキャスト、ニュースレター、コミュニティ、イベント、認定資格に関する日付付きの全情報源に加え、2026-09-08の確認時に判明した修正（名称変更、終了した番組、誤って帰属されていたポッドキャスト、URLの修正2件）が記載されています。references/people-to-follow.md、references/books.md、references/video-channels.mdには、媒体ごとのより詳しい一覧があります。references/curation-method.mdには、このファイルでは簡略化している順位付けの計算方法が記載されています。

インタビュー

以下の質問を一問ずつ尋ねてください。回答を待ってから、次の質問をしてください。選択肢は記載どおりに提示してください。

1. 「収益部門での役割は何ですか？」- (a) IC／アナリスト、(b) マネージャー、(c) リーダー（ディレクター以上）。
2. 「最新情報を把握するために、現実的に週あたりどのくらい時間を使えますか？」- (a) 30分未満、(b) 30～60分、(c) 60～120分、(d) 2時間以上。
3. 「新しい役割、計画サイクル、スタックの移行など、特定のタイミングに備えて情報を集めていますか？それとも、毎週継続する習慣を作ろうとしていますか？」- (a) 情報を集めている、(b) 継続する習慣。
4. 「実際に利用している媒体はどれですか？最大2つ選んでください。」- (a) 音声（ポッドキャスト）、(b) 動画、(c) テキスト（ニュースレター、ブログ）、(d) ライブコミュニティ（チャット、イベント）。
5. 「そのうち、完全に対象外となるものはありますか？たとえば、通勤やジムで音声を聴く時間がない、料金を払うつもりのない有料コンテンツ、有料コミュニティや経費精算できないカンファレンスなどです。」
6. 「幅広さと深さ、どちらを重視しますか？」- (a) 分野全体を幅広く把握する、(b) いくつかのテーマを深く掘り下げる（テーマを挙げてください）。
7. 「どのセグメントで事業を展開していますか？」- (a) B2B SaaS、(b) B2C／eコマース、(c) 両方。
8. 「ベンダーが運営する情報源（ツール企業のブログ、調査レポート）も含めますか？」- (a) はい。明確に区別してください、(b) いいえ。独立した発信者の情報のみ。
9. 「収益スタックの中核は、独自の管理者コミュニティや認定資格制度を持つ、圧倒的なシェアのCRMプラットフォームですか？また、そのプラットフォームのエコシステムに関する情報源も含めますか？」- (a) はい。含めてください、(b) いいえ。

質問2、3、5があるのは、情報源の種類によって必要な労力、効果が出るまでの速さ、得られるものが大きく異なるためです。これらを確認しないまま、ステップ6で順序をユーザーに代わって決めることはできません。提供日については尋ねないでください。レーダーに納品物はなく、質問3ですでに、期限を尋ねて得られる情報を確認しています。

B2BとB2Cの範囲

RevOpsの情報エコシステムは圧倒的にB2B SaaS中心で、B2C／DTCに特化した「RevOps」の分野は存在しません。B2Cまたはeコマースのユーザーには、このことを明示してください。同等の情報源があるかのように伝えないでください。

セグメントが(b)または(c)の場合は、B2Bの情報源から媒体に依存しないフレームワーク（ファネルの計算、予測、データの衛生管理）を取り入れつつ、コミュニティやベンチマークのニーズはeコマース事業者のコミュニティに案内してください（情報源リストに、確認済みの類似例が1つあります）。名前が挙がるベンチマークやプレイブックの多くは、B2Bの営業サイクルを前提としていることを伝えてください。

パーソナライズのワークフロー

1. references/sources.md と references/people-to-follow.md を読み込みます。各ファイルのヘッダーに記載されたスナップショットの日付を確認します。約6か月以上前のものであれば、そのリストを参考にする前に再確認が必要だとユーザーに伝えます。

2. インタビューの回答に基づいて候補を絞り込みます。

   • セグメント
   • 媒体
   • シニアリティの適合性
   • ベンダー運営を優先するか
   • プラットフォームのエコシステムを優先するか

3. 除外する場合は、候補から外します。ユーザーの条件に合わないソースは、すべて候補から除外します。

   • 通勤や運動に充てられる時間がない場合の音声コンテンツ
   • 経費で支払えない有料コミュニティやカンファレンス
   • 購入するつもりのないペイウォール
   • 参加できないプラットフォーム

   各候補を除外したことを出力内で明記します（「除外：Pavilion - 有料、予算なし」）。除外対象のソースをリストの末尾に残すと、次回の更新時に暗黙のうちに対象に戻ってしまいます。これはベンチではありません。ベンチに残すのは、予算の都合で今回のリストに入らなかった、検証済みのソースです。

4. 残った候補すべてについて、以下の鮮度チェックを行います。検証に合格するか、未検証であることを承知のうえでユーザーが受け入れた場合にのみ、ソースをリストに加えます。

5. 各候補の注意コストは、正確な数値ではなく、おおよその時間単位で見積もります。テキストは数分、動画は数十分、ポッドキャストのエピソードは1時間弱、コミュニティの流し読みは数十分、イベントはまとまった日数を要します。すでに費やしている時間（通勤や運動など）に組み込める音声コンテンツは、コストを半分にします。

6. 効率性で順位を付けます。安さやオーディエンスの規模ではなく、注意時間あたりの価値を基準にします。効率性は ニュースレター == ブログ > コミュニティの流し読み > ポッドキャスト > 動画、価値は コミュニティ == イベント > ポッドキャスト > ニュースレター == ブログ > 動画 の順です。同じ媒体の中では、まず役割との適合性、次に継続性（責任者が明確な著者、機関による後援、複数の場での継続的な発信）で順位を付けます。登録者数を基準にしてはいけません。各軸の詳しい考え方と、同順位となる理由については、references/curation-method.md を参照してください。

7. この順位付けによって何が後回しになるかを明記します。長文コンテンツ（ポッドキャスト、講演、イベント、コミュニティ）は価値が最も高い一方で、効率性の軸では最下位、または最下位付近に位置するため、効率性の高い順に予算を埋めると選ばれません。それでも、分野を学び始めたばかりのユーザー、指定したテーマを深く掘り下げたいユーザー、特定の節目に向けて情報を収集したいユーザー、すでに通勤やジムの時間があるユーザーには、長文コンテンツを優先して勧めます。

8. 予算の約90%まで候補を選び、残り約10%はコミュニティ1つ分として確保します。コミュニティはリストを更新し続ける手段だからです。候補から外すのではなく、有力な候補を2～3個「ベンチ」として挙げます。数値を用いた詳しい計算は、references/curation-method.md を参照してください。

9. すでに把握しているユーザーの状況に合わせて順位を付け直します。すでに料金を支払っているソースやメンバーシップは追加コストがかからず、雇用主のカンファレンス予算があればイベントは無料になり、コミュニティに参加している同僚がいれば、参加する代わりにその人に尋ねられます。この順位付けは標準的な方針であり、絶対的なルールではありません。

10. インタビューで確認した、どの程度幅広い情報を求めるかに応じて、集中させるか、分散させるかを決めます。

    • 深さを重視するユーザー：予算を3～5個のソースと、指定したテーマについて発信する人に集中させます。
    • 幅広さを重視するユーザー：複数の媒体に分散させ、中心となるコミュニティを1つ選びます。

11. 以下の出力形式に沿って、セクションごとにリストを提示し、最終決定の前に、内容を確認してもらうか、候補を入れ替えるかユーザーに尋ねます。

12. 実行環境に永続メモリがある場合は、インタビューの回答、最終リスト、検証日を記録し、更新時に差分を確認できるようにします。

鮮度チェック

おすすめする前に確認してください。ホームページに記載された更新頻度の主張（「週刊番組」など）は、日付のあるコンテンツで確認できるまでは、あくまで目標にすぎません。「週刊」とうたう評判の良い情報源でも、キャッチフレーズを掲載したまま7か月以上更新が途絶えている例が確認されています（RevOps FM と The Revenue Formula は、どちらも sources.md に記録された確認済みの例です）。

ウェブを閲覧または取得できる場合は、各情報源の正規 URL にアクセスし、最も新しい日付付きコンテンツを探して、サイト自身の主張ではなく、確認できた日付に基づいて分類してください。verified-active（約3か月以内）、verified-stale（アクセス可能だが、それより古い。ユーザーがリスクを受け入れる場合に限り掲載を続ける）、dead（駐車ページやマーケットプレイスのページにリダイレクトされる。必ず削除する）、unverified（取得に失敗した、またはアクセスをブロックされた。理由を記録する。403 やボットによるブロックは未確認であり、決して dead としない）に分類してください。名称変更後も存続しているもの、ドメインが転売されたもの、本当に消滅したものを区別し、同じ判定にまとめないでください。また、まだ活動を開始していない情報源（コンテンツが何も公開されていない「近日公開」ページが表示されているもの）も別に識別してください。劣化モードの分類の全容と具体例は、references/curation-method.md を参照してください。

動画プラットフォーム、ディスカッションフォーラム、短文投稿型ソーシャルネットワークは、自動チェックが体系的に困難です。理由を添えて未確認とし、手動で確認するか、取得可能な情報（ポッドキャストのゲスト一覧、登壇者一覧、チームページなど）で人物の存在を確認し、ハンドル名は独立して確認できていない旨を明記してください。

ウェブをまったく閲覧できない場合は、各項目に記録済みのステータスを付けて references/sources.md のリストを提示し、再確認できなかったことを明確に伝え、ユーザーに手動で確認してもらってください。

定期更新の手順

ハーネスが定期実行に対応している場合は、四半期ごとの更新を設定してください。対応していない場合は、ユーザーに定期的なカレンダーのリマインダー（「RevOps レーダーを更新 - 四半期ごと」）を設定し、通知が来たらこのスキルを再実行するよう伝えてください。

更新のたびに、次を行います。

1. 以前にアクセスできた URL も含め、すべての URL を再確認し、名称変更やドメインの転売を検出します。
2. 鮮度チェックを再実行し、新たに古くなった項目は格下げし、消滅した項目は削除し、以前に未確認または未公開だった項目は再試行します。
3. ユーザーに前四半期に実際に利用した情報源を尋ね、読まれなかったものは削除します。読まれない情報源でも、注意を払うコストはかかります。制約が解除されたとユーザーが明言しない限り、制約を理由に削除した情報源を再度提案しないでください。
4. 中心となるコミュニティや新たに追加した情報源に、それぞれ候補を1つ推薦してもらいます。確認したうえで、候補リストまたは掲載リストへの入れ替えを検討します。
5. 予算と照らし合わせて週あたりの推定時間を再計算し、超過分を削ります。

出力形式

ペルソナ、時間の予算、確認日を見出しに含め、日付を付けたウォッチリストを1つ作成してください。

媒体ではなく、利用頻度ごとに項目をグループ化します。

• 週次の中核
• 月次
• 年次（イベント）
• 候補（確認済みの代替）
• 削除（除外した理由付き）

各項目には、次を含めてください。

• 名前
• URL
• 媒体
• 推定時間（分）
• 掲載に値する理由を1行で記載
• 確認ステータスと日付
• 該当する場合はベンダー運営のフラグ

最後に、次の合計を記載してください。

• 週あたりの推定時間と予算
• セクションごとの件数
• verified-active の項目数

詳しい記入例と避けるべき例は、references/watch-list-example.md を参照してください。

呼び出し例：

• 「RevOps レーダーを作ってください。週に1時間ほど使える営業オペレーションマネージャーです。」
• 「時間を割く価値のある RevOps ニュースレターはどれですか？ポッドキャストは聴きません。」
• 「Revenue Operations で誰をフォローすべきですか？独立系の発信者に限ります。」

障害モード

• 活動を停止した、または休眠状態の情報源を推奨する。 推奨する前に必ず確認してください。確認せずに、あたかも現在も有効であるかのように参照リストをそのまま提示してはいけません。
• 記憶している URL を信用する。 ドメインは転売されることがあります。リンク先が開けても、現在は無関係な事業者のサイトにつながる可能性があります。あらためてアクセスし、内容が一致することを確認してください。
• 指標をでっち上げる。 情報源が購読者数、ダウンロード数、メンバー数を公開していない場合は、「記載なし」としてください。推定してはいけません。
• 予算を超えて詰め込みすぎる。 60 分の予算に対して優れた情報源を 40 件提示するのは、成果物として失敗です。予算に収まるように絞り込み、予備リストを活用してください。
• オーディエンスの規模を権威性と取り違える。 購読者数が多くても、マーケティングのリーチを示すだけです。複数の媒体で繰り返し取り上げられていることや、責任者として名前が明記された著者の存在のほうが、品質と継続性をよりよく予測できます。
• 衰退の形態を一括りにする。 名前が変わったものの存続している情報源を停止扱いにすると、価値ある情報源を失います。403 エラーの情報源を停止扱いにしても、価値ある情報源を失います。転売されたドメインを残すのは、どちらよりも問題です。
• スナップショットからリンクを取得する、または情報源に検証済みのリンクがないと明記する代わりに、記憶を頼りにもっともらしい URL を作る。

測定

四半期ごとの更新時に、以下のすべてを満たしていれば、ウォッチリストは機能しています。

• 掲載されているすべての情報源が過去 90 日以内に有効であることを確認済み、または古い／未検証であることをユーザーが明示的に了承している
• 推定週間所要時間の合計が、明示された予算以内である
• ユーザーが掲載項目の少なくとも 3 分の 2 を実際に利用していると報告している

いずれかの確認に失敗した場合は、修正してください。再確認、絞り込み、または予備リストからの入れ替えを行い、3 項目すべてに合格するまで提示し直します。納品時の合格基準はさらに厳格です。検証済みとして提示する未検証項目はゼロとし、予算を厳守してください。

参考資料

• references/sources.md — 分類と日付を記載した情報源リスト（ポッドキャスト、ニュースレターとブログ、コミュニティ、イベント、認定資格）。
• references/people-to-follow.md — LinkedIn URL、独立性フラグ、複数媒体での反復登場シグナルを確認済みの、フォローする価値がある実務家。
• references/books.md — 基礎書と実務家向け書籍のリスト。
• references/video-channels.md — 登録者数を記載した、検証済み YouTube チャンネルの全リスト。
• references/curation-method.md — ランキングの算出方法と鮮度確認における衰退形態の分類を網羅した資料。
• references/watch-list-example.md — 作成例と、避けるべき例。
• このコレクション内でタスクを振り分けるには、mbfinotti/revops-skills@revops-kickoff を参照してください。
• RevOps の職に就き、成長する方法については、mbfinotti/revops-skills@revops-career を参照してください。このスキルが扱うのは読むべき情報源とフォローすべき人の選定のみです。キャリア戦略については、そちらを参照してください。
• RevOps チームの構築については、mbfinotti/revops-skills@revops-hiring を参照してください。