大規模アプリのDIフレームワーク刷新戦略 ～過去最大規模の並行開発を止めずにアプリ全体に導入するまで～

ユーザーシステム開発部の高橋がExtensionDC Day1で発表した資料です。
https://dena.connpass.com/event/362412/

Transcript

1. © GO Inc. 大規模アプリのDIフレームワーク 刷新戦略 〜過去最大規模の並行開 発を止めずにアプリ全体に導入す るまで〜 2025.10.01 開発本部 ソフトウェア開発統括部 ユーザーシステム開発部 ユーザーシステム1グループ / 髙橋秀宗 GO株式会社
2. © GO Inc. iOSDC Japan 2025お疲れ様でした〜！🎉 毎年夏がどんどん暑くなってきていてしんどいです🫠 iPhone Airがめっちゃ薄くてびっくり📱 GO株式会社 iOSエンジニア 髙橋秀宗 2 自己紹介 @h1d3mun3
3. Index © GO Inc. 1. 背景・目的 2. Needle導入の障壁 3. 導入障壁への対応 4. 結果 5. まとめ 6. 参考資料 3
4. © GO Inc. 4 背景・目的 1
5. © GO Inc. 5 RIBsについて 1.a
6. © GO Inc. 6 RIBsとは • UberがiOS/Android向けに開発しているクロスプラットフォーム対応の アーキテクチャ ◦ 下記3つの要素を最小単位として構成 ▪ Router: 画面遷移 ▪ Interactor: ビジネスロジック ▪ Builder: RouterとInteractorをビルド • ビジネスロジックごとにRIBという1つのコンポーネントにすることで責 務が明確化 • RIBを再利用可能
7. © GO Inc. • 親子関係を持つ、木構造のアーキテクチャ 7 RIBsの特徴
8. © GO Inc. • 親子関係を持つ、木構造のアーキテクチャ 8 RIBsの特徴
9. © GO Inc. • 依存性は親子関係をベースに解決 ◦ LoggedIn -> Cart -> ItemDetail ◦ LoggedIn -> ItemSearch -> ItemDetail → そのRIBにアクセス可能な木構造のなかの全てのパスで、依存性が解決さ れている必要有 9 RIBsの特徴
10. © GO Inc. 10 RIBsアーキテク チャのDI事情 1.b
11. © GO Inc. • 別のRIBの配下にRIBを追加する時、パスごとに依存性を解決する必要 11 RIBの追加時
12. © GO Inc. 12 RIBの追加時 変更前 変更後
13. © GO Inc. • 変更前 ◦ LoggedIn -> Cart -> ItemDetail • 変更後 ◦ LoggedIn -> Cart -> ItemDetail ◦ LoggedIn -> ItemSearch -> ItemDetail → ItemSearchに依存性解決のための決まり切った単純なコードを大量に手 動で書く必要があり、作業時間の増大や再利用性が低下 13 RIBの追加・移動時
14. © GO Inc. • コンパイル時に木構造に基づき依存性解決コードを自動的に生成する Needleの導入を決定 ◦ https://github.com/uber/needle 14 DI課題の解決に向けて
15. © GO Inc. 15 Needle導入の障 壁 2
16. © GO Inc. 16 『GO』アプリの固有の状況 • 『GO』アプリの木構造の大きさ ◦ 500以上のRIBがあり、木構造が超巨大 • 内製ツールを用いたボイラープレートコードの自動生成処理 ◦ 内製ツール側がNeedleに未対応だったため、対応する必要
17. © GO Inc. • Needleは木構造の一番親RIBから1つ1つ対応 ◦ Root, LoggedIn, Cart, ItemSearchの4つがNeedle対応完了した ら、ItemDetailに着手できる 17 Needleの導入手順制約
18. © GO Inc. • 「導入作業が現在どこまで進捗しているか」をわかりやすく伝える ◦ これができないと「今作ろうとしている新機能はNeedle対応版で作 るべきなのか、そうでないのか」がわからず、新機能開発に影響が 及ぶ • Needle導入を手伝う場合、どこに着手したら良いのかも可視化する ◦ 500以上のRIBを修正するため、チームメンバーにも手伝ってもらう とより早く導入できる → これらができないとNeedle導入の失敗に加えて、新機能開発も失敗する という最悪の状況が起きる 18 作業進捗状況とNextActionの可視化の重要性
19. © GO Inc. 19 導入計画の高難易度 • 木構造の一番上のRIBから1つ1つNeedle導入を進めていく必要があるた め、円滑な導入にはアプリの木構造を踏まえた導入計画が必要 ◦ その一方で複数の機能にまたがって再利用されているRIBがあり、 木構造の親子関係を調べる作業が高コスト化 ▪ EX: 支払い方法選択の責務のRIBなど • 500以上という木構造そのものの大きさと、導入途中での木構造変化の 両方を許容する必要 ◦ 特に今回は並行して大規模開発が進んでいたので木構造変化のリス クが増大 → 導入計画策定が高難易度化
20. © GO Inc. 20 導入障壁への対 応 3
21. © GO Inc. 21 RIBsTreeMakerを利用した木構造の自動解析 • RIBsTreeMakerという木構造の解析ツールを改修し、指定したRIBの親 を自動解析するツールを開発 ◦ Needle化したいRIBを指定することで、導入計画を自動的に策定可 能 ▪ 副次的にフェーズを分けた計画策定も可能になり、計画策定の 柔軟さが向上
22. © GO Inc. 22 スプレッドシートを用いた依存関係整理 • 自動解析ツールの結果をスプレッドシートにまとめ、Needle化作業の状 況を可視化 ◦ 作業可能なものと、まだ作業できないものを可視化し、作業者の負 担を低減 ◦ 全体の進捗率も可視化し、モチベーションを維持 ◦ 週次で進捗状況を確認
23. © GO Inc. 23 実際のスクリーンショット（作業進捗状況とNextActionの可視化）
24. © GO Inc. • RIBsを追加する時、親となるRIBがNeedle対応済みであれば、Needle対 応のRIBを、そうでない場合は通常のRIBを追加する機能を追加実装 ◦ Needle対応の恩恵を社内のエンジニアが受けられるようにし、工数 削減に貢献 24 内製ツールの対応
25. © GO Inc. 25 並行プロジェクト向けの先行対応 • 導入作業を並行していたプロジェクトで、工数削減のためNeedleの採用 が決定 ◦ Needleを使って作業できるよう、先行してNeedle化作業を実施 ◦ 並行プロジェクト側での工数削減に貢献
26. © GO Inc. 26 結果 4
27. © GO Inc. • 約1年ほどで『GO』アプリ全体のRIBをNeedle対応完了 ◦ 500以上のRIBをNeedle化 ◦ チーム全体で協力して導入完遂 • 導入作業と並行していたプロジェクトでは、Needleの恩恵を十分に受 け、工数削減に貢献 • 今後全ての開発で依存性解決のためのボイラープレートコード記述の工 数を削減 27 結果
28. © GO Inc. 28 まとめ 5
29. © GO Inc. • RIBsアーキテクチャのDI課題解決のため、Needleの導入を決定 • 『GO』の木構造の都合上、手動での導入計画策定が困難だったため、 自動化ツールを用いて導入計画を策定 • 導入計画策定後、円滑に作業できるようスプレッドシートに状況をまと めチーム全体で共有 → 上記を進め、約1年ほどで『GO』全体のRIBをNeedle化を完遂 29 まとめ
30. © GO Inc. 30 学び • DIライブラリなどのアプリ全体への影響があるライブラリを導入する場 合はアプリの状況を踏まえた導入計画の策定が必要 ◦ 状況によっては人間で策定できないこともあるので、自動化ツール の活用・開発も検討 • 作業は単純でも、次に着手するものが明確でないと人間は作業しにくい ◦ スプレッドシートなどを活用して、可能な限りスムーズに作業に着 手できる環境を整備 ◦ 状況とメリットを事前に共有し、「個人ではなくチームの課題」と して作業を進める
31. © GO Inc. 31 参考資料 6
32. © GO Inc. • https://github.com/uber/RIBs • https://github.com/uber/RIBs-iOS • https://github.com/uber/needle • https://github.com/imairi/RIBsCodeGen • https://github.com/imairi/RIBsTreeMaker 32 参考資料
33. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.