MTC2018 - 海をまたぐ開発チームとTech Lead

Speaker: 今井 智章

メルカリでは今年からプラットフォームごとに技術ロードマップを策定し、技術的な観点からもプロダクトへ貢献できるような取り組みをしています。US版Mercari Androidチームはスケールしても機動力の高いしなやかなチームを作ることを目指し、技術ロードマップを策定しました。本セッションではどのように技術ロードマップが策定され推進されてきたのかをテックリードの役割も交えてお話します。

Transcript

1. 海をまたぐ開発チームとTech Lead 今井 智章 Tech Lead (Android)
2. Tech Lead Android Tomoaki Imai
3. 海をまたぐ開発チームと Tech Lead
4. • メルカリにおけるTech Leadの役割 • 海をまたぐ開発チームでTech Leadが取り組んだこと 今日話すこと
5. US Mercari Android 2017 → 2018
6. US Android Project プロジェクト爆誕 Mercari Plus リリース Mercari と統合 リブランディング
7. US Android Project プロジェクト爆誕 Mercari Plus リリース Mercari と統合 リブランディング
8. US Android Project プロジェクト爆誕 Mercari Plus リリース Mercari と統合 リブランディング
9. US Android Project プロジェクト爆誕 Mercari Plus リリース Mercari と統合 リブランディング
10. US Android Project プロジェクト爆誕 Mercari Plus リリース Mercari と統合 リブランディング • リニューアル後リリース回数: 42回(ベータ版リリース等も含 めると200回) • コード(Java, Kotlin): 100,215行 • スクリーン数 ◦ Native : 約60 ReactNative : 約40 • クライアントABテスト: 約40 (2018.10月現在) Fun facts
11. US Mercari Android Team 2017 → 2018
12. US Mercari Android Team
13. US Mercari Android Team Joined! (2018.2 ~) Joined! (2018.1 ~)
14. US Mercari Android Team Joined! (2018.2 ~) Joined! (2018.1 ~) Moving to SF -> Palo Alto
15. US Mercari Android Team Tech Lead (2018.1 ~) Tech Lead (2018.7 ~) Joined! (2018.2 ~) Joined! (2018.1 ~) Moving to SF -> Palo Alto
16. なぜ Tech Leadが必要なのか？
17. 2017/1 • 2名体制 • USメンバー のみ 2018/1 • 5 名体制 • コア基盤はUS側 で管理 20XX • 100~ 名体制 • 各国でオーナーシップを 持ち、爆速開発 • 大規模でも高品質な プロダクトを提供 US Mercari Android Teamの開発体制
18. 2017/1 • 2名体制 • USメンバー のみ 2018/1 • 5 名体制 • コア基盤はUS側 で管理 20XX • 100~ 名体制 • 各国でオーナーシップを 持ち、爆速開発 • 大規模でも高品質な プロダクトを提供 コード品質とスピードをどう保 つ? どうオーナーシップをメンバー が持てるようにする? US Mercari Android Teamの開発体制
19. メンバーがオーナーシップをもち、スケールに強い、 しなやかなチームを作るために 技術的な観点からチームを牽引するのが Tech Lead
20. Tech Lead として取り組んだこと • 技術的ロードマップを作る • 技術的ロードマップをリードする
21. Tech Lead として取り組んだこと • 技術的ロードマップを作る • 技術的ロードマップをリードする
22. 技術的ロードマップとは？ • 将来のあるべき姿に対して達成すべき技術的マイルストーン • メルカリUSでは全社的な技術的ロードマップをベースにプラットフォームごとの 技術方針を策定
23. 技術的ロードマップで意識したこと 技術的に やってみたいこと ユーザーへの価値 目指す姿 生産性/品質 あくまでユーザーに価値をできること、目指す方向進め ることにフォーカス
24. 取り組むべき課題の整理 スケール オーナーシップ ・暗黙知、属人化した仕様の増加 ・コードの複雑化によるキャッチ　 アップコスト ・海をまたぐことによるコミュニ　ケー ションコストや開発の遅延 ・技術的な役割分担の不足 品質 ・コードの品質や生産性の向上 ・脆弱性への対応
25. 取り組むべき課題の整理 スケール オーナーシップ ・暗黙知、属人化した仕様の増加 ・コードの複雑化によるキャッチ　 アップコスト ・海をまたぐことによるコミュニ　ケー ションコストや開発の遅延 ・技術的な役割分担の不足 品質 ・コードの品質や生産性の向上 ・脆弱性への対応 Modularize Kotlinize Design Language Security 2018年は4つの領域にフォーカス
26. Tech Lead として取り組んだこと • 技術的ロードマップを作る • 技術的ロードマップをリードする
27. 海をまたぐチームでいかにロードマップを遂行 するか？ 課題の先生になる 技術検証は誰よりもハマる オーナーシップの醸成 1 2 3
28. • 課題を誰よりも説明できるようになる ◦ なにが問題なのか ◦ どう解決したいのか • 課題を共有 ◦ ピッチスライドを作成してプレゼン 課題の先生になる 1 Why? How? • なぜ課題を解決すべきかメンバーに心か ら納得して関心を持ってもらうため
29. なぜ、なにを、どうやってを 明らかにする ラフなアイデアも共有 (但し深掘りしすぎない ) スライド上でオープンな Q&A とディスカッション ピッチスライドの例
30. • 手を動かして解決方法を検証する • 一番難しいケースにチャレンジする • 経験を共有する 技術検証は誰よりも ハマる 2 Why? How? • 自分が落とし穴を埋めてスムーズに新し い技術やアイデアにメンバーを導くため
31. コード上での検証 検証しながらフィードバックを受 ける 検証した結果や気づきなどはド キュメントにまとめる
32. • Tech Lead一人の力よりチームが一丸 になったほうが強いから オーナーシップの 醸成 3 Why? How? • タスクのオーナー制 • 必要なときの技術支援
33. 各オーナーが責任を持って進め る タスクのオーナーシップ テックロードマップ関連のタスク やDevTaskはGithub issueで管 理
34. タスクのオーナーシップ Fluxプロジェクト推進のため 1週間US出張 モジュール化プロジェクト関連で 1週間US出張 Googleチームとmtg
35. • スケールできるチームを技術的な観点から牽引するのが Tech Leadの役割 • ユーザーに価値を提供できることにフォーカスして ロードマップを策定 • “課題の先生になる”, ”誰よりもハマる”, ”オーナーシップの 醸成”、それが私のTech Leadしぐさ まとめ