RevOpsのためのSQL入門｜データ抽出・分析の基本クエリ集

TL;DR

• RevOps担当者にとってSQLは部門横断データを自力で抽出・分析できる最も実用的なスキル
• SELECT・WHERE・GROUP BY・JOINの4構文だけで主要な分析をカバーできる
• アドホック分析を待ち時間ゼロで実行でき意思決定スピードが格段に上がる

この記事が役立つ状況

• 対象者: RevOps担当者・営業企画・レベニューアナリティクス担当
• 直面している課題: BIツールやCRM標準レポートでは対応できないアドホック分析を、エンジニア依頼の数日待ちなしに自力で実行したい
• 前提条件: MetabaseやRedash等のSQLベースBIツール、または商談・顧客データを格納したデータベースへのアクセス権限

このノウハウをAIで実行するプロンプト

以下をコピーしてLLMに貼り付け、[ ] 内を自社の情報に書き換えてください。

あなたはRevOps向けSQLアドバイザーです。以下の前提でクエリを設計してください。

【分析したい指標】[例: MQL→SQL転換率を流入チャネル別に / 受注商談の平均リードタイムを四半期比較 など]
【利用テーブル】[例: deals, companies, leads など。カラム名も列挙]
【絞り込み条件】[期間・ステージ・営業担当など]
【集計軸】[GROUP BYに使う軸: owner_name / stage / channel など]

SELECT・WHERE・GROUP BY・JOINの4構文を基本に、可読性の高いSQLとカラムの意味を解説してください。

SQLがRevOps担当者に必要な理由

結論から述べると、SQLはRevOps担当者がデータに直接アクセスし、必要な情報を自分の手で取り出せるようになる最も実用的なスキルだ。BIツールの標準ダッシュボードやCRMのレポート機能だけでは対応できない「あと一歩の分析」を、待ち時間ゼロで実行できるようになる。

RevOps（Revenue Operations）の業務では、マーケティング・営業・カスタマーサクセスの部門横断データを統合して分析する場面が日常的に発生する。「先月のMQL→SQL転換率を流入チャネル別に見たい」「受注した商談の平均リードタイムを四半期ごとに比較したい」といったアドホックな分析要求に対して、エンジニアやデータチームに依頼していては数日のタイムラグが生まれる。SQLを使えば、こうした分析を自分で即座に実行でき、意思決定のスピードが格段に上がる。

BIツールの多くはSQLベースでデータを取得しており、MetabaseやRedashではSQLクエリを直接書いて可視化できる。SQLを理解していれば、営業ダッシュボードのカスタマイズも自在になり、ツールの制約に縛られない分析が可能だ。

本記事では、RevOps担当者が実務で使う頻度の高いSQLクエリを、具体的なユースケースとともに紹介する。

SQL基本構文 — SELECT・WHERE・GROUP BY・JOIN

SQLで営業データを分析するために最低限押さえるべき構文は4つだ。この4つを組み合わせるだけで、RevOps業務の主要な分析をカバーできる。

SELECT — データの取得

SELECTは「どのカラム（列）のデータを取得するか」を指定する構文だ。

-- 商談テーブルから商談名、金額、ステージを取得
SELECT
    deal_name,
    amount,
    stage
FROM deals;

WHERE — 条件による絞り込み

WHEREは取得するデータの条件を指定する。日付範囲や特定のステージなど、分析対象を限定する際に使いる。

-- 2026年Q1に作成された商談のみを取得
SELECT
    deal_name,
    amount,
    stage,
    created_at
FROM deals
WHERE created_at >= '2026-01-01'
  AND created_at < '2026-04-01';

GROUP BY — データの集計

GROUP BYはデータをグループ化し、件数（COUNT）、合計（SUM）、平均（AVG）などの集計を行いる。KPIツリーの各指標を算出する際の基本構文だ。

-- 営業担当者別の商談件数と合計金額
SELECT
    owner_name,
    COUNT(*) AS deal_count,
    SUM(amount) AS total_amount
FROM deals
WHERE created_at >= '2026-01-01'
GROUP BY owner_name
ORDER BY total_amount DESC;

JOIN — テーブルの結合

JOINは複数のテーブルを結合し、部門横断のデータを統合分析する際に使いる。商談データと顧客データ、活動ログとリードデータなど、別々のテーブルに格納された情報を繋ぎ合わせるのがJOINの役割だ。

