Movatterモバイル変換


[0]ホーム

URL:


Tabelog Tech Blog

食べログの開発者による技術ブログです

トップ>働き方>食べログ老人会 × Z世代!? 入社14年目と若手が語り尽くす、激動の技術変遷

食べログ老人会 × Z世代!? 入社14年目と若手が語り尽くす、激動の技術変遷

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

はじめに:食べログ、祝20周年!

こんにちは、e-ronny と申します。

2025年、食べログはサービス開始から20周年を迎えました。この20年間で、Web業界を取り巻く技術トレンドは劇的に変化しました。「オンプレミス」で物理サーバーと格闘していた時代から、「クラウドネイティブ」へ、そして「AI」が開発の頼れるパートナーとなる時代へ。

食べログのシステムもまた、その時代の波に揉まれながら、継ぎ足しと刷新を繰り返してきました。過去の技術的判断は、現在の私たちにとって「負債」として立ちはだかることもあれば、かけがえのない「資産」としてサービスを支え続けていることもあります。

本記事では、食べログ Advent Calendar 2025 の一環として、入社14年目のベテランと、現代の開発環境に慣れ親しんだ若手代表の対話を通じて、この激動の技術変遷を振り返ります。泥臭い物理作業の思い出から、最新のAI活用事情まで。新旧エンジニアの視点が交錯する「食べログ技術クロニクル」をお楽しみください。

この記事の登場人物

本記事は、入社14年目の筆者と、開発部内のエンジニアへのヒアリングを元に構成した「次世代メンバー」との対話形式でお届けします。※Z世代側の発言は、現場の若手エンジニアの皆さんにレビュー・リライトのご協力をいただきました。

  • 筆者: 🍵 (老人会 / ベテラン)
    • 入社14年目の現役エンジニア(IC)。激動の時代を見てきた証人。
  • 次世代: 🚀 (Z世代 / 若手代表)
    • クラウドやコンテナ技術が当たり前の環境で育ったエンジニア。
    • 食べログ入社後は、モダンな技術だけでなく、歴史あるオンプレ環境の知識も吸収中。
    • ※本記事では、特定の個人ではなく「現代の食べログ開発者」の総意としてのキャラクターとして登場します。

いざ、タイムトラベルへ

🍵「いやー、食べログももう20周年かぁ。僕が入社した頃とは、景色が全く別物になったよね」

🚀「お疲れ様です! 20年ってすごい歴史ですよね。僕が学生の頃にはもう当たり前にあったサービスって考えると、ちょっと震えます(笑)」

🍵「(...学生...!)今回はアドベントカレンダーの記事ということで、そんな『激動の20年』を振り返ってみたいと思うんだけど、今の若い子たちから見て『昔の食べログ』ってどんなイメージ?」

🚀「正直、想像つかないですね。コードを見ても『なんでこんな作りになってるんだろう?』って不思議に思うこともありますし...」

🍵「ふふふ、そこには涙ぐましい歴史と、当時の『最適解』があったんだよ。今日はその辺りの泥臭い話を暴露していくから、覚悟して聞いてね!」

🚀「お手柔らかにお願いします!(怖いもの見たさでワクワクしてきた...)」


インフラと運用の変遷:物理的な汗からコードによる統制へ

🍵「さて、まずは土台となるインフラの話から始めようか。当時は『物理』との戦い だったんだ」

🚀「物理...ああ、オンプレのサーバー のことですよね? 食べログのような大規模サービスを支える基盤として、今も現役でバリバリ動いていると聞きました」

🍵「そう。今はIaC (Infrastructure as Code) で管理されているけど、昔は文字通り『手作業』で管理していた時代があったんだよ。今回話したいのは、その変遷だね」

サーバー管理の進化:紙の台帳 vs IaC

🍵「昔はね、サーバーを増強するたびに『もんぐれる!!.xls』っていう通称のサーバー一覧表 を更新して、なんと紙に印刷してエンジニア全員に配ってた んだよ。当時はエンジニアだけじゃなく、企画もCSも、食べログに関わるすべてのメンバーがワンフロアにいた からこそできた、ある意味『熱量の高い』運用だね」

🚀「えっ、紙ですか!? Excel で管理してるのになんでわざわざ印刷を...? そもそも『もんぐれる』って何ですか?」

