「ユーザーインタビューは得意だけれど、ログ分析やSQLは苦手かも…」
そう感じているプロダクトマネージャーの方は一定数いるのではないでしょうか？
実は僕自身もSQL書くことを避けてきた派でした。しかし、いざ自分でログを引いてみると、インタビューで得た知見がさらに深まり、シャープな課題設定と説得力あるソリューション提案ができるようになりました。
本記事では、僕の経験などを元に「なぜユーザーインタビューが得意な人こそSQLをゴリゴリに書くべきなのか」を解説します。
ユーザーインタビューだけでは見えない“ログの世界”
ユーザーインタビューは、プロダクトマネージャーにとって“生々しい声”を拾える最強の武器だと僕は思っています。実際、僕は博報堂時代から数えて600名超のインタビューを行ってきました。
ただ、インタビューの強みは「あえて偏った事例や深いエピソード」を掘り下げる点にあります。一方で、大規模ユーザーの平均的な行動、あるいは意外なセグメントの動向を知るにはログなどの定量分析が必須になります。
定性（インタビュー）と定量（ログ）の両方を見られると、課題の優先度や打ち手のインパクトをより正確に把握できるのです。まさに「ユーザーインタビューだけでは分からない“ログの世界”」を補完するイメージになります。
僕のバックグラウンド：データ分析の入り口はExcelから
僕はもともと博報堂でマーケターをしていました。当時はユーザーインタビューを主軸に据えつつ、アンケートのローデータをExcelで分析してレポートを作っていました。
Excelベースの集計でも「何を切り口にするか」「どう解釈するか」という筋の良い発想は身につきました。でも、膨大なログを扱う段階になると、Excelだけではどうにもなりませんし、そもそもログデータを分析する場合は誰かにログデータをExcel形式に落としてもらう必要があります。それでもしばらくは「データ抽出は専門家に依頼すればOK」というスタンスだったんです。
その後、プロダクトマネージャーを始めてからも、ユーザーインタビューは積極的に行っていました（合計600名超は話しました）。しかし、徐々に「もっと細かい行動ログを自分で引きたい」と思うシーンが増えていきました。インタビューの答えが“本当なのか”を自分でささっと検証したい場面に直面する機会が増えたのです。
なぜSQLを書かなかったのか？避け続けた理由
そもそも、僕はなぜSQLを書くのを避けていたのか？主な理由は3つあります。
- 忙しい：PdMやマーケ業務が山積み
- 自信がなかった：文系出身で、プログラミングやDBに詳しくないことに引け目を感じていた
- 人に依頼すればいい：SQLはエンジニアやデータアナリストにやってもらえばいい、と割り切っていた（実際に依頼できる環境もあった）
この3つが組み合わさると、ますますSQLに手を出さなくなります。特に「人に任せればいい」という発想は楽ではあるものの、自分の中で仮説検証が柔軟に回せないというデメリットが目立ち始めました。「もし自分でログを引けたら、もっと早くユーザーインタビューの結果を裏付けられるのに」と感じる場面が増えたのです。
SQLを本格的に書き始めたきっかけ・学びのプロセス
いよいよSQLから本格的にやろうと思ったのはPdMをやり始めてからまあまあ経ってからで、リクルートに転職してからです。
リクルートはどのサービスでもログデータが莫大になるので、PdMがクイックにSQLでデータをみる文化なんですよね。基礎分析からPRDのファクト補強（検証）、ABテストでの検証などなどあらゆる場面でSQLでのログ分析が登場します。
そこで、「もう自分もやるしかない」と思い立ったんです。結果的に、LLMに質問しながら書いたり、UdemyのSQL講座を夜な夜な進めたりして一気に学習を進めました。テーブル構造を理解するために、先輩が書いたクエリを参考にしたり、意味を聞いたりして吸収するという地道な作業を繰り返したんです。
- LLMに質問：「このクエリのエラーはどう直せばいい？」などを即座に確認できる
- Udemy講座：セクションごとに演習があるため「手を動かす」勉強になる
- 過去クエリをパクる：チームで共有されているクエリを読み解き、テーブルの構造を把握
こうして、最初はコピペから入る形で知識を蓄積し、少しずつ自分オリジナルのクエリを書けるようになったのです。
ユーザーインタビュー×SQL分析のシナジー
SQLを使ってログを自分で引き出せるようになると、ユーザーインタビューとの相乗効果は想像以上に大きく、具体的には3つのシナジーがあります。
1 / 課題設定がシャープになる
ユーザーインタビューの結果は「気持ち」や「背景」を知るには最適ですが、定性的ゆえに解釈が人によってぶれがちです。そこにSQLでのログ分析を組み合わせると、
- 「実際にユーザーは何％がその操作をしているか」
- 「離脱率が高い画面はどこか」
などの事実が即座に得られます。
「ユーザーは声ではこう言っているけれど、ログでは実は別のアクションを取っている」という発見が何度もありました。すると自然に「なぜズレているのか？」という課題設定が生まれて、インタビューの指針もクリアになったのです。
2 / データ解釈の速さはインタビューの“記憶”が鍵
SQLを使って定量データを見ていると、よく「この数値はどういう意味なんだ？」と立ち止まることがあります。ここでインタビュー経験が豊富だと、ユーザーの行動背景や心理的な動きが頭の中に残っているため、その数字の理由づけが一瞬でできる場合が多いです。
たとえばUIの煩雑さを指摘する声が多かった機能をログで見たとき、「想定よりステップが多いせいで途中離脱するユーザーがX％いるんだな」と直感的に理解できる。これは、ユーザーインタビューの“生っぽい”感覚と、ログの客観的な数字を結びつけられる強みです。
3/ ソリューション提案の説得力が爆増
「こういう施策を入れたい」と提案する際に、インタビュー由来のエピソードだけでなく、定量データを裏付けとして組み合わせられると説得力が一気に増します。
ABテストの結果を見ながら「この改善でコンバージョン率が2.5%→3.1%に伸びた背景は、インタビューしたユーザーが『ボタン配置が分かりにくい』と感じていたことと直結しています」という話ができれば、チームや上層部の納得度が全然違います。
ABテストの設計や解釈の仕方は『A/Bテスト実践ガイド』の記事でも深堀りしています。
“自分で分析できる”がもたらす組織へのインパクト
ここからはもう少し組織的な観点に踏み込みます。「SQLを書けるようになる」メリットは、個人のスキルアップを超えて組織全体に波及していきます。
企画力・検証力の高速化
データアナリストやエンジニアに依頼する流れだと、「クエリ依頼→数日後にレポートが届く→さらに疑問点があって再依頼…」となりがちです（あとは、そもそもアナリストがいるチームでしか活躍できなくなります）。
自分で書けると、そのサイクルを自分の中でぐるぐる回せます。すぐにクエリを修正したり追加で集計したりして、仮説検証を1日で何回も実施できます。これなら企画のブラッシュアップに大きく貢献できますよね。
開発チームとのコミュニケーションが円滑に
テーブル構造やスキーマ設計をある程度理解すると、開発チームとの会話がスムーズになります。
「このテーブルにはユーザーIDと操作ログが紐づいていて、イベント名とタイムスタンプがカラムにある」というレベルの知識があれば、「次のリリースではどのタイミングでログを記録すべきか」なども自分から提案できます。結果として、より実践的なログ設計が可能になります。
依頼のやり取りが減り、時間とコストを節約
頼むたびに別の人の工数がかかる状態だと、分析のハードルが上がり、「まあそこまでやらなくていいか」という結論に流れがちです。
自分でSQLをゴリゴリ書けるようになると、そのハードルが一気に下がります。結果として、新しい施策をすぐ検証できるようになり、チームも「データ活用に積極的」な空気に変わっていきます。
これからの展望：より高度な分析・機械学習へのステップアップ
僕は今後、レコメンドシステムや検索周りの機械学習の理解を深めたいと考えています。例えば、ユーザーごとに最適な求人やコンテンツをレコメンドする機能を作るとき、ログの分布やユーザー属性を深く読み解く能力が欠かせません。
さらに、インタビューや質的データ分析で見えた潜在ニーズを、機械学習のアルゴリズムやモデルに落とし込む場面も増えていくはずです。このように、SQLをベースにログを理解する力があれば、より高度な分析に発展させやすくなります。
ユーザーインタビューと機械学習を掛け合わせる未来はとても面白いと感じています。「このユーザーはなぜこのUIで戸惑うのか」などの定性情報を、自然言語処理や行動分析に落とし込んで検証すれば、さらに粒度の高い仮説設定が可能になります。
インタビュースキルとSQLスキルが合わさることで得られる世界
ここまで、ユーザーインタビューとSQLのログ分析を組み合わせることで得られるメリットを、僕の実体験を通して紹介してきました。
インタビューでユーザーの深層心理や課題の根っこを知り、SQLで多くのユーザーにおける実際の行動データを裏付けとして押さえる。この2つが合わさると、次のような効果が期待できます。
- 課題設定の精度が上がる
- 「実際はこう行動している」という事実を使い、説得力が向上する
- チーム内コミュニケーションが高速化する
- 機械学習やレコメンド分野への橋渡しにもなる
ユーザーインタビューが得意な方ほど、SQLと結びつけることで“武器”が倍増すると僕は感じます。もし「SQLはハードルが高い」と敬遠しているなら、LLMなどのサポートを借りながら少しずつ書いてみてください。
「ログとインタビューの両輪で走るPM」になれたとき、チームが頼れる存在に変わるはずです。
今日から実践できるアクション
- 1. クエリ例を読む＋LLMに聞く
チームで共有されているSQLクエリをまず開いてみて、分からない部分はLLMに質問してみると良いです。コピペから始めるのは恥ずかしくありません。 - 2. 小さなテーブルから練習する
いきなり巨大なログテーブルに挑むのではなく、ユーザーマスタやセッション数など、シンプルな構造からスタートすると入りやすいです。 - 3. 簡単なABテスト結果を自分で引く
既に実施されたABテストのデータを抽出し、分析してみてください。A/Bテスト実践ガイドも参考になります。 - 4. ユーザーインタビューと対比する
「インタビューではこう言っていたけれど、ログではどうか？」を常にセットで見て、仮説検証の感覚を養うのがおすすめです。
Q&A
- Q1. 文系出身でプログラミング経験ゼロでも大丈夫でしょうか？
- 全然問題ありません。SQLは文法が限られていて、基本的なSELECT文やWHERE句など覚えることは意外とシンプルです。LLMでエラー解消のヒントをもらいながら進めれば、文系でも十分書けるようになります。
- Q2. インタビューとログを組み合わせる工数が心配です。
- 最初は慣れないので時間がかかるかもしれません。しかし、自分で引けるようになれば、依頼→待ち時間のサイクルがなくなるので、結果的に大幅な時短につながります。小さく試してみてください。
- Q3. 高度な機械学習やデータサイエンスまで学ぶ必要はありますか？
- 必須ではありません。ですが、SQLを通じてデータ構造を理解できると、後々の機械学習理解がスムーズになります。まずはSQL×インタビューで成果が出る領域を攻めるだけでも十分なメリットがあります。
参考情報
- Udemyの人気講座「The Complete SQL Bootcamp」等：基本文法から学習できる
- Google BigQuery公式ドキュメント：クラウド環境でのSQL活用例あり
- Periscope Data（現Sisense）：BIツールを使ったSQL分析の事例紹介
- Martin Fowler著『Refactoring Databases』：DB構造を理解する基本
引用・転載の際は帰属リンクをお願いします。
コメント