食べログのエンジニアが、コロナ禍で向き合った課題。テイクアウト、感染症対策情報、Go To Eat…求められた即対応

※2021年4月15日に開催されたエンジニアHubウェビナー「食べログエンジニアに聞く！大規模サービスの裏側エピソードを限定公開」より、全文書き起こしレポートをお届けします。

• 食べログは、外食におけるプラットフォーム
• テイクアウト、感染症対策情報、Go To Eat…求められたコロナ禍での即対応
• 「Go To Eatキャンペーン」、プロジェクト期間は1ヶ月。責務分けにこだわった概念図が即対応を可能にした
• 「ユーザーに価値を感じていただくための改善」に、終わりはない

食べログは、外食におけるプラットフォーム

「食べログ」が成長する中で、課題解決に向けて取り組んできたことをお話したいと思います

まず私の経歴を簡単に紹介させていただきます。2011年にSIerに新卒で入社しました。SIerで働く中で、「事業をまわしている感」に憧れを抱くようになり、2015年に自社サービスを事業会社として展開するカカクコムに転職をしました。

カカクコムでは、最初に食べログのレストラン検索チームに配属されました。主に、ユーザーが求めるレストランを、いかに正確かつスピーディーに検索できるようにするかを考えるチームです。

当時（2015年頃）の食べログは、まさに成長段階で、事業や組織も今に比べると小規模でしたし、各チームが扱う領域も専門性が高かったです。ディレクターとも密に会話し、どんな機能を開発すればユーザーに価値を感じてもらえるか、日々議論を重ねながら考えていく、といった感じでした。今はシステムの規模が大きく、扱う領域や関わる人も多い状況ですが、組織体制を工夫して、チームの専門性を高めたり、職種間の関わりを密にすることを実現しています。

食べログは「失敗しないお店選び」をコンセプトとしており、ネットでお店探しをする際に、起こりがちな「想像とは違うお店だった」といった失敗をなくすために、ユーザーのリアルな口コミと共に、全国各地のレストラン情報を掲載しています。

また「ユーザーに向けてレストランや口コミ情報を提供するサービス」といったイメージがあるかもしれませんが、外食におけるプラットフォームとして飲食店の皆様も「集客支援サービス」を提供しています。

もしかすると「食べログのような成熟したサービスで、これ以上変えるところはあるの？」と疑問に思う方もいるかもしれませんが、まだまだ発展途上であり、変えるべきところや課題はたくさんあります。

本日は、食べログがこれまでに向き合ってきた課題と、解決のために日々チャレンジしていることをお伝えさせていただきます。

テイクアウト、感染症対策情報、Go To Eat…求められたコロナ禍での即対応

「コロナ禍における状況変化への対応」というテーマでお話しをします。

食べログの事業、組織規模がまさに拡大している最中の2020年4月に、新型コロナウイルスによる緊急事態宣言が発令されました。

外出自粛が始まったことで、食べログを利用いただいているユーザーの外食機会が減るとともに、テイクアウト、レストランの感染症対策情報の掲載、Go To Eatキャンペーンなど、新たなニーズが次々と発生。急激な変化に対し、即対応が求められる状況でした。

同時に食べログは急成長してきたサービス。事業や組織規模も大きく、さまざまな技術的・組織的な課題を抱えていました。

技術的な課題としては、システム規模が大きく、改修による影響範囲が広いことです。影響範囲の調査を見誤ると、一部を改修しただけでも、意図しない別の箇所でエラーが発生してしまうことが想定されます。

また、組織的な課題としては、規模が大きくなればなるほど関係チームが多くなり、認識の相違が発生しやすいことです。その結果、無駄なコミュニケーションに時間を費やしてしまったり、ミスが起こりやすい状況にありました。

こちらは食べログの「システム規模」を表す数字です。

リポジトリ数は500以上、コードベースは30万ファイル以上、アプリケーションは約25個も存在し、一人では到底把握しきれない巨大なシステムです。

