エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug

エンジニアのための
プロダクトマネジメント入門
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～
2018/09/08(土)14:30-14:45
グロースエクスパートナーズ株式会社
関満徳＠fullvirtue
0

本セッションの概要
• 製品開発には、デザイナーやエンジニアなどに加
えて、プロダクトマネージャーが重要な役割を果
たします。
– プロダクトマネージャーは、複数部署からの担当者で構
成されるプロダクトチームにおいて、人ではなく製品を
管理するという役割を持ち、エンジニアに対する人事権
を持つエンジニアリングマネージャーなどとともに製品
開発をリードします。
– エンジニアリングとビジネスの双方に対して責任を持つ
非常に難易度の高いポジションですが、この役割の存在
がプロダクトの成否を分けることもあります。
• 本セッションでは、そのようなプロダクトマネー
ジャーが担うプロダクトマネジメントについて、
概説いたします。
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 1

本セッションの対象者
• プロダクトマネジメントに興味のある
エンジニア

本セッションのゴール
• プロダクトマネジメントについて把握する
• エンジニアがプロダクトマネージャーになる
ために必要なことを把握する

アジェンダ
• 「作る」から「使い続ける」へ
• アジャイルとスクラムとプロダクトオーナー
• プロダクト組織が抱える課題
• どう対応したらよいのか
• 米Microsoftが取り組んだこと
• プロダクトマネージャーとしてのキャリア
• 求められるスキルとマインドセット
• まとめ

アジェンダ
• まとめ

「作る」から「使い続ける」へ

