Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入す...
Search
GO Inc. dev
October 02, 2025
Programming
0
110
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
ユーザーシステム開発部の高橋がExtensionDC Day1で発表した資料です。
https://dena.connpass.com/event/362412/
GO Inc. dev
October 02, 2025
Tweet
Share
More Decks by GO Inc. dev
See All by GO Inc. dev
GPT-5と寿司合戦を攻略する
mot_techtalk
1
58
Grafanaスタックをフル活用したオブザーバビリティ基盤の紹介
mot_techtalk
6
950
オンデマンド交通のための車両ルーティング問題
mot_techtalk
0
110
Open-Vocabularyオブジェクト検出
mot_techtalk
0
49
Grafana Loki によるサーバログのコスト削減
mot_techtalk
1
850
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
820
GAEログのコスト削減
mot_techtalk
0
780
『GO』アプリ バックエンドサーバのコスト削減
mot_techtalk
0
830
タクシーアプリ『GO』のリアルタイムデータ分析基盤における機械学習サービスの活用
mot_techtalk
6
3.5k
Other Decks in Programming
See All in Programming
AIを活用したレシート読み取り機能の開発から得られた実践知 / AI Receipt Scan Practice
rockname
2
1.4k
Pythonスレッドとは結局何なのか? CPython実装から見るNoGIL時代の変化
curekoshimizu
3
870
まだ世にないサービスをAIと創る話 〜 失敗から学ぶフルスタック開発への挑戦 〜
katayamatg
0
160
Platformに“ちょうどいい”責務ってどこ? 関心の熱さにあわせて考える、責務分担のプラクティス
estie
2
500
ネイティブ製ガントチャートUIを作って学ぶUICollectionViewLayoutの威力
jrsaruo
0
110
Model Pollution
hschwentner
1
180
2025年版 サーバーレス Web アプリケーションの作り方
hayatow
23
25k
パフォーマンスチューニングで Web 技術を深掘り直す
progfay
18
4.7k
LLMとPlaywright/reg-suitを活用した jQueryリファクタリングの実際
kinocoboy2
4
630
階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜
yuhisatoxxx
3
690
Let's Write a Train Tracking Algorithm
twocentstudios
0
220
10年もののAPIサーバーにおけるCI/CDの改善の奮闘
mbook
0
540
Featured
See All Featured
The Invisible Side of Design
smashingmag
301
51k
Embracing the Ebb and Flow
colly
87
4.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
950
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Done Done
chrislema
185
16k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
GitHub's CSS Performance
jonrohan
1032
460k
Automating Front-end Workflow
addyosmani
1371
200k
GraphQLとの向き合い方2022年版
quramy
49
14k
Side Projects
sachag
455
43k
4 Signs Your Business is Dying
shpigford
185
22k
Transcript
© GO Inc. 大規模アプリのDIフレームワーク 刷新戦略 〜過去最大規模の並行開 発を止めずにアプリ全体に導入す るまで〜 2025.10.01 開発本部
ソフトウェア開発統括部 ユーザーシステム開発部 ユーザーシステム1グループ / 髙橋秀宗 GO株式会社
© GO Inc. iOSDC Japan 2025お疲れ様でした〜!🎉 毎年夏がどんどん暑くなってきていてしんどいです🫠 iPhone Airがめっちゃ薄くてびっくり📱 GO株式会社
iOSエンジニア 髙橋秀宗 2 自己紹介 @h1d3mun3
Index © GO Inc. 1. 背景・目的 2. Needle導入の障壁 3. 導入障壁への対応
4. 結果 5. まとめ 6. 参考資料 3
© GO Inc. 4 背景・目的 1
© GO Inc. 5 RIBsについて 1.a
© GO Inc. 6 RIBsとは • UberがiOS/Android向けに開発しているクロスプラットフォーム対応の アーキテクチャ ◦ 下記3つの要素を最小単位として構成
▪ Router: 画面遷移 ▪ Interactor: ビジネスロジック ▪ Builder: RouterとInteractorをビルド • ビジネスロジックごとにRIBという1つのコンポーネントにすることで責 務が明確化 • RIBを再利用可能
© GO Inc. • 親子関係を持つ、木構造のアーキテクチャ 7 RIBsの特徴
© GO Inc. • 親子関係を持つ、木構造のアーキテクチャ 8 RIBsの特徴
© GO Inc. • 依存性は親子関係をベースに解決 ◦ LoggedIn -> Cart ->
ItemDetail ◦ LoggedIn -> ItemSearch -> ItemDetail → そのRIBにアクセス可能な木構造のなかの全てのパスで、依存性が解決さ れている必要有 9 RIBsの特徴
© GO Inc. 10 RIBsアーキテク チャのDI事情 1.b
© GO Inc. • 別のRIBの配下にRIBを追加する時、パスごとに依存性を解決する必要 11 RIBの追加時
© GO Inc. 12 RIBの追加時 変更前 変更後
© GO Inc. • 変更前 ◦ LoggedIn -> Cart ->
ItemDetail • 変更後 ◦ LoggedIn -> Cart -> ItemDetail ◦ LoggedIn -> ItemSearch -> ItemDetail → ItemSearchに依存性解決のための決まり切った単純なコードを大量に手 動で書く必要があり、作業時間の増大や再利用性が低下 13 RIBの追加・移動時
© GO Inc. • コンパイル時に木構造に基づき依存性解決コードを自動的に生成する Needleの導入を決定 ◦ https://github.com/uber/needle 14 DI課題の解決に向けて
© GO Inc. 15 Needle導入の障 壁 2
© GO Inc. 16 『GO』アプリの固有の状況 • 『GO』アプリの木構造の大きさ ◦ 500以上のRIBがあり、木構造が超巨大 •
内製ツールを用いたボイラープレートコードの自動生成処理 ◦ 内製ツール側がNeedleに未対応だったため、対応する必要
© GO Inc. • Needleは木構造の一番親RIBから1つ1つ対応 ◦ Root, LoggedIn, Cart, ItemSearchの4つがNeedle対応完了した
ら、ItemDetailに着手できる 17 Needleの導入手順制約
© GO Inc. • 「導入作業が現在どこまで進捗しているか」をわかりやすく伝える ◦ これができないと「今作ろうとしている新機能はNeedle対応版で作 るべきなのか、そうでないのか」がわからず、新機能開発に影響が 及ぶ •
Needle導入を手伝う場合、どこに着手したら良いのかも可視化する ◦ 500以上のRIBを修正するため、チームメンバーにも手伝ってもらう とより早く導入できる → これらができないとNeedle導入の失敗に加えて、新機能開発も失敗する という最悪の状況が起きる 18 作業進捗状況とNextActionの可視化の重要性
© GO Inc. 19 導入計画の高難易度 • 木構造の一番上のRIBから1つ1つNeedle導入を進めていく必要があるた め、円滑な導入にはアプリの木構造を踏まえた導入計画が必要 ◦ その一方で複数の機能にまたがって再利用されているRIBがあり、
木構造の親子関係を調べる作業が高コスト化 ▪ EX: 支払い方法選択の責務のRIBなど • 500以上という木構造そのものの大きさと、導入途中での木構造変化の 両方を許容する必要 ◦ 特に今回は並行して大規模開発が進んでいたので木構造変化のリス クが増大 → 導入計画策定が高難易度化
© GO Inc. 20 導入障壁への対 応 3
© GO Inc. 21 RIBsTreeMakerを利用した木構造の自動解析 • RIBsTreeMakerという木構造の解析ツールを改修し、指定したRIBの親 を自動解析するツールを開発 ◦ Needle化したいRIBを指定することで、導入計画を自動的に策定可
能 ▪ 副次的にフェーズを分けた計画策定も可能になり、計画策定の 柔軟さが向上
© GO Inc. 22 スプレッドシートを用いた依存関係整理 • 自動解析ツールの結果をスプレッドシートにまとめ、Needle化作業の状 況を可視化 ◦ 作業可能なものと、まだ作業できないものを可視化し、作業者の負
担を低減 ◦ 全体の進捗率も可視化し、モチベーションを維持 ◦ 週次で進捗状況を確認
© GO Inc. 23 実際のスクリーンショット(作業進捗状況とNextActionの可視化)
© GO Inc. • RIBsを追加する時、親となるRIBがNeedle対応済みであれば、Needle対 応のRIBを、そうでない場合は通常のRIBを追加する機能を追加実装 ◦ Needle対応の恩恵を社内のエンジニアが受けられるようにし、工数 削減に貢献 24
内製ツールの対応
© GO Inc. 25 並行プロジェクト向けの先行対応 • 導入作業を並行していたプロジェクトで、工数削減のためNeedleの採用 が決定 ◦ Needleを使って作業できるよう、先行してNeedle化作業を実施
◦ 並行プロジェクト側での工数削減に貢献
© GO Inc. 26 結果 4
© GO Inc. • 約1年ほどで『GO』アプリ全体のRIBをNeedle対応完了 ◦ 500以上のRIBをNeedle化 ◦ チーム全体で協力して導入完遂 •
導入作業と並行していたプロジェクトでは、Needleの恩恵を十分に受 け、工数削減に貢献 • 今後全ての開発で依存性解決のためのボイラープレートコード記述の工 数を削減 27 結果
© GO Inc. 28 まとめ 5
© GO Inc. • RIBsアーキテクチャのDI課題解決のため、Needleの導入を決定 • 『GO』の木構造の都合上、手動での導入計画策定が困難だったため、 自動化ツールを用いて導入計画を策定 • 導入計画策定後、円滑に作業できるようスプレッドシートに状況をまと
めチーム全体で共有 → 上記を進め、約1年ほどで『GO』全体のRIBをNeedle化を完遂 29 まとめ
© GO Inc. 30 学び • DIライブラリなどのアプリ全体への影響があるライブラリを導入する場 合はアプリの状況を踏まえた導入計画の策定が必要 ◦ 状況によっては人間で策定できないこともあるので、自動化ツール
の活用・開発も検討 • 作業は単純でも、次に着手するものが明確でないと人間は作業しにくい ◦ スプレッドシートなどを活用して、可能な限りスムーズに作業に着 手できる環境を整備 ◦ 状況とメリットを事前に共有し、「個人ではなくチームの課題」と して作業を進める
© GO Inc. 31 参考資料 6
© 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 参考資料
文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.