食べログエンジニア組織2023年振り返り

この記事は食べログアドベントカレンダー2023 の25日目の記事です🎅🎄

はじめに

こんにちは、食べログシステム本部長の京和です。今年も🐓を務めさせていただきます（5年目）。

さて、今年のアドベントカレンダーの記事を改めて眺めてみると、技術的なトピックだけでなく、プロダクト開発やQA・テスト、マネジメントに関する記事など、幅広いトピックがあるなあと感じました。2018年や2019年のアドベントカレンダーを見てみると、その差がよく分かりますね。組織の変化が感じられてとても嬉しく思います。

本記事では食べログエンジニア組織の2023年振り返りとしていくつかのトピックに分けてご紹介していきます。

1. 食べログ事業について

まずは事業についてです。食べログは2023年Q2(7月-9月)の決算において、初めてコロナ禍前の売上を超えました。

「株式会社カカクコム 2024年3月期第2四半期決算説明資料(PDF)」 P.15 をもとに表を作成

しかし、これは単に外部環境がコロナ禍前に戻ったから、ということを意味しているわけではありません。以下の図は食べログ事業における売上の中核となる飲食店販促と呼ばれる領域の内訳になります。

「株式会社カカクコム 2024年3月期第2四半期決算説明資料(PDF)」 P.16をもとに表を作成

この内訳を見ると、ネット予約サービスが非常に伸びていることが分かります。つまり、食べログの売上がコロナ禍前から復活したのは、ネット予約という新しいビジネスモデルを、これまでの主力商品だったPRサービスに匹敵する売上にまで成長させたことが主要因となっています。競合サービスの中にはコロナ禍以降の業績回復に苦戦している企業もある中で、食べログはユーザーに向けてプロダクトをより使いやすく進化させ、そのメディアとしての集客力を売上に繋げていくビジネスモデルを構築するという、プロダクトとビジネスの両輪をしっかりと回すことによってコロナ禍前の売上を超えられたと言えるでしょう。

現在の食べログではGo To Eatキャンペーン（懐かしいですね）で特需となった期間に近い規模のネット予約があります。Go To Eatの頃は食べログのサービスが重くなるなどシステム面でも大変な状況だったのですが、今ではそれが日常となっています。目に見えないところで食べログのインフラも着実に進化しているのです。

飲食店DXとインバウンド

日本政府観光局の推計では、2023年10月の訪日外国人観光客数がコロナ禍以降初めて2019年同月を超える数値となりました。また、政府は2030年までに訪日外国人観光客数6000万人、消費額15兆円を目標としており、これは自動車産業の12兆円を上回る、国内最大の輸出産業となる規模となっています。

「通商白書2023年版第Ⅱ部第2章」をもとに表を作成

もちろんこのすべてが飲食で消費されるわけではありませんが、それでも非常に大きなマーケットとなるのは間違いありません。食べログではインバウンド向けのネット予約サービス開始も近く予定しており、訪日外国人観光客という新しいユーザーに向けてもチャレンジしていきます。

また、飲食店のDXをサポートする事業として「食べログノート」という予約台帳のプロダクト、「食べログオーダー」というモバイルオーダーのプロダクト、「食べログ仕入」という飲食店の受発注を行うプロダクトなど、新しい事業領域にも積極的にチャレンジしています。飲食店経営では若者世代の働き手の減少、円安や国際情勢による原材料費・光熱費の高騰など、アフターコロナにおいても様々な課題が山積しています。食べログでは飲食店のDXをサポートするプロダクトによって経営の効率化や売上アップに寄与することで、飲食店を支援していきたいと考えています。

また、DXが進むことによって、飲食店で行われる様々な行動がデジタルデータとして蓄積されていくことになります。メディアを持ち、外食領域に特化した食べログだからこそできる、ユーザーの予約から来店案内・配席・注文までを一気通貫で連携させることで、飲食店にとって圧倒的に使いやすい環境を作る。そうして得られたデータを利活用し、ユーザーや飲食店に対してフィードバックしていく仕組みを作っていくことで、さらに食べログが便利になっていくような世界観を作っていきたいと考えています。

食べログのこれから

食べログは既に成熟しているサービスだと思われるかもしれませんが、実はまだまだやりたいこと、やるべきことが山盛りであり、めちゃくちゃ面白いフェーズだということをご理解いただければと思います！

