プロダクトオーナー2.0

Toshihiro Ichitani All Rights Reserved.

Ichitani Toshihiro
市⾕聡啓
開発チームとプロダクトオーナーの間の境界線を
「プロダクトオーナーの⺠主化」によって解消する
プロダクトオーナー2.0

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

https://ichitani.com/
Proﬁle

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

「これまでの開発スタイル」から
「アジャイルな開発」に
向かうのを阻むものとは何か？

アジャイル開発は
２度失敗する

Photo on VisualHunt
1
アジャイル開発の習慣を
チームで⾝につけること
2
開発チームとプロダクトオーナー
の間に⽣まれる境界線

Photo on VisualHunt
1
アジャイル開発の習慣を
チームで⾝につけること
2
開発チームとプロダクトオーナー
の間に⽣まれる境界線
今⽇話すこと

開発チームはスクラムの振る舞いを
⾝につけられている。
開発チームとPOはPBLをはさんで
コミュニケーションすることに最適化。
POが何をしていて、どうやってPBLを
つくっているか開発チームが知らない。
「スプリントの空振り」が起きる。
プロダクトづくりの不吉なにおい
PBL…プロダクトバックログ

Toshihiro Ichitani All Rights Reserved. Photo credit: Steven Penton on VisualHunt / CC BY
プロダクトオーナーにかかる
プレッシャーは重い

プロダクトオーナーに求められること
プロダクトを形にするために必要な知識とスキル
ソフトウェア開発の
基本的な知識
プロダクトバックログの
管理⽅法
受け⼊れテストの実施と
テスト結果の活⽤
ユーザーテストによる
フィードバック取得と
継続的な計測
プロジェクトマネジメント
コミュニケーション設計
プロダクトがどうあるべきか
の牽引のために
チームとの協働のために
プロジェクトを遂⾏するために
開発メンバーとの意思疎通
のために

https://www.slideshare.net/papanda/97-78212969
ご興味があればこちらもどうぞ

PBLを⽣み出すための仮説検証に
⻑けており⼗分な知識と経験がある
しかも、プロダクトづくりの新しい
取り組みのタイミングで運良く
稼働が空いている！
"理想的なプロダクトオーナー"
“理想的なプロダクトオーナー” とは
都合の良い概念でしかない

間違ったものを
正しくつくる
Do the Wrong things Right
Photo credit: BeaLeiderman via VisualHunt.com / CC BY-NC-SA
いくら型どおりに正しくつくっていても、
間違ったもの(⽬的に適さないもの)をつくっている限り
ミッションは達成できない。

Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC
開発チームからPO側への越境

プロダクトデザイナー型PO中⼼のフォーメーション
ビジネス推進型PO中⼼のフォーメーション
要求の⾔語化、整理
ユーザーインターフェース
の⽅針を決める
ビジネスモデルの
設計
要求の⾔語化、整理
ユーザーインターフェース
の⽅針を決める
ビジネスモデルの
設計
プロダクト
マネージャーによる
補完
UIデザイナーに
よる補完
POの役割をチームで補完する

ケーススタディ
もっとも”伝統”のモメンタムが
かかりやすい組織と⾔えば？
伝統的な組織ほどアジャイルへの移⾏は逆境

経産省の「シン・ミラサポ」プロジェクト
をリニューアルしたい。
・ミラサポとは、助成⾦、補助⾦(合せて⽀援策)の情報提供サイト
https://www.mirasapo.jp/index.html
・⽬的や資本⾦、地域などから検索することができる
・主に中⼩企業、⼩規模事業者向け
・プロジェクトモチベーション
- 助成⾦、補助⾦の情報が必要な⼈に伝えられていないのではないか？
- ミラサポをもっと使ってもらえるようなものにしたい
- アジャイル開発で⾏きたい
2018年後半〜2019年3⽉

https://www.slideshare.net/
codeforjapan/ss-146226314
https://www.slideshare.net/
papanda/ss-145501029
詳しくはこちら

チームのフォーメーション
私
開発チーム
(プログラマー、デザイナー)
中企庁&経産省DXチーム
PO
(起案者)

現実のPOはそもそもソフトウェア開発⾃体が
ほぼ初めてということが少なくない
いきなり”PO”としての振る舞いを求めたところでどうにもならない。
それを⾝につける時間もプロジェクトには無い。

Photo credit: h.koppdelaney on Visual Hunt / CC BY-ND
プロダクトオーナー代⾏

PO代⾏
開発チーム
PO
(起案者)

開発チーム
PO
(起案者)
真っ当なプロダクトオーナー
PO代⾏

開発チーム
PO
(起案者)
PBLリファインメント中⼼(啓蒙)
PO代⾏

なぜ、プロダクトオーナーが
代⾏できるのか？

<Answer>
仮説検証を実施しているから
誰よりも想定ユーザーのことを理解している

選択の幅最⼤
（セットベース）
検証
計画
仮説⽴案
(モデル化)
検証
評価
価値探索
（正しいものを探す）
MVP特定
開発計画
(リリースプラ
ンニング)
スプリントプ
ランニング
スプリント
開発
スプリント
レビュー
スプリント
レトロスペクティ
ブ
MVP検証
アジャイル開発
（正しくつくる）
次の検証計画
(価値探索)へ
選択の振れ幅最⼩
（ポイントベース）
仮説検証型アジャイル開発
「価値探索」
この活動がなければ何をつくるべきかが関係者の勘と経験にしか依らない。
開発チームもプロダクトどうあるべきという基準が持てない。

GuildHub
https://lp.guildhub.jp/
https://www.amazon.co.jp/dp/4802511191/
仮説キャンバスをオンラインでつくる
仮説検証型アジャイル開発の
全容

プロダクトオーナー代⾏の遂⾏と責務
・そもそも、POも「正解」を持っているわけではない。
そもそもプロダクトづくりには仮説検証が必要。
・仮説検証を実施し、そこで得られた学びをチームで分かち合う。
当然、代⾏には仮説検証の練度が求められる。場数がモノを⾔う。
ドメイン知識の補完は、ドメインエキスパートに頼る。
(ただし、代⾏⾃⾝もドメインへの関⼼が無ければ成り⽴たない)
・実質的には「PO代⾏ ≒ PO」に他ならない。
代⾏には仮説検証の実施とともに、真正のPOを育成する仕事の
2つが同時に求められる。

PO代⾏観点でのコミュニケーションイメージ
PO
開発チーム
全員ステークホルダー
次期PO
PBLの詳細化と受け⼊れ
スプリントレビュー

…ということは
これからはPO代⾏という役割が
もっと増えていく？

Photo credit: afagen on Visualhunt.com / CC BY-NC-SA
"プロダクトオーナー”の⺠主化

向かうべきは「プロダクトオーナーの⺠主化」
・「PO代⾏」は経験・スキルを補完するための便宜的な役割。
“代⾏”が永続的に必要なのは解決⼿段が間違っている。
・仮説検証での学びからプロダクトの「基準」をつくり、チームに
宿すようにする。
基準はPOが唯⼀持っているものでも、PO代⾏が唯⼀持っている
ものでもない。チームで「プロダクトとしてどうあるべきなのか」
という基準を有し、チームの多様性でもって磨いていく。
そうして、価値発⾒の可能性を⾒出そう。
・チームが仮説検証できるようにリードする=「仮説検証リード」
実践や解釈には練度が求められる。仮説検証リードが補完する。

「役割による調整」から
「仮説検証による学びを
中⼼とした共創」へ

プロダクトオーナー2.0

More Related Content

What's hot

Similar to プロダクトオーナー2.0

More from toshihiro ichitani

プロダクトオーナー2.0