"SQLは書けません"から始まる データドリブン プロダクトデータアナリスト 合田翔平 2026年4月16日 

2 自己紹介 ● 合田翔平（ごうだしょうへい） ● @shohei_trapi ● kubell ← Unipos ● プロダクトデータアナリスト ● 福島県在住 

事業概要 *1 Nielsen NetView Customized Report 2025年7月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKSを含む44サービスを株式会社kubellにて選定。 *2 2025年12月末時点。 ● 国内最大級のビジネスチャット「Chatwork」を展開 業界のパイオニアであり国内利用者数No.1*1 導入社数は97.3万社*2を突破 ● 圧倒的な顧客基盤とプラットフォームを背景に、チャット経由で業務を請け負いDXを推進する BPaaSを展開 BPaaS (Business Process as a Service) ビジネスチャット「Chatwork」 業務代行 採用 経理・会計 労務 営業事務 AI・SaaSを徹底活用 3 AIエージェント 経理・総務・事務な ど幅広い業務に対応 人事・労務など専門 性の高い業務に対応 

「データ見たい、でもSQL書けない」問題 

5 こんな経験、ありませんか？ ● 施策の意思決定にデータが欲しい → でもSQLは書けない（書けても正しいか不安） ● アナリストに依頼すると数日〜1週間待ち → そのうちに意思決定のタイミングを逃す ● 結果として「勘と経験」で判断してしまう → なんとなく過去の類似事例をベースに決める 

6 kubellのPdMチームでも同じ壁が、、、 ● 多様なバックグラウンドが集まるチーム ● SQL力もプロダクトデータに関するリテラシーもバラバラ ベテラン 元エンジニア 社歴が浅い 自分で分析できる SQL書けるが 分析の切り口が わからない どういうデータが あるかを知らない → もっと手軽にデータ分析ができる環境を提供したい 

何を作ったか 

8 分析AIエージェントで「データに聞ける」環境を構築 ● 自然言語での対話により、誰でもデータ分析が可能 ● 用途別に複数のAIエージェントを構築し、全社的に展開 

9 なぜこのアプローチを選んだか ● 3つの選択肢を検討： ❌ PdMにSQLを学ばせる → 学習コストが高い ❌ アナリストを増やす → 採用リードタイムが長い ✅ ツール側で吸収する → 即時展開可能、精度もコントロール可能 ● 決め手： 用語やテーブルの意味をあらかじめ定義でき、回答精度をコントロールできる 

SQLなしでここまでできた 

11 ケース1【即答型】ふとした疑問をその場で確認 ● 会議中に出た質問への回答もこれまで1週間先だったのがその場で完結 これまで 「この機能の利用率どのくらい？」 いま 「後で調べます」 次の会議で共有 1週間ロス 「この機能の利用率どのくらい？」 「少しお待ちください」 数秒後にその場で共有 データに基づいた議論ができる 

12 ケース2【仮説検証型】施策のターゲット設計をデータで検証 ● 以前ならアナリストに依頼していた分析も自然言語の対話だけで目的達成 ● 分析依頼の工数も浮くので依存コストだけでなく時間的な余裕も生まれる ① 課題 ② 質問 ③ 自動分析 ④ 判断 施策ターゲットの 根拠が欲しい 「このセグメントの切り方に 問題はあるか？」 データの分布から仮説を検証 定量の裏付けを 自身で完結 

13 ケース3【探索型】プロダクト機能の利用実態を深掘り ● 最初から仮説がなかったとしてもAIとの対話から発見にたどり着ける ● ユースケースを想定することで精度をコントロールすることも可能 「この機能、実際どれくらい使われてる？」 月間アクティブ率 → 全体利用数を返答 「デバイス別に分けてみて」 モバイルで利用率が低いことが判明 「解約率との相関を調べて」 モバイル未利用 → 解約率3倍の相関を発見！ 

やってみてわかったこと 

15 ① 導入するなら「最初の成功体験」を設計すべき ● 43%のユーザーが1日で離脱（主な要因：何を聞けばいいか分からない） ● 一方で、最初の数日で手応えを感じた人はその後も自走できていた 「何を聞けばいい？」 「この質問を試してみて」 「お、使える！」 離脱 具体例を渡す 継続利用へ 

16 ② 使い込むほどAIの精度も上がる ● AIの"間違い"を正す場面が生まれ、自然と利用と育成のサイクルが回っていた 利用 フィードバック 改善 精度向上 

現在地点とこれから 

18 現時点での限界と取り組むべき行動 ● 複雑な多段集計、曖昧な問い、整備されていない領域への回答はまだ難しい → 一度作って終わりではなく、継続的な定義の整備が必要 ● とはいえこれらの限界はもはや「SQLが書けるかどうか」の問題ではない → 大事なのはSQLの知識ではなく「何を知りたいか」を言語化すること なぜ解約が増えているか調べて。 解約率が上がり始めたのは機能Xのリリース後と重なっている。 機能Xの利用有無で解約率に差があるか分析して。 売上データを分析して 先月のMRRが前月比-8%だった。解約増なのか新規減なのか ダウングレード増なのかを切り分けて、どのセグメントで何が起きているか教えて。 ユーザーをグループ分けして 企業規模・利用開始からの経過月数・直近の機能利用パターンの3軸で クラスタリングして。その上で各クラスターの解約リスクを比較して。 

まとめ 

20 ● SQLが書けなくても自分でデータに基づいた意思決定ができる ● 分析AIエージェントの導入はオンボーディング設計が大事 ● AIにフィードバックを送ることで精度向上の恩恵が受けられる ● 本当に必要なのはSQLスキルではなく「何を知りたいか」を言語化する力 もっと詳しい話を聞きたい！という方は懇親会などでぜひお話ししましょう！！ まとめ 

カジュアル面談しませんか？ ● プロダクトマネージャー ● プロダクトデータアナリスト ● データエンジニア 大大大募集中です！！！ 

働くをもっと楽しく、創造的に 22