SQLを学ぶのにプログラミング経験は必要ですか？

不要です。SQLは英語に近い構文で設計されており、SELECT（取得）、WHERE（条件）、GROUP BY（集計）といった直感的なキーワードで構成されています。RevOpsに必要な基本操作は1-2週間の学習で習得できます。

CRMのレポート機能があればSQLは不要ではないですか？

CRM標準のレポート機能は定型分析に適していますが、複数テーブルの結合や独自の集計ロジックが必要な分析には限界があります。SQLを使えばCRMでは作れない柔軟な分析が可能になり、BIツールと組み合わせることで分析の幅が大きく広がります。

RevOps担当者はどのデータベースでSQLを実行しますか？

主な実行環境はBIツール（Metabase、Looker Studio）、DWH（BigQuery、Snowflake、Redshift）、CRMのSQLアクセス機能（HubSpotのカスタムレポート、SalesforceのSOQL）です。組織の技術スタックに応じて選択してください。

SQLクエリの実行でデータを壊してしまう心配はありませんか？

SELECT文（データの読み取り）だけを使う限り、データを変更・削除することはありません。RevOpsの分析用途ではSELECT文のみを使用するため、安心して実行できます。権限設定で読み取り専用アクセスにしておくとさらに安全です。

RevOpsのための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の一行で得られる体験をすれば、データ分析への取り組み方が変わるはずです。クエリライブラリの蓄積が進めば、組織全体の分析力が底上げされ、意思決定のスピードと精度が向上します。

参考文献

W3Schools, “SQL Tutorial,” https://www.w3schools.com/sql/
Mode Analytics, “SQL Tutorial for Data Analysis,” https://mode.com/sql-tutorial
Clari, “Revenue Operations Metrics: The Complete Guide,” 2025
Gartner, “How to Improve Data Quality,” 2024
dbt Labs, “Analytics Engineering Guide,” https://docs.getdbt.com/guides