Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
開発チームが安定したプロダクトマネジメント
を⾏うための7つのルール
Ryohei N. Miyota
LINE Corp.
⾃⼰紹介
• ログイン、SDK、トークン周辺
サービス担当
• Google -> Twitter -> LINE
• LINE IDもTwitterハンドルも
josolennoso
Agenda ✓ 紹介
✓ プラットフォームチームの抱
えるハードル
✓ 開発体制変更と7つのルール
 
LINEについて
• 6年前からサービス提供開始
• ⽇本のMAUは71M
• 海外: タイ、台湾、インドネシア、他
• 国内外の開発拠点
• メッセージング以外にも多数のプラッフォーム機能
LINE Loginの年表
プラットフォーム観点からLINEの特徴
• LINEのプラットフォーム上に⾃らサービス作りで成果
• 3rd partyサービスが使いやすいプラットフォームの提供?
プラットフォーム観点からLINEの特徴
• LINEのプラットフォーム上に⾃らサービス作りで成果
• 3rd partyサービスが使いやすいプラットフォームの提供?
プラットフォーム機能を拡散することでMAU、Revenueの向
上に繋げること...
プラットフォームチームの抱えるハードル
プロダクトの課題
✓ 独⾃実装が多い
✓ 謎のマジックナンバー
✓ ⼀貫しない挙動
剥き出しの内部実装
剥き出しの内部実装
← 実は複数指定できない
← マジックナンバー。不可変
← これもマジックナンバー。可変。
プロダクトの課題
✓ 独⾃実装が多い
✓ 謎のマジックナンバー
✓ ⼀貫しない挙動
➡ 紐解いていくとほとんどが開発プロセスの問題
プロセスの課題
✓ 多様なステークホルダー
✓ それによって⽣じるトレードオフの問題
✓ 多岐にわたる開発チーム
多様なステークホルダー
• デベロッパー
• ユーザー
• パートナー
• etc
• 開発チーム
• ビジネスチーム
• セキュリティチーム
• リーガルチーム
• etc
トレードオフ
例:
• セキュアにするとAPIのフレキシビリティが減る
• 法的事項の明記を優先するとUXの⾒栄えが悪くなる
• ⼤きいパートナーと組めば短期的なレベニューは増えるがス
ケーラビリティは?
多岐にわたる開発チーム
✓ Authentication
✓ Token
✓ Storage
✓ Bot
✓ Login
✓ FE
✓ SDK
✓etc.
開発体制変更と7つのルール
⽬標
• デベロッパー⽬線で優れたプロダクト
• 事業⽬線で優れたプロダクト
• クオリティを損うことなく、迅速に、継続的にリリース
Ownership1/7
Ownershipを持たせる
• 最終的に誰の⼀存で決まるかを明確にする
• そして、その「誰」が意思決定プロセスに常に加わっていること
• 組織によるのでセオリーはないが明確になっていることが重要
例:
Ownershipを持たせる
• 最終的に誰の⼀存で決まるかを明確にする
• そして、その「誰」が意思決定プロセスに常に加わっていること
• 組織によるのでセオリーはないが明確になっていることが重要
L I N E
C L I E N T
N ...
Ownershipを持たせる
• 最終的に誰の⼀存で決まるかを明確にする
• そして、その「誰」が意思決定プロセスに常に加わっていること
• 組織によるのでセオリーはないが明確になっていることが重要
L I N E
C L I E N T
N ...
以前の開発体制
最 近 の 開 発 体 制
依存関係の⾒える化2/7
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...
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...
依存関係の⾒える化
✓ ツールでカバー
✓ 限界がある部分はプロジェクトマネージャーが⼈⼒
✓どのチームがどの機能をいつリリースするかをトラッキング
✓ ツールをベースとしたPM/TL間での徹底した議論
新規開発プロセスの明⽰3/7
「来期中にアカウントをバルクで⽣成する機能が欲しい。A社との取引の
オペレーションがスムーズになりアップセルを期待できる」(メール)
「来週中に◯◯ログインを✕✕ OSに対応して欲しい。」(チャット)
「来期中にアカウントをバルクで⽣成する機能が欲しい。A社との取引の
オペレーションがスムーズになりアップセルを期待できる」(メール)
「来年はもっとイルなボット機能が欲しい!!」(JIRA)
「来期中にアカウントをバルクで⽣成する機能が欲しい。A社との取引の
オペレーションがスムーズになりアップセルを期待できる」(メール)
「来週中に◯◯ログインを✕✕ OSに対応して欲しい。...
新規開発プロセスの5W1Hを明⽰する
新規開発プロセスの5W1Hを明⽰する
• When: いつリクエストできるの?
新規開発プロセスの5W1Hを明⽰する
• When: いつリクエストできるの?
• Who: 誰がリクエストできるの?
新規開発プロセスの5W1Hを明⽰する
• When: いつリクエストできるの?
• Who: 誰がリクエストできるの?
• What: 何をリクエストできるの?
新規開発プロセスの5W1Hを明⽰する
• When: いつリクエストできるの?
• Who: 誰がリクエストできるの?
• What: 何をリクエストできるの?
• Why: なぜリクエストするの?
新規開発プロセスの5W1Hを明⽰する
• When: いつリクエストできるの?
• Who: 誰がリクエストできるの?
• What: 何をリクエストできるの?
• Why: なぜリクエストするの?
• Where: どこからリクエストするの?...
3つの数字を最⼤化4/7
3つの数字を最⼤化するよう努める
開発者が開発に注ぐ時間 *
3つの数字を最⼤化するよう努める
開発者が開発に注ぐ時間
書いたコードがリリースされる
割合* *
3つの数字を最⼤化するよう努める
開発者が開発に注ぐ時間
書いたコードがリリースされる
割合* 実際に使われる頻度*
Silent Majority or Vocal Minority?5/7
よくあるパターン
✓とりあえず最重要パートナーであるVocal Minorityに⽿を傾け
てみる
よくあるパターン
✓とりあえず最重要パートナーであるVocal Minorityに⽿を傾け
てみる
✓謎パラメーターだらけになるが、ドキュメントやチュートリア
ルでカバーしよう
プロダクトライフサイクルにおけるコスト
✓ メンテナンス
✓ カスタマーオペレーション
✓ 本来の⽅向との⼀貫性
✓ 引き継ぎ
✓ etc
Vocal Minority -> Great Influencer
スクラムマスターやPjMの導⼊6/7
要件定義
開発
QAや
リリース関連
⼀般的な開発サイクル
スクラムマスターやPjMとの協業のメリット
✓ PMが開発やQAの進捗のフォローに費やす時間が減る
‣ リリースやマーケティングに割く時間を増やせる
‣ 次回リリースのスペック検討の時間を増やせる
PM = Party Managerでもある7/7
まとめ:開発体制変更と7つのルール
1. 各PMにOwnershipを明確に持たせる
2. サービス間の依存関係の⾒える化
3. ステークホルダーに新規開発プロセスを明⽰する
4. 3つの数字を最⼤化することを⽬指す
5. Influencer...
ご清聴ありがとうございました
Prochain SlideShare
Chargement dans…5
×

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

6 504 vues

Publié le

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

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

Publié dans : Technologie
  • Soyez le premier à commenter

開発チームが安定したプロダクトマネジメントを実現するための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. ご清聴ありがとうございました

×