More Related Content
Similar to エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug (20)
エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug
- 8. 参考資料(1/1)
– モノ消費ではなくコト消費の時代へ
» http://www.nikkeibp.co.jp/article/matome/20140220/384639/
– Naoya Ito - System of Record と System of Engagement
» https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98c
cecd6?slide=4#
– 赤間 信幸 - 拝啓『変わらない開発現場』を嘆く皆様へ
~変わっていくエンタープライズ系業務システム開発とマイ
クロソフトエンタープライズサービスの取り組み~
» https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmod
ernization/
– 小野 和俊 - わたしのバイモーダル戦略
» http://blog.livedoor.jp/lalha/archives/50524676.html
– 十返 文子 - プロジェクトマネジメント再入門
〜PjMは何であって何でないのか〜
» https://www.slideshare.net/togaeri/pjm-72819087/12
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 7
- 17. 「作る」から「使い続ける」へ
• マネジメント領域における役割
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 16
プロダクト
マネジメント
(PdM)
Do the right thing:
正しいことをする
プロダクト・マネージャー
プロダクト・オーナー
リーダー
プロジェクト
マネジメント
(PjM)
Do things right:
正しく実行する
プロジェクト・マネジャー
マネジャー
十返 文子 - プロジェクトマネジメント再入門 〜PjMは何であって何でないのか〜 https://www.slideshare.net/togaeri/pjm-72819087/14
- 18. 「作る」から「使い続ける」へ
• マネジメント領域におけるマネジメント対象
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 17
プロジェクトマネジメント プロダクトマネジメント
スコープ
マネジメント
コスト
マネジメント
コミュニ
ケーション
マネジメント
統合
マネジメント
ステーク
ホルダー
マネジメント
リスク
マネジメント
調達
マネジメント
資源
マネジメント
タイム
マネジメント
品質
マネジメント
What
How How
much
When
HowHow How
Why
How
WhoWhere
プロダクト
マネジメント
顧客(市場)
マネジメント
What Who
Who
ほぼ一緒?
やや重なる?
=分析・戦略…
十返 文子 - プロジェクトマネジメント再入門 〜PjMは何であって何でないのか〜 https://www.slideshare.net/togaeri/pjm-72819087/12
- 19. 「作る」から「使い続ける」へ
• SoR (System of Record) (モード1)
–情報を正しく 「記録」 するためのシステム
–想起するもの ・・・ バックエンド、予約、在庫、カー
ド決済、ポイント処理、管理画面
• SoE (System of Engagement) (モード2)
–ユーザーや取引先との「絆」を作るためのシステム
–想起するもの ・・・ UI、デザイン、アプリ、スマート
フォン、ダイレクトマーケティング、CRM
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 18Naoya Ito - System of Record と System of Engagement https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98ccecd6?slide=4#
- 20. 「作る」から「使い続ける」へ
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 19
SoR 型システム(モード1) SoE 型システム(モード2)
用語 • System of Record • System of Engagement
定義
• 事実を記録することに主眼を置いたシステ
ム・サービス
• お客様との関係(絆)を強化するための
システム・サービス
主役 • データ • 利用者
システム領域
• バックエンド
• 認証、在庫管理、決済、個人情報保護
• フロントエンド、スマートフォンアプリ
• UI、CRM、ダイレクトメール
開発手法
• 比較的ウォーターフォール寄り
• 開発前に要件を明確に定義
• 品質の確保を優先
• 比較的アジャイル、リーン寄り
• トライ&エラーで正しい問題・論点を
探り当てる
• 迅速なリリースを優先
性向 / 適合
• 安定性重視
• 予測可能業務
• リスクを抑えて安全運転
• 要件を事前に明確化
• ユーザーインタフェース品質、開発速度重視
• 探索型業務
• スピード重視で運転
• トライ&エラー、プロトタイピング
マネジメント
• トップダウン寄り
• 「正しい仕様」に基づいたプロジェクト管理
• 経営や開発部門が主導することが多い
• ボトムアップ寄り
• 「正しい仕様」は存在しない
• マーケティング、デザインが主導することも
ケイパ
ビリティ
• 要件定義力、調整力、プロジェクトマネジメ
ント
• SIのみなさんが得意そう
• ユーザー視点、デザイン思考、アナリティク
ス
• Web系が得意そう ケイパビリティ
Naoya Ito - System of Record と System of Engagement https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98ccecd6?slide=4#
赤間 信幸 - 拝啓『変わらない開発現場』を嘆く皆様へ~変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み~ https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmodernization/
- 22. 「使い続ける」実現プロセス
• [大量生産による解決]下でのプロダクトマネジメント
Copyright© Growth xPartners, Inc. All rights reserved. 21PMStyle – プロダクトマネジメント入門 http://pmstyle.biz/column/product/product1_3.htm
対
象
ス
キ
ル
【上流(upstream)】
~市場投入までに行うべきこと~
・ロードマップ
・ビジネスケース
・新製品開発
・市場投入
【下流(downstream)】
~市場投入後に行うべきこと~
・ライフサイクル管理
・ブランド管理
・マーケティング
・リーダーシップ
・意思決定
・会計
・コンペティティブ・
インテリジェンス
・価格戦略
プロダクトマネージャー
プロダクトオーナー
- 30. 「使い続ける」実現プロセス
• 日本的プロダクトオーナーの現状
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 29
スクラム
マスター
開発チーム
開発
日本的プロダクトオーナー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労の
ポイント
日本的プロダクトオーナーは、 スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。
- 32. 「使い続ける」実現プロセス
• 日本的プロダクトオーナーの現状
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 31
スクラム
マスター
開発チーム
開発
日本的プロダクトオーナー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労のポイ
ント
日本的プロダクトオーナーは、 スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。
- 33. 「使い続ける」実現プロセス
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 32
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ 計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
- 34. 「使い続ける」実現プロセス
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 33
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ 計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
プロダクトデザイン
・
リーンUX
スクラム
アーキ
テクチャ
本番運用
- 35. 「使い続ける」実現プロセス
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 34
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ 計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
リーン
スクラム
アーキ
テクチャ
本番運用
アジャイル
・
モダンアジャイル
- 36. モダンアジャイルの4原則
• [最高] 人々を最高に輝かせる
• [安全] 安全を必須条件にする
• [高速] 高速に実験&学習する
• [継続] 継続的に価値を届ける
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 35モダンアジャイルの原則・実践について - 今給黎 隆 http://bit.ly/2qCRRGu
- 37. モダンアジャイル プラクティス
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 36
カテゴリ プラクティス
1 [最高][安全] 仕事の憲章化
2 [高速][最高][安全] リーン・スタートアップの活用
3 [高速][最高] リーンUXの適用
4 [高速][安全][継続] 頻繁な協調と統合
5 [安全][高速] 安全に失敗できる環境
6 [安全][継続] テストとリファクタリング
7 [安全] 人々への敬意と感謝
8 [安全][高速] 非難しないふりかえりを指揮
9 [継続] フローに集中
10 [継続][高速][安全] 継続的なデプロイとリリース
11 [継続][安全] プロダクトコミュニティを形成
12 [継続][高速][安全] ソリューションを進化
モダンアジャイルの原則・実践について - 今給黎 隆 http://bit.ly/2qCRRGu
- 38. 「使い続ける」実現プロセス
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 37
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ 計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
思い込みにより発生
する各種ムダを省く
ためにリーンにやる
ムダなモノを省き
必要なモノを素早く
作り続ける
エンジニアリング
モノを支え
るアーキ
テクチャ
ムダなく本番運用を
まわし続ける
- 39. 「使い続ける」実現プロセス
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 38
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ 計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
用意しなければなら
ないモノ
用意しな
ければなら
ないモノ
対応しなければ
ならないコト
- 40. 「使い続ける」実現プロセス
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 39
プロダクト
Log
仮説 スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討 仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
アーキテクチャ
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測 出荷
プロダクト
利用
プロダクトデザイン
・
リーン
スクラム
アーキ
テクチャ
本番運用
- 41. バックログの作成プロセス
Copyright© Growth xPartners, Inc. All rights reserved. 40
経営層
ステークホルダー
オポチュニティ
バックログ
実現可能性
検討
顧客
意思決定
アーキテクチャ
検討
スクラム
マスター
開発チーム
プロダクトマネージャー
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
グルーミング
プロダクトロードマップ
マイルストーン
バックログ
リファインメント
計画見直し
プロダクト
バックログ
- 42. バックログの作成プロセス
Copyright© Growth xPartners, Inc. All rights reserved. 41
経営層
ステークホルダー
オポチュニティ
バックログ
実現可能性
検討
顧客
意思決定
アーキテクチャ
検討
スクラム
マスター
開発チーム
プロダクトマネージャー
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
グルーミング
プロダクトロードマップ
マイルストーン
バックログ
リファインメント
計画見直し
①
②
③
④
⑤
プロダクト
バックログ
- 43. 「使い続ける」実現プロセス
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 42
プロダクト
Log
仮説 スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討 仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
アーキテクチャ
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測 出荷
プロダクト
利用
- 47. プロダクト組織が抱える課題
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 46
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 営業や企画が強く、開発が企画機能の下請けに
なっている
発注 受託
- 48. プロダクト組織が抱える課題
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 47
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• プロダクトマネージャーが調整やタスクを抱え
すぎてパンク
仕事
抱えすぎ
- 49. プロダクト組織が抱える課題
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 48
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 抱えている調整が可視化されず、周辺がうまく
サポートできない
ブラック
ボックス
- 50. プロダクト組織が抱える課題
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 49
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• プロダクトマネージャーが倒れるとプロダクト
全体が大ダメージ
弱点
- 51. プロダクト組織が抱える課題
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 50
スクラム
マスター
開発チーム
開発
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 中心人物が辞めてしまった / 規模が大きくなっ
て組織を拡大したいが、中心人物がいない
誰かやって~!
- 52. プロダクト組織が抱える課題
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 51
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 企画のためのR&D調査、運用のための割り込み
調査、実現に向けた技術調査が、開発を圧迫
調査調査
調査
調査
調査
調査
か、開発が、、、
- 53. プロダクト組織が抱える課題
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 52
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 開発リソースをプロダクト別に分断したため、
プロダクト毎に開発チームの戦力が偏っている
プロダクトA
プロダクトB
プロダクトC
プロダクトD
チームA
チームB
チームC
チームD
- 54. プロダクト組織が抱える課題
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 53
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 事業計画に基づく開発ピークの重なりに抱えて
いる開発メンバーの再配分で対応できない
プロダクトA
プロダクトB
プロダクトC
プロダクトD
チームA
チームB
チームC
チームD
余裕あるから
休もうっと!
余裕あるから
別のことを...
エンジニアが足りない!!!
誰か手伝ってくれ….
- 58. どう対応したらいいのか
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 57
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 圧倒的なカリスマ的プロダクトマネージャー?
私に任せて!?
- 59. どう対応したらいいのか
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 58
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 強いプロダクト組織で対応!
- 62. Microsoft PowerPoint の 歴史
Copyright© Growth xPartners, Inc. All rights reserved. 61
出典:WikiPedia https://ja.wikipedia.org/wiki/Microsoft_PowerPoint
No. パッケージ版のリリース状況
バージョン 1 Forethougt が1987年にMacintosh向けにリリースしたもの。
バージョン 2 Macintosh版は1988年にリリースされ、Windows版はWindows 3.0用で1990年にリリースされた。
バージョン 3 Macintosh版は1992年にリリースされ、Windows版はWindows 3.1用にMacintosh版と同じ年にリリースされた。
バージョン 4 Windows版の PowerPoint 4.0 は1993年にリリースされ、Macintosh版のPowerPoint 4.0は1994年にリリースされた。
バージョン 7 他のOfficeソフトウェアとバージョン番号が統一されたため、バージョン番号が3繰り上がった。このバージョンはPowerPoint
95としてWindows版のみリリースした。日本語版はこのバージョンから用意された。
バージョン 8 Windows版のPowerPoint 97が1996年にリリースされ、Macintosh版のPowerPoint 98は1998年にリリースされた。
バージョン 9 Windows版のPowerPoint 2000が1999年にリリースされ、最後のMac OS 9版PowerPoint 2001は2000年にリリースされた。
PowerPoint 2000では従来アウトライン画面・スライド画面・ノート画面を別々の画面で操作していたものを、一つの画面で操
作できるようになったことで、プレゼンテーション制作の生産性を大幅に向上させた。
バージョン 10 Windows版のPowerPoint 2002が2001年にリリースされ、初のMac OS X版のPowerPoint Xも同年にリリースされた。
バージョン 11 Windows版のPowerPoint 2003が2003年にリリースされ、Mac OS X版のPowerPoint 2004は2004年にリリースされた。
バージョン 12 Windows版のPowerPoint 2007が2007年にリリースされ、Mac OS X版のPowerPoint 2008は2008年にリリースされた。
バージョン 14 Windows版のPowerPoint 2010が2010年にリリースされ、Mac OS X版のPowerPoint 2011も同年にリリースされた。
バージョン ? 2010年6月から「Office Web Apps」という名称で、Word、Excel、PowerPoint、OneNoteのブラウザベースのバージョンが
提供された。以降、都度バージョンアップを実施。
2014年2月に、「Office Online」に名称変更した。
バージョン? 2011年6月に「Office 365」が提供開始された。以降、都度バージョンアップを実施。
バージョン 15 Windows版のPowerPoint 2013が2013年にリリースされた。
バージョン 16 Windows版、OS X版、iOS版のPowerPoint 2016が2015年にリリースされた。
出典:WikiPedia https://ja.wikipedia.org/wiki/Microsoft_Office_365
- 63. Microsoft PowerPoint の 種類
• パッケージ版
–Office 20XX
» Windows 版
» MacOS 版
–Office 365
» Windows 版
» OS X 版
• Office Online
• スマートフォン用アプリ
–iOS 版
Copyright© Growth xPartners, Inc. All rights reserved. 62
- 64. Microsoft PowerPoint の 開発体制
• 複数チームで構成
• 1チームは、自律的に動ける人数に限定
–プログラムマネージャー × 1名~?名
–エンジニア × 数名
–プログラムマネージャーとエンジニアは同室にいる
–プラットフォーム毎にチーム編成を行っているわけ
ではない
• ローカライズは、別チームが担当
Copyright© Growth xPartners, Inc. All rights reserved. 63
- 65. Microsoft PowerPoint 開発の進め方
• タスクは、2種類に分類
• それぞれのタスクを担当するチーム数は
スプリント毎に再配分
–時期によって比率がかなり異なる
» Microsoft Build 後は、フィードバックがたくさん来る
▸ シールド : フィーチャー が 50% : 50% になることも
▸ シールドが溜まる傾向にある場合、シールド対応チーム数を増やして
対応
Copyright© Growth xPartners, Inc. All rights reserved. 64
タスク内訳
シールド フィードバック/不具合対応
フィーチャー 計画された機能開発→毎月リリース
- 68. ここ最近のTopix (2/3)
• チームメンバーからDev Lead がいなくなった
–マネージャー の役割をしていた人が一気に減った
–1チームの人数を減らして、マネージャーがいなくて
も管理可能に
Copyright© Growth xPartners, Inc. All rights reserved. 67
- 79. プロダクトマネージャーとしてのキャリア
• キャリアステップアップに必要なこと
Copyright© @fullvirtue. All rights reserved. 78
マーケティングから
プロダクトマネージャーへ
1. 「誰のどんな課題を解決
するべきか」という課題
発見の方法を知ること
2. 基本的なプロジェクトマ
ネジメントの方法を知る
こと
3.プロダクトを創る技術の
基礎を知ること
エンジニアから
プロダクトマネージャーへ
1. エンジニア職の延長では
なく、新しい職にチャレ
ンジするという気持ち
2.プロダクトマネージャー
に求められる役割を正し
く理解すること
3.いまの自分とのギャップ
を埋めていくこと
スタートアップから
プロダクトマネージャーへ
1.フェーズによる役割の変
化を理解すること
2.課題を定義すること
3.質と量のバランスを
見極めること
- 80. プロダクトマネージャーとしてのキャリア
• キャリアステップアップに必要なこと
Copyright© @fullvirtue. All rights reserved. 79
マーケティングから
プロダクトマネージャーへ
1. 「誰のどんな課題を解決するべ
きか」という課題発見の方法を
知ること
• マーケ = (基本的には)出来ている
コンセプトをどうやって世界に伝
えるか
• プロダクトマネージャー=誰が何に
困っているか見つけて解決策を生
み出す
2. 基本的なプロジェクトマネジメ
ントの方法を知ること
• 多少手間かかるけどプロトタイプ
綺麗なのを最初に作れば後々助か
るよ、とか
3. プロダクトを創る技術の基礎を
知ること
• 開発者が何を話しているかぐらい
はわかるようになる
• 「新たな技術でできるようになる
こと」の "肌感" を得る
エンジニアから
プロダクトマネージャーへ
1. エンジニア職の延長ではなく、
新しい職にチャレンジするとい
う気持ち
• エンジニア力は確かに強みの一つ
ではあるが、それだけではだめ
2. プロダクトマネージャーに求め
られる役割を正しく理解するこ
と
• 会社によって異なるので、自分の
成果は何なのかを確認・定義する
こと
3. そのうえでいまの自分との
ギャップを埋めていくこと
• 多くのエンジニアがギャップと感
じることは下記だと思う
• 正しい課題発見をするスキル (エン
ジニアは課題解決力のプロ)
• ひとを通じて成果をだすこと (PM
はだれかと協働しないと成果にな
らない)
スタートアップから
プロダクトマネージャーへ
1. フェーズによる役割の変化を理
解すること
• 初期フェーズは社長が PO であり、
その思いを開発チームに通訳する
• 成長フェーズは自身が PO の代理
としてビジネスサイドを巻き込む
• 拡大フェーズはプロダクトマネジ
メントのフレームを作る
• さらにその先には、PM を育てる
というマネジメントが求められる
2. 課題を定義すること
3. 質と量のバランスを見極めるこ
と
- 88. プロダクトマネージャーとしての成長
• 求められるスキルとマインドセット
Copyright© @fullvirtue. All rights reserved. 87
マーケティングから
プロダクトマネージャーへ
1. みんなが望んでいることを、
今まさに可能なことと組み
合わせて実現する総合力
1. 世界を少しでも良くしたい
という熱意
2. 自分はできるという一種の
傲慢さ (自信)
3. 大事なことを大事にする
4. できる方法を考える
エンジニアから
プロダクトマネージャーへ
1. インサイト発見力
2. マジ価値
3. ムーブメント
1. 製品を愛してください
2. いつでも楽しんで
3. 人間に対してアンテナを高
く持つ
スタートアップから
プロダクトマネージャーへ
1. 抽象的に捉える力
2. 説明能力(言語化能力)
1. プロダクトに対する情熱
2. プロダクトの責任者である
という自負
3. 関係者への配慮
4. 成功のためなら何でもやる
5. 他人を巻きこむ
ス
キ
ル
マ
イ
ン
ド
セ
ッ
ト
- 89. プロダクトマネージャーとしての成長
• 求められるスキルとマインドセット
Copyright© @fullvirtue. All rights reserved. 88
求められるスキル
1. みんなが望んでいることを今まさに可
能なことと組み合わせて実現する総合
力
• 誰が何に困っているか見つけるス
キル (UX理解)
• 今できることと出来ないことを嗅
ぎ分けるスキル (技術理解)
• お金の嗅覚 (ビジネス理解)
求められるスキル
1. インサイト発見力
• インタビュー・法律や商習慣・市
場環境・データ分析などを通じて
製品づくりに必要な情報を定義・
収集し、インサイトを得る
2. マジ価値
• 集めた情報からfreeeらしい価値を
創造する。
• ビジョン・仕様など何を作るか定
義をすることができる
3. ムーブメント
• UX・PjM・QA・Eng・Bizなど製
品開発に関わるチームと協働し、
価値ある製品をムーブメントとし
てリリースできる
求められるスキル
1. 抽象的に捉える力
• 個別の課題の本質を捉える
• 増大するバックログを整理する
• プロダクトの課題と組織の課題を
関連付ける
2. 説明能力(言語化能力)
• プロダクトの課題を言語化する
• タスク優先度の判断を説明する
• デザインモックの課題を具体的に
指摘する
• 開発の背景をエンジニアに共有す
る
求められるマインドセット
1. 世界を少しでも良くしたいという熱意
2. 自分はできるという一種の傲慢さ (自
信)
3. 大事なことを大事にする
4. できる方法を考える
求められるマインドセット
1. 製品を愛してください
2. いつでも楽しんで
3. 人間に対してアンテナを高く持つ
求められるマインドセット
1. プロダクトに対する情熱
2. プロダクトの責任者であるという自負
3. 関係者への配慮
4. 成功のためなら何でもやる
5. 他人を巻きこむ
- 97. ご清聴ありがとうございました!
コンタクト先 URL
Blog http://fullvirtue.com/
Twitter https://twitter.com/fullvirtue
Facebook https://www.facebook.com/fullvirtue
Email fullvirtue@gmail.com
資料公開場所 http://slideshare.net/fullvirtue/
これまで登壇してきた資料はこちらで公開しています!
是非ご覧ください!
関 満徳
せき みつのり
グロースエクスパートナーズ株式会社 ITアーキテクト
Microsoft MVP for Visual Studio and Development Technologies
ITサービス開発全般のコンサルティング、開発、運用を
一括して手掛けながら、「顧客価値の創造」と「持続可
能な仕組み創り」をテーマとしたアジャイル・プロダク
トマネジメントのワークショップデザインを数多く実施。
全国各地でファシリテーターとしても活躍。
Copyright© POStudy . All rights reserved.~アジャイル・プロダクトマネジメント研究会~ 96