プロダクトを切り開くのは、プロダクトオーナーか?プロダクトマネージャーか?

1. Toshihiro Ichitani All Rights Reserved.
Ichitani Toshihiro
市⾕聡啓
プロダクトを切り開くのは、プロダクトオーナーか？
プロダクトマネージャーか？それとも
プロダクトプレナーシップ

2. (My KeyWord)
市⾕ 聡啓
仮説検証型アジャイル開発
正しいものを正しくつくる
越境
Ichitani Toshihiro

3. https://ichitani.com/
Profile

4. https://www.amazon.co.jp/dp/4802511191/
6⽉14⽇発刊

5. 正しいものを正しくつくる
https://lp.guildhub.jp/

6. プロダクトづくりを切り開く
のに必要な役割とは何か？

7. 今回のお話で扱う役割
プロダクトオーナー
プロダクトマネージャー
それぞれに求められることを知り、
役割定義に振り回されないようにする

8. 役割論争
「プロダクトオーナーとは！」「プロダクトマネージャーとは！」
なぜ、役割定義にこだわりが⽣じるのか？
実際に、役割論争に巻き込まれた時、役割定義にこだわりを
持っている⼈に感じたのは、以下の2点。
・相⼿は、期待以上に振る舞ってくれるか？という不安
・⾃分は、どこまでどういう振る舞いが必要なの？という不安
(何にでもある)

9. 根底にあるのは「不安」
信頼関係が出来きっていない、あるいは「失敗したくない」
という感情が、安⼼の担保に役割定義に⾛らせる。
こうした定義を詰め切ろうとすることに、さほど価値は無い。
Photo on Visualhunt

10. 鉄壁の守りとは、”硬さ”ではなく”柔らかさ”
役割はどれほど⾔語化、決めきろうとしたところで全てのボール
(タスク、現象、事案) を捌き切ることを約束できるわけではない
(想定外のこぼれ⽟が役割の間を抜けていく)。
むしろ、役割を厳密に事前に⾔語化することに⼒を⼊れるのではなく。
ボールが転がっていること抜けようとしていることを捉えられること。
捉えられた後に、今後、この⽅向に来たボールをどう捌くか、
確認しあい、⽳を塞いで⾏けることのほうが本質的。

11. 事前の共通理解
⽇常で調整していく
部分
事前の共通理解
⽇常で調整していく
部分
相互の役割について、事前に共通理解にしておく部分と、
⽇常の中で調整していく部分の割合は、プロジェクトの不確実性、
当事者の練度などで決まる。
理解を確認して、後はふりかえりで適宜調整していく。
状況の不確実性⾼く読み切れない
⽇常で調整していく部分が多い
役割に慣れている、関係性できている
ある程度これまでの理解で処理できる

12. 事前の共通理解
⽇常で調整していく部分
世の中的テイギ関係者の頭が「世の中テイギ」ありきに
なっているような場合だと…苦労する
プロジェクトになる。
(「あってる？正解はなに？！」)
事前の共通理解
⽇常で調整していく
部分
役割についての「世の中的テイギ」は、
共通理解を助けるためのものでしかない。
(世の中テイギに頼りきらず⾃分たちで考えること!)
世の中的テイギ

13. プロダクトオーナー
プロダクトマネージャー

14. プロダクトオーナー
・プロダクトの価値を⾼めることに責任を担う
(どうすれば利⽤者にとっての有⽤性、意味を⾼められるかを考える)
・プロダクトバックログ(PBL)を保全し、⼀つ⼀つの中⾝を明確にする
(PBLの死は、プロダクトの死)
・プロダクトバックログの順序に意思を込める
・プロダクトの出来具合から間違った⽅向に向かっていないか確認する
(⽅向性の番⼈)
・プロダクトについての仮説を⽴て検証しPBLに学びを反映する
(仮説の番⼈)
ProductOwner
意思決定の集中 = ⽅向性のブレを抑える

15. プロダクトオーナーに求められること
単⾝で担うには負担が⼤きくなりがち。
チーム、他の役割で補完。協同的関係性で乗り切っていく。

16. プロダクトオーナー
プロダクトマネージャー
PdMはぽっと出の概念ではなく、それだけに定説もない。
ここではPOが存在し、その相対としてこの役割を捉える。

