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
Android/iOSアプリを協調開発するチーム~~スクラム開発の実践とその先へ~~
Search
Kuu
October 06, 2022
Programming
1
8.7k
Android/iOSアプリを協調開発するチーム~~スクラム開発の実践とその先へ~~
Kuu
October 06, 2022
Tweet
Share
More Decks by Kuu
See All by Kuu
公的機関の発表資料に適合した作業環境がBEST__情報機器作業における労働衛生管_理のためのガイドラインについて__を添えて.pdf
fumiyakume
0
250
202212_Kotlinfest2022.pdf
fumiyakume
1
62
All for One なポストモーテム運用と工夫
fumiyakume
1
480
Microdroidが 興味深い件について
fumiyakume
0
760
Gradle Plugin for Multi Module
fumiyakume
0
1.3k
UIレンダリングから見るクロスプラットフォーム開発
fumiyakume
0
260
Other Decks in Programming
See All in Programming
社内フレームワークとその依存性解決 / in-house framework and its dependency management
vvakame
1
550
Kubernetes History Inspector(KHI)を触ってみた
bells17
0
200
Pythonでもちょっとリッチな見た目のアプリを設計してみる
ueponx
1
480
Amazon S3 TablesとAmazon S3 Metadataを触ってみた / 20250201-jawsug-tochigi-s3tables-s3metadata
kasacchiful
0
100
一休.com のログイン体験を支える技術 〜Web Components x Vue.js 活用事例と最適化について〜
atsumim
0
110
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
770
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
3
730
Grafana Loki によるサーバログのコスト削減
mot_techtalk
1
110
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
10
1.8k
CNCF Project の作者が考えている OSS の運営
utam0k
5
690
Amazon ECS とマイクロサービスから考えるシステム構成
hiyanger
2
490
自分ひとりから始められる生産性向上の取り組み #でぃーぷらすオオサカ
irof
8
2.6k
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
20
2.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
RailsConf 2023
tenderlove
29
1k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
BBQ
matthewcrist
86
9.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
240
Transcript
Android / iOSアプリを協調開発するチーム 〜スクラム開発の実践とその先へ〜
自己紹介 Kuu @Fumiya_Kume Android Engineer at Mercari, Inc 船舶免許取ったので沖縄満喫中
Kazuki Otao @0meo iOS Engineer at Mercari, Inc 千葉に住んでる 2
日本最大のフリマアプリ かんたんに売り買いができて、あんしん・あんぜんなお取引ができるフリマアプリ 3
日本最大のフリマアプリ MAU 2000万人を越える大きなサービス [決算資料より引用] 4
• 2022年9月、2年半かけてコードベースを刷新 ◦ 技術負債を返済し、モダンな技術スタックの採用 ▪ Kotlin / Jetpack Compose /
Kotlin coroutines ◦ Google I/O にてケーススタディが公開 ◦ Jetpack Compose の採用で、 UI 開発の生産性が 56 % 向上したメルカリ | Google Play | Android Developers • 今回の発表で紹介するコンテンツは、その書き直しプロジェクト中に形成されたもの 5 0からメルカリアプリを書き直すプロジェクト
メルカリでのモバイルアプリ開発 コンテンツ スクラムイベントにおける工夫 02 01 6
メルカリでの モバイルアプリ開発 7
モバイルアプリの開発体制 • 一つのチームに各ロールが所属 • 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
開発の進め方 9 1. 実験アイディアの考案 2. ドキュメント作成 3. 実装 4. 実験の実施
開発の進め方:実験アイディアの考案 1. 実験アイディアの考案 2. ドキュメント作成 3. 実装 4. 実験の実施 ICEフレームワーク
インパクト・影響範囲 月間利用者数, 登録完了率... 等々 信頼性・確実性 過去の挑戦と結果も参考にする 容易に実施できるのか 開発・デザイン・分析... 10
開発の進め方:ドキュメント作成 11 コンテンツ 目的 オーナー Requirement Doc 要件・仕様・機能 What (要件)を
明らかにする Product Manager UI Design デザイン Designer (Software) Design Docs 開発方法 How (どのように 開発するか) を明らかにする Enginnear ※ 1つのRequirements Docに対して、 モバイル・Web・バックエンドと複数のDesign Docsが作られることがある 1. 実験アイディアの考案 2. ドキュメント作成 3. 実装 4. 実験の実施
開発の進め方:ドキュメント作成 / Design Docの内容 12 1. 実験アイディアの考案 2. ドキュメント作成 3.
実装 4. 実験の実施 項目 目的 関係者の一覧 誰に聞けばいいのか知る UIデザインのリンク UIの実装時に参照 画面の遷移・流れ 全体像を掴む・動作確認 Feature Flag / ログ 必要な情報を知る Story / Ticketのリンク 作業の依存関係を確認 各種調査結果 調査結果を記録 テストアカウント 動作確認に必要
開発の進め方:ドキュメント作成 / Why Design Doc? 13 1. 実験アイディアの考案 2. ドキュメント作成
3. 実装 4. 実験の実施 • Design Docを書く過程で仕様の欠落に気づくことができ、実装 時に生じるコミュニケーションコストを減らし、 開発速度の低下を防げる • 実装前に思考を整理し、困難点を推測できる。 必要に応じてPoCを作成して本実装前に議論する • 実装の概要を開発メンバーで事前に共有できるので、 PRレビューの精度が上がる
Android / iOSでDesign Docを共通化 14 • Android / iOSで別々のDesign Docsを書いていた
◦ ほとんどが共通化できるような内容であった ◦ エッジケースへの対処などの知見がうまく共有されなかった 以前の課題 提案 • Android / iOSでDesign Docを共通化 ◦ Design Docを作成するコストが1/2になった ◦ 共通の課題 / バグ等の知見の共有が進んだ
開発の進め方:実装 Design System サービス全体で共通コンポーネントを定義し、UIを構築する手法 UI開発時にデザインの共通言語として使い、効率よく実装できる トランクベース開発 寿命の長いfeatureブランチの代わりに、小さなPRを直接mainブランチ にマージすることで、ブランチのサイクルタイムを下げる手法 ペアプログラミング 基本的にはフルリモート・フルフレックスで非同期だが、
同期的な作業の方が効率が良い場合に実施 15 1. 実験アイディアの考案 2. ドキュメント作成 3. 実装 4. 実験の実施
開発の進め方:実験の実施 A/Bテスト 段階的機能公開 アプリを更新するために数時間 ~数日かかる審査が必要 モバイルアプリ特有のリリース事情 アプリを更新するタイミングや頻度はお客さま次第 Feature Flag アプリリリースとは別に機能の有効/無効を切り替えられる仕組み
バグがあってもすぐhotfix / revertできない 16 1. 実験アイディアの考案 2. ドキュメント作成 3. 実装 4. 実験の実施
メルカリでのモバイルアプリ開発 コンテンツ スクラムイベントにおける工夫 02 01 17
スクラムイベントにおける工夫 18
• 基本的な情報 ◦ 2週間1スプリント ◦ ファシリテーターはローテーション スクラムイベントにおける工夫 19
スクラムイベント 見出し スプリント中盤 スプリント初め • スプリントプランニング • リファインメント •
ドッグフーディング • レトロスペクティブ • スプリントレビュー スプリント後半 毎日 • デイリースタンドアップ 20
スクラムイベント 見出し スプリント中盤 スプリント初め • スプリントプランニング • リファインメント •
ドッグフーディング • レトロスペクティブ • スプリントレビュー スプリント後半 毎日 • デイリースタンドアップ 21
• ドッグフーディング? ◦ 実装した機能を開発者自らで使用してみること ◦ 「機能を使ったときの体験」を見て、お客さま目線で仕様の改善を提案する • QAではない ◦ QAは仕様通りに動くか、エッジーケースに対応できているかチェック
◦ QAは別に実施する ドッグフーディング 22
• スクショやGIF付きで、気づいた点を共有。必要ならチケットを作成 ドッグフーディング 23 OS 報告者 問題 スクショ Action Plan
Ticket (If needed) Xperia 1 Ⅱ / Android 12 @Kuu ダイアログのURLテキストが 通常のテキストよりも小さい @Kuu フォントサイズの指 定が正しいか 確認 @Otao デザイナーに確認 [Backlog] ダイアロ グのURLテキストの デザイン修正
APIを待つ時間が想定より長く、 実際に触ってみると不安を感じた お客さまの待ち時間観点からのフィードバック Progress indicators - Material Design 課題 提案
本来の仕様にはなかったが、 ローディングインディケーターを追加した 24
UIの細かな操作を行うことが難しく 体験面で改善点があると感じた アクセシビリティ観点からのフィードバック 課題 提案 • アクセシビリティの改善 ◦ リンクテキストのフォントサイズの変更 ◦
ボタンの最小サイズを大きく • Voice Overの対応 25 Material Design 3 - Accessible design
• ドッグフーディングでは Android / iOSエンジニア関係なく可能であれば両方のデバイスを触る • OSが違うことによる体験の差を体感する機会は 実はQAエンジニア以外だとなかなかない • AndroidエンジニアがiOSアプリの修正点を指摘をしたり、
iOSアプリを触ることでAndroidアプリの修正点に気づくことがある ◦ モバイルで共通化されたDesign Docを用いても、 Android / iOSエンジニアが仕様を勘違いして実装してしまうことはよくある Android / iOSエンジニアが協調開発するために 26
• ドッグフーディングをスクラムイベントの中に組み込むことで お客さま視点からの体験を改善させるための提案をエンジニアサイドから行う機会を作る ドッグフーディングのススメ 27
ドッグフーディングをうまく進めるためには? MTG前: 40分: 10分: MTG後: アプリを触って気づいた点を列挙 気づいた点の共有 チケットの作成 ドキュメントの準備 28
ドッグフーディングをうまく進めるためには? MTG前: 40分: 10分: MTG後: アプリを触って気づいた点を列挙 気づいた点の共有 チケットの作成 ドキュメントの準備 29
• テンプレートに埋める内容 ◦ ドッグフーディングする機能のDesign Docs, Figmaなどの関連URL ◦ 機能の使い方のフロー ◦ 有効にするFeatureFlag
◦ Android / iOSのビルド済みバイナリ ◦ 使用するテストアカウント ドッグフーディング - ドキュメントの準備 30
メルカリでのモバイルアプリ開発 コンテンツ スクラムイベントにおける工夫 02 01 31
まとめ 32
33 まとめ Android / iOSアプリを効率よく開発する施策 Design Doc • Howに着目したドキュメント •
我々のチームでは両OSで協力して作成 • 出戻りを防ぐことに大きく貢献 みんなで使いやすいスマホアプリを開発する施策 ドッグフーディング • チーム全員で、一人では見落としがちなお客さま視点の改善を拾い上げる • Android / iOSに精通しているからこそのプロフェッショナルな意見
• 我々はプロダクト自体の改善だけでなく、プロダクトの開発工程の改善も続けている ◦ その過程で得られた現時点でうまく動いている施策を紹介した • これらの施策は完成形ではなく、 1, 2年後にはきっと新たな施策・変化した施策・辞めた施策が出てくる • チーム改善に終わりはなく、チームの数だけ異なる形があることに留意し
「進化し続ける」ことを辞めない 34 スクラム開発の実践とその先へ
We are hiring & We have booth! 35 https://careers.mercari.com/jp/
Android/iOSアプリを協調開発するチーム 〜スクラム開発の実践とその先へ〜