この気持ちをChatGPTのDALL-E3に描いてもらいました

2.組織変更について

品質管理室の立ち上げ

今期の組織変更に関するハイライトの1つが、これまで技術部内の1チームとしてあった品質管理の組織が部室に昇格したことです。インターネットは既に生活に欠かせないインフラとなっており、その重要性は今後も上がり続けるでしょう。そうした時代背景の中で、食べログは日本を代表するお店探しのプラットフォームとしてその責任がますます強く求められていくことになりますし、事業の振り返りでも書かせていただいたように、ネット予約であったり、飲食店の業務に直接影響するようなDXプロダクトを提供しています。これまで中心となっていたインターネット上でのお店探しとしての提供価値に加えて、リアルに密接に関連する領域に進出してきていることからも品質管理の重要性が高まってきており、そうした背景の中で数年前から品質管理組織の立ち上げを行ってきました。

品質管理室の組織体制

品質管理室は大きく以下の3チーム体制となっています。

インプロセスQAチーム

インプロセスQAチームは新規機能の開発や機能改修のQAを行う組織です。いわゆるフェーズゲートとしてのQAではなく、プロダクト開発を進めるマトリクス型組織のチームに参画してQA活動をするという、Embedded SREのQA版のような形のイメージです。テックブログでもインプロセスQAの記事がいくつかあるのでご紹介します。

インプロセスQAチームの特徴は、単に外部品質を担保するだけではなく、「シフトレフト」と呼ばれるバグの作り込みをより早い段階で発見するための活動や、プロジェクトの様々なプロセスの改善などを通じて、生産性の改善にも寄与することをミッションとしている点でしょう。

ISO9126-1では品質を「プロセス品質」「内部品質」「外部品質」「利用時品質」の4つに分類し、それらが段階的に相互依存／影響することを示しています。「テスト偏重主義からの脱却～カギは内部品質と職場環境にあり」にあるISO9126-1の引用図が非常にわかりやすいので引用させていただきます。

実際にシステム開発をしている人にとってこの図は実感とも近いのではないでしょうか。プロセス品質は内部品質に影響する品質で、内部品質は外部品質や利用時品質にも波及していきます。つまり、品質連鎖の基底にあるプロセス品質は、生産性だけでなく品質にも影響力が大きい非常に重要な品質特性です。インプロセスQAチームが生産性にもフォーカスしているのは、品質管理室の前身となるチームが「Developer Productivityチーム」という名称だったことにも由来しています。バグを未然に発見し、市場流出不具合を減らすという、言ってみればマイナスをゼロにする価値だけでなく、生産性を改善することで、ユーザーに届ける価値向上にも寄与することをインプロセスQAチームでは目指しています。

現在のインプロセスQAチームはネット予約などの基幹システムと、飲食店DXプロダクトである食べログオーダーへのQA活動が主ですが、今後はメディア向けなどにも拡大していく予定です。

テスト自動化チーム

テスト自動化チームはその名の通り、テスト自動化を推進するチームです。テストの自動化は前述の4つの品質を構造的に下支えする屋台骨として非常に重要です。こちらもテックブログに記事がありますので活動例としてご紹介します。

現在はテスト自動化チームはE2Eテストにフォーカスしていますが、最終的にはユニットテストの充実にフォーカスしていきたいと考えています。食べログではアプリケーションをモジュラモノリスへ作り替えていく取り組みも行っており、そうしたリファクタリング／リアーキテクトによるテスタビリティの改善と、E2Eテストによる外部品質の担保を通じてユニットテストをメンテしやすい状況を作り、現在のアイスクリームコーン型のテストをピラミッドへと徐々に作り替えていくということを考えています。 ¹

SPIチーム

SPIはSoftware Process Improvementの略称です。SPIチームではいわゆるFour Keysなどに代表される、ソフトウェア開発の各種活動を定量／定性面の両面から計測し、そこから得られた指標をもとに、ソフトウェア開発プロセスの改善を推進するチームです。食べログではGitHubの活動をもとに「品質ダッシュボード」というものを作り、プロジェクトの活動を可視化する取り組みを行っています。こちらも詳細について書いた記事をご紹介します。

「開発プロセス改善による変化を定量的に捉える【緊急Ques 「食べログの品質ダッシュボード」】 - Tabelog Tech Blog」

