Android/iOSアプリを協調開発するチーム~~スクラム開発の実践とその先へ~~

Transcript

1. Android / iOSアプリを協調開発するチーム
   〜スクラム開発の実践とその先へ〜
   

   View Slide

2. 自己紹介
   Kuu

   　 @Fumiya_Kume

   Android Engineer at Mercari, Inc

   船舶免許取ったので沖縄満喫中

   Kazuki Otao

   　 @0meo

   iOS Engineer at Mercari, Inc

   千葉に住んでる

   2
   

   View Slide

3. 日本最大のフリマアプリ
   かんたんに売り買いができて、あんしん・あんぜんなお取引ができるフリマアプリ

   3
   

   View Slide

4. 日本最大のフリマアプリ
   MAU 2000万人を越える大きなサービス

   [決算資料より引用] 

   4
   

   View Slide

5. ● 2022年9月、２年半かけてコードベースを刷新
   ○ 技術負債を返済し、モダンな技術スタックの採用
   ■ Kotlin / Jetpack Compose / Kotlin coroutines
   ○ Google I/O にてケーススタディが公開
   ○ Jetpack Compose の採用で、 UI 開発の生産性が 56 ％ 向上したメルカリ | Google Play |
   Android Developers
   ● 今回の発表で紹介するコンテンツは、その書き直しプロジェクト中に形成されたもの
   5
   0からメルカリアプリを書き直すプロジェクト
   

   View Slide

6. メルカリでのモバイルアプリ開発
   コンテンツ
   スクラムイベントにおける工夫
   02
   01
   6
   

   View Slide

7. メルカリでの
   モバイルアプリ開発
   7
   

   View Slide

8. モバイルアプリの開発体制
   ● 一つのチームに各ロールが所属
   ● Android / iOSエンジニアはそれぞれ2名づつが多い
   8
   iOS Frontend Backend Designer PdM EM
   Feature team A
   Feature team B
   Feature team C
   アーキテクト
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   SWE
   Designer
   Designer
   Designer
   Designer
   PdM
   PdM
   PdM
   PdM
   EM
   EM
   EM
   EM
   Android
   

   View Slide

9. 開発の進め方
   9
   1. 実験アイディアの考案
   2. ドキュメント作成
   3. 実装
   4. 実験の実施
   

   View Slide

10. 開発の進め方:実験アイディアの考案
    1. 実験アイディアの考案
    2. ドキュメント作成
    3. 実装
    4. 実験の実施
    ICEフレームワーク
    インパクト・影響範囲

    月間利用者数, 登録完了率... 等々
    

    信頼性・確実性

    過去の挑戦と結果も参考にする
    

    容易に実施できるのか

    開発・デザイン・分析...
    

    10
    

    View Slide

11. 開発の進め方:ドキュメント作成
    11
    コンテンツ 目的 オーナー
    Requirement
    Doc
    要件・仕様・機能
    What (要件)を
    明らかにする
    Product Manager
    UI Design デザイン Designer
    (Software)
    Design Docs
    開発方法
    How (どのように
    開発するか)
    を明らかにする
    Enginnear
    ※ 1つのRequirements Docに対して、
    　モバイル・Web・バックエンドと複数のDesign Docsが作られることがある
    1. 実験アイディアの考案
    2. ドキュメント作成
    3. 実装
    4. 実験の実施
    

    View Slide

12. 開発の進め方:ドキュメント作成 / Design Docの内容
    12
    1. 実験アイディアの考案
    2. ドキュメント作成
    3. 実装
    4. 実験の実施
    項目 目的
    関係者の一覧 誰に聞けばいいのか知る
    UIデザインのリンク UIの実装時に参照
    画面の遷移・流れ 全体像を掴む・動作確認
    Feature Flag / ログ 必要な情報を知る
    Story / Ticketのリンク 作業の依存関係を確認
    各種調査結果 調査結果を記録
    テストアカウント 動作確認に必要
    

    View Slide

