pmconf参加レポート（yang & takashi）

今回は、タイミーの「Kaigi Pass」制度を利用して、12/4に開催のされたプロダクトマネージャーカンファレンス（以下、pmconf）に参加してきました。

この制度を通じて、非常に有意義な学びを得ることができましたので、その内容を共有します。

参加セッション

「メルカリのデータ分析AIエージェント『Socrates（ソクラテス）』と、それを支えるデータ整備」

登壇者：株式会社メルカリデータアナリティクスチーム

セッション詳細・学び

1. 背景と課題 (As-is)

メルカリでは専任のデータアナリストのリソースが潤沢ではなく、アナリストがいないチーム（0名のチームも存在）では、PdMが自らが分析を行う必要がありました。

部門を超えたインサイト収集の困難さ: 自分の担当外の領域（例：メルカリ担当がメルペイのデータを見る等）は分析のハードルが高く、工数を要するため、複合的な意思決定が困難でした。
リソースの壁: 「分析キャパシティ」がボトルネックとなり、問いの量と質が制限されていました。

2. 解決策：AIエージェント「Socrates」 (To-be)

自然言語で対話可能な分析エージェントを導入することで、以下の状態を実現しています。

未知の領域にも対応: 「メルペイの預金残高の使い道内訳」のような、ドメイン知識がない領域でも、エージェントがデータを探し出して集計・可視化してくれます。
並列思考: 複数の観点（Parallel Agent）でブレストを行い、仮説出しから検証までを一気通貫で実行します。
問いの量と質の向上: リソース制約を気にせず貪欲に調べられるようになりることで、アウトプットの総量もが直結して向上します。

3. 実現のための土台：Basic Tables

AIが正しくデータを扱える理由として、「AI-Readableなデータ分析基盤」の存在が強調されました。

3層構造: Raw Data Tables → Basic Tables → Analytical Tables/Views という構造を採用。
特徴: 「Basic Tables」は人間とAIの両方が分析しやすいように整理された中間テーブルであり、ここに粘り強く投資したことが勝因です。

4. 組織と運用の工夫

ツールを入れるだけでなく、それを使いこなすための組織づく作りもセットで行われています。

独立した実行組織: 企画・開発・マーケまで完結できる遊軍的な「BI Productチーム」が開発を主導。
使いこなしのルール:
- 気になったらまずエージェントに聞く（依頼する前に相談）。
- 基礎的なSQLと社内DBの理解を持ち、クエリレビューを徹底して品質を担保する。
人を動かすための活用: レポートを蓄積するだけでなく、「隙あらば分析レポートをシュッ」と提示し、ファクトをベースに組織全体を動かす文化をつく作っています。

5. 要件定義プロセスへの応用

分析だけでなく、要件定義のプロセス全体（インプット→処理→アウトプット）でにおいても活用されています。

インプット: ユーザーログ、定性調査、競合調査など。
アウトプット: ユーザーストーリー、機能仕様書、ABテスト設計書など。

これらをAIが処理することで、PdMの業務効率を飛躍的に高めています。

現場視点での気づきと、これからのアクション

今回のセッションを聞いて私たちが何を感じ、現在進めているプロジェクトをどう加速させていくのか。チームとしての「熱量」と「次の一手」をまとめました。

私たちが得た「確信」と「気づき」

■ 「領域横断」こそが、Growthの壁を壊す スライドに映し出された「部門を超えたインサイト収集が困難」という悩みは、正直なところ「これ、今の私たちのことだ」と痛感しました。特にGrowth領域でスピード感を持って仮説検証を回そうとすると、どうしても担当外のデータやドメイン知識の壁にぶつかります。もし「Socrates」のように社内の全データが地続きになり、AIがその文脈までを理解してくれれば、SQLを書く時間を「ユーザーに向き合って思考する時間」に変えられまする。そうしたの未来図に、強い可能性を感じました。

■ 誰もが「迷子」にならずに意思決定できる組織へ 「意思決定の階層を減らす」という思想も、組織が急拡大している今の私たちにとって非常に重要なテーマです。新しくジョインしたメンバーが、複雑なテーブル定義の森で迷子にならず、AIという「相棒」を通じて過去の経緯やデータに即座にアクセスできる。それが実現できれば、オンボーディングのスピードも、自走力も劇的に変わるはずです。

■ 定性データも「資産」として使い倒す 数字（定量データ）だけでなく、商談メモや行動ログといった「定性情報」までAIに読ませるという構想にはワクワクしました。「数字には表れないけれど、現場には落ちているヒント」をAIが拾い上げてくれれば、私たちが生み出す仮説の精度はもっと高まるはず。これを支えるための「徹底したデータ文化」や「BI Productチーム」という体制づくりも含めて、本気で真似していきたいポイントです。

これからやること（Next Actions）

■ 進行中のPoCを、さらに磨き込む 実は現在、私たちも社内で同様のデータ基盤構築に向けた取り組みを、PoC（概念実証）としてすでに始めていますスタートさせています。 「方向性は間違っていなかった」という心強さを感じると同時に、今回のセッションは、そのPoCを成功させるための大きなヒントになりました。

具体的には、以下の動きをすぐに始めます。

「Basic Tables」の思想を、自分たちのPoCへ
- 今回の大きな学びである「Basic Tables（AIと人間、両方が読みやすい中間層）」の構造を、現在私たちが進めているPoCの設計と照らし合わせてみます。
- DRE (Data Reliability Engineering) チームとも連携し、「今の設計でAIが本当にデータを正しく読めるのか？」という視点でからギャップを洗い出し、PoCの設計図をブラッシュアップします。
スモールスタートで「対話」を始める
- 基盤整備と並行して、まずは特定のデータセットに絞った形でも「対話型インターフェース」を試せないか検討します。来週さっそくチームで集まり、具体的なロードマップを引く予定です。

メルカリさんの事例を刺激に、私たちも「未来のデータ分析体験」の実装を一気に進めていきます。