UI設計の共通化で機能差異を埋めるモバイルアプリ開発

by CyberAgent

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

井原岳志 ● 2018年に株式会社サイバーエージェント中途入社 ● 株式会社AbemaTV Native Team所属 ● iOSチームのテックリード木永風児 ● 2020年に株式会社サイバーエージェント中途入社 ● 株式会社AbemaTV Native Team所属 ● Androidチームのテックリード

Slide 3

Slide 3 text

Slide 4

Slide 4 text

モバイルアプリのUI / UX刷新

Slide 5

Slide 5 text

たくさんの施策が同時にリリース ● テレビ機能刷新 ● テレビプレビュートリミング ● ボトムナビゲーション対応 ● 特集エリア ● 起動時表示物整理 ● 作品プレビュー ● チャンネル並べ替え ● 1歳刻みのデモグラアンケート ● 新聞型番組表 ● ホーム最適化画面 ● 複数選択ジャンルアンケート ● ホームチュートリアル ● ランディングチャンネル ● Welcome画面 ● マイページ画面の導線変更 ● 視聴形態ラベル刷新 ● タブレット最適化 ● プレミアムタブ ● ジャンル/ストアトップリデザイン ● SLI/SLO計測 ● ...

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

ABEMAにおけるモバイルアプリ ● Android / iOSアプリを提供 ○ 同一なデザインや機能を提供 ● 開発言語 ○ Android) Kotlin ○ iOS) Swift ● 開発体制 ○ 2016年) Android / iOSチーム ○ 2019年) Nativeチームに統合

Slide 8

Slide 8 text

モバイルアプリの機能差異 ● 大小関わらず機能差異がいくつか存在 ○ タブレットデザインの対応可否 ○ キャスト機能の対応有無 ○ プレイヤー再生画面のスワイプアクションの有無 ○ 参照するデータ元の差異 ● 機能差異を埋める取り組み ○ 各エンジニアのオーナーシップ ○ 改善Week ※現在は廃止サブスク登録コイン購入 PPV TVO D 投げ銭ブランドサーベイスポンサード広告 Ch 作品プレビュー購入視聴マルチアングル Mobile App iPhone/ iPad ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ Android ◯ ◯ ◯ ◯ ◯ ◯ ◯ ☓ ☓ ◯ 施策におけるモバイルアプリ間差異

Slide 9

Slide 9 text

機能差異がもたらす弊害 ● 機能が出揃うまでコンテンツの多重運用が必要 ● 互換性担保のための仕様やデザインの考慮が複雑になる ● 既存の機能差異が影響して新機能の開発工数が異なる

Slide 10

Slide 10 text

大規模プロジェクトで表面化 ● UI / UX刷新プロジェクトの工数が大きく異なる ○ Android) 10ヶ月 ○ iOS) 6ヶ月

Slide 11

Slide 11 text

大規模プロジェクトへ改善の盛り込み ● リリース後の機能開発で工数が近づくような改善 ○ プロジェクトのリリースを最終目標としない ○ 共通 / プラットフォーム個別の改善をそれぞれ検討 ● マイルストーンに工数として組み込む ○ オーナーシップに依存させない

Slide 12

Slide 12 text

共通の改善事例の紹介

Slide 13

Slide 13 text

共通の改善事例 1. 機能の棚卸し 2. UIコンポーネントの共通化 3. 起動シーケンスの共通化 4. Imp発火条件の共通化

Slide 14

Slide 14 text

共通の改善事例① 機能の棚卸し ● ユーザー体験をシンプルにする ● 運用負荷の高い機能やUI / UX刷新によって負債化しやすい機能を精査

Slide 15

Slide 15 text

共通の改善事例② UIコンポーネント ● デザインと実装のコンポーネント粒度を揃える ○ 変更時の考慮漏れや追加開発のリスクが縮小

Slide 16

Slide 16 text

共通の改善事例③ 起動シーケンス ● 刷新プロジェクト後も起動パフォーマンスを担保できるシーケンスを実現 ○ エラーハンドリングの方針を決めて、障害時などの対応アクションも決定 ● 他デバイス開発時にも流用が可能な状態になった

Slide 17

Slide 17 text

共通の改善事例④ Imp発火条件の共通化 ● ユーザーが特定の画面に遷移したと判定する条件を再定義 ○ 画面回転やバックフォア、スリープ状態、画面遷移形式などユーザー操作観点で整理 ○ Android / iOSのライフサイクル挙動の差異を考慮に含め、実装に落とし込む ● ユーザーが特定のビューやモジュールを見たと判定する条件を再定義 ○ Android / iOSで発火・再発火の条件を揃える ○ 画面固有の対応パターンを極力作らない汎用的なポリシーにする

