プロダクトオーナー2.0
4.3K Views
July 02, 19
スライド概要
デブサミサマー2019でお話した内容
関連スライド
各ページのテキスト
プロダクトオーナー2.0 開発チームとプロダクトオーナーの間の境界線を 「プロダクトオーナーの⺠主化」によって解消する Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓
市⾕ 聡啓 Ichitani Toshihiro (My KeyWord) 越境 正しいものを正しくつくる 仮説検証型アジャイル開発
Profile https://ichitani.com/
6⽉14⽇発刊 https://www.amazon.co.jp/dp/4802511191/
「これまでの開発スタイル」から 「アジャイルな開発」に 向かうのを阻むものとは何か？
アジャイル開発は ２度失敗する
1 アジャイル開発の習慣を チームで⾝につけること 2 開発チームとプロダクトオーナー の間に⽣まれる境界線 Photo on VisualHunt
1 アジャイル開発の習慣を チームで⾝につけること 今⽇話すこと 2 開発チームとプロダクトオーナー の間に⽣まれる境界線 Photo on VisualHunt
プロダクトづくりの不吉なにおい ﹅ 開発チームはスクラムの振る舞いを ⾝につけられている。 開発チームとPOはPBLをはさんで コミュニケーションすることに最適化。 POが何をしていて、どうやってPBLを つくっているか開発チームが知らない。 「スプリントの空振り」が起きる。 PBL…プロダクトバックログ Toshihiro Ichitani All Rights Reserved.
プロダクトオーナーにかかる プレッシャーは重い Toshihiro Ichitani All Rights Reserved. Photo credit: Steven Penton on VisualHunt / CC BY
プロダクトオーナーに求められること プロダクトを形にするために必要な知識とスキル プロダクトがどうあるべきか の牽引のために チームとの協働のために 受け⼊れテストの実施と テスト結果の活⽤ ユーザーテストによる フィードバック取得と 継続的な計測 プロダクトバックログの 管理⽅法 コミュニケーション設計 プロジェクトを遂⾏するために プロジェクトマネジメント 開発メンバーとの意思疎通 のために ソフトウェア開発の 基本的な知識 Toshihiro Ichitani All Rights Reserved.
ご興味があればこちらもどうぞ https://www.slideshare.net/papanda/97-78212969 Toshihiro Ichitani All Rights Reserved.
"理想的なプロダクトオーナー" PBLを⽣み出すための仮説検証に ⻑けており⼗分な知識と経験がある しかも、プロダクトづくりの新しい 取り組みのタイミングで運良く 稼働が空いている！ “理想的なプロダクトオーナー” とは 都合の良い概念でしかない Toshihiro Ichitani All Rights Reserved.
間違ったものを 正しくつくる Do the Wrong things Right いくら型どおりに正しくつくっていても、 間違ったもの(⽬的に適さないもの)をつくっている限り ミッションは達成できない。 Photo credit: BeaLeiderman via VisualHunt.com / CC BY-NC-SA Toshihiro Ichitani All Rights Reserved.
開発チームからPO側への越境 Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC Toshihiro Ichitani All Rights Reserved.
POの役割をチームで補完する プロダクトデザイナー型PO中⼼のフォーメーション 要求の⾔語化、整理 プロダクト ユーザーインターフェース の⽅針を決める ビジネスモデルの 設計 マネージャーによる ビジネス推進型PO中⼼のフォーメーション 要求の⾔語化、整理 UIデザイナーに よる補完 ユーザーインターフェース の⽅針を決める ビジネスモデルの 設計 Toshihiro Ichitani All Rights Reserved. 補完
ケーススタディ 伝統的な組織ほどアジャイルへの移⾏は逆境 もっとも”伝統”のモメンタムが かかりやすい組織と⾔えば？
KASUMI GASEKI
2018年後半〜2019年3⽉ 経産省の「シン・ミラサポ」プロジェクト をリニューアルしたい。 ・ミラサポとは、助成⾦、補助⾦(合せて⽀援策)の情報提供サイト https://www.mirasapo.jp/index.html ・⽬的や資本⾦、地域などから検索することができる ・主に中⼩企業、⼩規模事業者向け ・プロジェクトモチベーション - 助成⾦、補助⾦の情報が必要な⼈に伝えられていないのではないか？ - ミラサポをもっと使ってもらえるようなものにしたい - アジャイル開発で⾏きたい
詳しくはこちら https://www.slideshare.net/ https://www.slideshare.net/ codeforjapan/ss-146226314 papanda/ss-145501029
チームのフォーメーション 私 中企庁&経産省DXチーム PO (起案者) 開発チーム (プログラマー、デザイナー)
現実のPOはそもそもソフトウェア開発⾃体が ほぼ初めてということが少なくない いきなり”PO”としての振る舞いを求めたところでどうにもならない。 それを⾝につける時間もプロジェクトには無い。
プロダクトオーナー代⾏ Photo credit: h.koppdelaney on Visual Hunt / CC BY-ND
チームのフォーメーション PO代⾏ 中企庁&経産省DXチーム PO (起案者) 開発チーム (プログラマー、デザイナー)
チームのフォーメーション PO代⾏ 中企庁&経産省DXチーム PO 開発チーム (起案者) (プログラマー、デザイナー) 真っ当なプロダクトオーナー
チームのフォーメーション PO代⾏ 中企庁&経産省DXチーム PO (起案者) PBLリファインメント中⼼(啓蒙) 開発チーム (プログラマー、デザイナー)
なぜ、プロダクトオーナーが 代⾏できるのか？
<Answer> 仮説検証を実施しているから 誰よりも想定ユーザーのことを理解している
仮説検証型アジャイル開発 選択の幅最⼤ 仮説⽴案 （セットベース） (モデル化) 検証 計画 価値探索 （正しいものを探す） 評価 スプリントプ ランニング 検証 開発計画 MVP特定 (リリースプラ ンニング) 選択の振れ幅最⼩ （ポイントベース） スプリント 開発 アジャイル開発 （正しくつくる） スプリント レトロスペクティ ブ MVP検証 スプリント レビュー 「価値探索」 この活動がなければ何をつくるべきかが関係者の勘と経験にしか依らない。 開発チームもプロダクトどうあるべきという基準が持てない。 次の検証計画 (価値探索)へ
仮説検証型アジャイル開発の 全容 https://www.amazon.co.jp/dp/4802511191/ 仮説キャンバスをオンラインでつくる GuildHub https://lp.guildhub.jp/
プロダクトオーナー代⾏の遂⾏と責務 ・そもそも、POも「正解」を持っているわけではない。 そもそもプロダクトづくりには仮説検証が必要。 ・仮説検証を実施し、そこで得られた学びをチームで分かち合う。 当然、代⾏には仮説検証の練度が求められる。場数がモノを⾔う。 ドメイン知識の補完は、ドメインエキスパートに頼る。 (ただし、代⾏⾃⾝もドメインへの関⼼が無ければ成り⽴たない) ・実質的には「PO代⾏ ≒ PO」に他ならない。 代⾏には仮説検証の実施とともに、真正のPOを育成する仕事の 2つが同時に求められる。
PO代⾏観点でのコミュニケーションイメージ スプリントレビュー PBLの詳細化と受け⼊れ PO 中企庁&経産省DXチーム 全員ステークホルダー 次期PO 開発チーム (プログラマー、デザイナー)
…ということは これからはPO代⾏という役割が もっと増えていく？
"プロダクトオーナー”の⺠主化 Photo credit: afagen on Visualhunt.com / CC BY-NC-SA
向かうべきは「プロダクトオーナーの⺠主化」 ・「PO代⾏」は経験・スキルを補完するための便宜的な役割。 “代⾏”が永続的に必要なのは解決⼿段が間違っている。 ・仮説検証での学びからプロダクトの「基準」をつくり、チームに 宿すようにする。 基準はPOが唯⼀持っているものでも、PO代⾏が唯⼀持っている ものでもない。チームで「プロダクトとしてどうあるべきなのか」 という基準を有し、チームの多様性でもって磨いていく。 そうして、価値発⾒の可能性を⾒出そう。 ・チームが仮説検証できるようにリードする=「仮説検証リード」 実践や解釈には練度が求められる。仮説検証リードが補完する。
「役割による調整」から 「仮説検証による学びを 中⼼とした共創」へ
ともにつくる。