Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

開発チームが安定したプロダクトマネジメントを実現するための7つのルール

6,503 views

Published on

開発チームが安定したプロダクトマネジメントを実現するための7つのルール / LINE株式会社 御代田 亮平

Product Manager Conference 2017での発表資料です。
http://2017.pmconf.jp/schedule/

Published in: Technology
  • Be the first to comment

開発チームが安定したプロダクトマネジメントを実現するための7つのルール

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

×