-- 商談データに顧客情報を結合
SELECT
    d.deal_name,
    d.amount,
    d.stage,
    c.company_name,
    c.industry
FROM deals d
JOIN companies c ON d.company_id = c.id
WHERE d.stage = 'Closed Won';

この4つの構文を組み合わせるだけで、以降に紹介する実践的な分析クエリをすべて構築できる。

パイプライン分析のSQLクエリ

パイプラインマネジメントはRevOpsの中核業務だ。SQLを使えば、パイプラインの状況をリアルタイムに把握し、ボトルネックの特定や将来の売上予測に活用できる。

ステージ別パイプラインサマリー

現在のパイプラインをステージ別に集計し、件数・金額・平均単価を一覧化するクエリだ。

-- ステージ別のパイプラインサマリー
SELECT
    stage,
    COUNT(*) AS deal_count,
    SUM(amount) AS total_amount,
    ROUND(AVG(amount), 0) AS avg_deal_size,
    ROUND(AVG(DATEDIFF(CURRENT_DATE, created_at)), 1) AS avg_age_days
FROM deals
WHERE stage NOT IN ('Closed Won', 'Closed Lost')
GROUP BY stage
ORDER BY
    CASE stage
        WHEN 'Qualification' THEN 1
        WHEN 'Discovery' THEN 2
        WHEN 'Proposal' THEN 3
        WHEN 'Negotiation' THEN 4
    END;

加重パイプライン（Weighted Pipeline）

各ステージの受注確率を加味した加重パイプラインを算出する。フォーキャスト精度の向上に直結するクエリだ。

-- ステージ別の受注確率を加味した加重パイプライン
SELECT
    stage,
    COUNT(*) AS deal_count,
    SUM(amount) AS raw_amount,
    ROUND(SUM(amount * probability / 100), 0) AS weighted_amount
FROM deals
WHERE stage NOT IN ('Closed Won', 'Closed Lost')
  AND expected_close_date BETWEEN '2026-04-01' AND '2026-06-30'
GROUP BY stage
ORDER BY stage;

ファネル転換率の算出クエリ

セールスファネル分析では、各ステージ間の転換率を計測することでボトルネックを特定する。SQLを使えば、期間別・チャネル別・担当者別など多角的なファネル分析が可能だ。

月別ファネル転換率

リードから受注までの各ステージの転換率を月別に算出するクエリだ。

-- 月別のファネル転換率
SELECT
    DATE_FORMAT(l.created_at, '%Y-%m') AS lead_month,
    COUNT(DISTINCT l.id) AS leads,
    COUNT(DISTINCT CASE WHEN l.status = 'MQL' THEN l.id END) AS mqls,
    COUNT(DISTINCT CASE WHEN l.status = 'SQL' THEN l.id END) AS sqls,
    COUNT(DISTINCT d.id) AS opportunities,
    COUNT(DISTINCT CASE WHEN d.stage = 'Closed Won' THEN d.id END) AS won,
    -- 転換率
    ROUND(COUNT(DISTINCT CASE WHEN l.status = 'MQL' THEN l.id END)
        * 100.0 / NULLIF(COUNT(DISTINCT l.id), 0), 1) AS lead_to_mql_pct,
    ROUND(COUNT(DISTINCT CASE WHEN d.stage = 'Closed Won' THEN d.id END)
        * 100.0 / NULLIF(COUNT(DISTINCT l.id), 0), 1) AS lead_to_won_pct
FROM leads l
LEFT JOIN deals d ON l.id = d.lead_id
WHERE l.created_at >= '2025-10-01'
GROUP BY DATE_FORMAT(l.created_at, '%Y-%m')
ORDER BY lead_month;

チャネル別の転換率比較

流入チャネルごとの転換率を比較し、最も効率の良いチャネルを特定する。マーケティングのROI評価と予算配分の意思決定に直結する分析だ。

-- チャネル別の転換率と受注単価
SELECT
    l.source_channel,
    COUNT(DISTINCT l.id) AS leads,
    COUNT(DISTINCT d.id) AS opportunities,
    COUNT(DISTINCT CASE WHEN d.stage = 'Closed Won' THEN d.id END) AS won,
    ROUND(COUNT(DISTINCT CASE WHEN d.stage = 'Closed Won' THEN d.id END)
        * 100.0 / NULLIF(COUNT(DISTINCT l.id), 0), 1) AS win_rate_pct,
    ROUND(AVG(CASE WHEN d.stage = 'Closed Won' THEN d.amount END), 0) AS avg_won_amount
