「SQLを学ぶと何が変わるんですか？」
この問いに答えるために、現場で実際に起きた変化を具体的に書く。
理論ではなく現場の話だ。
「SQLを覚えたマーケター」が実際にどう変わったか。
これを5つのシーンで描く。
変化①：「会議の前に数字を確認できる」
SQLを学ぶ前
月次の施策レビュー会議の前日、「あの施策の数字、誰か確認してますか？」という状況になる。
エンジニアに急ぎで頼んで、数字が揃わないまま会議が始まる。「詳細は後で確認します」という言葉が飛び交う。
SQLを学んだ後
会議の前日の夜、Treasure Dataにログインして自分でSQLを実行する。
10分で「先月の新規顧客数・リピート率・CVR・上位購買商品」が手元にある。
翌朝の会議では「昨日確認したデータによると……」から話が始まる。
この変化が会議の質をどう変えるかは、想像できるだろう。
変化②：「施策の立案がデータ起点になる」
SQLを学ぶ前
「30代女性向けに何かキャンペーンをやりたい」という思いつきから施策が始まる。
30代女性という設定は「なんとなく重要そう」という直感から来ている。
SQLを学んだ後
-- 年代別・性別の購買傾向を確認する
SELECT
age_group,
gender,
COUNT(DISTINCT customer_id) AS customer_count,
SUM(amount) AS total_revenue,
ROUND(AVG(amount), 0) AS avg_order_value,
ROUND(
1.0 * COUNT(DISTINCT order_id)
/ COUNT(DISTINCT customer_id)
, 2) AS orders_per_customer
FROM orders o
JOIN customer_master c USING (customer_id)
WHERE
o.status = 'completed'
AND o.order_date >= DATE_ADD('day', -90, CURRENT_DATE)
GROUP BY age_group, gender
ORDER BY total_revenue DESCこのクエリを見ると「40代女性の一人あたり注文金額が他セグメントより30%高いが、顧客数は少ない」ことが分かる。
「40代女性の獲得に投資するか、30代女性のリピート率を上げるか」という問いが具体的になる。
変化③：「施策の効果検証が自分でできる」
SQLを学ぶ前
先月実施したメールキャンペーンの効果が知りたい。「エンジニアさん、メール配信リストとその後の購買データを突き合わせてほしいんですが……」と頼む。
1週間後に「配信済みCSVと購買テーブルをどう結合するかの仕様確認」が来る。
SQLを学んだ後
-- メールキャンペーン配信後30日以内の購買率を計算する
SELECT
m.campaign_id,
m.campaign_name,
COUNT(DISTINCT m.customer_id) AS total_recipients,
COUNT(DISTINCT o.customer_id) AS purchasers,
ROUND(
100.0 * COUNT(DISTINCT o.customer_id)
/ COUNT(DISTINCT m.customer_id)
, 1) AS conversion_rate_pct,
ROUND(SUM(o.amount) / COUNT(DISTINCT o.customer_id), 0)
AS avg_revenue_per_purchaser
FROM email_campaign_recipients m
LEFT JOIN orders o
ON m.customer_id = o.customer_id
AND o.order_date BETWEEN m.sent_date
AND DATE_ADD('day', 30, m.sent_date)
AND o.status = 'completed'
GROUP BY m.campaign_id, m.campaign_name
ORDER BY conversion_rate_pct DESCこのSQLが30分で書ける。そして「メールキャンペーンAのCVRは12%、Bは8%、Cは3%」という結果が5分で返ってくる。
次の施策への学習がその日のうちに始まる。
変化④：「異常値に気づける」
SQLを学ぶ前
月次レポートに「今月の返品率3.2%」と書いてある。先月も3.1%だったから「だいたい同じ」と思って通り過ぎる。
SQLを学んだ後
「返品率」を自分で集計するとき、商品カテゴリ別に分解する習慣が自然につく。
SELECT
product_category,
COUNT(DISTINCT CASE WHEN status = 'returned'
THEN order_id END) AS returned_orders,
COUNT(DISTINCT order_id) AS total_orders,
ROUND(
100.0 * COUNT(DISTINCT CASE WHEN status = 'returned'
THEN order_id END)
/ COUNT(DISTINCT order_id)
, 1) AS return_rate_pct
FROM orders
WHERE order_date >= DATE_ADD('day', -30, CURRENT_DATE)
GROUP BY product_category
ORDER BY return_rate_pct DESC「全体では3.2%だが、あるカテゴリだけ18%の返品率になっている」
集計してみて初めて見える異常値だ。このカテゴリの商品説明と実物の乖離、あるいはサイズ・カラーの問題が示唆される。
「全体を合計して見る」と見えないものが、「分解して見る」と見えてくる。この「分解する習慣」はSQLを書くことで自然に育つ。
変化⑤：「エンジニアへの依頼の質が上がる」
SQLを学んだ後、エンジニアに頼む場面は引き続きある。
複雑なクエリ、大規模なデータ処理、パイプラインの設計
これらはエンジニアに頼む。
しかし依頼の仕方が根本的に変わる。
SQLを学ぶ前の依頼
「過去3ヶ月の顧客のデータを色々な観点で分析してほしいです。購買傾向とか、リピート率とか……」
SQLを学んだ後の依頼
「こういうSQLを書いたんですが、10万件でも1秒以内に返るようにしたいです。インデックスをどう設定すれば良いか教えてもらえますか。あとこのJOINの結果が期待と違っていて、INNER JOINをLEFT JOINに変えたら意図通りになりますか？」
エンジニアはこの依頼に「即座に答えられる」。
前者は「そもそも何をしたいのか」から確認しなければならないが、後者は純粋な技術的問いだ。
