開発チームが安定したプロダクトマネジメントを実現するための７つのルール
•
2 likes•8,061 views
開発チームが安定したプロダクトマネジメントを実現するための７つのルール / LINE株式会社 御代田 亮平 Product Manager Conference 2017での発表資料です。 http://2017.pmconf.jp/schedule/
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to 開発チームが安定したプロダクトマネジメントを実現するための７つのルール
Similar to 開発チームが安定したプロダクトマネジメントを実現するための７つのルール (20)
More from LINE Corporation
More from LINE Corporation (20)
開発チームが安定したプロダクトマネジメントを実現するための７つのルール
- 2. ⾃⼰紹介 • ログイン、SDK、トークン周辺 サービス担当 • Google -> Twitter -> LINE • LINE IDもTwitterハンドルも josolennoso
- 3. Agenda ✓ 紹介 ✓ プラットフォームチームの抱 えるハードル ✓ 開発体制変更と７つのルール
- 4. LINEについて • 6年前からサービス提供開始 • ⽇本のMAUは71M • 海外: タイ、台湾、インドネシア、他 • 国内外の開発拠点 • メッセージング以外にも多数のプラッフォーム機能
- 6. プラットフォーム観点からLINEの特徴 • LINEのプラットフォーム上に⾃らサービス作りで成果 • 3rd partyサービスが使いやすいプラットフォームの提供？
- 7. プラットフォーム観点からLINEの特徴 • LINEのプラットフォーム上に⾃らサービス作りで成果 • 3rd partyサービスが使いやすいプラットフォームの提供？ プラットフォーム機能を拡散することでMAU、Revenueの向 上に繋げることがミッション
- 9. プロダクトの課題 ✓ 独⾃実装が多い ✓ 謎のマジックナンバー ✓ ⼀貫しない挙動
- 10. 剥き出しの内部実装
- 11. 剥き出しの内部実装 ← 実は複数指定できない ← マジックナンバー。不可変 ← これもマジックナンバー。可変。
- 12. プロダクトの課題 ✓ 独⾃実装が多い ✓ 謎のマジックナンバー ✓ ⼀貫しない挙動 ➡ 紐解いていくとほとんどが開発プロセスの問題
- 13. プロセスの課題 ✓ 多様なステークホルダー ✓ それによって⽣じるトレードオフの問題 ✓ 多岐にわたる開発チーム
- 14. 多様なステークホルダー • デベロッパー • ユーザー • パートナー • etc • 開発チーム • ビジネスチーム • セキュリティチーム • リーガルチーム • etc
- 15. トレードオフ 例: • セキュアにするとAPIのフレキシビリティが減る • 法的事項の明記を優先するとUXの⾒栄えが悪くなる • ⼤きいパートナーと組めば短期的なレベニューは増えるがス ケーラビリティは？
- 16. 多岐にわたる開発チーム ✓ Authentication ✓ Token ✓ Storage ✓ Bot ✓ Login ✓ FE ✓ SDK ✓etc.
- 17. 開発体制変更と7つのルール
- 18. ⽬標 • デベロッパー⽬線で優れたプロダクト • 事業⽬線で優れたプロダクト • クオリティを損うことなく、迅速に、継続的にリリース
- 19. Ownership1/7
- 20. Ownershipを持たせる • 最終的に誰の⼀存で決まるかを明確にする • そして、その「誰」が意思決定プロセスに常に加わっていること • 組織によるのでセオリーはないが明確になっていることが重要 例：
- 21. Ownershipを持たせる • 最終的に誰の⼀存で決まるかを明確にする • そして、その「誰」が意思決定プロセスに常に加わっていること • 組織によるのでセオリーはないが明確になっていることが重要 L I N E C L I E N T N E W F E AT U R E 例：
- 22. Ownershipを持たせる • 最終的に誰の⼀存で決まるかを明確にする • そして、その「誰」が意思決定プロセスに常に加わっていること • 組織によるのでセオリーはないが明確になっていることが重要 L I N E C L I E N T N E W F E AT U R E A P I FA M I LY A N E W A P I 例：
- 23. 以前の開発体制
- 24. 最 近 の 開 発 体 制
- 25. 依存関係の⾒える化2/7
- 26. A P I S E R V I C E 1 A U T H S E R V I C E A P I S E R V I C E 1 A P I G AT E WAY T O K E N S E R V I C E A P I S E R V I C E 2 B O T P L AT F O R M A P I S E R V I C E L O G I N S E R V I C E A P I S E R V I C E Web APIのバックエンド
- 27. A P I S E R V I C E 1 A U T H S E R V I C E A P I S E R V I C E 1 A P I G AT E WAY T O K E N S E R V I C E A P I S E R V I C E 2 B O T P L AT F O R M A P I S E R V I C E L O G I N S E R V I C E A P I S E R V I C E Web APIのバックエンド
- 28. 依存関係の⾒える化 ✓ ツールでカバー ✓ 限界がある部分はプロジェクトマネージャーが⼈⼒ ✓どのチームがどの機能をいつリリースするかをトラッキング ✓ ツールをベースとしたPM/TL間での徹底した議論
- 29. 新規開発プロセスの明⽰3/7
- 31. 「来週中に◯◯ログインを✕✕ OSに対応して欲しい。」（チャット） 「来期中にアカウントをバルクで⽣成する機能が欲しい。A社との取引の オペレーションがスムーズになりアップセルを期待できる」（メール）
- 35. 新規開発プロセスの5W1Hを明⽰する • When: いつリクエストできるの？ • Who: 誰がリクエストできるの？
- 36. 新規開発プロセスの5W1Hを明⽰する • When: いつリクエストできるの？ • Who: 誰がリクエストできるの？ • What: 何をリクエストできるの？
- 37. 新規開発プロセスの5W1Hを明⽰する • When: いつリクエストできるの？ • Who: 誰がリクエストできるの？ • What: 何をリクエストできるの？ • Why: なぜリクエストするの？
- 38. 新規開発プロセスの5W1Hを明⽰する • When: いつリクエストできるの？ • Who: 誰がリクエストできるの？ • What: 何をリクエストできるの？ • Why: なぜリクエストするの？ • Where: どこからリクエストするの？ • How: どうやってリクエストできるの？
- 39. 3つの数字を最⼤化4/7
- 43. Silent Majority or Vocal Minority?5/7
- 46. プロダクトライフサイクルにおけるコスト ✓ メンテナンス ✓ カスタマーオペレーション ✓ 本来の⽅向との⼀貫性 ✓ 引き継ぎ ✓ etc
- 47. Vocal Minority -> Great Influencer
- 50. スクラムマスターやPjMとの協業のメリット ✓ PMが開発やQAの進捗のフォローに費やす時間が減る ‣ リリースやマーケティングに割く時間を増やせる ‣ 次回リリースのスペック検討の時間を増やせる
- 51. PM = Party Managerでもある7/7
- 52. まとめ：開発体制変更と7つのルール 1. 各PMにOwnershipを明確に持たせる 2. サービス間の依存関係の⾒える化 3. ステークホルダーに新規開発プロセスを明⽰する 4. 3つの数字を最⼤化することを⽬指す 5. InfluencerたりうるVocal Minorityを⾒極める 6. スクラムマスターやPjMとの協業により効率的に進める 7. PM = Party Manager
- 53. ご清聴ありがとうございました