食べログアプリでの技術的負債との向き合い方

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 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.

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© Kakaku.com Inc. All Rights Reserved. 食べログについて 5 食べログとは？月間1億UU*を超える国内最大規模のグルメサービス ※PC、スマートフォンアプリ、スマートフォンサイトの合計独自のランキングやユーザーの口コミ・写真をもとに、様々なジャンルの人気のレストラン、目的や予算にぴったりのお店が見つかり、簡単にネット予約できます。 *2021年6月現在。サイトを訪れた人をブラウザベースで数えた利用者数です（特定環境下では一定期間経過後に再訪した利用者を重複計測する場合があります）。なお、モバイル端末のウェブページ高速表示に伴う利用者数の重複や、第三者による自動収集プログラムなどの機械的なアクセスについては可能な限り排除して計測しています。

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© Kakaku.com Inc. All Rights Reserved. 食べログAndroidアプリの技術的負債 7 食べログAndroidアプリ • アプリ初版リリースから10年以上経過 • 2014年フルリニューアル以降、ずっとサービスの改善を継続してきた • ソースコードは23万ステップぐらい • 画面数は100を超える規模 • 機能もたくさん • 店舗の検索 • 店舗の詳細情報閲覧 • 口コミ投稿 • 口コミ閲覧 • 予約 • 保存（ブックマーク的なもの） • 認証（複数プロバイダ） • 課金（Play Billingを利用した定期購入） • ユーザー間でのメッセージのやり取りやフォロー • 色々なコンテンツ配信 • The Tabelog Award、百名店、食べログマガジンなど

Slide 8

Slide 8 text

© Kakaku.com Inc. All Rights Reserved. 食べログAndroidアプリの技術的負債 8 どんな技術的負債があったか（2018年時点） • 実際にあった技術的負債は色々 • 依存関係、責務の分離 • Deprecated になったOSSやAPI • 食べログAPIメジャーバージョンアップ時の負債 • 利用言語や開発環境が古い • 負債の内容はそれぞれよくあるアンチパターンではある • しかし、それらが複合的に作用しているためかなり複雑 • 何段階も継承関係があるFatなUIクラス • 色々なクラスから参照される神クラスがさらに継承関係も持っている • 返済が滞っている原因 • コードベースの大きさ • 全てを修正するにはどうしても時間がかかってしまう • テスタブルな構成にはなっていないため、テストコードがない • モノリスな１モジュール構成

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 11 ビッグ・リライト or リアーキテクティングビッグ・リライト（フルスクラッチ）リアーキテクティング、リファクタリングメリット • ０から作るので過去から解放される • テスタビリティも確保しやすい • トータルの工数は比較すれば少なく済むかも * • 部分的にリリースできる • コンフリクトしなければ機能追加のキャッチアップは不要 • 仕様を把握しながら進められるデメリット • 最後まで作らないとリリースできない • 機能追加のキャッチアップが辛い • 全体仕様を把握してないとバグがでやすい • スケジュールは伸びがち • トータルの工数は多くなる • 既存コードへ影響があるので難易度は高い • 既存の仕様やバグに苦しむかも ※リファクタリング、リアーキテクティング、ビッグ・リライトについては書籍「レガシーソフトウェア改善ガイド（著者 Chris Birchall）」2016年翔泳社出版の第1部を参照 * あくまでリファクタリングだけですべてのコードをきれいにするのに比べたらという意味

Slide 12

Slide 12 text

© Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 12 リアーキテクティングを選択基本的には初めにリファクタリング・リアーキテクティングを検討すると良い • インクリメンタルに進めた方がメリットは大きい • 対応をしたものは、早急に恩恵が得られる • 開発メンバーのFeedbackも得られる • ビッグ・リライトはリスクもあるので最後の手段コードベースが大きいので、ビッグ・リライトでもかなりの時間を要する • その間の機能開発をすべてキャッチアップするのはかなり厳しい全体仕様を把握するのはかなり難しい • 分野によって仕様に詳しい人が違ったり、そもそも誰も知らなかったり • 実際に動いてるコードを調査しながら進めるのが無難

Slide 13

Slide 13 text

© Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 13 リアーキテクティングを選択厳密にはリアーキテクティング→ミニリライト • １ヶ月ぐらいの規模で既存の一部をリライトしていく手法 • 依存しているOSSの負債があったため、UI部分を刷新する必要があった • そこはフルKotlinでリライトする • 合わせてロジック部分もちょっとずつ分離してリライトする • 画面単位でリライトしてリリースできるので、ビッグリライトよりリスクが低い • その準備としてリアーキテクティングを行う神クラス UI UI UI UI UI 新UI ロジック神クラス

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© Kakaku.com Inc. All Rights Reserved. どういった戦略をとったか 16 部隊を分ける • サービス開発 • プロダクトの改善がメインミッション • ユーザーに価値を届ける • 基盤 • リファクタリング、環境改善などの専門チーム • OSバージョンやライブラリの更新、CI/CDの改善など • 基盤チームではプロダクト自体の改善は行わないので、エンジニアだけの独立したチーム • コミュニケーションパスが少ない • 技術的負債の返済や環境改善、保守対応などに集中できる • サービス開発側もユーザーへ如何にして価値を届けるかにフォーカスできる

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© Kakaku.com Inc. All Rights Reserved. 実際にやってみて 19 最初は地盤固め • とはいえ、最初基盤チームのAndroidエンジニアは1人でした、、、 • 最初の一年は地盤固め • 環境整備 • サービス開発側へのヒアリング • アーキテクチャ選定 • 採用活動現在 • 1年後には３名、今では４名体制になりました • 大きいことをやるには仲間集めは大事 • チーム内だけでなくチーム外へのコミュニケーションも • 人数が増えたことに合わせて自分自身の役割もシフト • 今はマネジメント寄り • チームビルディング、採用活動など • なるべくリライト以外のタスクを拾ったり

