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

by Kuu

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 Kuu  　 @Fumiya_Kume  Android Engineer at Mercari, Inc  船舶免許取ったので沖縄満喫中  Kazuki Otao  　 @0meo  iOS Engineer at Mercari, Inc  千葉に住んでる  2

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

日本最大のフリマアプリ MAU 2000万人を越える大きなサービス  [決算資料より引用]   4

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

モバイルアプリの開発体制 ● 一つのチームに各ロールが所属 ● 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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

開発の進め方:実験アイディアの考案 1. 実験アイディアの考案 2. ドキュメント作成 3. 実装 4. 実験の実施 ICEフレームワークインパクト・影響範囲  月間利用者数, 登録完了率... 等々   信頼性・確実性  過去の挑戦と結果も参考にする   容易に実施できるのか  開発・デザイン・分析...   10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

まとめ 32

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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