FROM leads l
LEFT JOIN deals d ON l.id = d.lead_id
GROUP BY l.source_channel
ORDER BY win_rate_pct DESC;

コホート分析・リテンション分析のクエリ

コホート分析は、特定の時期に獲得した顧客グループの行動を時間軸で追跡する手法だ。SQLで月次リテンションコホートを作成すれば、チャーンレートの改善ポイントを構造的に把握できる。

月次リテンションコホート

顧客の契約開始月をコホートとし、各月のリテンション率を算出する。

-- 月次リテンションコホート
WITH cohort AS (
    SELECT
        customer_id,
        DATE_FORMAT(MIN(subscription_start_date), '%Y-%m') AS cohort_month
    FROM subscriptions
    GROUP BY customer_id
),
monthly_activity AS (
    SELECT
        c.cohort_month,
        DATE_FORMAT(r.revenue_date, '%Y-%m') AS activity_month,
        COUNT(DISTINCT c.customer_id) AS active_customers
    FROM cohort c
    JOIN monthly_revenue r ON c.customer_id = r.customer_id
    GROUP BY c.cohort_month, DATE_FORMAT(r.revenue_date, '%Y-%m')
)
SELECT
    ma.cohort_month,
    ma.activity_month,
    TIMESTAMPDIFF(MONTH,
        STR_TO_DATE(CONCAT(ma.cohort_month, '-01'), '%Y-%m-%d'),
        STR_TO_DATE(CONCAT(ma.activity_month, '-01'), '%Y-%m-%d')
    ) AS month_number,
    ma.active_customers,
    ROUND(ma.active_customers * 100.0
        / FIRST_VALUE(ma.active_customers) OVER (
            PARTITION BY ma.cohort_month
            ORDER BY ma.activity_month
        ), 1) AS retention_rate_pct
FROM monthly_activity ma
ORDER BY ma.cohort_month, ma.activity_month;

このクエリの結果をピボットテーブルに変換すれば、月を追うごとにどのコホートが離脱しているかを視覚的に把握できる。Month 3での急激な離脱が見られれば、オンボーディングプロセスの改善が必要というシグナルだ。カスタマーオンボーディングの設計と組み合わせて、離脱ポイントの原因究明に活用してください。

営業KPIレポートの自動化クエリ

週次・月次の営業ダッシュボードに使えるKPIレポートのクエリを紹介する。一度作成すればBIツールの定期実行機能で自動更新でき、手動集計の工数を削減できる。

営業担当者別パフォーマンスレポート

担当者ごとの主要KPIを一覧化し、チーム全体のパフォーマンスを比較するレポートだ。

-- 営業担当者別の月次パフォーマンス
SELECT
    d.owner_name,
    COUNT(CASE WHEN d.created_at >= DATE_FORMAT(CURRENT_DATE, '%Y-%m-01')
               THEN d.id END) AS new_deals_this_month,
    SUM(CASE WHEN d.stage = 'Closed Won'
              AND d.closed_at >= DATE_FORMAT(CURRENT_DATE, '%Y-%m-01')
             THEN d.amount ELSE 0 END) AS won_amount,
    COUNT(CASE WHEN d.stage = 'Closed Won'
               AND d.closed_at >= DATE_FORMAT(CURRENT_DATE, '%Y-%m-01')
               THEN d.id END) AS won_count,
    ROUND(
        COUNT(CASE WHEN d.stage = 'Closed Won'
                   AND d.closed_at >= DATE_FORMAT(CURRENT_DATE, '%Y-%m-01')
                   THEN d.id END) * 100.0
        / NULLIF(COUNT(CASE WHEN d.stage IN ('Closed Won', 'Closed Lost')
                            AND d.closed_at >= DATE_FORMAT(CURRENT_DATE, '%Y-%m-01')
                            THEN d.id END), 0)
    , 1) AS win_rate_pct,
    ROUND(AVG(CASE WHEN d.stage = 'Closed Won'
                   THEN DATEDIFF(d.closed_at, d.created_at) END), 1) AS avg_sales_cycle_days
FROM deals d
GROUP BY d.owner_name
ORDER BY won_amount DESC;

MRR推移レポート

SaaSビジネスの生命線であるMRR（月次経常収益）の推移を、新規・拡張・縮小・解約に分解して算出する。

