Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Kuu
October 06, 2022

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

Kuu

October 06, 2022
Tweet

More Decks by Kuu

Other Decks in Programming

Transcript

  1. 自己紹介 Kuu
   @Fumiya_Kume
 Android Engineer at Mercari, Inc
 船舶免許取ったので沖縄満喫中


    Kazuki Otao
   @0meo
 iOS Engineer at Mercari, Inc
 千葉に住んでる
 2
  2. • 2022年9月、2年半かけてコードベースを刷新 ◦ 技術負債を返済し、モダンな技術スタックの採用 ▪ Kotlin / Jetpack Compose /

    Kotlin coroutines ◦ Google I/O にてケーススタディが公開 ◦ Jetpack Compose の採用で、 UI 開発の生産性が 56 % 向上したメルカリ | Google Play | Android Developers • 今回の発表で紹介するコンテンツは、その書き直しプロジェクト中に形成されたもの 5 0からメルカリアプリを書き直すプロジェクト
  3. モバイルアプリの開発体制 • 一つのチームに各ロールが所属 • 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
  4. 開発の進め方:実験アイディアの考案 1. 実験アイディアの考案 2. ドキュメント作成 3. 実装 4. 実験の実施 ICEフレームワーク

    インパクト・影響範囲
 月間利用者数, 登録完了率... 等々 
 信頼性・確実性
 過去の挑戦と結果も参考にする 
 容易に実施できるのか
 開発・デザイン・分析... 
 10
  5. 開発の進め方:ドキュメント作成 11 コンテンツ 目的 オーナー Requirement Doc 要件・仕様・機能 What (要件)を

    明らかにする Product Manager UI Design デザイン Designer (Software) Design Docs 開発方法 How (どのように 開発するか) を明らかにする Enginnear ※ 1つのRequirements Docに対して、  モバイル・Web・バックエンドと複数のDesign Docsが作られることがある 1. 実験アイディアの考案 2. ドキュメント作成 3. 実装 4. 実験の実施
  6. 開発の進め方:ドキュメント作成 / Design Docの内容 12 1. 実験アイディアの考案 2. ドキュメント作成 3.

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

    3. 実装 4. 実験の実施 • Design Docを書く過程で仕様の欠落に気づくことができ、実装 時に生じるコミュニケーションコストを減らし、 開発速度の低下を防げる • 実装前に思考を整理し、困難点を推測できる。 必要に応じてPoCを作成して本実装前に議論する • 実装の概要を開発メンバーで事前に共有できるので、 PRレビューの精度が上がる
  8. Android / iOSでDesign Docを共通化 14 • Android / iOSで別々のDesign Docsを書いていた

    ◦ ほとんどが共通化できるような内容であった ◦ エッジケースへの対処などの知見がうまく共有されなかった 以前の課題 提案 • Android / iOSでDesign Docを共通化 ◦ Design Docを作成するコストが1/2になった ◦ 共通の課題 / バグ等の知見の共有が進んだ
  9. スクラムイベント 見出し スプリント中盤
 スプリント初め
 • スプリントプランニング 
 • リファインメント
 •

    ドッグフーディング
 • レトロスペクティブ
 • スプリントレビュー
 スプリント後半
 毎日
 • デイリースタンドアップ 
 
 20
  10. スクラムイベント 見出し スプリント中盤
 スプリント初め
 • スプリントプランニング 
 • リファインメント
 •

    ドッグフーディング
 • レトロスペクティブ
 • スプリントレビュー
 スプリント後半
 毎日
 • デイリースタンドアップ 
 
 21
  11. • スクショやGIF付きで、気づいた点を共有。必要ならチケットを作成 ドッグフーディング 23 OS 報告者 問題 スクショ Action Plan

    Ticket (If needed) Xperia 1 Ⅱ / Android 12 @Kuu ダイアログのURLテキストが 通常のテキストよりも小さい @Kuu フォントサイズの指 定が正しいか 確認 @Otao デザイナーに確認 [Backlog] ダイアロ グのURLテキストの デザイン修正
  12. • ドッグフーディングでは Android / iOSエンジニア関係なく可能であれば両方のデバイスを触る • OSが違うことによる体験の差を体感する機会は 実はQAエンジニア以外だとなかなかない • AndroidエンジニアがiOSアプリの修正点を指摘をしたり、

    iOSアプリを触ることでAndroidアプリの修正点に気づくことがある ◦ モバイルで共通化されたDesign Docを用いても、 Android / iOSエンジニアが仕様を勘違いして実装してしまうことはよくある Android / iOSエンジニアが協調開発するために 26
  13. • テンプレートに埋める内容 ◦ ドッグフーディングする機能のDesign Docs, Figmaなどの関連URL ◦ 機能の使い方のフロー ◦ 有効にするFeatureFlag

    ◦ Android / iOSのビルド済みバイナリ ◦ 使用するテストアカウント ドッグフーディング - ドキュメントの準備 30
  14. 33 まとめ Android / iOSアプリを効率よく開発する施策 Design Doc • Howに着目したドキュメント •

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