🍵「昔 Rails を動かすのに使っていた Web サーバーだよ。ここ15年くらい更新されてないみたいだけど懐かしいなぁ(参照)」

🚀「なるほど、Webサーバーの名前だったんですね!」

🍵「ちなみに、僕も最近知ったんだけど、さらに上の世代の先輩によると、前身となる『もんぐれる!.xls』 もあったらしいよ。初期は全13台だった 頃の話で、一覧表ですらないメモ書きレベルだったとか」

🚀「じゅ、13台ですか!? 今の食べログの規模からは想像もつかない少なさですね...。でも紙で配れるってことは、進化した『!!』の時点でもまだ台数は少なかった ってことですよね?」

🍵「そうそう。僕が入った頃でも数十台レベルだったかな。ただ、台数は少なくても1台のサーバーに色んな役割(ロール)が相乗りしていて、構成がめちゃくちゃ複雑だった んだよ。あるロールでリソースを食いすぎて詰まった場合、そのサーバーに相乗りしている他のロールも巻き添えを受けるとかね(笑)」

🚀「うわぁ、一番触りたくないやつだ...! だからExcelで可視化しないと管理できなかったんですね」

🍵「あと、当時はモニタの解像度も低かったから、Excelの一覧性が重宝された のかもね。何かあったらすぐに SSH で対象のホスト名を指定して入る必要があったし、パッと見てその名前がわかる『紙』が最強だったのかもしれない」

もんぐれる!!.xls の実物

🚀「なるほど、物理的な近さと一覧性が重要だったんですね」

🍵「そう。で、そんな『繊細なガラス細工』みたいな環境だから、リリース作業も一筋縄じゃいかなくてね...」

🚀「なんか嫌な予感がします...」

デプロイ今昔物語:絶叫 vs 自動化

🍵「まず、リリース自体が週に数回の一大イベントだった。だから開始前には、フロア中に響き渡る大声で『デプロイしまーす!』って叫んでた んだよ」

🚀「(絶句)...あの、叫ぶ必要性は...?」

🍵「さっき言った通り、全員がワンフロアにいて顔が見える距離感 だったからね。物理で叫ぶのが一番確実だったんだよ(笑)。そしたら全員が『お願いしまーす!』って返す のがお決まりだった」

🚀「なんか部活みたいですね(笑)。今はエンジニアだけでも人数が増えてオフィスに入り切らないし、リモートワークの人も多いから不可能だけど」

🍵「今の規模でやったら、他の部署の人たちがびっくりして仕事にならないかもね(笑)」

🚀「あはは、確かに(笑)。それに、今はデプロイ頻度も上がって、リリースごとに担当するチームが決まってます から、自チーム以外のリリース作業はそこまで気にしなくて済みますしね」

🍵「昔はね、デプロイ宣言後はフロア全体が静まり返って、全員が固唾を飲んで見守ってた んだよ。何かあった時にどのチームの影響か切り分ける必要があったし、万が一の時はチームの垣根を超えて全員で復旧を助けるため でもあったんだ」

🚀「緊張感えぐいですね...。デプロイスクリプトはどうだったんですか?」

🍵「それがまた魔改造されすぎてて、『この順番で、このタイミングで叩かないと動かない』 みたいな秘伝のタレ状態だったのさ。担当者のプレッシャーたるや...」

🚀「胃が痛くなりそう...。今は改善されて、誰でも用意された3つのスクリプトを順番に叩くだけで安全にデプロイ できるようになりましたし、一部はマージボタンを押すだけで終わりますからね」

🍵「ほんと、いい時代になったもんだよ...」

障害対応と保守:運のあみだくじ vs 仕組みのOpsGenie

🍵「僕が入社する前の伝説なんだけど、年末年始の休みの最中に、突然サービスが全滅して保守担当が当番制で持っていた専用のガラケー が鳴り止まない事件があったらしくて...。調査したらサーバー上のファイルが全部消えてた んだって」

🚀「えっ、ファイル消失ですか!? 怖すぎます...」

🍵「いや、当時は『古いリリースファイルを自動で消す』ような仕組み自体は動いてたらしいんだけど...」

🚀「ああ、ディスク容量を圧迫しないようにするためですかね」

🍵「そう。でも、その年はたまたま暦の関係で連休がいつもより長かったとかでね。リリースが止まっている期間もその掃除の仕組みだけが元気に走り続けて...気づいたら『最新のリリースを含む全てのファイル』を綺麗に削除してしまってた らしいんだよ」

