この記事は 食べログアドベントカレンダー2025 の19日目の記事です🎄🎅🎄
こんにちは。食べログカンパニー 開発本部 どいです。
最近の食べログアドベントカレンダーでは「食べログ20周年」を記念して様々な特集記事が連日アップされているところですが、今日はちょっとだけ趣向を変えて“箸休め的なエッセイ”をお届けします。
はじめに
食べログ20周年。気がつけば、私もこの「食べログ」という同じサービスに16年関わっています。
といっても、私の中では同じ場所にいるという感覚はあまりありません。人が増えるたび、サービスが大きくなるたび、私の役割も立場も、見える景色も、仕事の内容も目まぐるしく変わっていきました。 最初はただの一エンジニアで、サーバとコードと戦いながら「どうにかして動かす」毎日を過ごしていました。
それが気づけば組織を見渡し、さらに業務の流れを整え、サービス全体をどう持続させるかを考えるポジションになっていた。正直、役職とか肩書きはどうでもよくて、ただ、目の前の仕事と向き合っていたら、いつの間にか“サービス全体の流れ”に興味が移っていたという感じです。
技術だけではなく、企画や営業、サポートの仕事にまで「これ、こうしたらもっと楽になるはず」と手を出すようになり、最近ではあれこれ言いながら「やろうよ！」と部署をまたいで仕掛けてまわるような働き方になりました。
おかげで影響範囲は広がり続けていますが、そこは自慢のおじさん力でどーんと腹を据えて働けています。長く関わると責任が重くなる反面、自由度も増えていく。その両方が、仕事を続けさせてくれている気がしています。
そして今、サービスも組織もかなり大きくなったこのタイミングで、AIという強烈な変化がやってきて、「また速さを追い求めてもいいんじゃないか」と久しぶりにワクワクしています。 そんな私の食べログとの歩みを振り返ってみたいと思います。
第1章：コードとトラブルと“マジかよ”のはじまり
2009年4月。私が入社した頃、食べログチーム全体で20名程度。
そのうちエンジニアは私を含めても5名。伊東の温泉宿にエンジニア全員で合宿しても1部屋で収まるくらいの規模でした。
朧げな記憶をたどってみると、開発環境は他サービスからのお下がりで、サーバやバッチ一覧はExcelを印刷して配ってくれるメンバーがいて、CIなんて知らん、DB(MySQL) は単一SourceとReplica数台での単純なレプリケーション。
退社前にデプロイしてちゃんと動作確認もせずそのまま飲みに行くも、翌朝「昨日からずっと見れないんだけど！……」と怒られたり、キャッシュクリアが手動で、マイルドにフラッシュするためにチャンクを1つ消すたびにふらっと外の空気を吸いに出かけたりするのも日常。SourceDB に直接ログインしてデータ抽出してサーバを落とすのも“気をつけてね”のレベル。テレビで紹介されるとだいたい落ちる。悔しいけど、仕方ない。そういう“仕様”でした。
なかでも鮮烈なのは、お正月にAPサーバからすべてのプログラムファイルが消えた事件。原因は、APサーバのcrontabに rm -rf ./* のようなものがセットされていたのを止め忘れた、というオチ。「マジかよ」と思いながら笑うしかなくて。担当者からの復旧の電話連絡を待っていたのを思い出します。
休日にスポーツジムのロッカールームでコンソールを開いてmongrelを再起動したこともあるし、IRCのチャネルが1つ2つあれば十分だったあの頃の空気は、今でも忘れられません。
何をしていても“手触り”があって、世界のどこかで自分たちが作った仕組みが動いている感覚があった。「速さは正義」をモットーに多少の無茶は楽しかったし、それでも「なんとか動かし続ける」という一点だけを信じて働いていました。
この混沌が、当社での私のエンジニアとしての原体験です。
第2章：技術が追いつかず、でも止められない日々
2011年ごろから、サービスが一気に伸び始めました。
同時に、裏側では限界が見え始めていました。スマホが台頭し、私たちはPCとガラケーだけだったサービスのスマホ版を、数週間の突貫で作ってリリースしました。今思うと正気じゃなかったと思います。
同じ頃、SourceDBが完全に死んだ日がありました。すべて止まり、本当に心臓が冷たくなるような瞬間でした。
当時、別目的でたまたま準備していた“リードオンリーモード”（Replicaだけを使って食べログの最低限のコアサービスをリードオンリーで提供するモード）に切り替え、不完全ながらも2〜3時間で閲覧だけ復活させましたが、「これはもう通用しないな」と痛感しました。
アクセスは増え続け、Railsは古く、CIは後手後手で、svnからgitへの移行も混乱に満ちていました。 Jenkinsを導入してCI基盤をとりあえず作り、スパム対策にreCAPTCHAを入れ、DB負荷が限界になって検索エンジンを導入し、アクセス解析向けにHadoopを導入し……とにかく「止めない」ための対応が続きました。
サービスが伸びるスピードに、技術が追いつかない。でも、追いつかないからといって止められない。そんな日々でした。あの頃は、本当に綱渡りでした。
第3章：組織が大きくなると、“見えるもの”が変わる
食べログシステムに関わるエンジニアが30人を超え、50人を超え、100人を超える頃、私の仕事は徐々に変わっていきました。
私自身が「設計する」「コードを書く」だけでは回らなくなり、チーム全体の流れを整える役割にシフトしていきました。デザイナーやデータサイエンティスト、CS、営業など、関わる職種も広がり、私の視点も「コード」から「サービス全体の流れ」へと移っていきました。
また、この頃からReactへの移行が本格化し、オンプレ環境の片足をKubernetesへ移し、データ分析基盤もTreasure DataからGoogle Cloud・BigQueryへと移行していきました。
技術的な正しさだけではなく、誰がどの業務で何をしているのか、その業務の裏側でどんなデータが動いているのか、サービスを守るために“全体”を見ざるを得ない状況でした。つまり、技術的な興味だけではなくて、業務自体を理解しないと自分の仕事ができなくなってきたのです。私にとってこの変化は大きかったです。
エンジニアという肩書きは変わらなくても、やっていることはどんどん“サービス全体を動かす仕事”に寄っていきました。
第4章：業務を作らないと、システムは進化できないという結論
2020年、コロナが来ました。Go To Eat対応で桁違いのアクセスが流れ込み、状況は混乱していましたが、それでもついに最後までサービスダウンすることはありませんでした。昔の状態を知っている私からすると「本当にここまで来たのか」と胸に迫るものがありました。
けれど、同時期に1つはっきりしたのは、システムが複雑になりすぎて、業務が曖昧だと何も前に進まないという現実です。モノリスの分離をしようとしても、「この機能、誰が使っているんだっけ？」という話になる。SaaS導入やKubernetes移行でも同じ。“業務そのものが整理されていない”のが最大の課題でした。
つまり、正直言って技術はもうおおよそ十分だったのです。足りなかったのは、業務の設計でした。この頃から私は、業務のフローを書き直すところから始めるようになりました。
企画、営業、CS、開発、デザイン、それぞれが何をしていて、どこで情報が詰まり、どこが苦しくなるのか。業務をつくり直すことは、未来の技術的負債を減らす最善策になるのではないかと。
この気づきは、私のエンジニア人生の中でも特に大きな転換点です。
第5章：業務設計は“全職種をつなぐエンジニアリング”だった
最近の私は、企画や営業サポートの相談にも顔を出すし、CSの業務フローの改善にも参加する。
なぜそんなことができるのかというと、サービスの構造を長く見てきたことで、やっと“全体をつなぐ楽しさ”がわかってきたからなのかもしれません。業務を設計するというのは、エンジニアリングの一部だと考えています。むしろ、組織が大きくなればなるほど、コードの性能より業務の流れの方がサービスを動かす力を持つことがある。
営業、企画、デザイン、開発、すべての職種がつながる設計図を描く。やらなきゃいけないからやるというより、最近は「これやりたいよね、作りたいよね」と思える場面が増えました。
自由度のある立場と長く関わったからこその視点が相俟って、今はそれを使って“橋をかける”仕事が多くなったように思います。
第6章：AI時代、“また速さを求めてもいい時代が戻ってきた”という感覚
いま、会社全体でGitHub CopilotやGemini、Cursor、Claude Code、DevinなどのAIツールが普通に使えるようになりました。
これは本当にすごいことで、技術も成熟し、サービスも大きくなり、運用業務に関わるステークホルダーが多数いるという状況下で「もう速さだけを求めて動く時代じゃないのかもな」と思っていた私の感覚が、ここにきてガラッと変わりつつあります。
AIがコードを書く。AIがレビューする。AIが設計する。でも、それで仕事が減るわけではなく、むしろ人間には“AIが動くためのコンテキストをつくる”という新しい役割が増えています。技術的な実装はAIに任せて、人間はサービスの流れや業務構造をつくる側へとシフトしていく。
これは私がこの16年でたどり着いた結論とまったく矛盾しないどころか、むしろ補強してくれる変化です（たまに嘘をつくAIに苦労する部分はありますが）。
そして何より、久しぶりに“速く作れる喜び”が戻ってきつつある。プロトタイプがその場で立ち上がる。アイデアや計画が形になっていくスピードが上がる。
正直、食べログに参画した当時のあの感覚に似ていてワクワクします。
第7章：私がたどり着いたエンジニアリングのかたち
私は今でも、頼まれればコードを一緒に読みに行くし、設計の相談にも乗るし、ときどきペアプロもします。
マネジメントの経験が長くなっても、プロジェクトやシステムの健康状態はPRのコードを読むと大体わかるものです。技術的な負債は資料からは見えない。PRを見ると「あ、ここが苦労してるな」とわかる。だから、デスクや会議室で考え、ターミナルで確かめる。その往復は、私にとってエンジニアとしての大事な“呼吸”のようなものと言えるかも。
また、システムに対してだけではありません。16年のあいだに、私の仕事は何度も姿を変えてきました。コードを書く人から、チームをつなぐ人へ。組織を動かす側から、業務を設計する側へ。
そして今は、技術と業務とサービスをつなぐ“流れを設計する者”として働いています。 けれど、どの時代を振り返っても共通していたのは、サービスを止めずに、価値を届け続けるために仕組みを整えることでした。
エンジニアリングの最終形は人それぞれですが、私にとっては“業務を設計すること”がひとつの答えでした。そしていま私は、「業務設計を通じてエンジニアリングを完成させる」 という考え方にたどり着いています。
職種を超えて流れをつくり、あらゆる人が同じ方向に向かって仕事を進められるように設計すること。これはエンジニアリングそのものであり、サービスを提供し続けるための重要なファクターだろうと。
おわりに
先日、私が10年以上前に書いたコードを、若手のエンジニアが見つけて「まだ生きてましたよ！」と笑いながら言ってくれました。それを聞いて少し胸が熱くなったというか、ちょっと照れくさいというか。そんな複雑な感情が湧きながらも、私が書いたコードが、誰かのスタートラインになっていたという事実は想像以上に励みになります。
時代は変わりました。かつて人がコードで世界を動かしていた時代から、いまは人が業務を設計してAIと共に世界を動かす時代へ。でも、不思議と恐怖はなくて。
食べログに参画してから現在に至るまで、年々変わりゆく組織体形の中で チームリーダ、マネージャ、部長、本部長…… といった様々な管理職寄りのポジションを経験してきましたが、きっと、この変化やカオスを“怖い”ではなく“面白い”と感じられるうちは、私はまだエンジニアですね。
明日は Tabelog Tech Blog編集チームによる『20年目の食べログを、若手はどう見ている？大規模開発の裏側から未来の構想まで語る、エンジニア座談会』です。お楽しみに!
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
