この記事は 食べログアドベントカレンダー2025 の14日目の記事です🎅🎄。
こんにちは。食べログでAndroidアプリのテックリードをしているsadaです。
普段は食べログAndroidアプリのリアーキテクチャ、自動テスト環境整備、開発基盤のアップデートなどを担当しています。
上記のほか、新規アプリ立ち上げ時のサポートや、AI活用の推進などにも携わっています。
食べログAndroidアプリは初版リリースから今年で14年が経ちました。
ここまでアプリがどのように変わってきたのか、まずは百聞は一見にしかず、歴代のスクリーンショットをご覧ください。
Android初期から開発に携わっていた方は最初のアプリのようなUIが懐かしいのではないでしょうか？
この14年間、UIだけでなく内部のアーキテクチャも大きく変化し続けてきました。
今回はその長い歩みを振り返りつつ、そこから私たちが何を学び、今後どのような技術的挑戦をしていくのかをお伝えしたいと思います。
目次
- アプリリリースからの7年間と、積み上がった「光と影」（2011年12月〜）
- リアーキテクチャプロジェクト発足（2018年8月〜）
- コロナ禍での対応と体制の変化（2020年3月〜）
- プロダクトの躍進と断続的な組織の変化（2022年4月〜）
- インバウンド向け新規アプリ開発と技術的負債の解消（2025年4月〜）
- 学び
- AIネイティブ時代のAndroid開発へ
アプリリリースからの7年間と、積み上がった「光と影」（2011年12月〜）
食べログのサイト公開から約7年。SPサイト（スマートフォン向けサイト）が約580万MAUに達し、iOSアプリも順調に成長していた2011年12月、満を持してAndroidアプリの初版がリリースされました。
初版リリースの舞台裏とEclipseの時代
2011年12月、無事初版のリリースを迎えましたが、リリースされたアプリは品質面で多くの課題を抱えていました。バグの多発に加え、当時のAndroid端末特有の不安定さも重なり、ユーザー体験を損なう事態も少なくありませんでした。
開発環境もEclipse + ADTが主流の時代です。ビルドやデバッグに膨大な時間を要するなど、現在のAndroid Studioの快適さからは想像もつかないような苦労がありました。
その後、2014年にはこれらの課題を解消すべくフルリニューアルを実施。外部パートナーを増員し、チーム一丸となって性能・安定性の改善に取り組みました。
組織の分化と技術支援体制
事業の急成長に伴い、機能拡充やUI/UX改善が優先される一方で、裏側では技術的負債が確実に蓄積していました。調査・テスト工数の増大や、影響範囲の肥大化といった問題が顕在化し始めたのです。
この状況を打破するため、組織を「プロダクト開発チーム（機能開発主導）」と「基盤チーム（技術支援主導）」に分割し、負債返済への体制を整えました。
Androidフルリプレース計画の頓挫
開発トレンドがSwift/Kotlinへ移行する中、採用競争力の観点からもモダン技術への刷新が急務となりました。
当初は段階的なリプレースも検討されましたが、「技術的負債の返済」に対する投資対効果を経営層へ説明する難しさもあり、API最適化とセットにした「一気通貫のフルリプレース」へと舵を切りました。
2016年、iOS版はフルリプレースを完遂。しかしAndroid版は、リードエンジニアの退職などが重なり、計画は無念の頓挫。
その結果「新APIへの対応」だけは必要であったため、アプリ内で「新APIのレスポンスを旧APIの形式にマッピングする」という不毛な処理を追加せざるを得なくなりました。
負債を解消するための計画が、新たな、そしてより深刻な負債を生む結果となってしまったのです。
サービス全体が約7,470万MAUという巨大な規模へ成長する裏で、Androidアプリの負債解消は進まず、iOSエンジニアが兼任で延命処置を行うという苦しい時期が続くことになりました。
リアーキテクチャプロジェクト発足（2018年8月〜）
当時、Androidアプリの技術的負債が深刻化しているにもかかわらず、その解消を主導できる人材が不在という状況でした。
以前から「食べログ」に関心を持っていた私は、この状況を知り応募しました。「食べログ」ほどの大規模サービスにおいて、技術的負債の解消という難題に挑める点は非常に魅力的で、そのまま入社を決意したことを今でも覚えています。
入社後すぐに、Androidアプリのリアーキテクチャプロジェクトが始動しました。 このプロジェクトでは「事業を止めずに刷新する」ことを大前提としました。通常、アプリをリプレイスする期間はプロダクト開発が停滞し、事業成長の機会を損失するリスクがあります。しかし私たちは、事業成長と技術的健全性の両立を目指しました。
完全な刷新までの期間は長くなりますが、重要度や修正頻度の高い画面から優先的に着手する方針を策定しました。これにより、プロジェクトの途中段階からリアーキテクチャの効果を実感できるようにし、長期化に伴うリスクを最小限に抑えるアプローチをとりました。
プロジェクトの詳細は以下のブログにまとめています。技術的負債の具体的内容や、プロジェクト途中段階での成果についても触れていますので、ぜひご覧ください。
このように技術的負債の返済を進める一方で、プロダクトにおいては「地図検索のリニューアル」などユーザー価値に直結する改善も実施し、2019年には「Google Play ベスト オブ 2019 生活お役立ち部門賞」を受賞することができました。
コロナ禍での対応と体制の変化（2020年3月〜）
迅速なサービス貢献とリモートワークへの適応
コロナ禍では、飲食店への貢献を第一に考えて動いていました。
アプリとしては、お知らせ機能、テイクアウト情報、感染症対策情報の掲載に加え、サービスとしてもテイクアウトアプリを立ち上げるなど、少しでも貢献できる施策を迅速に提供し続けました。
この時期は働く環境も激変し、リモートワークへの移行が急務でした。
以前はリモートワークが主流ではなかったため、開発環境の整備は急ピッチで進められました。
当時利用していたPCもデスクトップのiMacだったため、取り急ぎ梱包してタクシーで自宅まで帰宅したのは良い思い出です。
また、チームとしても環境が大きく変わったため、コミュニケーション設計や心理的なケアなど、チームビルディングに注力しました。
例えば、リモートの利点を活かして画面共有とホワイトボードツールを活用したモブプロを試みるなど、より良い環境を目指して工夫を凝らしました。
参考記事
マトリクス型組織への移行とチーム間連携の強化
2020年10月頃からは、プロダクト開発チームはミッション単位でチームを分ける「マトリクス型組織」へと移行し、各ミッションに深くフォーカスする体制になりました。
この体制により部署間調整などの課題が解決され、事業はさらに伸長していきます。
一方で、食べログAndroidアプリの負債解消も継続していたため、プロダクト開発チームと基盤チーム間の連携には細心の注意を払いました。
具体的には、リーダー間の定例会、チャットツールでの案件共有チャンネルの開設、そして基盤チーム側から仕様確認段階で積極的にプロダクト開発メンバーを巻き込むなど、お互いの状況を透明化する仕組みを構築していきました。
参考記事
新規事業へのシフトとモダンな技術選定
そして2021年の夏頃、飲食店向けサービス（食べログオーダー・食べログノート）のプロジェクトが立ち上がり、アプリ開発メンバーの約半数が新規事業へシフトしました。
その一つ、予約台帳アプリ「食べログノート」（2022年春リリース）のAndroid版では、GraphQLを採用し「スキーマドリブン開発」を実践しています。
UIツールキットには、GraphQLと相性のよいJetpack Composeを採用しました。当時はまだJetpack Composeの安定版が出たばかりでしたが、宣言的UIとの親和性を高く評価し、採用に至っています。
参考記事
プロダクトの躍進と断続的な組織の変化（2022年4月〜）
前述したマトリクス型組織によって施策の推進スピードが加速し、プロダクトは再び大きく躍進しました。
その一方で、ミッションやテーマの変遷に伴い組織も断続的に変化し、案件の優先度も流動的でした。そのため、プロダクト開発チームは組織変更への追従を、基盤チームは状況に合わせたリアーキテクチャの優先度判断を行うなど、変化への適応が不可欠な期間となりました。
Androidアプリの技術面に関しては、リアーキテクチャと並行してSmallなユニットテストの実装は進んでいましたが、Medium/Largeサイズのテスト導入が追いついていない課題がありました。
そこで、手動テストでカバーしていた範囲の一部をMediumテストへ移行したほか、スクリーンショットテストの導入などを推進しました。
食べログAndroidアプリの自動テスト戦略については以下をご参照ください。
インバウンド向け新規アプリ開発と技術的負債の解消（2025年4月〜）
今年に入り、海外からの旅行客をターゲットとしたインバウンド向けアプリの開発プロジェクトが始動しました。iOS版が先行していましたが、Android版も6月中旬から開発に着手しています。
すでにWeb版は公開済みで、急増するインバウンド需要に応えるために「スピード感のあるリリース」が求められていました。一方で、完全新規のアプリであるため、「可能な限りモダンな技術を取り入れたい」というエンジニアとしての想いもありました。
そこで今回は、メンバーの既存スキルセットにとらわれず、モダンな構成を積極的に採用する方針をとりました。その分、学習コストやリリース日程のリスクを考慮し、通常より厚めの人員体制でバランスをとっています。
技術スタックは以下の通りです。
- UI: Jetpack Compose
- Architecture: Clean Architecture + MultiModule
- Presentation: UDF (Unidirectional Data Flow)
これは現代のAndroid開発におけるスタンダードな構成と言えます。インバウンド版は国内版アプリとデータフローや画面構成が近いため、ここで得た知見は、将来的に国内版アプリをComposeへ完全移行する際への布石となると見込んでの判断でした。
結果として、2025年11月に無事リリースを迎えることができました。
開発の詳細は、アドベントカレンダー11日目の記事で詳しく紹介していますので、ぜひご覧ください！
そしてついに、長年取り組んできたAndroidアプリのリアーキテクチャも完了の段階を迎えました。
コードの100%が浄化されたわけではありませんが、9割以上の画面設計が刷新され、メンテナンスされていない古いライブラリの撲滅も完了しています。
参考までにリアーキテクチゃが完了した状態の技術的な健全性の指標として、以下の値を計測しています。
技術的健全性の可視化（リアーキテクチャの成果）
コード割合（Javaからの脱却）
リアーキテクチャ開始当初はコードベースの9割がJavaでしたが、Kotlin化がどこまで進んだかをclocを用いて定点観測しました。
| 年月 | java code | java % | kotlin code | kotlin % | total code |
|---|---|---|---|---|---|
| 2018年8月 | 187,952 | 91.0% | 18,596 | 9.0% | 206,548 |
| 2022年12月 | 149,884 | 39.6% | 228,924 | 60.4% | 378,808 |
| 2025年11月 | 26,974 | 4.6% | 566,206 | 95.4% | 593,180 |
結果として、Kotlin率は95.4% に達しました。
修正頻度や重要度の低い一部のレガシーコード等はJavaのまま残していますが、実質的な開発におけるKotlin化は完了したと言えます。
複雑度（保守性の担保）
コードの複雑度計測にはdetektを採用しました。 ここでは、リアーキテクチャ過程で追加された「Kotlinコードの複雑度」の変化に注目しています。
| 年月 | lloc | total code mcc | total code smells | mcc per 1,000 lloc | code smells per 1,000 lloc |
|---|---|---|---|---|---|
| 2018年8月 | 12,367 | 2,846 | 1,950 | 230 | 157 |
| 2022年12月 | 163,533 | 24,371 | 5,741 | 149 | 35 |
| 2025年11月 | 427,459 | 57,736 | 8,666 | 135 | 20 |
特筆すべきは、コードベースが約3倍に膨れ上がっているにも関わらず、複雑度（mcc per 1,000 lloc）は大幅に低下しているという点です。
これは、適切な設計導入によって「機能は増えても、コードの見通しは良くなった」ことを示しており、リアーキテクチャの最大の成果と言えます。
テストコード量（安全網の拡充）
テストコードが全く存在しなかった初期状態から、どれだけ「安全網」を拡充できたかをclocで計測しました。
| イベント | 年月 | テストコード |
|---|---|---|
| 入社 | 2018年8月 | 0 |
| 最初のテストコード | 2019年4月 | 445 |
| リファクタリング開始 | 2019年11月 | 15,323 |
| リアーキテクチャ開始 | 2020年1月 | 47,502 |
| 以前のテックブログ | 2022年12月 | 83,199 |
| 現在 | 2025年11月 | 210,486 |
以前テックブログで紹介した時点から比較しても、飛躍的に増加しています。
これは単純なユニットテストの量産だけでなく、UIテストなど多様なサイズのテストを拡充してきた結果です。
テストカバレッジ（品質の保証範囲）
Jacocoを利用し、コード量だけでなく「重要なロジックが守られているか」をカバレッジで監視しました。
以前の結果（2022年12月ごろ）
| レイヤー | C0（命令網羅） | C1（分岐網羅） |
|---|---|---|
| Presentation | 30% | 21% |
| UseCase(Domain) | 74% | 64% |
| Infrastructure | 62% | 18% |
最新の結果（2025年11月ごろ）
| レイヤー | C0（命令網羅） | C1（分岐網羅） |
|---|---|---|
| Presentation | 37% | 36% |
| Presentation（ロジック部） | 63% | 53% |
| UseCase(Domain) | 77% | 59% |
| Infrastructure | 79% | 67% |
Presentation層に関しては、Viewへのバインディングや画面遷移・計測などを行う「ロジックが集約されたクラス」に焦点を絞ってテストしています（表中「Presentation（ロジック部）」）。
闇雲に全体の数値を追うのではなく、「壊れてはいけない重要なポイント」に絞ってテストを厚くするアプローチをとっています。
さらに、ユニットテストだけではカバーしきれない領域については、自動テストの導入で品質保証の範囲を広げました。
- リグレッションテストの自動化: 手動ケースの約7割（206/292ケース）を自動化
- VRTの導入: 66パターンのスクリーンショットテストを作成
学び
技術的負債の「複利」を甘く見てはいけない
冒頭で触れた通り、諸事情により返済が滞った結果、技術的負債は膨大な量へと積み上がってしまいました。
負債の一つひとつは小さくても、それらが相互に依存し合うことで複雑化し、返済コストは指数関数的に跳ね上がります。
まさに「借金（Debt）」の名の通り、放置すれば利子が膨らむため、計画的な返済サイクルの重要性を再認識しました。
「プロダクトを止めない」選択が生んだ柔軟性
今回、プロダクト開発を止めずにリファクタリングを進めたことは、結果として正解でした。継続的にユーザーやQAからのフィードバックを得られる状態を維持できたからです。
おかげで、状況に応じて優先度を入れ替えたり、実装方針を微修正したりと、臨機応変なハンドリングが可能になりました。
（例：非同期処理の移行をRxJavaからCoroutinesへ変更するなど）
また、プロダクト案件の緊急度が高い時期はそちらにリソースを寄せ、余裕がある時はチーム全員で負債返済に注力するなど、リソース配分の最適化も図れました。変化の激しい成長フェーズにおいて、この「柔軟さ」こそが、事業成長と改善の両立に寄与したと考えています。
AIネイティブ時代のAndroid開発へ
現在のAI活用と、その先へ
現在も、調査・設計・コーディング・テスト項目の作成といった各工程でAIを導入しています。PRの自動レビューや、detektとDevinを連携させた軽微な負債の自動改修などもその一例です。
AIファーストな世界観を目指して
今後は、要件定義からテストまで、すべてを「AIファースト」で進める世界を目指します。
今回の負債解消によってコードベースのコンテキスト（文脈）が整理されたこと、そして自動テストが拡充されたことは、AI活用における大きなアドバンテージとなりました。AIが生成したコードの品質をテストで担保できる領域が広がったからです。
今後も環境整備は必要ですが、今回の取り組みが「AIファースト」への強固な土台になったことは間違いありません。
私たちと一緒に、次世代の開発プロセスを構築したいという方、ぜひお気軽にお声がけください！
明日は Tabelog Tech Blog編集チーム による「データと語るグロースハックの裏側 - 食べログは何故、20年間成長し続けられているのか。」です。お楽しみに!
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
