お疲れ様です！ ADWAYS DEEEでエンジニアリングマネージャー（EM）をしている、いとうです。
前回は2人チームで開発をした記事を書きましたが、現在はPdM・デザイナー・エンジニアの3ロールがいるプロダクト開発チームのマネジメントをしています。
最近、チームのPdMやデザイナーにもClaude Codeでデータ分析をしてもらう取り組みを進めていました。 もともとデータを出すのはエンジニアの仕事になっていましたが、それを全ロールでできるようにしてみよう、というものです。 始めてから数か月経ち、今では施策の振り返りが安定して回るようになりました。 今回はその経験について書いてみようと思います。
背景：分析がクエリを書けるメンバー待ちになっていた
これまでのプロダクト開発チームでは、クエリを書けるのはエンジニアと一部のPdMといったわずかなメンバーのみでした。 そのため、施策を分析するには、そのメンバーへクエリの作成を依頼する必要がありました。 このような属人化により、下記のような状況が慢性的に続いていました。
- 結果が早く見たいのに見られない
- あの数値どうなっていたっけ？と思って数値出しを依頼しても、対応が優先されづらい
その結果、分析のリードタイムが長くなるだけでなく、途中で宙に浮いてしまう施策も出ていました。 さらに、定量的なファクトも貯まりづらい状況でした。 感覚としては、5つの施策・プロジェクトのうち3つほどは結果や着地が曖昧なまま、次の関心ごとに移ってしまっていたと思います。
やったこと：Claude Code前提の分析環境をチームに広げた
きっかけ
2026年の春から夏にかけて、プロダクト開発が初めてまたは久しぶりのエンジニアに加え、デザイナー・PdMが新たにチームにジョインしました。 このような状況で、UI変更の施策が増えたり、新たなメンバーへのオンボーディングが必要になったりしました。 また、Claude Codeの活用がチームで進み始めていたことや、データ基盤の刷新が走っていたこと、先行してAIを活用してデータ分析をしていた先駆者がいたことも追い風でした。 そこで、分析環境を横展開しつつ、チームメンバーが気楽にデータ出しをできる環境を作ろうと考えました。 メンバーには先駆者が作っていたプロンプトやスキルなどの環境を配布し、BigQueryの権限を付与しました。
ペアプロ形式での伴走
環境を渡すだけでは実際に使うまでのハードルが高いだろうと思い、1on1のペアプロ形式で伴走しました。 対象は非エンジニアのメンバーで、おおむね2週に1度、手厚い時期はそれ以上の頻度で一緒に手を動かしました。 環境構築からClaude Codeの使い方、分析してレポートを共有するところまでをサポートしています。 また、他のメンバーにも伴走を協力してもらったり、やってみたことを発表してもらったりしました。
苦労したこと
苦労したこと1：プロダクトのドメイン知識やログ設計などの共有と、数値の正しさの保証
自分が出してみたデータと、他の方に出してもらったデータが異なっていることがありました。 例えば、PdMが施策ごとの効果レポートを作ってくれたときのことです。 レポート自体は2か月分のデータでまとまっていたのですが、数値を確認していくと、こちらで出した数値と合わないところが出てきました。 一緒に数値確認をしていくと、PdMの指示を受けてClaude Codeが生成したクエリが、ログの意味を取り違えたまま組まれており、意図と違う数値がレポートに入っていたことが分かりました。
この事象を深掘ってみると、ログ設計についての知識を共有できていないことに起因しているケースが多くありました。 「このログは何を表しているのか」「この施策ではどのログを見るべきか」は、プロダクトのドメイン知識が無いと判断できません。 そこで、プロダクトで普段とっているログや、施策でどのようなログをとるかなど、ドメイン知識やログ設計は適宜伴走しつつメンバーへ共有していきました。 共有の方法は口頭がメインで、FigJamで一緒に図を描いたり、出社日にはホワイトボードで説明したりしながら、その場で疑問を解消していきました。 あわせて、レポートを外に出す前には、数値を一緒に確認するステップを挟むようにしました。
苦労したこと2：想定外の挙動は原因の切り分けと改善を行っていくしかない
実際にメンバーにAIを使ってもらうと、想定していない挙動をすることがあります。 例えば、自分がとある数値出しをした際は5分もかからないものが、特定のメンバーではトークンを使い切ってしまうということがありました。 こちらの事象に関しては、BigQuery MCP（ClaudeからBigQueryを操作するための連携機能）ではなく、bqコマンドを原則使ってもらうことで解決しました。 bqコマンドに寄せたことで、余計な推論や指示を掃除できたと推測しています。 このようなイレギュラーはなぜ起きてしまったかを分析しつつ、地道に改善をしていきました。
実際の効果
効果1：施策から振り返りまでのリードタイムが短くなった
一番大きかったのは、施策を出してから振り返るまでのリードタイムが短くなったことです。 例えば、デザイナーが実装したUI改善の施策は9月上旬にリリースし、約3週間分のデータで効果を検証しました。 9月末には結果がどうなったのかまで、デザイナーからチームへ共有してくれました。 以前であれば、エンジニアにクエリを依頼し、手が空くのを待ってから分析が始まるので、数値が出るまでに2〜3週間かかっていました。 今では見たいと思ったその日のうちに自分で数値を確認できるので、体感では2〜3週間かかっていたものが1日に縮まっています。 ほかの施策でも同じように、リリース後の効果を短いリードタイムで自分たちで確かめられるようになっています。
また、6月に入社したPdMは、入社から約3週間で施策ごとの効果レポートのMVP（最小限の構成）を作り上げました。 プロダクトのデータに触れるのが初めての状態から、自分で数値を出してレポートにするところまでを短期間で進められたのは、データの民主化が進んだからこそだと感じています。
効果2：PdMもデザイナーもフッ軽になった
自分でデータを見られるようになったことで、PdMもデザイナーもフットワークが軽くなりました。 PdMは施策ごとの効果レポートを作り、セールスにも共有しています。 デザイナーは課題仮説をもとに自分で実装し、リリース後の効果検証まで担当しました。 PdMとデザイナーが一緒にデータを見ながら議論する場面も増えています。
今後の展望
始めてから数か月経ち、今では施策を出してから振り返るまで、安定して流れるようになりました。 データを分析しやすくなったからこそ、今後はOKRなどの目標設定でもその数値を活かせるといいなと思っています。 また、この取り組みをさらに他のチームにも横展開していきたいです。
まとめ
今回は、クエリを書けるメンバーに分析が集中していたチームで、PdM・デザイナーでも取り組めるようにした経験をご紹介しました。 課題仮説を出してから効果検証までの期間が縮まり、プロダクト開発が速くなったと感じています。 加えて、データを見たいときに見られるようになったことが、一番大きな成果だと実感しています！