ただ、残念ながら、こちらのチームは現在専任の担当者がおらず、十分に推進できていません。大変おもしろい領域ですので、ご興味のある方はぜひお声がけください！

部長をシャッフルした話

食べログのエンジニア組織は以前に食べログの大規模なエンジニア組織を段階的に改善していく取り組みでもご紹介させていただいたように、ユーザーやデバイスなどで区分した事業領域と、システムを横串で見る技術領域に大別されます。現在もこの構造は変わっていません。今期のもう1つのハイライトが、各部門の部長を全員シャッフルするというチャレンジをしたことです。

なぜやったのか①: 事業方針に基づく開発組織の最適化

まず最初に考えた観点としては、事業方針に基づく開発組織の最適化です。例えばこれまで食べログオーダーはiOSアプリやAndroidアプリを所管するアプリ開発部、食べログノートは飲食店向けの管理画面や予約基盤を所管する飲食店開発部と分かれていましたが、事業の振り返りでも書かせていただいたように、この2つのプロダクトの相互連携を進め、予約から配席・注文までを一気通貫で管理できるようにしていくという世界観を作っていく事が必要でした。この取り組みを推進していくためには、この2つのプロダクトで所管部門が分かれているよりも、同じ部門内に合ったほうがよりよい形ではないか、というような観点です。

また、それ以外においても今後の食べログにおいてはこれまで以上に各システムが相互に連携するプロジェクトが増えていく見込みでした。そのため、すべてを部門に閉じる形で運営していくのが現実的な状況ではなく、そのことが次の領域横断的オーナーシップの話に繋がっていきます。

なぜやったのか ②: 領域横断的オーナーシップ

食べログのエンジニアリング組織はサーバーサイド（バックエンド）、フロントエンド、iOSアプリやAndroidアプリというアプリケーションの技術領域、メディアや飲食店というドメイン領域に基づいて分割されています。さらに、それぞれのドメインの中でも検索や予約などの複雑なドメインが存在し、そうしたドメインには専任チームが存在しています。

このようにして分割することによるメリットとしては、特定のドメインや技術領域に特化することで、認知負荷が許容範囲内におさまり、その領域内においてはオーナーシップを持つことができるようになる、ということが挙げられます。デメリットとしては、関心領域や関係性が閉じていき、全体を見るオーナーシップが失われていく懸念があります。

プロダクト開発というのは特定のシステムに閉じた活動ばかりではありません。例えば、ネット予約の仕組みを変えようとした場合は、ユーザー向けの予約UI/UX、ネット予約のシステム基盤、飲食店向けのネット予約管理画面、社内スタッフ向けの管理画面など、複数のシステム領域に渡った開発が必要になります。これは、特に大規模なプロジェクトであるほどその傾向は顕著になり、横断する領域も広くなっていきます。

そのような開発プロジェクトを円滑に進めていくためには、個々の担当領域だけではなく、担当領域を横断してプロジェクト全体に関心を持つ「領域横断的オーナーシップ」を持った人が非常に重要になってきます。今期のテーマの1つとして「Crossover」を掲げている ² のにはそうした背景があります。

ただ、大規模なソフトウェア開発の現場において、「認知的過負荷にならない範囲を責任として持つ」ことと、「領域横断的オーナーシップを持つ」という2点を両立させることは非常に難しく、食べログでもマトリクス型組織の取り組みなども行っていますが、それでも完全に解決したとは言えない状況でした。そうした中で、「様々な領域を経験し、知識や繋がりが周辺領域にもある人であれば、領域横断的オーナーシップを持ちやすいのではないか」という仮説を持ち、その事が今回のチャレンジに繋がっています。

どうやったのか & どうだったのか

当社では毎年4月が期の始まりのため、大規模な組織変更はこのタイミングで行われることが一般的です。今回の部長シャッフルは、その前年の11月というかなり早いタイミングから検討を開始しました。異動については部長だけでよいのか、それとも今回のWhyを踏まえるともう少し大規模な異動を実施するべきか、というような検討を私と部長陣全員で行いました。最終的には部長のみが異動することになりましたが、これは組織のバランスを考えてのことでした。

人が成長する環境として「コンフォートゾーン」「ラーニングゾーン」「パニックゾーン」という3つの領域に分類するという話を聞いたことがある方も多いかと思います。あまり大規模に組織変更を行いすぎるとパニックゾーンとなる懸念があることから、まずは部長のみで異動するということになりました。