17. プロダクトマネージャ
・プロダクトの価値 = ビジネスの価値 + ユーザーの価値
ユーザー体験の最適化に重⼼があるPOは、ビジネス価値の設計が
弱い場合がある
・PdMがビジネス価値、POがユーザー価値という「重⼼の分担」
・プロダクトがビジネス観点で存続できるように、プランニングする
・組織とPO、組織とチームの間での「翻訳」を担う (整合性を保つ)
組織の意思決定は必ずしもユーザーファーストではない場合がある
・POの孤独を⽀える
ProductManager
チームの”外堀”を担う = プロダクトの存続に注⼒
外堀…ビジネス的、政治的、マーケット向けという観点でプロダクトの外づらにあたる

18. アジャイル、リーン⽅⾯のイニシエの先達

19. Alanの説明
1. ステークホルダーがビジネス
上の与件を定義する。
2. 与件からMMF（Minimum
Marketable Feature/市場に出せ
る最⼩限の機能性）を定義する。
3. MMFに順序付けを⾏い、順序
付けたMMFをストーリーに分割
4. チーム(複数)にストーリーを
割り当てする
http://www.manaslink.com/articles/4435

20. Alanの説明
1. ステークホルダーがチームの
状況までトレースするのは無理な
ので、POが担う
2. ただし、ステークホルダーの
関⼼事(MMF)の分割の仕⽅によっ
ては、複数チームにまたがって、
POが状況マネジメントする必要
が出てくる (ヤバイ)
http://www.manaslink.com/articles/4435

21. Alanの説明
MMF→Story→Teamの複雑性を、
PdMとPOという役割分担によって
抑え込む。
PdMは、
・ステークホルダーへの代表者と
なる。
・MMFの順序付けを担う
・MMFを分割する
POは、
・チームに対して何したいかを詳
しく分かっている専⾨家として振
る舞う。
・PdMに対してチームの代表者と
なる。
・MMFの分割をPdMと共に⾏う
http://www.manaslink.com/articles/4435

22. Alanの説明
ちなみにMMF→Storyという分割を
して開発をしているため、市場に出す
際にはStory→MMFという統合が必要。
「リリーストレイン」というイベント
で、バラバラのタイミングで上げられ
るアウトプットを定期的に意味のある
単位でまとめあげてリリースする。
http://www.manaslink.com/articles/4435

23. POとPdMの違い
PO …特にユーザー体験の最適化に重⼼を置く
PdM…特にビジネス価値の最⼤化に重⼼を置く
くらいの共通理解、基づくミッションを置いて、後は両者で調整する

24. …以上が「役割による調整」
での問題解決。
「役割による調整」を中⼼に置くと
その「役割」がプロダクト、チームの
可能性の上限になりやすい。
(意思決定が集中しがちなPOの練度が低いままだとしたら…
プロダクトは、ビジネスは、ユーザーは、どうなる？)

25. 「孤⾼のPO」「役割による調整頼み」から
「仮説検証による”学び”を中⼼に置いた共創」
で可能性を広げる

26. “PO” を解体するだけで良いの？
(仮説検証をチームで取り組むとして)

27. プロダクトづくりには
⼈の意識と知恵を結集させる⼒
= 「引⼒」が必要
Photo credit: jurek d. (Jerzy Durczak) on VisualHunt.com / CC BY-NC

28. いわゆる”アントレプレナーシップ(起業家精神)"
ということになるのだろうけど…。
必ずしも”(社内)起業だから”必要なことではなく
多くのプロダクトや事業づくりに必要とされる姿勢といえる

29. そもそも「プレナー」はフランス語を語源としており、
“受け⼿” や ”間を取り持つ⼈(between taker)” という
意味がある。
プロダクトづくりには
「⼈とその意識を集め、巻き込み、勇気づける」振る舞いが
求められる。こうした ”プレナーシップ” を発揮する⼈物が必要。
POでも、PdMでも、デザイナーでも、プログラマーでも良い。
しかし誰も持ち得ていないとしたら。成果は期待できない。
⼈の意識と知恵を結集させる引⼒
= 「プロダクトプレナーシップ」

30. ⼈の振る舞いを「役割定義」から解放し
「引⼒」に惹かれあうチームの協働で
プロダクトづくりに挑む。

31. 「正しいものを正しくつくれているか？」