---
title: プロダクトオーナー2.0
tags: 
author: [市谷聡啓](https://www.docswell.com/user/papanda)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/8G7W9Q6Q72.jpg?width=480
description: デブサミサマー2019でお話した内容
published: July 02, 19
canonical: https://www.docswell.com/s/papanda/K27MGZ-20-153121944
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/8G7W9Q6Q72.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/W4JZ9WY3J3.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/KYE6KGDZEV.jpg)

Proﬁle
https://ichitani.com/


# Page. 4

![Page Image](https://bcdn.docswell.com/page/5GE5PV39E4.jpg)



# Page. 5

![Page Image](https://bcdn.docswell.com/page/V97263Z5JR.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/5DJY91R6EM.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/2V7NL2X1J8.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GYJ9418YE3.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/5GJ8Q48KED.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/MLJLX6RPJR.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/547ML5R2EW.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/ZP7RK3R5E9.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/NPJXL4RXJX.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/63JKLZR9ED.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/4LE33D89E5.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/V8ED4PM8JG.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/4V7PMNRW78.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/L2JV9KR9EQ.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/Z5EGZQM47L.jpg)

KASUMI
GASEKI


# Page. 20

![Page Image](https://bcdn.docswell.com/page/V4JQLKRREP.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/DK74DP8QJ1.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/PLJ1Z92L7G.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/8GJW9QRQJ2.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/W4EZ9WR3E3.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/KY76KGRZ7V.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/5G75PV8974.jpg)

チームのフォーメーション
PO代⾏
中企庁&amp;経産省DXチーム
PO
開発チーム
(起案者)
(プログラマー、デザイナー)
真っ当なプロダクトオーナー


# Page. 27

![Page Image](https://bcdn.docswell.com/page/V9J263K5ER.jpg)

チームのフォーメーション
PO代⾏
中企庁&amp;経産省DXチーム
PO
(起案者)
PBLリファインメント中⼼(啓蒙)
開発チーム
(プログラマー、デザイナー)


# Page. 28

![Page Image](https://bcdn.docswell.com/page/5DEY91N67M.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/2VJNL2V1E8.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/GYE9416Y73.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/5GE8Q4ZK7D.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/MLELX6DPER.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/54JML5P27W.jpg)

PO代⾏観点でのコミュニケーションイメージ
スプリントレビュー
PBLの詳細化と受け⼊れ
PO
中企庁&amp;経産省DXチーム
全員ステークホルダー
次期PO
開発チーム
(プログラマー、デザイナー)


# Page. 34

![Page Image](https://bcdn.docswell.com/page/ZPJRK31579.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/NPEXL4YXEX.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/63EKLZ397D.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/4L733DG975.jpg)

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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/V87D4P18EG.jpg)

ともにつくる。


