データ分析の仕事を始めた頃、私はSQLの勉強ばかりしていました。
INNER JOIN、LEFT JOIN、WITH句、ウィンドウ関数。
新しい書き方を覚えるたびに、
「もっと複雑なSQLが書けるようになれば価値を出せるはずだ」
と思っていました。
しかし実際に複数の分析案件に携わる中で気付いたことがあります。
データ分析案件で本当に重要なのは、SQLを書く力だけではありません。
むしろ、それ以上に重要なのがヒアリング力でした。
「売上を見たいんです」
データ分析の依頼でよくあるのが、このような相談です。
売上を見たいんです。
一見するとシンプルな依頼です。
しかし、実際にはここから確認すべきことがたくさんあります。
例えば、
- 受注ベースですか？
- 出荷ベースですか？
- 請求ベースですか？
- 税込ですか？税抜ですか？
- キャンセルは含みますか？
- 返品は含みますか？
同じ「売上」という言葉でも、人によって想定している定義が異なることは珍しくありません。
ここを確認せずに分析を始めると、SQLは正しくても結果は間違ったものになります。
SQLは正しくても、レポートは間違う
例えば、売上金額を集計するSQLを書いたとします。
SELECT
SUM(amount) AS sales
FROM sales;
構文としては正しいSQLです。
しかし、集計対象にキャンセルデータが含まれていたらどうでしょうか。
あるいは、依頼者が見たかったのは「受注金額」ではなく「出荷金額」だったらどうでしょうか。
SQLは正しく動いています。
それでも、依頼者にとっては間違った数字になります。
技術的には100点でも、業務的には0点になってしまうのです。
お客様自身も答えを持っていないことがある
分析案件で面白いのは、依頼者自身も本当に欲しい情報を整理できていないことがある点です。
例えば、
売上を見たい
という依頼があったとします。
そこで、
「なぜ売上を見たいのでしょうか？」
と質問すると、
最近広告費を増やしたので、その効果を確認したい
という回答が返ってくることがあります。
この場合、本当に知りたいのは売上そのものではありません。
- 新規顧客数
- 顧客獲得単価（CPA）
- コンバージョン率
- 広告経由売上
といった指標の方が重要かもしれません。
最初の依頼だけを聞いてダッシュボードを作ると、本当に必要だった情報を見落としてしまいます。
良い分析者は翻訳家
私は、データ分析者は翻訳家に近い仕事だと思っています。
依頼者の言葉は、多くの場合とても曖昧です。
例えば、
最近売上が悪い気がする
という相談があったとします。
ここから、
- いつから悪いのか
- どの商品なのか
- どの顧客層なのか
- 何と比較して悪いのか
- どんな意思決定をしたいのか
を整理していく必要があります。
そして、その曖昧な課題をデータで検証可能な形に変換する。
これが分析者の役割です。
振り返ると、一番時間を使っていたのはSQLではなかった
これまで携わった案件を振り返ると、実はSQLを書いていた時間よりも、
- 要件整理
- KPI設計
- 顧客との定例
- 認識合わせ
- 分析結果の説明
に費やしていた時間の方が長かったように思います。
もちろんSQLは重要です。
しかし、SQLだけでは課題は解決できません。
どんなに高度な分析をしても、そもそも課題設定が間違っていれば意味がないからです。
SQLは後から覚えられる
近年は生成AIの発達により、SQLを書くハードルはさらに下がっています。
実際、簡単な集計やクエリ作成であれば、AIに相談しながら進めることも可能です。
一方で、
- 相手が何に困っているのかを理解する力
- 曖昧な要望を整理する力
- 関係者の認識を揃える力
は、簡単には代替できません。
データ分析の価値は、クエリを書くことそのものではなく、意思決定を支援することにあります。
まとめ
データ分析案件で成果を出すために必要なのは、難しいSQLを書く力だけではありません。
むしろ重要なのは、
「相手が本当に知りたいことは何か」
を引き出す力です。
私自身、分析の仕事を始めた頃はSQLこそが最重要スキルだと思っていました。
しかし実際の現場で評価されたのは、技術力だけではなく、相手の課題を整理し、適切な指標へ落とし込む力でした。
SQLを書く前に、まず話を聞く。
遠回りに見えて、実はそれが最も重要な分析プロセスなのかもしれません。