食べログAndroidアプリ プロダクトを止めないリアーキテクチャの実践知

モバイルアプリの長期運用と向き合う ~10年以上続くアプリで重ねてきた判断と工夫~
https://findy.connpass.com/event/382789/

登壇資料「食べログAndroidアプリ プロダクトを止めないリアーキテクチャの実践知」

Transcript

1. 食べログAndroidアプリ プロダクトを止めない リアーキテクチャの実践知 食べログカンパニー 開発本部 アプリ基盤チーム 2026年2月19日（木） 1 太田 定志
2. 太田 定志（おおた さだし） • 2018年 株式会社カカクコム入社 • 食べログカンパニー 開発本部 技術部 アプリ基盤チーム • 主にAndroidアプリを担当 • アーキテクチャの見直し、リファクタリング、OS/ライブラリのアップ デート、リリースフローの最適化、CI/CDの改善、開発環境の整備、採 用、チームビルディング などなど、、、 • X • sada(@sadashi_ota) • GitHub • @sadashi-ota • Qiita • sadashi 2 The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License. 自己紹介
3. 食べログについて 食べログは20周年を迎えました！ 20周年を記念して、昨年のAdventCalendarでは テックブログで色々な記事が紹介されています。 その中で、食べログAndroidアプリの歴史を振り返る記事も書きましたのでよ かったらご覧ください。 https://tech-blog.tabelog.com/entry/advent-calendar-20251214
4. 食べログAndroidアプリも初版リリースから14年が経ちました。 色々な出来事、意思決定が行われてきましたが、今日はその中でも特に大きかっ た「リアーキテクチャプロジェクト」についてお話します。 今日の内容について
5. 目次 • 負債が大きく溜まった要因 • リアーキテクチャプロジェクトの方針 • うまくいったこと / 問題点 • 最後に
6. 負債が大きく溜まった要因
7. 負債はどんな時に溜まる？ • 継続的にプロダクトを改善していくと自然に溜まる ◦ 色々な人が色々な機能を実装していくので • 外部要因もあったりする ◦ OSアップデートとか、時代の流れとか • 実はポジティブな側面もある ◦ 学びの結果、今のコードが負債になるなど 負債が大きく溜まった要因
8. けど、自分たちで一番インパクトがあったのはリプレイスの中止 • リプレイスを進める途中で、退職・休職などが重なってしまい、リプレイスが頓挫して しまった • 両OSでリプレイスを進めており、合わせてAPIのバージョンアップ対応も行う予定で、 新APIへ最低限の対応は必要だった ◦ アプリ内に新レンスポンス → 旧レスポンス への変換処理を実装することになり さらなる負債となる • そして、単純にリードするような人が不在だったのもあり、改善が滞る 負債が大きく溜まった要因
9. そこでリアーキテクチャ プロジェクト開始！
10. 方針を決めるための判断材料 • プロダクトの状況は？ • 負債の状況は？ ◦ コードベースの量は？ ◦ 利用しているフレームワークやライブラリは？ ▪ 非推奨やメンテされてないものは移行する必要がある • 開発環境は？ ◦ AndroidStudioのバージョン、Linter、Formatter、CI/CDなど • メンバーやスキルセット リアーキテクチャプロジェクトの方針
11. 食べログの場合（リアーキテクチャを始める前） • プロダクトはまだまだ成長中 ◦ 機能追加だけでなく、UIのリニューアルもありえる • 負債はかなりあって、コードベースも多い ◦ 当時で20万行（9割Java）、テストコードはなし ◦ レガシーなライブラリも多々あり、旧APIの残骸も ◦ 設計も統一されてない • 開発環境は一部更新できていない • 自動ビルド、ストア更新の自動化はできてる • 当時はメンバーも足りていない リアーキテクチャプロジェクトの方針
12. 食べログの場合（リアーキテクチャを始める前） 技術的負債についての詳細はこちらのブログにまとめてます！ https://tech-blog.tabelog.com/entry/road_to_tech_debt_repayment_for_ android リアーキテクチャプロジェクトの方針
13. 何を優先したいのか？ • 当然、事業成長の機会損失は避けたい • フルリプレイスするとしても結構な期間が必要なのでなかなか厳しい ◦ 短期間に詰め込むとあまりいいことはない（と思う） • 負債の状況は結構深刻なので、なるべく早く返済したい • その前に開発環境は最新化しないと • そもそもメンバーが足りないのどうにかしないと • エンジニアとしてはゼロから綺麗にしたい気持ちも。。。 リアーキテクチャプロジェクトの方針
14. 方針1 : リプレイスはせずに徐々に改善する • プロダクトを止めない選択 • 優先度の高い画面・機能から順次対応してリリースする • どんなケースもこれが正解というわけではない ◦ プロダクトの状況、チームとしてのケイパビリティ、負債の状況など、総合的に 考える必要がある ◦ 過去からの学びや、将来の状況も想像するのも大事 リアーキテクチャプロジェクトの方針
15. 方針2 : チーム体制はプロダクトと基盤で分ける • 開発環境の整備は一番最初に進める • 人数的には足りてないので、やれることをやりつつ人集め • OS・ライブラリアップデートなどのタスクも並行して担当する • ただし、優先度の判断は基盤タスクだけでなく事業の状況も考慮する リアーキテクチャプロジェクトの方針
16. うまくいったこと
17. 「プロダクトを止めない」選択が生んだ柔軟性 • 状況に応じて優先度や実装方針の変更ができた ◦ モバイルは技術トレンドの変化が早い傾向がある ◦ 最初に選定した技術スタックがすぐ古くなるなんてこともしばしば ▪ 例 : 非同期処理をRxJavaからCoroutinesへ変更 ◦ もし、フルスクラッチで全部やってたら、その修正もさらに大変だった • 徐々に進めていたからこそ、状況の変化に対応できた ◦ 新しく課題が出てきた時も迅速に取り込める うまくいったこと
18. 「プロダクトを止めない」選択が生んだ柔軟性 • プロダクト案件の緊急度に応じて、リソース配分の最適化もできた ◦ チームは分けていたけど、状況に応じてヘルプにも入る ▪ 例 : 新規のアプリを作る時はファーストリリースまではそちらに入る etc ◦ 逆にプロダクト側の手が空く時はリファクタを手伝ってもらう うまくいったこと
19. チーム体制を分けて良かったこと • スピードは遅くなることもあるが、完全に止まることはなかった ◦ 常に最低１人は担当 • 技術的な課題へのアプローチも迅速にできた ◦ 自動テスト拡充 ▪ UIテスト ▪ スクリーンショットテスト うまくいったこと
20. 問題点
21. 柔軟性を優先した結果 • 完了するまでかなり長期化してしまった ◦ とはいえ、優先度の高い画面などは先行して進めたので、すべてが悪かったわけ ではない • 色々なものが共存するコードに ◦ 方針は早めに修正できるが、手を入れたコードがすぐ直るわけではない • そのため、JetpackComposeへの移行もなかなか進まなかった ◦ 今はやっと進み出した 問題点
22. 基盤チームとして分担したことの弊害 • 最初から基盤チームに入ると、プロダクト状況に疎くなりがち ◦ 複雑な部分だと仕様として何が正しいかを判断するのに時間がかかる ▪ 既存仕様の調査、ヒアリング • 大きめのアップデートを入れるにはそこそこのコストがかかる ◦ 画面数などが多いのでテストが大変 ◦ なかなかリアーキテクチャに注力できない時もあった 問題点
23. 最後に
24. 今回はリアーキテクチャプロジェクトを進める上での意思決定とその結果のお話 • どんなことにもメリット・デメリットはある ◦ 一番重要なポイントを据えて考えると整理しやすくなるかも • もしすぐには決めきれないことがあるなら、なるべく柔軟に動ける選択をしつつ、判断 を遅らせるのも手 ◦ 学びを得た上で再度判断していく • 今はAIという新しい武器も登場 ◦ 状況は大きく変わってきているので、違った選択ができるかも ◦ 例えば食べログでは、サーバサイドでAIによる自律的なリファクタリングも既に 実施しています 最後に
25. © Kakaku.com Inc. All Rights Reserved. 25 We are hiring！！！ • 一緒に食べログを成長させましょう！ • カジュアル面談大歓迎ですのでお気軽にご連絡ください • https://hrmos.co/pages/kakakucom/jobs 最後に
26. ご清聴ありがとうございました 26 Android is a trademark of Google LLC. Kotlin is a registered trademark of the Kotlin Foundation. IOSは、Cisco の米国およびその他の国における商標または登録商標であり、ライセンスに基づき使用されています。