1. プロダクトオーナーアンチパターン 2023/6/20 株式会社アトラクタ 吉羽 龍太郎 (@ryuzee)
2. 自己紹介 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
3. プロダクトオーナーアンチパターン 3 プロダクトオーナーの仕事（スクラムガイド2020より） ▸ プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に 責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである ▸ プロダクトオーナーは1人の人間であり、委員会ではない ▸ プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければ ならない ▸ プロダクトオーナーだけがスプリントを中止する権限を持つ
4. プロダクトオーナーアンチパターン 4 プロダクトオーナーの仕事（スクラムガイド2020より） ▸ プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ ▸ プロダクトゴールを策定し、明示的に伝える ▸ プロダクトバックログアイテムを作成し、明確に伝える ▸ プロダクトバックログアイテムを並び替える ▸ プロダクトバックログに透明性があり、見える化され、理解されるようにする ▸ 上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる。 いずれの場合も、 最終的な責任はプロダクトオーナーが持つ ▸ プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある ▸ ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する
5. プロダクトオーナーアンチパターン それではアンチパターンを紹介・解説していきましょう アンチパターンを網羅することは不可能なので、今日は典型的ないくつかのものを紹介します ▸ 1. 顧客やユーザーの軽視 ▸ 2. 不十分なステークホルダーマネジメント ▸ 3. 不在がちなプロダクトオーナー ▸ 4. プロダクトバックログのリファイン不足 ▸ 5. プロダクトオーナーが開発者に発注する ▸ 6. プロダクトよりプロジェクト 5
6. プロダクトオーナーアンチパターン アンチパターン1: 顧客やユーザーの軽視 ▸ 兆候 ▸ 社内のミーティングでスケジュールが埋まっている ▸ 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいてい るものが多い ▸ ユーザーがプロダクトを触っているところを見たことがほとんどない 6
7. プロダクトオーナーアンチパターン 7 価値交換システム $$$ ▸ 顧客やユーザーにとっての価値は、問題を解決したり要望やニーズを叶えること（アウトカム） ▸ 本質的に、プロダクトやサービスそのものに価値があるわけではない ▸ ビジネスにとっての価値は、お金、データを始めとしたビジネスを活性化するもの ▸ この価値交換を継続しなければいけない
8. プロダクトオーナーアンチパターン 8 “ 建物の外に出よ スティーブ・ブランク（シリコンバレーの有名起業家） fl Source: https://www. ickr.com/photos/jdlasica/11320863595/ ”
9. プロダクトオーナーアンチパターン 9 プロダクト開発の流れに顧客やユーザーの評価を組み込む 問題を設定しなおす ① 解決したい問題を 見つける 繰り返す ② 問題とソリューション の仮説を評価する ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数/安価 大人数/高価
10. プロダクトオーナーアンチパターン アンチパターン2: 不十分なステークホルダーマネジメント ▸ 兆候 ▸ ステークホルダーをスプリントレビューに招待していない ▸ ステークホルダーと個別にコミュニケーションしていない ▸ ステークホルダーに何か言われるとすぐに対応している ▸ 「◯◯さんの指示なのでやらないといけない」のような口癖 10
11. プロダクトオーナーアンチパターン ステークホルダーとは？ ▸ プロダクトに対して利害関係を持つ人 ▸ ビジネスステークホルダー: プロダクトを作る上で直接的な関与が必要な人たち ▸ スポンサー： プロダクトを作るための資金やアセットを提供する人たち ▸ 顧客： プロダクトを購入する人たち ▸ エンドユーザー： 実際にプロダクトを使う人たち ▸ …… ▸ スクラムチーム自身もステークホルダー 11
12. プロダクトオーナーアンチパターン 12 ステークホルダーの分類 ▸ ひとくちにステークホルダーと言っても、影響度やコミュニケーション方法は大きく異なる ▸ 関与の度合い、スプリントレビューに呼ぶ頻度や時期など、扱い方はさまざま（全員同じではない） 影響力 大 Market 常に満足させておく必要のあるス テークホルダー（関連する情報だけ を伝達する） 満足させ続ける 緊密にやりとりする Write your 関 心 度 低 常に見ておく必要がほとんどないス テークホルダー（情報共有の間隔を 長くして、最小限の労力で距離を保 つ） 関 心 度 高 定期的に 情報提供する ニーズを予測する 影響力 小 『スクラム実践者が知るべき97のこと』（オライリージャパン）、p.40をもとに作成 緊密に管理する必要のあるステーク ホルダー。グループが大きくなるほ ど、やることも多くなるのは言うまで もないので、人数は最小限にしてお きたい 常に報告する必要のあるステークホ ルダー（前もって計画したり情報を伝 達したりすることで距離を保つ）
13. プロダクトオーナーアンチパターン 例: スプリントレビューにステークホルダーを招待する 参加者 スクラムチーム プロダクトマネージャー CEO、VPoP セールス・マーケティング 運用・サポート セキュリティ ユーザー 参加したい人すべて（公開実施） #1 #2 #3 #4 #5 #6 #7 スプリントレビューに来ら 13 れないが超重要なステークホル ダーがいるなら、出張レビューが必 要になることもある #8 #9 #10 #11 …
14. プロダクトオーナーアンチパターン 14 “ 何をしないかを決めることは、何をするのか を決めるのと同じくらい大事なことだ スティーブ・ジョブズ Source: https://en.wikipedia.org/wiki/Steve_Jobs ”
15. プロダクトオーナーアンチパターン アンチパターン3: 不在がちなプロダクトオーナー ▸ 兆候 ▸ イベントの時間帯が頻繁に変更される ▸ イベントの欠席が多い ▸ メールやチャットへの返信が遅い 15
16. プロダクトオーナーアンチパターン 16 スクラムイベントの時間の目安: プロダクトオーナーなら1週間あたり8時間 ロール スプリント プランニング デイリースクラム スプリント レビュー スプリント レトロスペクティブ (リファインメント) 時間の目安 (1週間スプリント) 2時間 1.25時間 1時間 1時間 4時間 プロダクトオーナー ◎ △ ◎ ◎ ◎ 開発者 ◎ ◎ ◎ ◎ ◎ スクラムマスター ◎ ◯ ◎ ◎ ◯ ステークホルダー △ △ ◯ △ △ ◎絶対に参加 / ◯参加しなくて良いこともある / △チームの求めに応じて参加 / ✕参加できない
17. プロダクトオーナーアンチパターン 17 スクラムイベントやリファインメント以外に必要な時間 ▸ ステークホルダーマネジメント ▸ ユーザーと会う ▸ 開発者からの質問に答える ▸ 開発者が開発したインクリメントが開発しているかどうか確認する ▸ スプリントレビューなどのイベントの準備をする ▸ プロダクトのメトリクスを確認する ▸ プロダクトの現状や将来について検討する ▸ …… つまり、プロダクトオーナーはか なりの時間が必要な仕事。片手間で はできない
18. プロダクトオーナーアンチパターン 18 “ プロダクトオーナーは、半分の時間を顧客や ステークホルダーと一緒に過ごし、残りの半分 はチームと一緒に過ごす ジェフ・サザーランド ff Source: https://en.wikipedia.org/wiki/Je _Sutherland ”
19. プロダクトオーナーアンチパターン アンチパターン4: プロダクトバックログのリファイン不足 ▸ 兆候 ▸ スプリントプランニングでスプリントゴールのアイデアが曖昧 ▸ スプリントプランニングに時間がかかる ▸ スプリント中に開発者からプロダクトオーナーに多数の質問が出る ▸ 完成を確認したときに認識の相違がよくある 19
20. プロダクトオーナーアンチパターン 20 プロダクトオーナーはプロダクトバックログの適切な管理の最終責任を持つ プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。 （中略） 上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任するこ ともできる。 いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 -- スクラムガイド2020
21. プロダクトオーナーアンチパターン 21 プロダクトバックログアイテムを常に洗練された状態に保つ ✕ ✕ 全 部 全 部 が 粗 い が 細 か い 〜 ◯ 〜 上 は 細 か く 下 は 粗 い
22. プロダクトオーナーアンチパターン 大原則: 準備ができているプロダクトバックログアイテムだけを投入する ▸ 準備ができていないプロダクトバックログアイテムをスプリントに入れてしまうと何が起きる？ ▸ スプリント中に何度もプロダクトオーナーと仕様を確認することになる ▸ 着手したあとに、想像以上に規模が大きいことが分かる ▸ プロダクトオーナーに完成確認をしたときに、認識の相違が見つかる ▸ これらの結果として、選択したプロダクトバックログアイテムが完成しない確率が高まる ▸ スプリントごとの成果の量が不安定になり、予測精度が下がる ▸ つまり「生煮えプロダクトバックログアイテムを食べると腹を壊す」 ▸ これを防ぐために、準備ができているプロダクトバックログアイテムだけを投入する ▸ スクラムチームごとに、どこまで準備をすれば適切なのかは違う 22
23. プロダクトオーナーアンチパターン アンチパターン5: プロダクトオーナーが開発者に発注する ▸ 兆候 ▸ プロダクトオーナーが多くのプロダクトバックログアイテムの詳細を用意している ▸ 実現したい価値よりも、機能の詳細や仕様の議論に時間を割いている ▸ スプリントプランニングやスプリントレビューがプロダクトオーナーの発言ばかり 23
24. プロダクトオーナーアンチパターン 24 スクラムはチームによる取り組み ▸ 「（スクラムチームは）一度にひとつの目的（プロダクトゴール）に集中している専門家が集まった単位 である」（スクラムガイド2020） ▸ 「スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プ ロダクトに関して必要となり得るすべての活動に責任を持つ」（同） ▸ 全員がプロダクトゴールの達成の責任の一端を担う ▸ 「スクラムがもたらす最終的な結果、いわば設計目標は、飛躍的に生産性を上げるチームの実現にあ る」（『スクラム 仕事が4倍速くなる”世界標準のチーム戦術”』 p.22） ▸ プロダクトオーナーがすべてを決めるなら、それはウォーターフォールと変わらない ▸ 逆に、プロダクトオーナーが決めず、合議で決めようとするのもうまくいかない
25. プロダクトオーナーアンチパターン アンチパターン6: プロダクトよりプロジェクト ▸ 兆候 ▸ 「このままだと間に合わない」といった言葉がよく登場する ▸ 当初のスコープや機能の必達を目指している ▸ スクラムチームの学習や技術的負債への対応時間を取らない ▸ ゴールや価値に関する会話が少ない ▸ ベロシティの目標を設定している 25
26. プロダクトオーナーアンチパターン プロジェクトにおける鉄の三角形 ▸ プロジェクトでは3点を同時に固定することはできない ▸ 費用・納期固定 => スコープ可変 ▸ 費用・スコープ固定 => 納期可変 ▸ 納期・スコープ固定 => 費用可変 ▸ プロダクト開発でも同じ 26
27. プロダクトオーナーアンチパターン 27 機能が多くても使われない。使われなければ価値はない ▸ 2019年Pendoの調査 12% 8% まったく使わない 24% ▸ Pendoはプロダクトマネジメント関連のSaaS企業 ▸ 24%の機能はまったく使われない ▸ 80%の機能はほとんど/まったく使われない ▸ 昔と状況は変わっていない ほとんど使わない 56% まったく使わない ほとんど使わない よく使う いつも使う 出典 https://www.pendo.io/resources/the-2019-feature-adoption-report/
28. プロダクトオーナーアンチパターン うまくたくさん作ることが最重要なわけではない ▸ Outcome (成果)の方が重要 ▸ 成果と生産性を比べてみると (生産性 = 生産量 / 投下時間 つまりベロシティ) ▸ 成果はでないが生産性は高い = ゴミの高速生産 ▸ 成果はでてるが生産性は低い = なにか問題でも？ ▸ 成果はでてないし生産性も低い = つらい人生… ▸ もっと全員が成果にフォーカスする必要性 ▸ そのためにはフィードバックが何よりも重要 28
29. プロダクトオーナーアンチパターン ベロシティはスクラムチーム自身が予測や計画づくりに使う ▸ ベロシティは昨日の天気 ▸ 直近数スプリントの実績をもとにして、今後の見通しをたてるために使う ▸ チームごとに基準が違うので、チーム間の比較はできない ▸ スクラムチームの能力は急には上がらない ▸ 目標ベロシティを設定すると、過大見積りをしたり、品質を下げたりするだけ ▸ 誤ったメトリクスを組織が気にすると、悪影響を及ぼす ▸ グッド・ハートの法則 「管理のために用いられる測定はすべて、信頼できない」 ▸ = 測定され、報酬が与えられるものはすべて改ざんされる 29