🚀「うわぁ...。リリースがないのに掃除だけしちゃったんですね。でも、サービスは動いてたんですかね?」

🍵「うん。しばらくは動いてたみたいだけど、何かの拍子に再起動がかかった瞬間、読みに行くファイルが虚無になってて...サービス全滅。休み中の保守担当者は生きた心地がしなかっただろうね」

🚀「それにしても、保守担当はガラケーを持っていたんですね。スマホじゃないんだ...」

🍵「当時は長期休暇の前になると、チーム全員で『あみだくじ』をして保守担当を決めてた んだよ。当時は人数も少なかったから、みんなでワイワイあみだくじで決めるイベント感があったんだ。当たった人は、休暇中ずっと専用のガラケー を持ち歩くことになっていてね...」

🚀「あみだくじですか!? 公平なのか不公平なのかわからないですね(笑)。でも、そういう『みんなで決める』っていう空気感、なんかいいですね」

🍵「そのガラケーが鳴ると、もう心臓が止まりそうになるんだよ。しかも、気づいたことを知らせるために、発報メールに『対応します』って返信するルールがあったんだけど、ガラケーだとその一言を打つだけでも一苦労 でね...」

🚀「フリック入力ですらない時代ですもんね...。着信音がトラウマになるのもわかります」

🍵「街中で同じ着信音を聞くとビクッとなる『職業病』は、未だに治ってないよ(笑)。でも、ガラケーで『対応します』って返信した後は、すぐにPCを開いて関係者に連絡してたなぁ」

🚀「わかります...。今はOpsGenie が自動で担当をローテーションして 、個人のスマホに通知を飛ばしてくれますけど、そこまでビクビクすることは少なくなりましたね」

🍵「おっ、肝が座ってるねぇ。緊張しないの?」

🚀「もちろん緊張はしますけど、大きな不具合の元はおよそ潰してきましたし、障害対応のノウハウも蓄積されてますから。 『やばい』障害はそうそう起きないだろう、という安心感はありますね。それに、何かあったらすぐに連絡を取り合って連携する姿勢は変わってないですから」

🍵「なるほど...! 過去の失敗をちゃんと糧にして、システムを堅牢にしてきた結果だね。頼もしい限りだよ」

🚀「はい。何かあったらすぐにチャットにみんなが集まってきて一丸となって対応する 体制は、昔も今も変わってないですからね。一人で抱え込まなくていいのは大きいです」

🍵「うん、精神論で乗り切るんじゃなくて、仕組みで解決できるようになったのは本当に大きな進歩だよ」


🍵「...とまぁ、インフラ周りはこんな感じかな」

🚀「なるほど。僕たちが物理的な苦労を知らずに開発に集中できるのは、そうやって先輩たちが進化させてきてくれたおかげなんですね。じゃあ、僕らが普段触っているアプリケーションコードや、開発の進め方はどうだったんですか?」

🍵「そこもまた、職人芸と自動化への執念が入り混じった歴史があるんだよ。次は開発現場の変遷を見ていこうか」

コードと開発プロセスの変遷:職人芸から巨人の肩の上へ

開発プロセスと品質保証:カーチャン vs CircleCI & AI

🍵「CI/CDなんて言葉が流行る前から、うちは『カーチャン』 っていう自作のCIツールがテストやコーディング規約のチェック(RuboCop)を走らせてくれてたんだ」

🚀「『カーチャン』...? まさか『テスト落ちてるわよ!』って怒られるんですか?」