Slide 18

Slide 18 text

iOSの改善事例

Slide 19

Slide 19 text

iOSの改善事例① アニメーション ● ProtopieのInteraction Recipesを介したデザイナーとのコミュニケーション ○ 複雑なアニメーション開発フローの確立 ○ 変化量や時系列などがデザイナーが意図した通りに実装 ○ iOS側で先行して検証実施

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

iOSの改善事例② ミニアプリ ● 新設されるホーム画面をミニアプリ化して単体でのアプリ起動を実現 ○ デザインやアニメーションの検証を高速化 ○ 本体側にgit submoduleでコード注入して組み込んでビルド可能 ○ クラス名やView階層をNativeチーム・デザイナーで議論 ● リリース時にはミニアプリ化を止めて本体側に完全移行 ○ 現状のアーキテクチャでは優先順位が低いため

Slide 22

Slide 22 text

現状のアーキテクチャ

Slide 23

Slide 23 text

現状のアーキテクチャ + ミニアプリ

Slide 24

Slide 24 text

Androidの改善事例

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Androidの改善事例 NavigationComponent 🤝 SingleActivity

Slide 27

Slide 27 text

これまでのABEMA Android ● 1画面につき、1つのActivity ● ドロワーメニュー経由の画面遷移 ● 継承(extends)による共通処理 ● オリジナルなDagger Component ○ 画面回転後も生存するScreenScope ○ ViewPager配下のPageScope

Slide 28

Slide 28 text

Slide 29

Slide 29 text

これからのABEMA Android ● 1画面につき、1つのFragment ● ボトムナビゲーション経由の画面遷移 ● 委譲による共通処理 ● Hiltを使用したDagger Component

Slide 30

Slide 30 text

なぜ変更する必要があったか Androidの改善事例

Slide 31

Slide 31 text

1画面につき、1つのFragment ● 下タブの実現に伴い、NavigationComponentを採用する場合はFragment化がマスト要件 ○ iPadはすでに下タブ化されており、機能差異の要因となっていた ● PictureinPictureやミニプレイヤーなど将来的な可能性を見据える

Slide 32

Slide 32 text

ボトムナビゲーション経由の画面遷移 ● よりシームレスな回遊体験をユーザーに提供する ○ Navigation2.4.0とFragment1.4.0でMultiple back stacksにも対応👏 ● navigation-composeを使ったJetpackCompose化を見据える https://medium.com/androiddevelopers/multiple-back-stacks-b714d974f134

Slide 33

Slide 33 text

Slide 34

Slide 34 text

委譲による共通処理 ● Activityの共通処理もFragment移行の対象になる ● 画面ごとの処理を持ちやすくなり、要件に合わせたカスタマイズが容易に ● テストの書きやすさが向上

Slide 35

Slide 35 text

Hiltを使用したDagger Component ● 新しく画面を作るたびに依存関係の注入を手作業で行う必要があった ● 複雑かつ大規模な依存関係により、改修が困難となり開発効率が低下していた ○ ビルドエラーが頻発 ○ 依存関係ツリーの知識が属人化 ○ 新規参入者の学習コスト過多 https://developer.android.com/training/dependency-injection/hilt-android

Slide 36

Slide 36 text

これからのABEMA Android ● 1画面につき、1つのFragment ● ボトムナビゲーション経由の画面遷移 ● 委譲による共通処理 ● Hiltを使用したDagger Component 再掲

Slide 37

Slide 37 text

まとめ

Slide 38

Slide 38 text

まとめ ● 今後の機能差異を埋める開発フロー・仕組みを検証・導入できた ○ UIコンポーネントの見直し ○ 起動シーケンスの見直し ○ ログ定義 ○ ProtopieのInteraction Recipesを活用したアニメーション実装 ○ 開発時のミニアプリ活用 ○ NavigationComponent 🤝 SingleActivity ● 将来の展望 ○ マルチプラットフォームの推進 ○ 宣言的UI化 (SwiftUI / Jetpackcompose)

Slide 39

Slide 39 text

関連セッション Multiplatform Engineering ● UI設計以外でも共通化に取り組んでいます ○ 詳しい内容は、この後のセッションにて

Slide 40

Slide 40 text

No content