LeSS Study 読書会 第8章 プロダクトオーナー

https://less-study.doorkeeper.jp/events/124007

Transcript

1. LeSS Study 読書会 第8章 プロダクトオーナー 2021/07/30 発表：おりんぼう (@orinbou) https://less-study.doorkeeper.jp/
2. 2 目次と本日のテーマ １ LeSSでもっと多く ２ LeSS 第I部 LeSS の構造 ３ 導入 ４ 顧客価値による組織化 ５ マネジメント ６ スクラムマスター 第II部 LeSS のプロダクト ７ プロダクト（P143-156） ８ プロダクトオーナー（P157-181） ９ プロダクトバックログ １０ DONEの定義 第III部 LeSS スプリント １１ プロダクトバックログリファインメント １２ スプリントプランニング １３ 調整と統合 １４ レビューとレトロスペクティブ 第IV部 More or LeSS １５ 次は何をすべきか？ 大規模スクラム Large-Scale Scrum(LeSS)
3. 3 本編に入る、その前に LeSSは、1つのプロダクトを複数チームで協働するために考えられた スクラムです。 • LeSSはスクラム： Large-Scale Scrum(LeSS)は、新しいスクラムでも、スクラムの改良版でも ありません。ましてや、”おのおののチームがスクラムで、その上に別のレイ ヤーを載せたものでもありません”。LeSSはスクラムの原理・原則、目的、要 素、洗練された状態を大規模な状況にできるだけシンプルに適用したものです。 LeSSはスクラムは、その他の真にアジャイルなフレームワークと同様にインパ クトの強い「必要最低限の手法」のみを提供しています。 • なぜLeSS？ スクラム同様にLeSSも、様々な状況における学習の余地を残すため、意図的 に不完全なものになっています。（※中略）あまり定義されていないプロセス は、より多くの学習をもたらします。少し（LeSS）でもっと多く。
4. 4 本章でわかること • LeSS • プロダクトオーナーの役割と責任について • スケーリングする場合のプロダクトオーナーに関する原則 • LeSS Huge • 巨大なスケーリングの場合のプロダクトオーナーに関する原理・原 則 https://less.works/jp/less/framework/product-owner
5. “Personally I'm always ready to learn, although I do not always like being taught.” 個人的に私は常に学ぶ準備ができている。人に教わるのは好きではないのだが。 Winston Churchill （ウインストン・チャーチル） 1874 - 1965
6. 6 １チームスクラム（P157） プロダクトオーナーは1人で、顧客にとって素晴らしいプロダクトのビ ジョンに責任があって、その影響（ROIなど）を最適化します。プロダク トオーナーとして、あなたはプロダクトバックログを継続的に育て、学習 および変化に対する適応にもとづいてアイテムを追加、削除、再優先順位 付け（並べ替え）します。また、上位マネジメント、チーム、顧客に対し て、プロダクトバックログが見える状態にしておくことで、透明性を保ち ます。あなたはアイテムが明確になるように、チームや顧客と協働します。 新しいスプリントに提示するアイテムは、プロダクトオーナーが適応的に 決めますが、どのくらい選択するかはチームが決めます。そして、プロダ クトオーナーだけがチームに仕事を依頼することができます。スクラムマ スターは、プロダクトオーナーに役割と責任についてコーチします。 スクラムのスケーリングは、標準の1チームスクラムを理解することから始まります。 https://less.works/less/scrum/index
7. 7 8.1 LeSSのプロダクトオーナー（P157） • プロダクト全体思考： 大規模なプロダクト開発では、人々が自分の役割に没頭する場が簡単につくられてしまいます。1つのプロ ダクトバックログをもつ1人のプロダクトオーナーが、プロダクト全体思考を支えます。 • リーン思考：無理の回避 多くのチームに1人しかプロダクトオーナーがいない場合、どうにかやれる程度の仕事量を維持するには、 どうすればよいでしょうか？この章のガイドの多くは、要求や仕様の詳細確認作業の大部分をチームに委 譲したり、チームを顧客/ユーザーと直接結び付けたりするなど、この課題を扱うものです。 • 大規模スクラムはスクラム：システム思考 真のスクラムは、契約ゲームの終わりを暗に意味します。契約ゲームとは、固定スコープと固定期間の内 部「契約」を最初にビジネス側と開発側との間で合意し、契約を履行するためのプロジェクトを開発側が 実行するという従来型のモデルです。はっきりさせますが、スクラムは内部契約を履行するための効率的 なメカニズムではありません。スクラムは顧客との協調と適応へのパラダイムシフトです。すべてのスプ リントで出荷し、意思決定権限をもつビジネス側の人がプロダクトオーナーになります。従来の大規模開 発では、契約ゲームが組織設計に組み込まれており、内部契約に責任をもつプログラムマネジメントオ フィスや無数の関連する役職、方針、プロセスがあります。この環境にLeSSが導入されるとき、LeSSで 現在のモデルを置き換えるのではなく、現在のモデルにLeSSを適合させるという誤った見方をされること があります。そして結局、プロダクトオーナーの役割は、プログラムマネージャーやプロジェクトマネー ジャーが果たすと誤解されます。 • 少しでもっと多く LeSSでは、プロダクトオーナーの役割をたった1人で効果的にスケールすることが可能です。役割、役職、 そして複雑さはより少なくするべきです。 スケーリングする場合のプロダクトオーナーに関する原則
8. 8 LeSS ルール（P158） プロダクトオーナーが1人、プロダクトバックログが1つあり、出荷可 能なプロダクト全体を運用します。 プロダクトオーナーだけでプロダクトバックログリファインメントをす るべきではありません。複数チームが顧客やユーザー、ステークホルダー と直接コミュニケーションをとり、プロダクトオーナーをサポートします。 すべての優先順位付けはプロダクトオーナーに確認をとりますが、要求 や仕様の詳細確認は極力チーム間や顧客、ユーザーまたはステークホル ダーと直接行います。
9. 9 8.1.1 ガイド：誰がプロダクトオーナーになるべきか？（P158-161） • a. ステップ1：自分達の開発タイプを知る プロダクトオーナーを見つける場所は、 開発タイプによって違います。 ①プロダクト開発 外部の顧客または市場向けです。 ②内製（プロダクト）開発 社内の1つ以上のグループ向けです。 ③プロジェクト開発 通常は1つの外部顧客向けです。開発は、 ある種のプロジェクトとして組織され、 契約されます。 LeSSを導入するグループは、どこでプロダクトオーナーを見つけるべきでしょうか？ https://less.works/jp/less/framework/index
10. 10 8.1.1 ガイド：誰がプロダクトオーナーになるべきか？（P158-161） • b. ステップ2：プロダクトオーナーを探す ①プロダクト開発 プロダクトマネジメント部門がある場合は、 “プロダクトマネージャー”が良いでしょう。 その他の方法では“プロダクトの主導権を もつビジネス部門の人”が良いでしょう。 LeSSを導入するグループは、どこでプロダクトオーナーを見つけるべきでしょうか？ https://less.works/jp/less/framework/product-owner
11. 11 8.1.1 ガイド：誰がプロダクトオーナーになるべきか？（P158-161） • b. ステップ2：プロダクトオーナーを探す ②内製（プロダクト）開発 LeSSにおける良いプロダクトオーナーは (1)システムを利用するグループに所属し (2)システムがサポートする実業務に密に 関係し、深い経験を持ちます。 彼らは本当のユーザーに非常に近い存在です。 そして、彼らがプロダクトオーナーになった ときに重みがあり、独立した、プロダクトに 関しての意思決定の権限が必要になります。 LeSSを導入するグループは、どこでプロダクトオーナーを見つけるべきでしょうか？ https://less.works/jp/less/framework/product-owner
12. 12 8.1.1 ガイド：誰がプロダクトオーナーになるべきか？（P158-161） • b. ステップ2：プロダクトオーナーを探す ③（アウトソーシング）プロジェクト開発 大事なことは、プロダクトオーナーがシステム を利用するグループに所属しており、内製開発 と同様に実務に関わり、深い経験があって、 ユーザーに近いということです。 LeSSを導入するグループは、どこでプロダクトオーナーを見つけるべきでしょうか？ https://less.works/jp/less/framework/product-owner
13. 13 8.1.1 ガイド：誰がプロダクトオーナーになるべきか？（P158-161） • 内製開発とプロジェクトに共通すること システムが多部門で使用される場合です。 その場合、実務経験が豊富で主要なユー ザー部門に精通している志願者をプロダ クトオーナーとするのが良いでしょう。 • 最後にすべてのケースにおいて 優れたプロダクトオーナーは、プロダク トへの情熱、政治的精通、カリスマを持 っています。それなら心配ありません！ LeSSを導入するグループは、どこでプロダクトオーナーを見つけるべきでしょうか？ https://less.works/jp/less/framework/product-owner
14. 14 8.1.1 ガイド：誰がプロダクトオーナーになるべきか？（P158-161） • c. ステップ3：プロダクトオーナーに権限と責任を与える プロダクトオーナーは、仕事のスコープと期限の契約を果たす従来型の プロジェクトマネージャーやプログラムマネージャー、もしくは対象領域 の専門家に対する新しい名称ではありません。それどころか、プロダクト オーナーとしてあなたは、重大なビジネス上の意思決定、コンテンツの選 択と変更、リリース日、優先順位、ビジョンなどについて、独立した権限 をもちます。もちろん、ステークホルダーと協力しますが、本当のプロダ クトオーナーには最終的な意思決定の権限があります。 LeSSを導入するグループは、どこでプロダクトオーナーを見つけるべきでしょうか？
15. 15 8.1.1 ガイド：誰がプロダクトオーナーになるべきか？（P158-161） • d. 複数拠点のヒント：チームより顧客に近づく 世界規模の大衆市場向けの場合はさておき、プロダクトオーナーがチー ムよりも顧客やユーザーに物理的に近いことは重要です。プロダクトオー ナーとして、顧客よりもチームとの同一ロケーションを優先しないでくだ さい。チームの内側に集中してしまい、顧客やユーザーへの観点を失うこ とになるでしょう。 遠隔チームとは複数拠点ミーティング（スプリントプランニング1,2,.） が行われることになるでしょう。素晴らしいビデオコラボレーションツー ルを使えば、このような会議は比較的、効果的にできます。私たちはそう いうものを何度も見てきました。 LeSSを導入するグループは、どこでプロダクトオーナーを見つけるべきでしょうか？
16. 16 8.1.2 ガイド：一時的な仮のプロダクトオーナーと早めに、または適当に始める（P161-162） • 遅い変化： ビジネス側の人間は忙しく、プロダクトオーナーとしてどのように行動す ればよいのか分からないので、候補者をみつけて準備するのには時間がか かります。 • 混乱した開始： 序盤（最初または2回目）のスプリントを開始すると、様々なことが怒り 得ます。最良の場合は、初心者のビジネス側のプロダクトオーナーが我慢 します。しかし、最悪の場合は「LeSSはすべてを悪化させるし、何もで きあがらない初期段階で、なぜ私が関わらなければいけないのかわからな い」と結論づけてしまう。 「まず、素晴らしいビジネス側のプロダクトオーナーを見つけてから導入を始めよう」の潜在的な問題
17. 17 8.1.2 ガイド：一時的な仮のプロダクトオーナーと早めに、または適当に始める（P161-162） この状況での選択肢の1つは、一時的な仮のプロダクトオーナーと一緒に LeSSの導入を早く始めることです。一時的な仮のプロダクトオーナーは、 起きていることを理解し、プロダクトオーナー役を務めることができます が、ビジネス側の人ではありませんし、専門的なビジネス知識はなく、 ROIの責任もありません。主な障害が解消されるまで、何回かスプリント を終え、（ここからが重要！）このグループがスプリントごとに、本当に 「完了」した出荷可能なインクリメント（または近いもの）を出荷できる ようにすることです。なぜ、これが重要なのでしょうか？開発者がビジネ スグループに出向いて、本当のプロダクトオーナーの参加を要請するとき に、明確なビジネス上の利益をもたらす、引き付けられる新しい可能性を 示すことができるのは魅力的な話です！ 一時的なプロダクトオーナーは正式ではないことを、皆が理解している ことは非常に重要です。そして、できるだけ早く交代させましょう。文字 通り仮のプロダクトオーナーという名前を使うとよいです。 「まず、素晴らしいビジネス側のプロダクトオーナーを見つけてから導入を始めよう」の潜在的な問題
18. 18 8.1.3 ガイド：ユーザ/顧客は誰？（P162-163） • 顧客： 商品を購入、取得、選択したり、商取引に関する意思決定に深く関 わっている人のことをいいます。 • ユーザー： 特に組織のサイロがある大規模開発では、開発者は誰がユーザーなのかを知ることが困 難です。ユーザーとは、（いつもそうではありませんが）通常はプロダクトを実際に 使っている人を指します。この人達は、支払いをする顧客または上位の決裁者といつも おなじとは限りません。（※中略） 要求を明確にするため、開発者と真の要求元の直接の協働を劇的に増やすことがLeSS の目標です。しかし、それは現状の役職やプロセスを変えようとする、マインドセット とふるまいの大転換です。よって、プロダクトオーナーは、積極的に古い構造を置き換 え、開発者とユーザーのコネクターとしてふるまう必要があります。
19. 19 8.1.4 ガイド：明確化より優先順位付け？（P163-164） (1)プロダクトを進化させる方向を適応的に決定し、その決定をプロダクトバッ クログの優先順位付けに反映させること 利益の源泉、戦略的顧客、ビジネスリスクなどに関する情報が求められ、分 析される。 (2)ユーザーのニーズやアイテムの詳細を発見して明確にすること 詳細なふるまいとアイテム、ユーザーエクスペリエンスなどを明確にするこ とが目的 プロダクトオーナーとして、あなたは方向性や優先順位付けを考慮することに 重きを置き、可能な限り詳細の発見をチームに任せます。あなたはチームと ユーザーの間に立つ役割ではなく、チームとユーザーを繋げる役割となり、 チームがユーザーと直接対話することを奨励し、助けます。要するに、あなた はチームに委任された詳細な明確化よりも、主に優先順位付けに注力します。 スクラムにおいて、プロダクトオーナーに関する、2つの重要な情報フローがあります。
20. 20 8.1.5 ガイド：やってはいけないこと（P164-165） LeSSのプロダクトオーナーは、ビジョン達成のために開発を1人で舵取りし、多くのことに関わるため簡単に過負荷になってしまいます。 ＜重視すべきこと＞ • 方向性と優先順位付け：次に進化する場所の決定 • ビジョン、進化、テクノロジーの導入：長期的視点をもつ • 関係と政治：誰もが（十分に）幸せになる • 判断と予測：市場と競合他社の評価 ＜時間吸血鬼＞ • 明確化：アイテムが意味する詳細の把握 • 管理作業：報告とメトリクスの追跡 • 部門間調整：製造、販売などの部門間の関係 • 市場、技術、行号についての学習 ＜やるべきでないこと＞ • 依存関係の調整またはチーム間の調整 • チームの仕事の予測と計画 • 見積もり • 一般的にいってしまえば、人々の間の情報の運搬
21. 21 8.1.6 ガイド：プロダクトオーナーのヘルパー（P165-166） • チーム： まず最初に、チームを利用します。開発とプロダクトマネジメント作業の間の壁を壊し、チームをビジネ スに徐々に引き込みます。仕事の共有だけでなく関与を深めて全体を見ることができるようにします。市 場調査を委ねたければ、プロダクトバックログにアイテム「市場調査」を単純に追加してください。また、 アイテムの明確化やユーザーとの会議はチームに委任します。 • プロダクトマネージャー： プロダクトオーナーがプロダクトマネジメントグループのメンバーである場合、他のプロダクトマネー ジャーに助けを求めることができます。 • リリースマネージャー/コーディネーター： 従来の大きなグループでは、リリースマネージャーと呼ばれる人が調整を担当します。リリースマネー ジャーは、プロダクトオーナーとチームを支援する側でその逆ではありません。 注意！「プロダクトオーナーチーム」には、アナリスト、仕様書作成者、UI/UXデザイナー、アーキテク トはいません。彼らがいると現状の問題と組織構造が、新しいラベルを付けて維持されてしまいます。ス ペシャリストは通常のフィーチャーチームに参加します。 プロダクトオーナーの仕事を共有しましょう。でも誰と？？？
22. 22 チームはプロダクトオーナーが顧客に向けて実現可能な最高のプロ ダクトを作れるよう支援します。チームは次に何を作るのかと既に 作ったものが成功したかどうかを知る必要があります。プロダクト オーナーはチームを支援するために、彼らに必要なモノが何かを知 る必要があります。 8.1.7 ガイド：5つの関係（P166-173） • a. プロダクトオーナーとチーム ヒント ①ともに当事者になる ②対等の関係 ③チームに助けを求める ④信頼を構築する ⑤助けましょう、次の場合を除いて チームの責任である調整作業はやらない スクラムマスターの助けを借り、理由を 説明して断らなくてはならない ⑥マイクロマネジメントはしない ⑦ふりかえる ⑧チームの拠点を訪ねる プロダクトオーナーは5つの主要な関係を理解する必要があります。 https://less.works/jp/less/framework/product-owner
23. 23 8.1.7 ガイド：5つの関係（P166-173） ※このセクション長い！！！！ • b. プロダクトオーナーと顧客/ユーザー ヒント ①教育する ②ユーザーと一緒に参加する ③少なくともスプリント単位で出荷する ④透明性を高める プロダクトオーナーは5つの主要な関係を理解する必要があります。 https://less.works/jp/less/framework/product-owner プロダクトオーナーとチームは顧客のために、実 現可能な限り最高のプロダクトを作れるよう努め ます。顧客は、自分たちが気にしている機能がい つ手に入るのか、そしてその背景（優先順位づけ の理由）を知る必要があります。透明性を確保す ることで、顧客を最大限巻き込むことができます。 プロダクトオーナーは顧客の真のゴールや問題を 学び、（あるいは彼らのビジョンのさらに向こう にあるものを想像し）優先順位付けに必要な情報 を集める必要があります。
24. 24 8.1.7 ガイド：5つの関係（P166-173） ※このセクション長い！！！！ • c. チームと顧客/ユーザー ヒント ①コネクターになる ②ビジネス活動を共有する ③顧客と話す方法を教える ④顧客関係管理グループと組む ⑤中間の人たちを統合する プロダクトオーナーは5つの主要な関係を理解する必要があります。 https://less.works/jp/less/framework/product-owner チームは顧客に向けて実現可能な最高のプロダ クトを作れるよう努力しています。彼らは機能 の背景や、その分野の詳細な知識を知る必要が あります。理想的には、チームは顧客の本質的 な（表面的でない）ゴールと問題を把握し、顧 客と一緒にソリューションを作り上げるべきで す。チームは、自分たちが顧客と共に明らかに した要望を完全に理解しているか、顧客に確認 する必要があります。
25. 25 8.1.7 ガイド：5つの関係（P166-173） ※このセクション長い！！！！ • d. プロダクトオーナーと上級マネジメント ヒント ①自己評価する ②まわりを教育し、役割を売り込む ③「プロダクトオーナーに」を伝える プロダクトオーナーは5つの主要な関係を理解する必要があります。 https://less.works/jp/less/framework/product-owner プロダクトグループの上にいる上級管理職 （ポートフォリオマネージャ、経営幹部など） はプロダクトオーナーをプロダクトの成功に関 する決定権と説明責任を持つ存在と見なすべき です。プロダクトオーナーは、プロダクトが与 える影響（例えばROIやマーケットシェア）を 最適化するため、開発状況の可視化と、より経 営レベルの(大抵暗黙な)任務を遂行させる必要 があります。プロダクトオーナーはスクラムマ スターのサポートを受けながら、組織構造を改 善するために、上級管理職の支援を求めます。
26. 26 8.1.7 ガイド：5つの関係（P166-173） ※このセクション長い！！！！ • e. プロダクトオーナーとスクラムマスター ヒント ①少しだけ ②生徒になる ③じっくり考える プロダクトオーナーは5つの主要な関係を理解する必要があります。 https://less.works/jp/less/framework/product-owner スクラムマスターとの関係性は、プロダクト オーナーの知識と振る舞いに関連します。スク ラムマスターはプロダクトオーナーを支援する ために、プロダクトオーナーの悩み、疑問、障 害を知る必要があります。良いスクラムマス ターは、親身にプロダクトオーナーの話を聞き、 プロダクトオーナーが辛いときには肩を貸しま す。スクラムマスターはプロダクトオーナーが 適応できるよう、教育し、フィードバックを与 えます。
27. 27 8.1.8 ガイド：何よりも顧客との協調を（P173-174） 継続的に優先順位付けするということは、学習の影響を最適化するため に、プロダクトバックログの既存および新規アイテムの優先順位を「常 に」更新するということです。理想的には、初期の価値を提供し、透明性 を高め、フィードバックを得るために少なくともスプリントごとに出荷し てください。フィードバックは新しい優先順位に影響を与えます。 大規模で従来型のグループからLeSSに移行する人々にとって、以前は 契約ゲームで開発を進めていたため、継続的な優先順位付けはマインド セットやふるまいの劇的な変化となることが多いです。そして、ときどき、 まだ契約ゲームを行っています。
28. 28 8.1.8 ガイド：何よりも顧客との協調を（P173-174） 従来型の（特に大きな）開発グループでは、ビジネス部門やプロダクトマネジメントグループ と開発グループで特定の日付とスコープ（時にはコストも）で内部的な「契約」をします。契 約は開発グループに引き渡され、「契約をコミットする」ことを命じられ、約束通りに行う責 任を負うことになります。 プロダクト開発の複雑さと変化しやすさが、スコープ、詳細、または確実な見積もりを幻想 にします。したがって、強制されたコミットメントに対応すると、ビジネスやプロダクトマネ ジメントグループと開発グループ間で責任のなすり付け合いをするようになります。このゲー ムは、ゆっくりとですが、避けがたいプロダクトの品質低下と組織の能力低下を起こします。 それは、どうやって引き起こされるのでしょうか？ 要約すると、内部契約であるコミットメントに対応するために、ゲームは一見、短期的な成 功のために行われます。そのため、その場しのぎの対応や手っ取り早い手法で行われ、長期的 な遅れや間接的な影響、そして負債が発生します。コミットメントを強制する人たちは、めっ たに2ゲーム目まで残らないため、これらの負債による遠い将来の結果を経験することは決して ありません。その結果、契約ゲームが行われると、物事はさらに悪化し、負のスパイラルが始 まります。最終的に、このプロダクトは最下位リーグに加わり「イエメンのレガシー開発」入 りさせられます。 LeSSを導入することは、固定スコープの錯覚および契約ゲームを放棄し、スプリントで得た 情報を使って、最大の価値を提供するようにプロダクト開発を指揮することを意味します。そ れは、長期計画を意味せず、計画を現実と混同しないことを意味します。これは、計画に従う だけでなく、学び、変化に対応することを意味します。 契約ゲーム
29. 29 8.1.9 ガイド：少なくともスプリントごとに出荷する（P174-175） スプリントごとに市場（または社内ユーザー）へ正確に出荷することは、大規 模なグループにとって、マインドセットとふるまいの大きな変化です。できる 限り、プロダクトオーナーとして、スプリントごとに出荷するか、もっと頻繁 に出荷するかを決定する必要があります。その理由は、 (1)価値を早期に提供する (2)新しい機能の有効性についてフィードバックをもらい、将来のスプリントで より良く適応する (3)変化するビジネスニーズへの対応力の強化 (4)頻繁な出荷を妨げる摩擦が痛いほど明らかになり修正しなくなることによる 開発グループの濃く深い改善 (5)達成感や進捗している感覚によるチーム間の内部モチベーションの改善 (6)具体的な結果によるステークホルダー菅野信頼性の向上 出荷は、言葉よりも声が大きい。
30. 30 8.1.10 ガイド：良い人になるな（P175-176） プロダクトオーナーとして、あなたはチームへの期待設定に置いて重要な役割 を果たします。チームがあなたのところに来て、”一連のアイテムが半分しかで きなかった”ことを伝えることがあったとします。熟練のプロダクトオーナーは 共感するかもしれませんが、それを「受け入れる」ことはありません。良い人 になってはいけません。かわりに、アイテムが完成していないことをはっきり させ、チームに作業の仕方を改善して、完成したアイテムを届けることを期待 します。 これは、各スプリントで最初に計画したすべてのアイテムの完成を要求する ことを意味するのではありません。その要求は契約ゲームの機能障害（透明性 の低下、処罰を避けるためのバッファの増加、品質と学習の低下）への回帰を 引き起こします。 あまり良くないプラクティスやサイロ型のマインドセットが原因で完成して いないアイテムを受け入れる「良い人」なプロダクトオーナーをよく見ていま す。黙認は、永遠に働きの悪いチームを作ります。Doneの定義を弱めることな く拡張していく必要があることを理解すべきです。 迅速かつ効果的に改善のための具体的な支援を提供することが組織にとって重要です。
31. 31 8.1.11 ガイド：放棄しよう（P176-177） LeSSを効果的に導入できているときには、すべての作業を行い、他のチームと調整を し、自己管理型で同一ロケーションにいるフィーチャーチームがいます。そして、短い サイクルで完全なプロダクトを出荷する（もしくは出荷できない）ことがもたらす高い 透明性があります。だから「マイクロマネジメント」を含むスプリント中に開発をコン トロールしようとする習慣を放棄することができます。 多くのチームは自己管理に長けていませんが、その弱点は何をすべきかを伝えても解 決はしません！チームには場所と時間、そして成長を助ける熟練のスクラムマスターが 必要です。 ＜例＞ (1)スプリント中にチームを点検したり、状況報告を要求したりはしません。チームに させてください。顧客に集中し、将来のスプリントの準備をします。もちろん、チーム が助けを求めているなら、助けます。 (2)スプリントレビューで、プロダクトを使い、起きたことから学びます。次のスプリ ントの目標を適応的に決定してください。 (3)オーバーオールレトロスペクティブでは、プロセスや環境、妨げになる、もしくは 役に立ったふるまいについて調査し学びます。あなたのグループと、改善のための実験 を適応的に決定します。
32. 32 8.1.12 ガイド：やっていないことをUndoneワークにするな（P177） 簡単にいうと、Doneの定義と出荷可能の違いは、Undoneワークです。大きく 古い習慣をもつグループにに最初にLeSSが導入されたときは良く見られます。 出荷可能 = Doneの定義 + Undoneワーク Undoneワーク： Doneの定義と出荷可能との差分です。Doneの定義が完璧であればUndoneワー クは存在しません。 ＜Undoneワークの例＞ 「テストは後でかこう」「セキュリティ試験は全機能が完成してから実施」etc. https://less.works/jp/less/framework/definition-of-done https://www.slideshare.net/MinoruYokomichi/ss-46849331/78
33. 33 8.1.13 ガイド：LeSSのミーティング（P177-178） LeSSに対する良くある質問として「どうやって1人のプロダクトオーナーが、すべての チームのすべてのミーティングに参加するの？」というものがありますが、この質問は 誤解に基づくものです。1人のプロダクトオーナーは、各チームごとのミーティング （スプリントプランニング2、デイリースクラム、チームバックログリファインメント、 チーム・レトロスペクティブ）には参加しません。 2週間スプリントを例とした場合、プロダクトオーナーが出席するミーティングと、そ れに費やす平均的な時間はおよそ5.5～8.5時間くらいです。 • スプリントプランニング1：1時間 • オーバーオール・プロダクトバックログリファインメント (PBR)：1～4時間（？） • スプリントレビュー：2時間 • オーバーオール・レトロスペクティブ：1.5時間 もちろん、プロダクトオーナーがチームと話しをする必要がある場合は、ミーティング を持つ必要はありません。歩いて行って、”ただ話す”だけです。
34. 34 8.1.13 ガイド：LeSSのミーティング（P177-178） （補足）1人のプロダクトオーナーが出席するミーティングをフレームワーク図からも読み解く https://less.works/jp/less/framework/index
35. 35 8.2 LeSS Huge（P178～ P181） Sorry! 204 No Content Maybe coming someday…
36. 36 本章のまとめ LeSSのプロダクトオーナーは基本的に1チームのスクラムと同じだが、規模拡大により視点が少し変わり、 常に全体像を 意識しながら投資対効果(ROI)を最大化することが求められます。 • LeSSのプロダクトオーナー 1人のプロダクトオーナーが1つのプロダクトバックログをメンテナンスすることで、プロダクト全体思考を支える。 • 明確化より優先順位づけ 優先順位付けには注力しますが、明確化はチームの力を借りて協力（◦：繋ぎ役、×：仲介者）しながら行います。 (1) プロダクトバックログにおけるアイテムの優先度（順序） (2) プロダクトバックログにおけるアイテム内容の明確化 • 開発タイプに応じたプロダクトオーナー プロダクトオーナーのあるべき像は開発のタイプ（①プロダクト開発、②内製開発、③プロジェクト開発）に依存して変わります。 Step 1: 開発タイプを把握する Step 2: 適切なプロダクトオーナーを見つける Step 3: 真のプロダクトオーナーに権利と責任を与える • 5つの関係 以下５つの関係性を理解して関係改善に向けて働く必要がある。 a. プロダクトオーナーとチーム b. プロダクトオーナーと顧客/ユーザー c. チームと顧客/ユーザー d. プロダクトオーナーと上級マネジメント e. プロダクトオーナーとスクラムマスター • LeSS ミーティング プロダクトオーナーは各チームの種々のミーティングには参加しない https://less.works/jp/less/framework/product-owner