「このデータ、エンジニアに出してもらわないと分からないんですよ」
この言葉を、何度聞いただろう。
言っているマーケター本人に悪意はない。事実だし、合理的な判断だ。
データはエンジニアが管理するシステムにある。
エンジニアが出してくれれば問題は解決する。なぜそれが問題なのか、と思うかもしれない。
しかしこの「依存の構造」が、マーケターから少しずつ、確実に、重要なものを奪っている。
「頼む」コストを可視化する
エンジニアにデータを頼むとき、何が起きているか。
時間のコスト
依頼を書いて送る。エンジニアのキューに入る。他の仕事が優先される。2日後に返ってくる。
「あ、でもこの集計は期間が違って、こっちの条件も追加してほしくて……」という追加依頼が生まれる。
さらに2日かかる。
認知のコスト
「エンジニアに出してもらったデータ」を見るとき、その数字の意味を正確に理解するためには「どうやって集計されたか」の背景知識が必要だ。
それが自分で書いたSQLなら一目瞭然だが、他者が書いたものは「これは何を条件にしているのか」という解読作業が生まれる。
思考の断絶
「この施策の効果を知りたい」という問いが生まれたとき、自分でSQLを書けば「問い→データ→洞察→次の問い」というサイクルが止まらない。
しかしエンジニアに頼む場合、「問い→依頼→待ち→データ→洞察→（また思いついた問いがある）→依頼→待ち……」という断絶が生まれる。
この断絶が何を奪うか。「問いの流れ」だ。
分析の最も重要な瞬間は「最初の答えを見て、次の問いが生まれる瞬間」だ。
「CVRが下がっている。なぜか？ → 年齢層別に見てみよう → 30代だけ下がっている。なぜか？ → 30代に多いチャネル別に見てみよう → ……」
このサイクルが止まらずに続くとき、本当の洞察が生まれる。しかしエンジニアへの依頼が介在するたびに、このサイクルが「待ち」で中断される。
エンジニアが「困っていること」
エンジニアの立場から見た現実も書いておく。
データエンジニアは「データを出す」仕事をしたいわけではない。
パイプラインを設計したい。データ品質を改善したい。より複雑な問いに答えるアーキテクチャを構築したい。
しかし「ちょっとこのデータ出してほしい」という依頼が毎日何十件も来る。
それぞれは小さな依頼だが、積み重なると「本当にやるべき仕事」ができなくなる。
あるデータエンジニアがこんなことを言っていた。
「マーケターがSQLを覚えてくれたら、本当に助かるんです。私がやるべきは、そのSQLが速く動く環境を整えることで、SELECT文を代わりに書くことじゃない」
「エンジニアに頼む」は、エンジニアを助けているわけでもない。
マーケターがSQLを書けるようになることは、マーケターだけでなくエンジニアの生産性も上げる。これは全員に利益があることだ。
「分かる」と「分かった気になる」の差
もう一つ、「依存」が生む問題がある。
エンジニアに出してもらったデータを見るとき、「分かった気になる」ことがある。
数字が並んでいる。数字には意味がある。その意味を読んで「なるほど」と思う。
しかし「この数字がどうやって作られたか」を正確に理解していない状態での「なるほど」は、砂上の楼閣だ。
自分でSQLを書いてデータを取り出したとき、その数字の「文脈」が自分の中にある。
「このSQLは、2023年1月以降の完了注文だけを対象にしていて、返品を除外していて、1顧客につき1注文としてカウントしている」
これを自分で決めてSQLに書いたなら、数字の意味が完全に分かる。
数字を見て「これは異常値かもしれない」という直感が生まれたとき、すぐに「なぜなら……」を確認できる。
しかし「エンジニアに出してもらった数字」は、その文脈が不透明なことがある。
条件の細部が分からない。だから「この数字は本当に自分が見たいものを表しているか」という疑問を持ちにくい。
自分でデータを取り出すことは、「数字を信頼できる」という確信を生む。
「自立」の副産物│コミュニケーションが変わる
SQLを覚えたマーケターが最も驚くのは「エンジニアとの会話の質が変わる」ことだ。
SQLを知らない状態でのエンジニアとの会話
「先月のキャンペーンの効果を知りたいんですが、売上と新規ユーザー数と……」
SQLを知っている状態でのエンジニアとの会話
「こんなSQLを書いてみたんですが、このJOINの条件がうまく動かなくて。あと、このクエリが重くなる理由が分からなくて教えてもらえますか」
前者は「何を出すか」の合意から始まる長い会話が必要だ。
後者は「どう実装するか」という具体的な技術的相談だ。
この会話の質の変化が、エンジニアとマーケターの関係を変える。
「データを代わりに出してくれる人」という関係から「データをより良く使うために協力する仲間」という関係に変わる。
「完全な自立」を目指す必要はない
最後に、大事なことを言っておく。
「エンジニアに頼むな」という話をしているのではない。
複雑なデータ統合、大規模なパイプライン設計、パフォーマンスの最適化
これらはエンジニアの仕事だし、マーケターが全部できる必要はない。
「自分でできること」と「エンジニアに頼むべきこと」の線引きを正しく引く
これが目標だ。
「日次の集計を見たい」
「このセグメントの顧客数を知りたい」
「このキャンペーンの前後でCVRがどう変わったか確認したい」
これらは自分でできるし、自分でやるべきだ。
「このデータウェアハウスのスキーマを最適化してほしい」
「このクエリが重すぎて実行できないので改善してほしい」
これはエンジニアに頼むべきだ。
SQLを学ぶことは、この線引きを正しい場所に移動させることだ。今、多くのマーケターにとってこの線が「全てエンジニアに頼む」側にある。それを「シンプルなデータ取り出しは自分でやる」という場所に移動させる。
その移動が、見える世界を変える。