Slide 20

Slide 20 text

© Kakaku.com Inc. All Rights Reserved. 実際にやってみて 20 並行してやらなきゃならないことが多々ある • チームを分けたけど、基盤チームもやることは色々ある • OSアップデート対応は毎年必要 • 開発環境のアップデート、ライブラリの更新作業 • リリースフローの最適化、自動ビルド、アプリ配布など • 食べログぐらいの規模だとそれぞれの対応にも割とコストがかかる • 「オレが3人分になる・・・」なんてことは難しい

Slide 21

Slide 21 text

© Kakaku.com Inc. All Rights Reserved. 実際にやってみて 21 並行してやらなきゃならないことが多々ある • チームを分けたけど、基盤チームもやることは色々ある • OSアップデート対応は毎年必要 • 開発環境のアップデート、ライブラリの更新作業 • リリースフローの最適化、自動ビルド、アプリ配布など • 食べログぐらいの規模だとそれぞれの対応にも割とコストがかかる • 「オレが3人分になる・・・」なんてことは難しい対策 • リアーキテクティング・リライトは専任にする • 集中してスピード感を出していきたい • なるべくコンテキストスイッチを減らす • 人 or 時間で分けると良さそう

Slide 22

Slide 22 text

© Kakaku.com Inc. All Rights Reserved. 実際にやってみて 22 レガシーコードに向き合う辛さ結局のところこれが一番大変 • 仕様書は詳細には整備されてない • リライトする画面については、レガシコードをひたすら調査 • かなりのスパゲッティなので、紐解くのが相当大変 • 延々と過去と向き合うような作業が多い • ふりかえりでも思考がネガティブになっていることが実際にあった • 右上の付箋は実際にMiroでふりかえりを行った時のもの • チームメンバーは正直者なので、ふりかえりでは遠慮なく愚痴ってますw

Slide 23

Slide 23 text

© Kakaku.com Inc. All Rights Reserved. 実際にやってみて 23 レガシーコードに向き合う辛さ対策 • 仕様面に関してはサービス開発側にも協力してもらう • 要所でのレビューや、事前調査時の仕様確認など • 個々のモチベーション向上 • 新しい技術のキャッチアップのために、定期的なチーム内勉強会も実施 • 刷新後に、こういった技術を入れるとこういった世界が待ってるみたいなイメージにつながる • 課題があったときは1人で悩まずみんなで解決 • リモートだからこそ孤立しないようにするケアは特に大事 • モブワークが有効 • 去年こんな記事も書いてます「リモートワークでモブプロをやってみた」 • 定期的な朝会、夕会、ふりかえりなども良いコミュニケーションの場 • 意図的に雑談する場もあるといい • ふりかえりのやり方も工夫しています（KPT→Fun/Done/Learnに変えたり）

Slide 24

Slide 24 text

© Kakaku.com Inc. All Rights Reserved. 実際にやってみて 24 進捗状況 • 最初のリファクタリングを開始してから2年経過 • やっとKotlin化は 20%弱 → 50% Over！！ • 店舗や写真の詳細画面など、主要な画面もいくつか対応済み • サービス開発側からも、リアーキテクチャしてから案件対応したいという声も上がっている • コードも整理されて品質も向上している • 3ヶ月間の1.2万クラッシュの内、刷新した画面のクラッシュはわずか229（2%弱）今後について • だいぶレガシーコードへの耐性（ノウハウ）も溜まってきた • まだまだ主要な画面も残っているので、対応を加速させていきたい • 目処がついたら、新しいことへのチャレンジも検討したい • Jetpack Compose （宣言的UI）の導入など

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© Kakaku.com Inc. All Rights Reserved. まとめ 26 • ビッグ・リライト or リアーキテクティングは状況によりけり • メリット・デメリットを考えて選択する • 基本的にはリファクタリング・リアーキテクティングでできないか最初に考える • 判断に迷うならまずはリファクタリングしてみるのもOK • 規模が大きいシステムはやることに応じてチームを分けるのも手 • 規模に比例して難易度が上がるタスクは個別チームでないとなかなか手が回らない • チーム力やモチベーションが大事 • 結局のところ「人」がやるので、個々のモチベーションは生産性に直結する • 課題解決は個人よりモブでやった方が速い • 全員のレベルアップにもつながる • 日頃からチームで解決していけるように、細かくコミュニケーションを取れるようになっていると良い • 特にリモートワーク環境下では意識的にやった方がいい

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 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 の米国およびその他の国における商標または登録商標であり、ライセンスに基づき使用されています。