よくある誤解がある。
「SQLを覚えれば、答えが分かる」という期待だ。
違う。SQLはデータを取り出す道具だ。
しかしデータは「答え」を持っていない。
データは「問い」に答えるだけだ。
「売上が下がっている」というデータがある。それは「何が起きているか」という事実だ。
しかし「なぜ下がっているか」「どうすれば上がるか」
これらの「答え」はデータの中にない。それらを問い、解釈し、判断するのは人間の仕事だ。
道具を持つことと、道具を使いこなすことは別だ。SQLを書けることと、SQLで深い洞察を得られることは別だ。
「データを取り出せること」と「問いを立てられること」
データ分析における本当の価値は「問いを立てる」能力だ。
良い問いとは何か。「売上が下がっている。なぜか？」は問いではなく、「もっと詳しく見たい」という願望だ。
良い問いはこうだ
「先月の売上低下は、新規顧客の減少によるものか、既存顧客の購買頻度の低下によるものか、それとも客単価の変化によるものか」
これは検証可能な仮説を含んだ問いだ。
この問いがあれば、SQLは「何を集計するか」が明確になる。
問い①：新規顧客数は前月比でどう変わったか？ → 初回購買日が当月の顧客数を月別に集計する問い②：既存顧客の購買頻度はどう変わったか？ → リピート率・購買間隔の変化を計算する問い③：客単価はどう変わったか？ → 月別の平均注文金額を集計する
この3つの問いに答えることで、「売上低下の原因」が分解される。そして分解されれば、「どこに手を打つべきか」が見えてくる。
「なぜ？」を5回問う習慣
トヨタ生産方式で有名な「なぜを5回問う」という考え方がある。
機械が止まった。なぜ？ →
過負荷になったから。なぜ過負荷に？ →
潤滑が足りなかったから。なぜ潤滑が足りない？ →
ポンプが正常に動いていないから。なぜポンプが？ →
軸が摩耗しているから。なぜ摩耗？ →
フィルターがなく切粉が混入しているから。
「機械が止まった」という事象から「フィルターがないこと」という根本原因まで、「なぜ？」を繰り返すことで到達できる。
データ分析でも同じだ。「CVRが下がっている」で止まるのではなく、なぜなぜを繰り返す。
CVRが下がっている。なぜ？ → 特定のランディングページのCVRが特に低い。なぜ？ → そのページへの流入がモバイルに偏っている。なぜ低いのか？ → モバイルでの表示速度が著しく遅い。なぜ？ → 高解像度画像が最適化されていない。
この「なぜの連鎖」を追いかけるためには、毎回「次の問い」に対応したSQLを書く必要がある。
しかし問いが明確であれば、SQLはシンプルになる。
複雑なSQLは、多くの場合「問いが曖昧」の証拠だ。
問いが明確なSQLは、しばしばシンプルで読みやすい。
「仮説なき分析」の罠
現場でよく見る失敗パターンがある。
「とりあえずデータを全部出して、何か分かれば良い」というアプローチだ。
これを「探索的分析」と呼ぶことがある。確かに、仮説なしにデータを見て偶然の発見があることもある。
しかし多くの場合「とりあえず全部出す」は「何も分からない」で終わる。
データは広大だ。どんな切り口でも見られる。
年代別・チャネル別・商品カテゴリ別・購買頻度別、無数の分け方がある。
「何か分かれば良い」という心持ちでは、「何か」が何なのかが分からないまま、数字の海で溺れる。
仮説があるから、データが意味を持つ。
「30代女性の購買単価が最近上がっているように感じる。なぜだろう」という仮説があるから、「30代女性の月別平均購買単価の推移」というSQLに意味が生まれる。
仮説とは「間違っているかもしれないが、検証する価値がある思い込み」だ。マーケターの経験・直感・現場感覚、これらが仮説の材料になる。そして仮説があれば、SQLは「仮説を検証する道具」として使える。
問いの「質」を上げるための3つの問いかけ
良い問いを立てるために、習慣的に自分に問いかける3つの問いを紹介する。
①「それで何をするつもりか？」
データを取り出す前に「このデータで何を意思決定するのか」を問う。
答えられないなら、そのデータを今取り出す必要はないかもしれない。
②「それは測れるか？」
問いを立てたとき、「データで検証できる形になっているか」を確認する。
「顧客が不満を感じているか」は直接測れないが、「返品率・カスタマーサポートへの問い合わせ件数・再購買率の変化」は測れる。
測れる問いに変換することがSQLへの橋渡しだ。
③「比較対象はあるか？」
「今月のCVRは1.2%だ」という数字は、それ単体では意味が薄い。
「先月は1.5%だった」「競合の業界平均は0.9%だ」「昨年同月は1.1%だった」
比較対象があることで数字は意味を持つ。問いを立てるとき、常に「何と比べるか」を考える。
「問いの文化」を組織に作る
個人がSQLを学ぶことも重要だが、より大きなインパクトは「問いを問いやすい組織文化を作ること」だ。
「このデータを見せてください」という発言が増えている組織は、健全だ。
「感触ではこうだ」「おそらくこうだろう」という発言を「データで確認しよう」に変換する習慣が根付いている。
この文化を作るために、リーダーができることは一つだ。
自分でデータを見て、会議に「数字」を持ち込む。
「私が昨日SQLで確認したら、こういう数字だった」というリーダーの発言は、チーム全体に「この会議では数字が必要だ」というメッセージを送る。リーダーがデータを見る姿勢を見せることで、チームに「問いを持つ文化」が育つ。
SQLは個人の道具だが、「問いを立てる習慣」は組織の文化だ。