【2週間の爆速開発】食べログChatGPTプラグインPJを率いたPMに聞く、緊急度の高いPJに抜擢される優秀なエンジニアの特徴

2023年5月6日、食べログがChatGPTプラグインの提供を開始し、大きな話題となりました。このプロジェクトは、OpenAI社がChatGPTプラグイン機能を開放した3月23日の翌日にスタートし、約2週間後には実装が完了していたそう。

月間利用者数約9600万人（2023年3月実績） を擁する食べログという大規模プロダクトで、企画・法務・セキュリティなど関係各所との調整から開発まで爆速で完遂した精鋭チームには、どのようなエンジニアが抜擢されていたのでしょうか？　「技術力の高さ」以外の重要なポイントは？　本プロジェクトでPMを務めた2名にお話を聞きました。

• keyboard_arrow_down 選抜チームを結成し、PJ始動→テスト完了まで2週間で完走
• keyboard_arrow_down 選ばれたのは、ビジネスサイドにとって「話が早い人」
• keyboard_arrow_down ビジネスサイドとのすれ違いを防ぐコツは「同じ言葉を使うこと」
• keyboard_arrow_down ビジネスサイドとのコミュニケーションが、「手戻りのない爆速開発」を叶えた

——今回のプロジェクトでは、お2人はどんな役割を担っていたんですか？

羽澤：私たち2人は普段食べログシステム本部のマネージャーを務めています。私は今回のプロジェクトでセキュリティ方面のPMを担当し、情報セキュリティ部門との調整の部分に深く関わっていました。

関戸：自分は2015年から食べログの開発に携わっていて、既存の仕様をよく知っていることもあって、今回のChatGPTプラグインPJでは開発側のPMを担当しました。

——ChatGPTのプラグイン開放からわずか2週間で開発を完了したという驚異的な速さでしたが、どういった開発スケジュールを組まれていたのでしょうか。

関戸：早期リリースを目指して、開発、インフラ構築、テストをすべて最小限の工数でできるように進めていきました。

OpenAIがChatGPTを一般公開した2022年末ごろから動向を追いかけていて、プラグインの発表を受けてすぐに「この形なら利用できそう」と考えました。プラグインが開放されたのが2023年3月23日で、その翌日に開発プロジェクトを始動しました。そして、2週間後の4月7日には開発が完了。動作確認を済ませて審査が通ったのが、リリース日の5月6日というスケジュールでしたね。

羽澤：ChatGPTプラグインについては国内で前例がなかったこともあり、プロジェクト進行にあたり、開発以外の部署とも綿密にコミュニケーションを取りました。

法務関係ではエンジニア主導で法務部と連携し、個人情報の取り扱いや、既存の利用規約の内容と反さないかといった検討を行いました。セキュリティ関係では、今回開発するシステム構造を図式化した上で、情報セキュリティ部門に説明し、脆弱性診断をしました。

リリースまでのスケジュールがかなりタイトでしたが、「このプロジェクトは全社としても最優先である」という共通認識をつくれていたこともあり、滞りなく進められました。

——そもそもなぜ食べログのChatGPTプラグインが必要だと考えたのですか？

関戸：2022年末、ChatGPTの動向を追い始めたころから、ChatGPTはGoogle検索に迫るポテンシャルがあるツールかもしれないと感じていました。今後ユーザーの情報収集の選択肢にChatGPTが入るなら、日本最大のグルメ情報プラットフォームとして何か対応しなくては、とずっと思っていました。

プラグインの開放は、ChatGPTがあらゆるビジネスとユーザーの接点となることを意味します。「食べログ公式」として早期にプラグインを提供することで、食べログが保有している飲食店情報を、ChatGPTを通してより多くのユーザーに届けることができると考えたんです。

羽澤：ChatGPTは学習データが足りないと正しくない情報を出力してしまいます。ただ裏を返せば、こちらから正確な情報を与えられれば、ユーザーのニーズを精度高くアシストすることができる。

食べログには、日本中の飲食店の情報が集まっているといっても過言ではないくらい膨大なデータがあります。これらのデータを活用すれば、「より役に立つ飲食店情報を提供できるプラグイン」をつくることができるのではないかと考えました。

——開発チームはどういったメンバーで構成されたのでしょうか。

関戸：企画、Webエンジニア、機械学習エンジニア、SRE、品質管理のチームから、各チームのリーダーにそれぞれ2名ずつ選抜してもらいました。今回は迅速に開発を進めるために、チームの垣根を超えてメンバーを選抜する特別な体制を組みました。

——エンジニアの選出基準はなんですか？

関戸：このプロジェクトはスピードが命なので、まずは技術力が高く既存機能への理解が深い人。その中でもコミュニケーションコストを最小限に抑えるために何より重視したのは、ビジネスサイドとスムーズに議論ができるかどうかです。

羽澤：例えば「こういうことがしたい」という要求提案に対して、企画側の意図を組んで「それならこうやるといいですよ」「このくらいの期間でできますよ」とすぐに提案できる人ですね。いわゆる「話が早いエンジニア」を選びました。

——「話の早いエンジニア」になるためにはなにが必要ですか？

羽澤：ビジネスサイドと目線を揃え、「ユーザーにどんな価値を提供するのか」を軸に考え、行動することですね。

