LeSS' Morning #18
〜スクラムのプロダクトオーナーとLeSS のプロダクトオーナーの違いとは？〜

概要：https://techplay.jp/event/981240

運営の丸田です。

 6月27日に「スクラムのプロダクトオーナーとLeSS のプロダクトオーナーの違いとは?」と題したイベントを開催しました。

オンサイト会場は株式会社タイミー様にご提供いただきました。運営を代表して感謝申し上げます。

ワークショップの説明

今回の LeSSʼ Morning では、「スクラムのプロダクトオーナーとLeSS のプロダクトオーナーの違いとは?」をテーマに議論を深めました。

当日は、オーガナイザー江端からワークショップの説明がありました。

• プロダクトオーナー業務の可視化

• 単一チームと複数チームで変わりそうなこと・課題の特定

• 対策方法の検討

プロダクトオーナー業務の可視化

まず、プロダクトオーナーの業務内容について、共通認識を持つために可視化を行いました。
プロダクトゴールやPBIの作成、PBLの管理やステークホルダーとの調整などが挙げられました。

単一チームと複数チームで変わりそうなこと・課題の特定

このステップでは、チームが単一から複数に拡大した場合に生じる変化と、それによって顕在化する課題について、活発な意見交換が行われました。

主に以下のような変化や課題が議論されました。

スケーリングによる変化、複数チーム特有の困難になる行動

• 利害関係者の増加とコミュニケーションパスの増加: チームが増えることは、直接的・間接的に関わる利害関係者の増加を意味します。結果として、コミュニケーションパスが増加し、時間あたりの活動（コミュニケーション）が圧倒的に多くなるという懸念が示されました。

• プロダクトバックログアイテムの作成量の増加: 「20チーム全部のプロダクトバックログの作成、詳細化は非現実」という意見が出され、POが単独で全チームのバックログアイテムを作成することの限界が議論されました。

• 成果物の検査、適応の難易度の高まり：規模が大きくなると期間あたりの成果物量が多くなり、その分成果物が受け入れ条件等を満たしているのかといった検査する量の増加やどの成果物がビジネス価値を生んだのか分析する難易度の増加などが議論されました。また、検査ができなくなると適応性が損なわれることについても議論されました。

• ビジネス規模・開発規模の増大に伴う不確実性: 規模が大きくなると、ビジネス要件も開発プロセスもより複雑化し、知らないところで不具合が生じるといった不確実性の増加が議論されました。

• 物理的にできない振る舞い：スクラムチームごとの相談事項が発生した場合、複数チームを並列して相談に乗ることができないので、結果的に相談する順番が発生し、待ち行列ができ、円滑に進めることができないことが議論されました。

• 見積もりの難易度の高まり: チーム間の作業の依存関係など問題が複雑化し、予測が困難になることで、計画や見積もりが楽観的になるといった傾向が議論されました。

このような議論を通じて、江端から以下のような問いかけがありました。

スクラムでもLeSSでもプロダクトオーナーの役割や責任、意思決定の基準そのものは変わりません。
では、なぜ、単一チームの段階で、すでにスケールを見据えた働き方ができないのでしょうか？

複数チームで顕在化するコミュニケーションの複雑化や情報過多といった課題は、往々にして単一チームの時点では表面化しにくいため、潜在的な問題として見過ごされてしまう傾向にあるのではないでしょうか？

しかし、チームがスケールするにつれて、情報の流通の仕方・情報量の増加は避けられません。この変化に適応できず、単一チームでの振る舞いをそのまま複数チームに持ち込もうとすると、往々にしてマンパワーで乗り切ろうとしたり、あるいは突然放任的な振る舞いにシフトしたりといった状況に直面しがちです。

単一チームの段階から戦略的にスケーリングを見越した働き方を意識しなければ、プロダクトオーナーは将来的にビジネスのスケーリング、チームのスケーリングに対応するスキルを持たないまま複雑な問題に対象することになるのではないでしょうか？

対策方法の検討

ここからは、これまで出た課題に対し、どのような対策方法があるのかを議論しました。

江端からは、「他の人に任せるといったレポートラインを作るような対策はNG 。プロダクトオーナー自らが確認できる仕組みを検討してください。」といった説明をした上で検討が開始されました。

以下のような対策方法が議論されました。

• 完成の定義の強化

• 成果物を機能単位で検査するのではなく、ユーザーストーリーに合わせて検査する

ここでも江端から問いかけがありました。
スケールするとPOの認知負荷が大きくなり、ディベロッパーが担う業務範囲が多岐にわたり、ディベロッパーのスキルを求める場面が多くなるのではないでしょうか？
この課題に対し、POはビジネス価値への投資だけではなく、ディベロッパーに対する教育への投資の必要性が出てくるのではないでしょうか？また、単一チームのアンチパターンが複数チームだとリスクの見合いで取るべきときもあるのではないでしょうか？
という問いが提起されました。これは、スケールリングする中で、トレードオフを受け入れる必要性があることを示唆されました。

イベント実施後のアンケート結果

今回は参加者17名中8名の方に回答いただきました。

どのような気づきや学びが得られましたか

• スケールの意識の大切さと難しさを考えることができた

• スクラムとLeSS（複数チーム）とでとりある発想や思考が変わらざるを得ない領域が現れること

• lessでのpoの観点

• 1:1と20チームで考え方や取り組む観点が変わることを再認識しました

• また、アンチパターンもただの選択肢として、リスクヘッジをもとにパターンとして捉えて選択することもあることを学びました

• 複数チームと1チームで共通のものも多いが違いが明らかにあるものもあるしわ複数チームの場合1チームでアンチパターンとしていたものをリスクを加味して取り入れることも必要であある

• 規模によってアンチもアンチでなくなることもある

• アンチパターンの捉え方が変わった。状況によってアンチパターンを許容した方が良いことについては理解できたが、一般的にアンチパターンを許容するときの判断軸は何か？という点に難しさを感じた。LeSSとスクラムの違いについても理解が深まった。

• PO の違いに目から鱗

LeSS morning（コミュニティ）またはLeSSの夜明け（カンファレンス）についてのご要望があればご記入ください

• いつもありがとうございます

• 10月が楽しみです！

• 特にありません。

• 参加者コミュニティがもっと活性化できると良いと思いました

• 今特に思いつかないです。

• 現状なし

• 楽しみにしています。

• 参加者の敷居が広がるように、前回の「評価」のような汎用的なテーマもあると嬉しいなと個人的に思った

• 今回のような比較シリーズお願いします

いつもアンケートに協力いただきありがとうございます！いただいたフィードバックは今後の参考にさせていただきます。

今後もあらゆる参加者にとって学びになる場を提供していきたいと思います。

引き続きよろしくお願いします！