-- MRR推移の分解（New / Expansion / Contraction / Churn）
WITH mrr_by_month AS (
    SELECT
        customer_id,
        DATE_FORMAT(revenue_date, '%Y-%m') AS revenue_month,
        SUM(mrr) AS monthly_mrr
    FROM monthly_revenue
    GROUP BY customer_id, DATE_FORMAT(revenue_date, '%Y-%m')
),
mrr_changes AS (
    SELECT
        curr.revenue_month,
        curr.customer_id,
        curr.monthly_mrr AS current_mrr,
        COALESCE(prev.monthly_mrr, 0) AS previous_mrr
    FROM mrr_by_month curr
    LEFT JOIN mrr_by_month prev
        ON curr.customer_id = prev.customer_id
        AND prev.revenue_month = DATE_FORMAT(
            DATE_SUB(STR_TO_DATE(CONCAT(curr.revenue_month, '-01'), '%Y-%m-%d'),
                     INTERVAL 0 MONTH) - INTERVAL 1 MONTH, '%Y-%m')
)
SELECT
    revenue_month,
    SUM(CASE WHEN previous_mrr = 0 AND current_mrr > 0
             THEN current_mrr ELSE 0 END) AS new_mrr,
    SUM(CASE WHEN previous_mrr > 0 AND current_mrr > previous_mrr
             THEN current_mrr - previous_mrr ELSE 0 END) AS expansion_mrr,
    SUM(CASE WHEN previous_mrr > 0 AND current_mrr < previous_mrr AND current_mrr > 0
             THEN current_mrr - previous_mrr ELSE 0 END) AS contraction_mrr,
    SUM(CASE WHEN previous_mrr > 0 AND current_mrr = 0
             THEN -previous_mrr ELSE 0 END) AS churn_mrr
FROM mrr_changes
GROUP BY revenue_month
ORDER BY revenue_month;

このクエリで得られるMRR分解は、NRR（売上維持率）の算出にも直結する。経営レポートにおけるSaaS KPIの根拠データとして、ボードレポーティングにも活用できる。

SQLクエリを運用に定着させるための3つのルール

SQLクエリを書ける人が増えても、運用が属人化してしまっては組織としての分析力は向上しない。チームでSQLを活用する際には、以下の3つのルールを設けることを推奨する。

第一に、クエリライブラリを共有リポジトリで管理することだ。 頻出クエリをGitHubやNotionにカテゴリ別で蓄積し、誰でも検索・再利用できる状態にする。「パイプライン分析」「ファネル転換率」「コホート分析」などのフォルダ構成で整理すると、新メンバーでも必要なクエリをすぐに見つけられる。

第二に、クエリにはコメントで意図を残すことだ。 SQLの--コメントで「何を分析するためのクエリか」「WHERE句の条件の理由」を記述する。3ヶ月後に自分が見返したときに意図が分からなくなるクエリは、他のメンバーにとっても読めない。データガバナンスの観点からも、分析ロジックの透明性は重要だ。

第三に、データ定義を統一することだ。 「受注」はClosed Wonのみか、Closed Won + Closed Won (Renewal)を含むか。「商談作成日」はCRM上のcreated_atか、初回ミーティング日か。こうしたデータ定義がチーム内で揃っていなければ、同じクエリを実行しても結果が異なる。定義書を作成し、SQLクエリ内のコメントでも参照先を明示してください。

まとめ — SQLはRevOpsの分析力を加速させる武器

SQLはRevOps担当者にとって、データドリブン営業を実現するための最も汎用的な武器だ。SELECT・WHERE・GROUP BY・JOINの4構文を押さえるだけで、パイプライン分析、ファネル転換率、コホート分析、KPIレポートといったRevOpsの主要分析をカバーできる。

まずは本記事で紹介したクエリを自社のデータベースで実行してみてください。CRMのレポート機能では見えなかった洞察が、SQLの一行で得られる体験をすれば、データ分析への取り組み方が変わるはずだ。クエリライブラリの蓄積が進めば、組織全体の分析力が底上げされ、意思決定のスピードと精度が向上する。

SQLで抽出したデータをダッシュボードに可視化する手順はRevOpsのKPIダッシュボード設計で、データ品質を維持しクエリ結果の信頼性を高める取り組みはRevOpsのデータ品質管理ガイドで詳しく解説している。