食べログアプリでの技術的負債との向き合い方

こちらのイベントの登壇資料です
【クルーズ/ZOZO/カカクコム(食べログ)各社の技術負債への向き合い方！】技術で切り開く未来～長期運営プロダクトが抱えた苦境と変化の話～ TECH HILLS #1

Transcript

1. © Kakaku.com Inc. All Rights Reserved. 食べログアプリでの 技術的負債との向き合い方 TECH HILLS #1 食べログシステム本部アプリ開発部 太田 定志 2021年11月24日（水） 1
2. © Kakaku.com Inc. All Rights Reserved. 自己紹介 太田 定志（おおた さだし） • 2018年 株式会社カカクコム入社 • 食べログアプリ開発部 基盤チーム リーダー • アプリ開発部 34名（内、基盤チーム 6名） • 食べログアプリに関わっているのは20名強ぐらい • 主にAndroidアプリを担当 • 初めてAndroid触ったのは2010年 • 最近の業務 • アーキテクチャの見直し、リファクタリング 、OS/ライブラリのアップ デート、リリースフローの最適化、CI/CDの改善、開発環境の整備、採 用、チームビルディング などなど、、、 • 趣味 • 漫画、アニメ鑑賞（割となんでも） • Twitter • @sadashi_ota • Qiita • sadashi 2 TWITTER, TWEET, RETWEET and the Twitter logo are trademarks of Twitter, Inc. or its affiliates. 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. © Kakaku.com Inc. All Rights Reserved. 目次 1. 食べログについて 2. 食べログAndroidアプリの技術的負債 3. どういった戦略を取ったか 4. 実際にやってみて 5. まとめ 3
4. © Kakaku.com Inc. All Rights Reserved. 1. 食べログについて 4
5. © Kakaku.com Inc. All Rights Reserved. 食べログについて 5 食べログとは？ 月間1億UU*を超える国内最大規模のグルメサービス ※PC、スマートフォンアプリ、スマートフォンサイトの合計 独自のランキングやユーザーの口コミ・写真 をもとに、様々なジャンルの人気のレストラン、 目的や予算にぴったりのお店が見つかり、 簡単にネット予約できます。 *2021年6月現在。サイトを訪れた人をブラウザベースで数えた利用者数です（特定環境下では一定期間経過後に再訪した利用者を重複計測する場合があります）。 なお、モバイル端末のウェブページ高速表示に伴う利用者数の重複や、第三者による自動収集プログラムなどの機械的なアクセスについては可能な限り排除して計測しています。
6. © Kakaku.com Inc. All Rights Reserved. 2. 食べログAndroidアプリの技術的負債 6
7. © Kakaku.com Inc. All Rights Reserved. 食べログAndroidアプリの技術的負債 7 食べログAndroidアプリ • アプリ初版リリースから10年以上経過 • 2014年フルリニューアル以降、ずっとサービスの改善を継続してきた • ソースコードは23万ステップぐらい • 画面数は100を超える規模 • 機能もたくさん • 店舗の検索 • 店舗の詳細情報閲覧 • 口コミ投稿 • 口コミ閲覧 • 予約 • 保存（ブックマーク的なもの） • 認証（複数プロバイダ） • 課金（Play Billingを利用した定期購入） • ユーザー間でのメッセージのやり取りやフォロー • 色々なコンテンツ配信 • The Tabelog Award、百名店、食べログマガジン など
8. © Kakaku.com Inc. All Rights Reserved. 食べログAndroidアプリの技術的負債 8 どんな技術的負債があったか（2018年時点） • 実際にあった技術的負債は色々 • 依存関係、責務の分離 • Deprecated になったOSSやAPI • 食べログAPIメジャーバージョンアップ時の負債 • 利用言語や開発環境が古い • 負債の内容はそれぞれよくあるアンチパターンではある • しかし、それらが複合的に作用しているためかなり複雑 • 何段階も継承関係があるFatなUIクラス • 色々なクラスから参照される神クラスがさらに継承関係も持っている • 返済が滞っている原因 • コードベースの大きさ • 全てを修正するにはどうしても時間がかかってしまう • テスタブルな構成にはなっていないため、テストコードがない • モノリスな１モジュール構成
9. © Kakaku.com Inc. All Rights Reserved. 3. どういった戦略をとったか 9
10. © Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 10 アプローチ方法
11. © Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 11 ビッグ・リライト or リアーキテクティング ビッグ・リライト（フルスクラッチ） リアーキテクティング、リファクタリング メリット • ０から作るので過去から解放される • テスタビリティも確保しやすい • トータルの工数は比較すれば少なく済むかも * • 部分的にリリースできる • コンフリクトしなければ機能追加のキャッ チアップは不要 • 仕様を把握しながら進められる デメリット • 最後まで作らないとリリースできない • 機能追加のキャッチアップが辛い • 全体仕様を把握してないとバグがでやすい • スケジュールは伸びがち • トータルの工数は多くなる • 既存コードへ影響があるので難易度は高い • 既存の仕様やバグに苦しむかも ※リファクタリング、リアーキテクティング、ビッグ・リライトについては 書籍「レガシーソフトウェア改善ガイド（著者 Chris Birchall）」2016年 翔泳社出版 の第1部を参照 * あくまでリファクタリングだけですべてのコードをきれいにするのに比べたらという意味
12. © Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 12 リアーキテクティングを選択 基本的には初めにリファクタリング・リアーキテクティングを検討すると良い • インクリメンタルに進めた方がメリットは大きい • 対応をしたものは、早急に恩恵が得られる • 開発メンバーのFeedbackも得られる • ビッグ・リライトはリスクもあるので最後の手段 コードベースが大きいので、ビッグ・リライトでもかなりの時間を要する • その間の機能開発をすべてキャッチアップするのはかなり厳しい 全体仕様を把握するのはかなり難しい • 分野によって仕様に詳しい人が違ったり、そもそも誰も知らなかったり • 実際に動いてるコードを調査しながら進めるのが無難
13. © Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 13 リアーキテクティングを選択 厳密にはリアーキテクティング→ミニリライト • １ヶ月ぐらいの規模で既存の一部をリライトしていく手法 • 依存しているOSSの負債があったため、UI部分を刷新する必要があった • そこはフルKotlinでリライトする • 合わせてロジック部分もちょっとずつ分離してリライトする • 画面単位でリライトしてリリースできるので、ビッグリライトよりリスクが低い • その準備としてリアーキテクティングを行う 神クラス UI UI UI UI UI 新UI ロジック 神クラス
14. © Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 14 リソースどうするか
15. © Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 15 なかなかリソースを確保するのは難しい • 技術的負債の返済に関する工数を確保するのは難しい • 障害対応をはじめとした日々の保守 • 事業的に重要度・緊急度の高い案件がくると、どうしても優先せざるを得ない • 片手間でやるには大きすぎるので、抜本的な改善は手がつかない
16. © Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 16 部隊を分ける • サービス開発 • プロダクトの改善がメインミッション • ユーザーに価値を届ける • 基盤 • リファクタリング、環境改善などの専門チーム • OSバージョンやライブラリの更新、CI/CDの改善など • 基盤チームではプロダクト自体の改善は行わないので、エンジニアだけの独立したチーム • コミュニケーションパスが少ない • 技術的負債の返済や環境改善、保守対応などに集中できる • サービス開発側もユーザーへ如何にして価値を届けるかにフォーカスできる
17. © Kakaku.com Inc. All Rights Reserved. 4. 実際にやってみて 17
18. © Kakaku.com Inc. All Rights Reserved. 実際にやってみて 18 最初は地盤固め • とはいえ、最初基盤チームのAndroidエンジニアは1人でした、、、 • 最初の一年は地盤固め • 環境整備 • サービス開発側へのヒアリング • アーキテクチャ選定 • 採用活動
19. © Kakaku.com Inc. All Rights Reserved. 実際にやってみて 19 最初は地盤固め • とはいえ、最初基盤チームのAndroidエンジニアは1人でした、、、 • 最初の一年は地盤固め • 環境整備 • サービス開発側へのヒアリング • アーキテクチャ選定 • 採用活動 現在 • 1年後には３名、今では４名体制になりました • 大きいことをやるには仲間集めは大事 • チーム内だけでなくチーム外へのコミュニケーションも • 人数が増えたことに合わせて自分自身の役割もシフト • 今はマネジメント寄り • チームビルディング、採用活動など • なるべくリライト以外のタスクを拾ったり
20. © Kakaku.com Inc. All Rights Reserved. 実際にやってみて 20 並行してやらなきゃならないことが多々ある • チームを分けたけど、基盤チームもやることは色々ある • OSアップデート対応は毎年必要 • 開発環境のアップデート、ライブラリの更新作業 • リリースフローの最適化、自動ビルド、アプリ配布など • 食べログぐらいの規模だとそれぞれの対応にも割とコストがかかる • 「オレが3人分になる・・・」なんてことは難しい
21. © Kakaku.com Inc. All Rights Reserved. 実際にやってみて 21 並行してやらなきゃならないことが多々ある • チームを分けたけど、基盤チームもやることは色々ある • OSアップデート対応は毎年必要 • 開発環境のアップデート、ライブラリの更新作業 • リリースフローの最適化、自動ビルド、アプリ配布など • 食べログぐらいの規模だとそれぞれの対応にも割とコストがかかる • 「オレが3人分になる・・・」なんてことは難しい 対策 • リアーキテクティング・リライトは専任にする • 集中してスピード感を出していきたい • なるべくコンテキストスイッチを減らす • 人 or 時間で分けると良さそう
22. © Kakaku.com Inc. All Rights Reserved. 実際にやってみて 22 レガシーコードに向き合う辛さ 結局のところこれが一番大変 • 仕様書は詳細には整備されてない • リライトする画面については、レガシコードをひたすら調査 • かなりのスパゲッティなので、紐解くのが相当大変 • 延々と過去と向き合うような作業が多い • ふりかえりでも思考がネガティブになっていることが実際にあった • 右上の付箋は実際にMiroでふりかえりを行った時のもの • チームメンバーは正直者なので、ふりかえりでは遠慮なく愚痴ってますw
23. © Kakaku.com Inc. All Rights Reserved. 実際にやってみて 23 レガシーコードに向き合う辛さ 対策 • 仕様面に関してはサービス開発側にも協力してもらう • 要所でのレビューや、事前調査時の仕様確認など • 個々のモチベーション向上 • 新しい技術のキャッチアップのために、定期的なチーム内勉強会も実施 • 刷新後に、こういった技術を入れるとこういった世界が待ってる みたいなイメージにつながる • 課題があったときは1人で悩まずみんなで解決 • リモートだからこそ孤立しないようにするケアは特に大事 • モブワークが有効 • 去年こんな記事も書いてます「リモートワークでモブプロをやってみた」 • 定期的な朝会、夕会、ふりかえりなども良いコミュニケーションの場 • 意図的に雑談する場もあるといい • ふりかえりのやり方も工夫しています（KPT→Fun/Done/Learnに変えたり）
24. © Kakaku.com Inc. All Rights Reserved. 実際にやってみて 24 進捗状況 • 最初のリファクタリングを開始してから2年経過 • やっとKotlin化は 20%弱 → 50% Over！！ • 店舗や写真の詳細画面など、主要な画面もいくつか対応済み • サービス開発側からも、リアーキテクチャしてから案件対応したいという声も上がっている • コードも整理されて品質も向上している • 3ヶ月間の1.2万クラッシュの内、刷新した画面のクラッシュはわずか229（2%弱） 今後について • だいぶレガシーコードへの耐性（ノウハウ）も溜まってきた • まだまだ主要な画面も残っているので、対応を加速させていきたい • 目処がついたら、新しいことへのチャレンジも検討したい • Jetpack Compose （宣言的UI）の導入など
25. © Kakaku.com Inc. All Rights Reserved. 5. まとめ 25
26. © Kakaku.com Inc. All Rights Reserved. まとめ 26 • ビッグ・リライト or リアーキテクティングは状況によりけり • メリット・デメリットを考えて選択する • 基本的にはリファクタリング・リアーキテクティングでできないか最初に考える • 判断に迷うならまずはリファクタリングしてみるのもOK • 規模が大きいシステムはやることに応じてチームを分けるのも手 • 規模に比例して難易度が上がるタスクは個別チームでないとなかなか手が回らない • チーム力やモチベーションが大事 • 結局のところ「人」がやるので、個々のモチベーションは生産性に直結する • 課題解決は個人よりモブでやった方が速い • 全員のレベルアップにもつながる • 日頃からチームで解決していけるように、細かくコミュニケーションを取れるように なっていると良い • 特にリモートワーク環境下では意識的にやった方がいい
27. © Kakaku.com Inc. All Rights Reserved. 最後に 27 We are hiring！！！ • 一緒にAndroidのリアーキテクチャやりませんか？ • もちろんAndroid以外のエンジニアも募集してます • カジュアル面談大歓迎ですのでお気軽にご連絡ください • https://hrmos.co/pages/kakakucom/jobs/1011510
28. © Kakaku.com Inc. All Rights Reserved. ご清聴ありがとうございました 28 Android is a trademark of Google LLC. Kotlin is a registered trademark of the Kotlin Foundation. IOSは、Cisco の米国およびその他の国における商標または登録商標であり、ライセンスに基づき使用されています。