エンジニアとビジネスサイドが同じ視点を持っていれば、コミュニケーションエラーが起きづらく、開発もスムーズに進みますし、開発の目的とアウトプットがずれないから手戻りも少なくなり、高速なリリースにつながります。

——エンジニアとビジネスサイドの視点を合わせるために、どんなことをしていますか？

関戸：マネージャーとしては「この開発はなぜやるのか」「なぜこのソリューションなのか」といった案件の目的や背景を常にメンバーに伝えるようにしています。

案件の目的や背景は、常に「ユーザーの課題を解決するため」にあります。ユーザーの存在を意識し、目的や背景に立ち返りながら開発することが当たり前になれば、コミュニケーションのとり方も、コードの見方も、案件の捉え方も変わっていきます。

羽澤：また、案件の進行中や終わった後には、エンジニアとビジネスサイドが一緒に、ユーザーの課題、案件の目的、実際のアウトプットなどを振り返っています。

よくあるのは、つくっているうちについつい「どう作るか」の会話に集中してしまい、当初の目的からずれていってしまう、というパターンですね。振り返りの中で、案件の目的とメンバー自身の考え方やアウトプットのずれを正しく認識することが、案件の途中で軌道修正して手戻りを防いだり、次の案件に取り組むための教訓につながっています。

——ビジネスサイドとのコミュニケーションスキルをすぐに身につけるのは難しそうな気もしますが、どんな取り組みをしていますか？

関戸：そうですね。食べログ全体はクロスファンクション型組織（部署を横断して経験や手法などを共有できる組織）を目指しているため、エンジニアと非エンジニアのコミュニケーション機会自体は多いと思います。

最初は不慣れだったエンジニアも、だんだんとビジネスサイドとのコミュニケーションに慣れていく場合が多いんですが、中には苦戦する人もいますね。

羽澤：ビジネスサイドとエンジニアでは、同じ言葉でも別の使い方をすることが多く、その違いや合わせ方がなかなかつかめないんですよね。まさにこの間「非エンジニアとのコミュニケーション」というテーマで社内勉強会を行いました。

そのとき解決策として話したのは「ビジネスサイドと同じ言葉を使う」こと。

例えば、サポートからきた「口コミ投稿でエラーが出た」という問い合わせに対して、エンジニアが「データではこうなってます」といきなり答えてしまうんです。

エンジニアにとっての「データ」は、サポートにとっての「エラーが出ている原因」にあたるものを指しますが、いきなり「データ」と言ってしまってはサポート側も「データって？」と困ってしまいます。言いたいことを伝えるためには、同じ言葉を使って説明することが大切なんです。

この場合だと「データ」という言葉は使わず、サポートから出た「投稿」「エラー」という言葉を使い、「投稿が○○で△△だから」などですね。

言葉を合わせることを意識すると、お互いの伝えたいことがうまく伝わるようになり、少しずつコミュニケーションがとれるようになっていきます。

——ほかにも、ビジネスサイドとのコミュニケーションにおいて大切なことはありますか？

関戸：開発の進捗や詳細に関してビジネスサイドからの質問を待つのではなく、コミュニケーションの機会を積極的につくっていくエンジニアの方が成長が早く、プロジェクトの進捗も良いように思います。

エンジニアは、プロダクトや機能をつくることに関して上流から下流まで知り尽くしている立場です。ビジネスサイドには見えづらくなりがちな「具体的にどうやってつくるのか」を、エンジニアは身をもって経験している立場ですから、つくる上で必要な観点や構造を伝えてお互いの認識を合わせたほうが、プロジェクトは円滑に進みます。

それに、伝える過程で「前提知識や経験のない相手に理解してもらえるように言語化、説明するスキル」が鍛えられますから、コミュニケーション力の底上げにもつながります。

羽澤：ビジネスサイドと円滑にコミュニケーションをとれると、より管掌領域が広い役割にキャリアアップする際にも大きな財産になりますよね。プロダクトの設計段階から携わるPMや、開発組織のアウトプットを最大化するEMなど、責任範囲が広ければ、ビジネスサイドとやりとりする機会も増えますから。

——改めて、今回のような緊急度の高いプロジェクトを高速に完了できた秘訣を教えてください。

関戸：「ユーザー視点」をひとつの共通言語として、ビジネスサイドと齟齬なくコミュニケーションをとることで、プロジェクトの目的とズレずにアウトプットを出せたからだと思っています。

機能開発を担当したエンジニアは2名でしたが、自主的に関係各所とコミュニケーションを取りながら進めていってくれたので、安心して任せられました。

結果としてプロジェクト発足当初の目的を果たせましたし、ユーザーの皆さんにも、「ChatGPTで食べログを使う」という新しい体験をお届けできたんじゃないかと思っています。

羽澤：特に今回のプロジェクトのような短期決戦では「開発の手戻りがないこと」がすごく重要ですし、それが実現できたのは組織としても大きな収穫でしたね。

とはいえ、今回のように重要かつ緊急度の高いプロジェクトに自信をもってアサインできるエンジニアは、まだ組織内の一部です。極端ですが、メンバー全員がそういったエンジニアになれれば、食べログをより高速に改善し、今よりもっとユーザーに役立つ便利なプロダクトに進化させることができるんじゃないかと思っています。これからはその領域を目指していきたいですね。

取材：石川 香苗子
文：中島 佑馬
撮影：曾川 拓哉