Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

プロダクトオーナー2.0

4,535 views

Published on

デブサミサマー2019でお話した内容

Published in: Software
  • DOWNLOAD FULL MOVIE, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... ,DOWNLOAD FULL. MOVIE 4K,FHD,HD,480P here { https://tinyurl.com/yybdfxwh }
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

プロダクトオーナー2.0

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

×