特に25個もアプリケーションがあるというと、それだけで大きなシステムと感じられると思いますが、実はまだまだ一つが大きな状態。今後さらにマイクロサービス化などを行い、システム改修時の影響範囲を限定する工夫をしていこうと思っています。

次に、食べログ事業の「組織規模」を示す参考として、食べログのシステム領域の区分を記載します。

食べログの事業は大きく「ユーザー領域」と「飲食店領域」に区分されており、それぞれの領域の中でさらに複数のシステムに分かれています。

ユーザー領域には、サービスの2大要素である「レストラン情報掲載、検索」や「ユーザー様情報管理（口コミやポイントなど）」のシステムがあります。

・レストラン情報掲載・検索…レストランを検索したり、詳細情報を閲覧できるシステム。

・ユーザー情報管理…口コミの検索や詳細情報、また口コミを投稿するレビュアーの情報。

ポイント利用など、さまざまなサービスを提供する上での、ユーザーアカウント管理システム。

一方で、飲食店領域には、飲食店オーナー様がレストラン情報を入力する「管理画面」や、ネット予約のための「在庫管理」、支払い管理のための「販売管理」などがあります。

特にコロナ禍では、これらの領域を横断し、システムをスピーディーに開発する必要があったため、普段以上に難易度が高い状況でした。これらの課題をどのように解決したのか、次のパートでお話をさせていただきます。

「Go To Eatキャンペーン」、プロジェクト期間は1ヶ月。責務分けにこだわった概念図が即対応を可能にした

「Go To Eatキャンペーン」への対応は、影響範囲が大きかったもののひとつです。

食べログがGo To Eatキャンペーンの受託事業者になったのが2020年8月25日、開始日は10月1日でした。プロジェクト期間が1か月程度しかなかったため、無駄な時間の消費やミスを避けるために、システム概念図を作成しました。

概念図をもとにチーム間の責務分けを行なうことで、「Go To Eatキャンペーン」の改修による食べログメインシステムへの影響を最小限にするためのポイントなどについて、共通認識を持ちながら開発を進めることができました。

開発をスピーディーに進めるにあたり、概念図の作成には各システム領域への深い理解が大切だと考え、必要に応じて各システムのソースコードを確認しました。また、「Go To Eatキャンペーン」を構成する概念の把握も必要だと考え実施要項を熟読しました。

また、責務分けにもこだわって作成しました。

具体的には、各システム領域固有の生データを他のシステムが参照していないか、そのシステムがするべきでない業務履行をしていないか、という点が挙げられます。

責務分けが曖昧だと各システムで同じことを実現し、無駄な時間の消費につながってしまいます。また、同じことが実現できたとしても、微妙に仕様が異なっていればミスにつながってしまいます。

さらに、責務分けができていない場合、そのシステムを扱う担当者はより広範囲な知識を求められ、目の前の実現すべきことに集中できないことや知識不足による時間の消費、ミスを招く可能性があります。

責務分けこだわり、概念図を作成したからこそ、Go To Eatキャンペーンの開発をスムーズに進めることができ、ユーザーが求める価値に即対応できたと考えます。

「ユーザーに価値を感じていただくための改善」に、終わりはない

「Go To Eatキャンペーン」の影響により、多くのネット予約が利用され、様々な開発ケースが体験できました。そして同時に課題も見つかりました。

ネット予約を通し、ユーザーがレストランに対して求めている食体験をちゃんと提供できているか。またネット予約で得られるポイントなどのメリットについて、更なる体験の向上を目指した施策ができないかなどです。これらの課題に対するプロジェクトも「Go To Eatキャンペーン」期間中に立ち上がり、終了後も続きました。

直近では、ネット予約によるポイント付与を、翌月から数日後に短縮する改修を実施しました。ネット予約のメリットをより感じていただけるようになったと思います。

「ユーザーに価値を感じていただくための改善」に終わりはないので、フィードバックをもらいながら、さらにより良いサービスにしていければと考えています。