結果的には大きなハレーションが起きることなく組織変更は行われました。これはこの3年間で培われた現場の成長があってこそだと思っていて、組織変更に伴う負荷がありながらもしっかりとプロジェクトを推進してくれたことにとても感謝しています。また、それぞれの部門であらたな部門長が今までの良い部分を引き継ぎながら新しい文化や考え方を導入し、よりよい組織へと成長させてくれています。今年のアドベントカレンダーではアプリ開発部や飲食店システム開発部長の部長が投稿していて、アドベントカレンダーの賑わいがさらに増しました。

組織の中に不安定な部分を創る

これは余談にはなりますが、故・松下幸之助さんが「会社の中に不安定な部分をどうやって創り出していくか」ということについて語っており、それが示唆に富んでいて非常に面白かったので、少し長いですが引用します。

安定してるけど安定させない。それが大企業病を克服するひとつの方法であるわけやな。これに成功するかどうかということ。

以前、ある人から聞いた話やけど、ロボットな、あれはいま日本で盛んに作られ、使われておるけどな、あれ、人間そっくりなものはまったくないやろ。人間の上の部分というか、手と胴の部分を備えたロボットと、下の部分の足やな、そのふたつに分かれて、ひとつの人間のような形をしたロボットは、きみ、見たことがないやろ。それはどうしてかというと、そういうロボットはいまのところできんそうや。

それは重心に関係があるらしい。人間の重心はおなかにある。ところがそれは力学的に言うと、不安定だというんや。それはそうやな。重心が真ん中にあるんやから、不安定といえば不安定やわな。一番の安定は足やわな。足に重心があれば、これは絶対に転ばんわな。

だから絶対に安定させようとするならば、重心は足に持ってこんといかんということになる。ところがそうすると、からだ全体の自由がきかなくなるそうや。走ることもできん。跳ぶこともできん。そりゃそうやな、足に重心があるんやから、重たくてそんなことはできんわな。不自由というわけや。　

ところが人間の重心はおなかにある。不安定なところにある。その不安定なところにあるがゆえに、今度は跳ぶこともできるし、走ることもできる。まあ、自由に振る舞うことができるというわけや。これやな。適度の不安定さの中にこそ自由があるということや。

自由というものは完全な安定の中には存在しない。ということはどういうことかと言うと、あんまり安定してしまったら、自由が失われるということやな。

「こんな時代だからこそ学びたい松下幸之助の神言葉50」 P.155より引用

今回の体制変更においても、現状の組織構造が約3年間続いてきた中で安定してきたことがきっかけの一つになっています。一方で、いたずらな組織変更はかえって混乱を生みかねません。あくまでこれまで挙げてきたような課題を克服するための手段ですので、不安定にすることが目的ではない事をしっかりと意識する必要があります。

先程の故・松下幸之助さんの例は、「安定化」をコンフォートゾーンに寄っていく力学、「不安定化」をコンフォートゾーンから外れていく力学、と捉えることができるでしょう。また、個人的な解釈として、コンフォートゾーンのさらに内側には、「レイジー（だらけた）ゾーン」と呼ぶべきような領域があると考えています。組織を健全なコンディションに維持し続けるためには、レイジーゾーンやパニックゾーンに行かずに、コンフォートゾーンとラーニングゾーンを適度に行き来するような設計が望ましいと思います。

とはいえ、実際にはどこまでの変化を起こすとどの領域になるのかを事前に読み切るのは困難です。このあたりの采配のバランス感覚は本当に難しく、リスクも大きいため、まだまだ学ぶべきことが多いと感じました。また、今回のような課題に対しては、人や組織だけではなくシステム面でも改善を進めていく必要があります。今後も様々な面から改善を進めていきたいと思います。

3. 生成AIの取り組み

2023年は生成AIと切っても切り離せない1年でしたね。食べログでは2023年5月6日にChatGPTプラグインをリリースしました。これは当時のタイミングでは日本企業として初だったこともあり、テレビや雑誌などでも取り上げられるなど、非常に話題になりました。5月15日にはプラグイン開発の舞台裏を書いたテックブログを公開し、こちらも同様に大きな反響がありました。

「日本初の挑戦〜食べログによるChatGPTプラグイン開発の舞台裏」