参考資料(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.～アジャイル・プロダクトマネジメント研究会～ 8モノ消費ではなくコト消費の時代へ http://www.nikkeibp.co.jp/article/matome/20140220/384639/

–モノを作る
–作ったモノを使い続けてコトを得る
–モノを作らずコトを得る
–Experienceを売っている

–一度作ったモノは、作ったらおしまい
–目に見えない価値であるコトは変わっていくので、
追随していく必要がある

–一度作ったモノは、成長しない
–一度作ったモノは、リリース後も成長し続ける
リリース1回目
↓
リリースn回目
↓
成
長
度
時間
成長しない
成長し続ける

–一度作ってリリースしたら、改修されない
–リリース後も改修し続ける
リリース1回目
↓
リリースn回目
↓
成
長
度
改修されない
改修し続ける
時間

–モノの提供＝数年間に一度のリリースの時代
–コトの提供＝数ヶ月/数週間/数日に1回、または
1日数回のリリースの時代へ
時間
時間
リ
リ
ー
ス
リ
リ
ー
ス

–単一リリースのためのアーキテクチャ
単一リリース
アーキテクチャ
–複数リリース毎に改善するアーキテクチャ
複数リリース
改善するアーキテクチャ
…

–単一プロジェクトのためのプロダクトマネジメント
単一プロジェクト
プロダクトマネジメント
–複数プロジェクトに跨がるプロダクトマネジメント
複数プロジェクト
プロダクトマネジメント
…

• マネジメント領域における役割
プロダクト
マネジメント
（PdM）
Do the right thing:
正しいことをする
プロダクト・マネージャー
プロダクト・オーナー
リーダー
プロジェクト
マネジメント
（PjM）
Do things right:
正しく実行する
プロジェクト・マネジャー
マネジャー
十返文子 - プロジェクトマネジメント再入門〜PjMは何であって何でないのか〜 https://www.slideshare.net/togaeri/pjm-72819087/14

• マネジメント領域におけるマネジメント対象
プロジェクトマネジメントプロダクトマネジメント
スコープ
マネジメント
コスト
マネジメント
コミュニ
ケーション
マネジメント
統合
マネジメント
ステーク
ホルダー
マネジメント
リスク
マネジメント
調達
マネジメント
資源
マネジメント
タイム
マネジメント
品質
マネジメント
What
How How
much
When
HowHow How
Why
How
WhoWhere
プロダクト
マネジメント
顧客（市場）
マネジメント
What Who
Who
ほぼ一緒？
やや重なる？
＝分析・戦略…
十返文子 - プロジェクトマネジメント再入門〜PjMは何であって何でないのか〜 https://www.slideshare.net/togaeri/pjm-72819087/12

• 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#

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/

• バイモーダルで実現する企業IT
モード1
方向
転換
馬力
モード2
小野和俊 - わたしのバイモーダル戦略 http://blog.livedoor.jp/lalha/archives/50524676.html

「使い続ける」実現プロセス
• [大量生産による解決]下でのプロダクトマネジメント
Copyright© Growth xPartners, Inc. All rights reserved. 21PMStyle – プロダクトマネジメント入門 http://pmstyle.biz/column/product/product1_3.htm
対
象
ス
キ
ル
【上流(upstream)】
～市場投入までに行うべきこと～
・ロードマップ
・ビジネスケース
・新製品開発
・市場投入
【下流(downstream)】
～市場投入後に行うべきこと～
・ライフサイクル管理
・ブランド管理
・マーケティング
・リーダーシップ
・意思決定
・会計
・コンペティティブ・
インテリジェンス
・価格戦略
プロダクトマネージャー
プロダクトオーナー

• インターネット時代のプロダクトマネジメント
Copyright© @fullvirtue. All rights reserved. 22プロダクトマネジメントトライアングル(改案) https://webexpert-draft.jp/articles/59

プロジェクトマネジメント
社内外調整／資源獲得
プロダクト仕様
カスタマー/技術サポート
データ分析
デザイン
マーケティング
パートナーシップ
ビジネスデベロップメント

プロダクト
マネージャー

• [例]プロダクトマネージャーへのキャリアパス
プロダクト
マネージャー
エンジニア
マーケティングスタートアップ

• [例]プロダクトマネージャーへのキャリアパス
プロダクト
マネージャー
エンジニア
営業 QA

アジェンダ
• まとめ

アジャイルとスクラムとプロダク
トオーナー

• 日本的プロダクトオーナーの現状
スクラム
マスター
開発チーム
開発
日本的プロダクトオーナー
経営層
情シス
営業
広報ｺｰﾙｾﾝﾀｰ
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労の
ポイント
日本的プロダクトオーナーは、スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。

• スクラムで定義しているプロダクトオーナー
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
スクラム
マスター
開発チーム
開発
プロダクトオーナー

• 日本的プロダクトオーナーの現状
スクラム
マスター
開発チーム
開発
日本的プロダクトオーナー
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労のポイ
ント
日本的プロダクトオーナーは、スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
プロダクトデザイン
・
リーンUX
スクラム
アーキ
テクチャ
本番運用

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
リーン
スクラム
アーキ
テクチャ
本番運用
アジャイル
・
モダンアジャイル

モダンアジャイルの4原則
• [最高] 人々を最高に輝かせる
• [安全] 安全を必須条件にする
• [高速] 高速に実験＆学習する
• [継続] 継続的に価値を届ける
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 35モダンアジャイルの原則・実践について - 今給黎隆 http://bit.ly/2qCRRGu

モダンアジャイルプラクティス
カテゴリプラクティス
1 [最高][安全] 仕事の憲章化
2 [高速][最高][安全] リーン・スタートアップの活用
3 [高速][最高] リーンUXの適用
4 [高速][安全][継続] 頻繁な協調と統合
5 [安全][高速] 安全に失敗できる環境
6 [安全][継続] テストとリファクタリング
7 [安全] 人々への敬意と感謝
8 [安全][高速] 非難しないふりかえりを指揮
9 [継続] フローに集中
10 [継続][高速][安全] 継続的なデプロイとリリース
11 [継続][安全] プロダクトコミュニティを形成
12 [継続][高速][安全] ソリューションを進化
モダンアジャイルの原則・実践について - 今給黎隆 http://bit.ly/2qCRRGu

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
思い込みにより発生
する各種ムダを省く
ためにリーンにやる
ムダなモノを省き
必要なモノを素早く
作り続ける
エンジニアリング
モノを支え
るアーキ
テクチャ
ムダなく本番運用を
まわし続ける

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
用意しなければなら
ないモノ
用意しな
ければなら
ないモノ
対応しなければ
ならないコト

プロダクト
Log
仮説スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測出荷
プロダクト
利用
プロダクトデザイン
・
リーン
スクラム
アーキ
テクチャ
本番運用

バックログの作成プロセス
Copyright© Growth xPartners, Inc. All rights reserved. 40
経営層
ステークホルダー
バックログ
実現可能性
検討
顧客
意思決定
検討
スクラム
マスター
開発チーム
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
グルーミング
プロダクトロードマップ
マイルストーン
バックログ
リファインメント
計画見直し
プロダクト
バックログ

バックログの作成プロセス
経営層
ステークホルダー
バックログ
実現可能性
検討
顧客
意思決定
検討
スクラム
マスター
開発チーム
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
グルーミング
プロダクトロードマップ
マイルストーン
バックログ
リファインメント
計画見直し
①
②
③
④
⑤
プロダクト
バックログ

プロダクト
Log
仮説スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討仕様検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測出荷
プロダクト
利用

アジェンダ
• まとめ

プロダクト組織が抱える課題

• 日本的なプロダクト組織
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 営業や企画が強く、開発が企画機能の下請けに
なっている
発注受託

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• プロダクトマネージャーが調整やタスクを抱え
すぎてパンク
仕事
抱えすぎ

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 抱えている調整が可視化されず、周辺がうまく
サポートできない
ブラック
ボックス

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• プロダクトマネージャーが倒れるとプロダクト
全体が大ダメージ
弱点

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 中心人物が辞めてしまった / 規模が大きくなっ
て組織を拡大したいが、中心人物がいない
誰かやって～！

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 企画のためのR&D調査、運用のための割り込み
調査、実現に向けた技術調査が、開発を圧迫
調査調査
調査
調査
調査
調査
か、開発が、、、

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 開発リソースをプロダクト別に分断したため、
プロダクト毎に開発チームの戦力が偏っている
プロダクトA
プロダクトB
プロダクトC
プロダクトD
チームA
チームB
チームC
チームD

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 事業計画に基づく開発ピークの重なりに抱えて
いる開発メンバーの再配分で対応できない
プロダクトA
プロダクトB
プロダクトC
プロダクトD
チームA
チームB
チームC
チームD
余裕あるから
休もうっと！
余裕あるから
別のことを...
エンジニアが足りない！！！
誰か手伝ってくれ….

アジェンダ
• まとめ

どう対応したらよいのか

どう対応したらいいのか
• 日本的なプロダクト組織
スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 圧倒的なカリスマ的プロダクトマネージャー？
私に任せて！？

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
• 強いプロダクト組織で対応！

アジェンダ
• まとめ

Microsoft PowerPoint における開発手法
米Microsoftが取り組んだこと

Microsoft PowerPoint の歴史
出典：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

Microsoft PowerPoint の種類
• パッケージ版
–Office 20XX
» Windows 版
» MacOS 版
–Office 365
» Windows 版
» OS X 版
• Office Online
• スマートフォン用アプリ
–iOS 版

Microsoft PowerPoint の開発体制
• 複数チームで構成
• 1チームは、自律的に動ける人数に限定
–プログラムマネージャー × 1名～?名
–エンジニア × 数名
–プログラムマネージャーとエンジニアは同室にいる
–プラットフォーム毎にチーム編成を行っているわけ
ではない
• ローカライズは、別チームが担当

Microsoft PowerPoint 開発の進め方
• タスクは、2種類に分類
• それぞれのタスクを担当するチーム数は
スプリント毎に再配分
–時期によって比率がかなり異なる
» Microsoft Build 後は、フィードバックがたくさん来る
▸ シールド : フィーチャーが 50% : 50% になることも
▸ シールドが溜まる傾向にある場合、シールド対応チーム数を増やして
対応
タスク内訳
シールドフィードバック／不具合対応
フィーチャー計画された機能開発→毎月リリース

お話してくださった方が言うには
• アジャイルやスクラムをやっているという認識
はない
• Microsoft 社内で試行錯誤した結果、今の形に
行き着いた
• とはいえ、ここまでくるのにいろいろなことが
あった

ここ最近のTopix (1/3)
• チームメンバーからテスターがいなくなった
–開発とテストは両輪
–同じ人が同時にやればよい
–エンジニアAが実装、エンジニアBがテスト、という
分担をすることもある
–テストは基本的にすべて自動化が必要
» とはいえ、数十年前から存在するソースコードのため、
既存のコードは膨大に存在するが、その部分を自動化する
ようなことはしていない
» 今回手を入れる部分について、新たにテストコードを記述

• チームメンバーからDev Lead がいなくなった
–マネージャーの役割をしていた人が一気に減った
–1チームの人数を減らして、マネージャーがいなくて
も管理可能に

• 評価制度がかなり変わった
–リリースされなかったら評価がゼロ
–どのぐらいのインパクトを与えたかが評価
» 10やってたことを2に減らす、かわりに
やった2を10箇所にApplyしてインパクトを増やすetc…
» やることを減らして、クオリティを上げる傾向に
–評価はかけ算
» セキュリティやパフォーマンスが悪いと0点に

アジェンダ
• まとめ

プロダクトマネージャーとして
のキャリア

プロダクト
マネージャー

プロダクト
マネージャー
エンジニア

プロダクト
マネージャー
エンジニア
営業 QA

エンジニア
プロダクト
マネージャー
• キャリア
ステップアップに
必要なことは？

プロダクト
マネージャー
• キャリア
ステップアップに
必要なことを
事前に聞きましたエンジニア

• キャリアステップアップに必要なこと
マーケティングから
プロダクトマネージャーへ
1. 「誰のどんな課題を解決
するべきか」という課題
発見の方法を知ること
2. 基本的なプロジェクトマ
ネジメントの方法を知る
こと
3.プロダクトを創る技術の
基礎を知ること
エンジニアから
1. エンジニア職の延長では
なく、新しい職にチャレ
ンジするという気持ち
2.プロダクトマネージャー
に求められる役割を正し
く理解すること
3.いまの自分とのギャップ
を埋めていくこと
スタートアップから
1.フェーズによる役割の変
化を理解すること
2.課題を定義すること
3.質と量のバランスを
見極めること

• キャリアステップアップに必要なこと
1. 「誰のどんな課題を解決するべ
きか」という課題発見の方法を
知ること
• マーケ = (基本的には)出来ている
コンセプトをどうやって世界に伝
えるか
• プロダクトマネージャー=誰が何に
困っているか見つけて解決策を生
み出す
2. 基本的なプロジェクトマネジメ
ントの方法を知ること
• 多少手間かかるけどプロトタイプ
綺麗なのを最初に作れば後々助か
るよ、とか
3. プロダクトを創る技術の基礎を
知ること
• 開発者が何を話しているかぐらい
はわかるようになる
• 「新たな技術でできるようになる
こと」の "肌感" を得る
1. エンジニア職の延長ではなく、
新しい職にチャレンジするとい
う気持ち
• エンジニア力は確かに強みの一つ
ではあるが、それだけではだめ
2. プロダクトマネージャーに求め
られる役割を正しく理解するこ
と
• 会社によって異なるので、自分の
成果は何なのかを確認・定義する
こと
3. そのうえでいまの自分との
ギャップを埋めていくこと
• 多くのエンジニアがギャップと感
じることは下記だと思う
• 正しい課題発見をするスキル (エン
ジニアは課題解決力のプロ)
• ひとを通じて成果をだすこと (PM
はだれかと協働しないと成果にな
らない)
1. フェーズによる役割の変化を理
解すること
• 初期フェーズは社長が PO であり、
その思いを開発チームに通訳する
• 成長フェーズは自身が PO の代理
としてビジネスサイドを巻き込む
• 拡大フェーズはプロダクトマネジ
メントのフレームを作る
• さらにその先には、PM を育てる
というマネジメントが求められる
2. 課題を定義すること
3. 質と量のバランスを見極めるこ
と

アジェンダ
• まとめ

求められるスキルとマインドセ
ット

プロダクトマネージャーとしての成長
• 成長とは？

• 成長とは？

• 成長とは？
プロダクト
マネージャー
求められるもの？

• 成長とは？
スキル
マインドセット

プロダクト
マネージャー
• 成長に必要な
スキルと
マインドセットを
事前に聞きましたエンジニア

1. みんなが望んでいることを、
今まさに可能なことと組み
合わせて実現する総合力
1. 世界を少しでも良くしたい
という熱意
2. 自分はできるという一種の
傲慢さ (自信)
3. 大事なことを大事にする
4. できる方法を考える
1. インサイト発見力
2. マジ価値
3. ムーブメント
1. 製品を愛してください
2. いつでも楽しんで
3. 人間に対してアンテナを高
く持つ
1. 抽象的に捉える力
2. 説明能力（言語化能力）
1. プロダクトに対する情熱
2. プロダクトの責任者である
という自負
3. 関係者への配慮
4. 成功のためなら何でもやる
5. 他人を巻きこむ
ス
キ
ル
マ
イ
ン
ド
セ
ッ
ト

求められるスキル
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. 他人を巻きこむ

アジェンダ
• まとめ

まとめ

本セッションのゴール
• プロダクトマネジメントについて把握する
• エンジニアがプロダクトマネージャーになる
ために必要なことを把握する

今日お話したこと
• まとめ

お知らせ

http://2018.pmconf.jp/

ご清聴ありがとうございました！
コンタクト先 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サービス開発全般のコンサルティング、開発、運用を
一括して手掛けながら、「顧客価値の創造」と「持続可
能な仕組み創り」をテーマとしたアジャイル・プロダク
トマネジメントのワークショップデザインを数多く実施。
全国各地でファシリテーターとしても活躍。

エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug

Ähnlich wie エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug (20)

Mehr von 満徳関

Mehr von 満徳関 (20)