🍵「ご名答(笑)。AA(アスキーアート)の『カーチャン』(`J( 'ー`)し`)になりきって、プルリクエストに『テスト ニ 失敗シチャッタワ』 とかコメントしてくれるんだ。Jenkinsおじさんよりお節介焼きだったね」

PR に実際にカーチャンがコメントしている様子

🚀「キャラが濃い...! でも、なんでわざわざ自作してたんですか?」

🍵「当時はまだ CircleCI もなくて、Jenkins を使うにも設定が大変だったんだよ。あと、実は当時も Jenkins は動いてたんだけど、そもそもPull型ではエラーに気づきづらかった んだよ。だから、開発者が普段見ているプルリクエストに直接コメントさせることで、情報をPush型で通知して『嫌でも目に入る』ようにした んだよ」

🚀「なるほど、情報のプッシュ型配信 ですね! 今はCircleCI が標準になって、プルリクエスト上の Checks に結果が出るのが当たり前ですけど、当時から『開発者の目に触れる場所にフィードバックを返す』という DevX(Developer Experience)の精神があったんですね」

🍵「そうそう。形は変わっても、開発者を楽にするための『お節介』は大事ってことだね」

🚀「AIコードレビューも導入されて、AIに『このコード、バグの可能性が高いよ』って指摘されると、たまにイラッとしますけど、カーチャンに怒られてると思えば愛着が湧く...かも?(笑)」

持続可能なコードベースの維持

🍵「ライブラリのアップデート追従とか、昔は僕が所属していた取りまとめチームで Changelog を読んで『ここが変わったから対応が必要』ってサマリを書いて、各チームに動作検証を依頼 してたんだよ...。英語の長文と格闘する日々だったなぁ」

🚀「うわぁ、一番やりたくない作業ですね...。今はライブラリ更新の担当チームが進捗管理から改修・テストまで実施 して、各開発チームでは『特に影響がありそうな箇所』に絞って事前チェックするフローになっていますね」

🍵「なるほど、それなら各チームは自分たちの機能開発に集中できるね」

🚀「そうなんです!ライブラリのアップデート対応によるスループット低下を最小限に抑えつつ、お互いの専門領域に集中できる ようになったので、組織全体の生産性も上がっていると思います」

🍵「あと、コードの削除も大変でね。昔『呼ばれていないはずのコード』を確認するために念のため警告ログを仕込んだら、実はそのコードが大量に呼ばれていて、ログサーバーを溢れさせたこともあったな...」

🚀「あるあるですね(笑)。ただ、今は『食べルンバ』 っていう内製のデッドコード検出ツールのおかげで、安全に削除候補を見つけられるようになりましたよ」

speakerdeck.com

🍵「ああ、あのツールは本当に便利だよね。おかげで、ログに怯えながらコードを消す必要がなくなったのは大きいよ」

🚀「はい! プロセス内で実行された行をマークする仕組みで、本番環境で実際に使われたコードと、そうでないコード(デッドコード)を可視化 できるんです。使われていないメソッドを BigQuery で集計できるので、削除候補を見つけるのが格段に楽になりました」

🍵「ネーミングセンスは独特だけど、やってることはめちゃくちゃ高度だよね。そうやって『負債を溜めない仕組み』ができているのは素晴らしいよ」

アーキテクチャとDB設計:Excelマトリックス vs オブザーバビリティへの挑戦

🍵「コードの次はデータの話だね。昔はテーブルの使用状況を把握するのも一苦労で、『どのテーブルがどの画面で使われているか』を管理するために、Excelで巨大なマトリックス表 を作って運用してたよ。更新漏れがあったら終わりなんだけどね(笑)」

🚀「うわぁ、その運用は想像したくないですね...。今は規模が大きすぎて、人力のマトリックスじゃ破綻してしまいます。だからこそ、組織としてマイクロサービス化を推進する体制 が整えられ、システムをドメインごとに分割しようと動いていますよね」

🍵「20年分の重みがあるから、解体するのも一苦労だよね」

🚀「そうですね。正直、一朝一夕にはいかない『道半ば』の挑戦 です。でも、だからこそ分散トレーシングなどのオブザーバビリティ(可観測性) を高める取り組みも始まっていますし、『巨大なモノリスを現代的なアーキテクチャへ進化させる』という、エンジニアとして一番燃えるフェーズ にいるとも言えますよ!」


🍵「技術的な話はずいぶんしたけど、最後にもう一つ、僕が大事だと思っていることについて話してもいいかい?」

🚀「もちろんです! 技術以外の『開発文化』の話ですね?」

🍵「そう。ツールや環境が変われば、そこで働く人たちの関わり方も変わる。でも、変わっちゃいけないものもあるはずなんだ」

開発文化の変遷:変わる景色、変わらない魂

コミュニケーションと交流:物理イベントからリモート雑談へ

🍵「例外が大量発生すると、オフィスの一角に集まってホワイトボードで作戦会議をしたもんだ。物理的に顔を突き合わせてると、不思議と一体感が生まれるんだよね。あの時の『みんなで何とかするぞ』っていう熱気は、今でも覚えてるよ」

🚀「形は違いますけど、今も障害時はオンラインの会議スペースに全員集合 しますよね。関係者が増えたりリモート環境になったりしても、音声と画面共有でリアルタイムに連携しながら、あの『全員でなんとかする』空気感はしっかり受け継がれてる気がします。むしろ、離れていてもログやグラフを全員で同じ画面で見られる分、効率的かもしれません」

🍵「あと、昔はもっと『フィジカルな交流』も多かったなぁ。新卒が入ると『あだ名』をつける文化があったり、オフィスでうどんを打ったり...。食べログ関係者全員でイベントホールを借りて忘年会をした時は、各部署でダンス動画を撮って繋ぎ合わせた映像 を流して盛り上がったりもしたよ。餅つき大会なんて、まさに『同じ釜の飯を食う』って感じだった」

🚀「うどん!? しかも全員でダンス動画ですか、すごい熱量ですね...! 今も飲み会とか、MTG冒頭のアイスブレイクとかで結構雑談してますよ。1on1が文化として定着 しているおかげで、メンタル面のフォローは昔より手厚くなってるかもしれません」

🍵「なるほどね。ちゃんと『人となり』を知る機会はあるわけだ。じゃあ今度、みんなで何か美味しいものでも食べに行こうか」

🚀「それはぜひ! 技術の話だけじゃなくて、くだらない話で盛り上がれる関係性は、今も昔も変わらない資産ですからね」

技術選定とエンジニアの矜持

🍵「こうして振り返ると、使うツールも言語のバージョンも、インフラも開発フローも、何もかも変わったように見えるけど...」

🚀「でも、『ユーザーのために、技術で解決する』 という根っこの部分は変わってないですよね。昔の先輩たちが泥臭く守ってくれた土台があるから、僕たちは今、新しい技術に挑戦できているんだと思います」

🍵「そう言ってもらえると、喉を枯らして『デプロイしまーす!』って叫び続けてた甲斐があるよ(笑)。これからの20年は、もっと変化が激しくなるだろうけど、君たちなら大丈夫そうだね」


おわりに:20年の積み重ねを、次の20年へ

食べログの20年は、技術的負債との戦いであると同時に、技術を楽しみ、変化を恐れないエンジニアたちの歴史でもありました。物理サーバーからクラウドへ、そしてAI時代へ。ツールや環境は劇的に変化しましたが、私たちの根底にある「ユーザーのために、技術で解決する」「困難な時こそ、チームで協力して乗り越える」という魂は変わりません。これからも、私たちは過去の積み重ねを糧に、新しい技術を貪欲に取り入れながら進化し続けていきます。


🍵「...って、ちょっと真面目に語りすぎたかな?」

🚀「いいじゃないですか。たまには先輩らしいところも見せてくださいよ(笑)。さて、次の20年は僕たちがもっと面白くしていきますから、期待しててください!」

🍵「頼もしいねぇ。そうそう、アドベントカレンダーはまだまだ続くからね。明日の記事も楽しみだ」

🚀「はい! 明日はshiraishiwataru さんの「「黄色いサイト」から「AIネイティブ」へ。新卒15年目が見た、食べログデザイン変遷記」 ですね。お楽しみに!」

🍵「ちなみに、12/13〜12/25のアドベントカレンダー後半戦は『食べログ20周年記念特集』になっているから、他の記事でもディープな歴史が語られているかもしれないよ。要チェックだね」

🚀「おぉ、それは気になりますね! 皆さん、ぜひ読んでみてください!...そして、僕たちと一緒にこれからの20年を作っていく仲間 も募集してますよね?」

🍵「もちろん! 歴史を知る人も、これから歴史を作る人も、大歓迎だよ。ご興味のある方は、ぜひこちらもチェックしてみてね」


※本記事の執筆にあたり、新旧問わず多くのエンジニアにエピソード提供やレビューのご協力をいただきました。この場を借りて感謝申し上げます。

検索
プロフィール

株式会社カカクコムが運営する「食べログ」の開発者ブログです。

引用をストックしました

引用するにはまずログインしてください

引用をストックできませんでした。再度お試しください

限定公開記事のため引用できません。

読者です読者をやめる読者になる読者になる

[8]ページ先頭

©2009-2025 Movatter.jp