13. 開発の進め方:ドキュメント作成 / Why Design Doc?
    13
    1. 実験アイディアの考案
    2. ドキュメント作成
    3. 実装
    4. 実験の実施
    ● Design Docを書く過程で仕様の欠落に気づくことができ、実装
    時に生じるコミュニケーションコストを減らし、
    開発速度の低下を防げる
    ● 実装前に思考を整理し、困難点を推測できる。
    必要に応じてPoCを作成して本実装前に議論する
    ● 実装の概要を開発メンバーで事前に共有できるので、
    PRレビューの精度が上がる
    

    View Slide

14. Android / iOSでDesign Docを共通化
    14
    ● Android / iOSで別々のDesign Docsを書いていた
    ○ ほとんどが共通化できるような内容であった
    ○ エッジケースへの対処などの知見がうまく共有されなかった
    以前の課題
    提案
    ● Android / iOSでDesign Docを共通化
    ○ Design Docを作成するコストが1/2になった
    ○ 共通の課題 / バグ等の知見の共有が進んだ
    

    View Slide

15. 開発の進め方:実装
    Design System
    サービス全体で共通コンポーネントを定義し、UIを構築する手法
    UI開発時にデザインの共通言語として使い、効率よく実装できる
    トランクベース開発
    寿命の長いfeatureブランチの代わりに、小さなPRを直接mainブランチ
    にマージすることで、ブランチのサイクルタイムを下げる手法
    ペアプログラミング
    基本的にはフルリモート・フルフレックスで非同期だが、
    同期的な作業の方が効率が良い場合に実施
    15
    1. 実験アイディアの考案
    2. ドキュメント作成
    3. 実装
    4. 実験の実施
    

    View Slide

16. 開発の進め方:実験の実施
    A/Bテスト 段階的機能公開
    アプリを更新するために数時間 ~数日かかる審査が必要
    モバイルアプリ特有のリリース事情
    アプリを更新するタイミングや頻度はお客さま次第
    Feature Flag
    アプリリリースとは別に機能の有効/無効を切り替えられる仕組み
    バグがあってもすぐhotfix / revertできない
    16
    1. 実験アイディアの考案
    2. ドキュメント作成
    3. 実装
    4. 実験の実施
    

    View Slide

17. メルカリでのモバイルアプリ開発
    コンテンツ
    スクラムイベントにおける工夫
    02
    01
    17
    

    View Slide

18. スクラムイベントにおける工夫
    18
    

    View Slide

19. ● 基本的な情報
    ○ ２週間１スプリント
    ○ ファシリテーターはローテーション
    スクラムイベントにおける工夫
    19
    

    View Slide

20. スクラムイベント
    見出し スプリント中盤

    スプリント初め

    ● スプリントプランニング 
 ● リファインメント

    ● ドッグフーディング

    ● レトロスペクティブ

    ● スプリントレビュー

    スプリント後半

    毎日

    ● デイリースタンドアップ 

    

    20
    

    View Slide

21. スクラムイベント
    見出し スプリント中盤

    スプリント初め

    ● スプリントプランニング 
 ● リファインメント

    ● ドッグフーディング

    ● レトロスペクティブ

    ● スプリントレビュー

    スプリント後半

    毎日

    ● デイリースタンドアップ 

    

    21
    

    View Slide

22. ● ドッグフーディング？
    ○ 実装した機能を開発者自らで使用してみること
    ○ 「機能を使ったときの体験」を見て、お客さま目線で仕様の改善を提案する
    ● QAではない
    ○ QAは仕様通りに動くか、エッジーケースに対応できているかチェック
    ○ QAは別に実施する
    ドッグフーディング
    22
    

    View Slide

23. ● スクショやGIF付きで、気づいた点を共有。必要ならチケットを作成
    ドッグフーディング
    23
    OS 報告者 問題 スクショ Action Plan
    Ticket
    (If needed)
    Xperia 1 Ⅱ /
    Android 12
    @Kuu ダイアログのURLテキストが
    通常のテキストよりも小さい
    @Kuu
    フォントサイズの指
    定が正しいか
    確認
    @Otao
    デザイナーに確認
    [Backlog] ダイアロ
    グのURLテキストの
    デザイン修正
    

    View Slide

