こんにちは。食べログカンパニー 開発本部 国内メディア開発部 店舗情報チームの高橋です。
本記事では、案件の企画検討フェーズにおけるデータ分析の進め方を、AIコーディングエージェントのDevinを活用して見直した取り組みを紹介します。企画メンバー（PdM）とエンジニアが個別にAIを使う状態から、Devinを介して共同でデータ分析に取り組む進め方へ変えました。その結果、工数は約3人日から約1.6人日へ、リードタイムは2〜3日から1日へ短縮できました。
この変化の出発点にあったのは、企画検討フェーズでよくある進め方への疑問でした。「エンジニアがデータを取得し、企画メンバーが分析する」という分業スタイルです。私たちもそうしていましたが、この進め方には、個人がAIを使って作業を効率化するだけでは解決しない、構造的な課題がありました。
本記事では、その構造的な課題に対して「個人のAI活用」を「共同のAI活用」に変えることでどうアプローチしたのか、その過程で得た学びとあわせてお伝えします。
企画検討フェーズでのデータ分析の進め方
私が所属する店舗情報チームでは、食べログに掲載されている店舗の基本情報（例：位置情報・営業時間など）の網羅性や正確性を向上させる取り組みをしています。案件の企画検討フェーズでは、「その店舗情報にどんな課題があり、どのくらいの改善が見込めるのか」をデータ分析で明らかにする必要があります。
データ分析を進めるには、まずデータベースから必要なデータを取得しなければなりません。たとえば、店舗の基本情報を取得してエリアなどのよく用いる観点で網羅率を集計するのはエンジニアの役割です。企画メンバーはその集計結果をもとに、「どの項目の欠損が多いのか」「特定の条件で絞ると傾向が変わるのか」といった観点で深掘りしていきます。こうした取得・分析にはそれぞれ時間がかかるため、AI導入以前からこの分担が自然と定着していました。
取得と分析のどちらにも時間がかかる以上、この分業は当時の環境では合理的な進め方でした。
個人のAI活用で見えてきた、次に変えるべきポイント
AIの導入後、個人の作業自体は確かに効率化されました。私はAIコーディングエージェントのDevinにデータの取得を任せ、企画メンバーはAIコーディングアシスタントのCursorでデータを加工した上で、分析していました。
しかし、AIの利用に慣れてきた頃にチームで進め方を振り返ったところ、個人の作業は速くなっても、分業という進め方の構造上どうしても残る課題があることに気づきました。ツールを変えても、進め方を変えなければ、チームとしての課題は残り続けるのです。AIの登場によって、この課題に対してもアプローチできる余地が生まれました。
具体的には、以下の2つの課題です。
| 課題を感じる人 | 課題 |
|---|---|
| エンジニア | 認識のズレ
|
| 企画メンバー | 待ち時間
|
分業という進め方自体を変えるために、AIの活用の仕方を変える
待ち時間も認識のズレも、「エンジニアがデータを出し、企画メンバーが分析する」という分業の進め方自体が生み出しているものです。既に個人の作業にはAIを取り入れていたので、そのAIの使い方を「個人の効率化」から「共同の進め方の変革」へ見直すことで、この構造自体を変えられるのではないかと考えました。
とはいえ、AIに高度な判断を任せるような大きな変革ではありません。企画検討フェーズでは「人間が素早く良い意思決定できること」が特に重要です。そこに焦点を絞ったため、AIの使い方は既存のナレッジから素早く実践できる範囲で十分だと考えました。
Devinを「企画会議の参加者」にしてみた
目指した変化
前述の2つの課題を踏まえ、人の動き方として以下の変化を目指しました。
| 対象 | 目指した変化 |
|---|---|
| エンジニア | 「データを出す人」から「一緒に分析する人」に変わること。
|
| 企画メンバー | 条件設計と結果解釈により集中できるようになること。
|
Devinの活用方法
この変化を実現するために、Devinを以下のように活用しました。
食べログではSlack経由でDevinを利用できる仕組みがあり、DevinのSlackスレッドを画面共有しながら通話で進めました。通話しながらDevinへ指示し、返ってきた結果を一緒に見て、次の方針を決めるという流れです。
活用の概要は以下の3点です。
- Devinの役割はデータ取得に絞る： Devinには、指示に基づいてBigQueryのSQLを生成・実行し、集計結果を返してもらいました。取得したデータや議論の内容はGitHub上のMarkdownとして記録しました。（なお、実行するのはエンジニア個人の参照権限の範囲内に限られ、対象データに個人情報は含みません。）
- 処理待ちも議論の時間に充てる： Devinが指示を解釈しSQLを生成・実行・結果を整形するまでの処理待ち（数分〜十数分）の間は、次に見るべきデータの議論やスコープの取捨選択を進めました。たとえば「駐車場の情報も対象に入れよう」といった議論が処理待ちの間に済み、結果が返ってきた時点ですぐ次のアクションに移れました。
- 正確性の判断はエンジニアが担う： たとえば、ある条件の店舗数がほぼ0件と返ってきた際、業務知識から数万件はあるはずだと気づきSQLを確認したところ、Devinが参照したテーブルは特定条件でフィルタ済みのデータしか持っておらず、対象の店舗が含まれていませんでした。正しいテーブルを指示して再集計すると約9.5万件が見つかりました。テーブル構造と業務の両方を知るエンジニアの判断が不可欠でした。
なお、Devinを選んだのはこのプロセスに適していたためであり、同等の機能を持つAIツールであれば代替可能と考えています。選定の理由は以下の2点です。
- エンジニアと企画メンバーが同時にセッションを操作・閲覧できる。
- やりとりがSlack上に残るため、後から経緯を追いやすい。
実際に起きた変化
目指していた人の動き方の変化は、実際に実現できました。
| 対象 | 実際に起きた変化 |
|---|---|
| エンジニア | 企画メンバーと同じ場で分析の方向性を議論する側に移った。
|
| 企画メンバー | データがその場で返ってくるため、条件設計と結果解釈に集中できるようになった。
|
「とりあえずDevinに聞いてみよう」でのつまずき
ただし、最初から理想的な動き方ができたわけではありません。
データがすぐ手に入ると、「とりあえず聞いてみよう」が先行しがちになりました。Devinにあれこれ集計を依頼した結果、数字ばかりが並んで「で、何が課題なのか？」がわからなくなったのです。
この反省から、企画メンバーとエンジニアがまず「何を明らかにしたいか」を共同で設計し、そのうえでデータを取得することをルール化しました。
具体的には、Devinへ指示を出す前に以下の3点を整理するようにしました。
| 整理する項目 | 例 |
|---|---|
| 明らかにしたいこと | 改善対象の店舗にはどんな課題パターンがあり、それぞれどのくらいの割合か？ |
| 定義・条件 | 「課題あり」＝必須項目のうち1つ以上が未入力、または登録済みだが内容が最新でない |
| 期待する結果 | 課題あり・改善可能 / 課題あり・改善不可 / 課題なし / 判断不能 の4分類の件数と割合の一覧表。「改善可能」が多ければ施策の優先度が高いと判断できる |
これらを整理したうえで「何のデータを、どういう定義で、どう分解して取得するか」を一緒に議論し、Devinへの指示に落とし込みます。
企画メンバーとエンジニアが設計に集中してからデータを取得する流れが定着し、結果の妥当性をその場で判断でき、次の深掘りへすぐ進めるようになりました。
やってみてどうなったか
スピードと工数
| Before | After | |
|---|---|---|
| 工数 | 約3人日 | 約1.6人日 |
| リードタイム | 2〜3日 | 1日 |
| 内訳 |
|
|
待ち時間解消によるリードタイム短縮に加え、AIと素早く対話しながら分析を進められたことで工数も短縮できたと考えています。
認識のズレの解消
データの設計から分析まで一緒に行うことで、「何を見たいか」「なぜそのデータが必要か」を共有できました。現在進行中の要件定義・設計の中で、エンジニア側で各要件の背景が説明できる状態になっていると体感しています。定量的な効果測定は今後の課題ですが、少なくとも要件の背景を確認するためのやりとりは明らかに減りました。
個人のAI活用から、共同のAI活用へ
私たちのケースでは、企画メンバーとエンジニアがそれぞれAIを使って作業を効率化しても、待ち時間や認識のズレという構造的な課題は残り続けました。それが、Devinを介して共同でデータ分析に取り組むことで解消されました。
この取り組みを通じて得た学びを整理します。
- AIの導入効果は活用の設計で決まる： ツールの性能だけでなく、「誰が・いつ・どう使うか」が重要。同じDevinでも、個人で非同期に使う場合と、画面共有しながら共同で使う場合とでは得られる成果が大きく異なった。
- 個人の生産性向上とチームの変革は別問題： AIで個人の作業が速くなっても、分業の構造が変わらなければ、チームとしての課題は残る。チームで進め方を振り返る機会を意識的に作ることが、構造的な課題に気づくきっかけになった。
- 人の動き方が変わることで進め方を根本から変えられる： AIに高度な判断を任せなくても、人の役割が変わるだけで進め方は根本から変わる。今回はDevinにデータ取得を任せる形だったが、それによりエンジニアの役割自体が変わった。
- 「何を明らかにしたいか」の設計が先： 「とりあえずAIに聞く」と数字は出るが解釈できない状態に陥る。問い・定義・期待する結果を人間同士で先に設計することが、AIの出力の質を左右する。
今回の取り組みを通じて、私自身の役割も「依頼されたデータを出すエンジニア」から「事業の意思決定に伴走するエンジニア」へと変わりました。なぜこの要件が必要で、事業としてどんな意思決定をしたいのかという、開発前の背景への解像度が格段に上がったと感じています。
AIをどう使うかだけでなく、AIがいることで自分たちの動き方がどう変わるかに目を向けること。それが、チームの連携の質を変える第一歩になるのではないかと思います。
食べログでは、一緒に働く仲間を募集しています。
ご興味のある方は、ぜひ採用情報をチェックしてみてください。