詳細については上記ブログをご覧いただければと思いますが、個人的に印象深かったのは、開発者向けのテックブログにも関わらず、NewsPicksなどのビジネス層の方たちからの反響も大きかった点でした³。また、私は開発の佳境のタイミングでサンフランシスコに海外出張しており、16時間の時差がある中で現場とやり取りしていたのも良い思い出です。

来年に予定されているGPT Storeの公開に伴い、ChatGPTプラグイン自体はシュリンクしていきそうな流れですが、早期にプロダクトをリリースしたことで非常に多くの学びを得られましたし、採用活動などにおいても触れられることが多かったので、非常に価値のある取り組みだったと思っています。

また、2023年12月号のSoftware Designに合計26ページに渡って食べログのChatGPT活用の特集記事を掲載しました。ChatGPTプラグイン、またiOS版でのみ試験公開している食べログAIチャット(β)という機能についての開発についても詳しい記事が掲載されていますので、よろしければぜひご覧ください。

「「Software Design 2023年12月号」に食べログのChatGPT特集を寄稿しました」

私自身も「企業における生成AI活用の考え方」として、LLMの仕組みや活用に対する考え方というテーマで寄稿させていただきました。食べログとしてこの規模の特集記事を雑誌に寄稿するのは初めてのことでしたし、記事を書くにあたって改めて膨大な量の学習や調査をしたのでこちらも思い出深いです。

GitHub Copilot

多くの企業同様、食べログにおいても全開発者がGitHub Copilotを利用可能になっています。ソフトウェア開発における生成AIの活用というテーマについては別途テックブログで寄稿できればと思いますが、先日「Copilot Knowledge JAM」という、各人が気づいたGitHub Copilotの便利な活用方法を共有するイベントを開催しました。

イベント画像やイベント名もChatGPTと考えました

期間中に社内ブログに記事を投稿する形式で、全18件の投稿がありました。ドキュメントやテスト、リファクタリングなど現場感のある取り組みが投稿され、私自身も非常に参考になりました。食べログはユーザー投稿型のCGMサービスですし、このような形でノウハウを共有し合うというのは素晴らしい取り組みだと思います。なお、GitHubの担当者の方に「賞を選定してください」と無茶振りしたらご快諾いただけました。心より感謝申し上げます。

生成AIの業務活用

業務活用においても食べログでは生成AI活用を進めています。今年のアドベントカレンダーではオープンソースのChatGPT UIクローンを活用した記事作成支援の取り組みとしてご紹介させていただきました。

「生成AIによる記事作成支援において、プロジェクトの各ステップで意識したポイントと、プロジェクトを通して得た気づき」

食べログでは仮説を検証するためのMVPを早期に実装する、エンジニアが積極的に現場に出向き、ユーザーと会話をしたり、業務を直接観察するなど、業務活用においても一般的なプロダクト開発の考え方を取り入れて進めています。個人的に印象深かったのは、「記事の書き出しに悩むことが多いので助かる」というご意見が多かった点です。これは私自身が生成AIを使っていても実感するところですし、生成AIは生産性改善だけでなく、人間がより本質的な価値の部分に注力できるようにするためのものである、ということを実感させる結果となりました。

食べログでは来年以降も生成AIに関する新たな機能のリリースを予定していますので、ご期待いただければと思います。また、食べログのような日本中の人たちが日々使っていて、食という暮らしに密接に関わるプロダクトを先進的な技術で改善できるというのは、エンジニア冥利に尽きることだと思います。興味がある方はぜひお話を聞きに来てください。

4.おわりに

食べログエンジニア組織の2023年の振り返りとしていくつかの取り組みをご紹介しました。振り返ってみると、やはり今年は生成AIのインパクトが強い一年でした。生成AIは進化のスピードがこれまでにないほどに速く、来年は一体どうなるんだろうと今から楽しみです。また、その中で、「人間が向き合わなければいけない仕事とはなにか」ということも改めて考えさせられました。生成AIが普及したとしても、人と人が協同して仕事をするという世界は今後も続くと思います。AIによって仕事や組織、そしてエンジニアリングがどのように変わっていくのか。そして僕は来年のアドベントカレンダーでは一体なにについて書くことになるのか、想像もできないですね。

それでは、今年も一年ありがとうございました。みなさま良いお年をお過ごしください。