24. APIを待つ時間が想定より長く、
    実際に触ってみると不安を感じた
    お客さまの待ち時間観点からのフィードバック
    Progress indicators - Material Design
    課題
    提案
    本来の仕様にはなかったが、
    ローディングインディケーターを追加した
    24
    

    View Slide

25. UIの細かな操作を行うことが難しく
    体験面で改善点があると感じた
    アクセシビリティ観点からのフィードバック
    課題
    提案
    ● アクセシビリティの改善
    ○ リンクテキストのフォントサイズの変更
    ○ ボタンの最小サイズを大きく
    ● Voice Overの対応
    25
    Material Design 3 - Accessible design
    

    View Slide

26. ● ドッグフーディングでは
    Android / iOSエンジニア関係なく可能であれば両方のデバイスを触る
    ● OSが違うことによる体験の差を体感する機会は
    実はQAエンジニア以外だとなかなかない
    ● AndroidエンジニアがiOSアプリの修正点を指摘をしたり、
    iOSアプリを触ることでAndroidアプリの修正点に気づくことがある
    ○ モバイルで共通化されたDesign Docを用いても、
    Android / iOSエンジニアが仕様を勘違いして実装してしまうことはよくある
    Android / iOSエンジニアが協調開発するために
    26
    

    View Slide

27. ● ドッグフーディングをスクラムイベントの中に組み込むことで
    お客さま視点からの体験を改善させるための提案をエンジニアサイドから行う機会を作る
    ドッグフーディングのススメ
    27
    

    View Slide

28. ドッグフーディングをうまく進めるためには？
    MTG前:
    40分:
    10分:
    MTG後:
    アプリを触って気づいた点を列挙
    気づいた点の共有
    チケットの作成
    ドキュメントの準備
    28
    

    View Slide

29. ドッグフーディングをうまく進めるためには？
    MTG前:
    40分:
    10分:
    MTG後:
    アプリを触って気づいた点を列挙
    気づいた点の共有
    チケットの作成
    ドキュメントの準備
    29
    

    View Slide

30. ● テンプレートに埋める内容
    ○ ドッグフーディングする機能のDesign Docs, Figmaなどの関連URL
    ○ 機能の使い方のフロー
    ○ 有効にするFeatureFlag
    ○ Android / iOSのビルド済みバイナリ
    ○ 使用するテストアカウント
    ドッグフーディング - ドキュメントの準備
    30
    

    View Slide

31. メルカリでのモバイルアプリ開発
    コンテンツ
    スクラムイベントにおける工夫
    02
    01
    31
    

    View Slide

32. まとめ
    32
    

    View Slide

33. 33
    まとめ
    Android / iOSアプリを効率よく開発する施策
    Design Doc
    ● Howに着目したドキュメント
    ● 我々のチームでは両OSで協力して作成
    ● 出戻りを防ぐことに大きく貢献
    みんなで使いやすいスマホアプリを開発する施策
    ドッグフーディング
    ● チーム全員で、一人では見落としがちなお客さま視点の改善を拾い上げる
    ● Android / iOSに精通しているからこそのプロフェッショナルな意見
    

    View Slide

34. ● 我々はプロダクト自体の改善だけでなく、プロダクトの開発工程の改善も続けている
    ○ その過程で得られた現時点でうまく動いている施策を紹介した
    ● これらの施策は完成形ではなく、
    1, 2年後にはきっと新たな施策・変化した施策・辞めた施策が出てくる
    ● チーム改善に終わりはなく、チームの数だけ異なる形があることに留意し
    「進化し続ける」ことを辞めない
    34
    スクラム開発の実践とその先へ
    

    View Slide

35. We are hiring & We have booth!
    35
    https://careers.mercari.com/jp/
    

    View Slide

36. Android/iOSアプリを協調開発するチーム
    〜スクラム開発の実践とその先へ〜
    

    View Slide