本記事は、Stefan Wolpers さんの「20 Questions from New Scrum Master to Product Owner
」の翻訳です。翻訳にあたり、Stefan さんの承諾をいただいております。誤字脱字、誤訳がありましたらぜひご指摘ください。
TL; DR: 新任スクラムマスターとしてスピードを上げるためにプロダクトオーナーに聞くべき20の質問
スクラムマスター（SM）からプロダクトオーナー（PO）へ、この質問集は、SMとPOの2人の個人とスクラムチーム間の将来的な協働を扱うことになります。この質問集は、パフォーマンスの高いチームに共通する基本原則に基づいてモデル化されています。印刷可能なテンプレートをダウンロードして使ってください。
スクラムチームの成功に欠かせないプロダクトオーナーという役割
スクラムを適切な問題領域（複雑な問題領域において創発的なプロダクト）に適用しているかどうか、あるいは、開発チームが技術的な熟練度に優れていて、スイスの時計仕掛けのような規則性を持ってプロダクトインクリメントをデリバリーできるかどうかは、問題ではありません。プロダクトバックログが開発チームの作業から得られる価値を最大化していないために、スクラムチームが間違った方向に向かってしまっているのであれば、誰も気にかけることができないでしょう。ガベージイン、ガベージアウト --- ゴミを入力してゴミを出力しているということになるからです（詳しくは、Marty Cagan の記事「Product Success」を読んでみましょう）。
価値を提供する実践的なプロダクトバックログのメンテナンスを担当するのは、プロダクトオーナーです。
プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。
『スクラムガイド』
PO としてこのゴールを達成する主な方法は、プロダクトバックログのマネジメントになります。『スクラムガイド』によると、この活動に次のように構成されています：
- プロダクトバックログアイテムを明確に表現する
- ゴールとミッションを達成するようにプロダクトバックログアイテムを並び替える
- 開発チームが行う作業の価値を最大化する
- プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す
- 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう
引用: 『スクラムガイド』(2017)
スクラムマスターとして、スクラムチームを成功に導くためには、プロダクトオーナーを最大限にサポートする必要があります。
新任スクラムマスターからプロダクトオーナーへの質問集
この質問集は、スクラムチーム全体を巻き込むことなく、プロダクトオーナーと新しいスクラムマスターとの最初に会話することを目的としています：
1. プロダクトのビジョンとそのためのGTM戦略はありますか？
ビジョンや戦略に関する質問が出たときに、プロダクトオーナーは、チームで一番の頼りになる人物でなければなりません。
*GTM: Go-to-Market
2. 新たなアイデアや要求については、どのように学んでいますか？
ここでは、プロダクトオーナーは、プロダクトの発見プロセス全体について説明できる必要があります。アイデアから仮説、実験、そして最終的な検証に至るまで説明できるでしょうか。
3. プロダクト発見プロセスにユーザー調査をどのように組み込んでいますか？
私は、学習する組織がユーザーテストを継続的に実施しないで運営できるとは思えません。したがって、プロダクトオーナーは、ユーザーテストのプロセス全体だけでなく、スクラムチームがどのようにプロダクトの発見に関わっているのかを説明できるべきです。
4. ユーザー調査と顧客ニーズの把握にどれくらいの時間を割いていますか？
経験則としては、50％の時間を割いていれば素晴らしいでしょう。10％未満の時間ならば、プロダクト発見プロセスに（たくさんの）改善の余地があります。プロダクトオーナーの作業負荷に関する質問でフォローアップしましょう。また、プロダクトオーナーが顧客と話しをする時間を増やすためにどのようなサポートができるかを説明しましょう。
5. スクラムチームはどの段階でプロダクト発見プロセスに関与しますか？
プロダクト発見プロセスの出来る限り早い段階で、スクラムチームが参加できることを強く推奨します。開発チームのメンバーがこのプロセスに参加するのが早ければ早いほど、技術的に実現不可能であったり、投資に対するリターンが得られない解決策であったりが押し進められる可能性が低くなります。
6. 利害関係者との連携をどのように整理していますか？
これはプロダクトオーナーにとっては簡単な質問でしょう。このコミュニケーションを時間をかけて確立し、改善するにはさまざまな方法があります。例えば、それぞれの利害関係者との定期的なミーティングを設けることや、利害関係者をアンバサダーとして任命して「連絡将校」として育成するなどです。利害関係者/アンバサダーとのワークショップを手配しましょう。ユーザー体験担当者とチームを組んで実行しましょう。例えば、ユーザージャーニーやユーザーストーリーマッピングのワークショップを開催したり、利害関係者をリファインメントのセッションに招待し、ユーザーストーリーの価値を説明してもらったりしましょう。詳しくは、「利害関係者とのコミュニケーション 〜 11の実績のある戦術」をご覧ください。
7. 長年のプロジェクト (pet project) をどう扱っていますか？
新任スクラムマスターが知りたいのは、プロダクトオーナーがプロダクトバックログを本当に守ことができるかです。過去にその人は、「いいえ」と言ったことがありますか？また、スクラムチームが長年のプロジェクト（pet project）に取り組んでいたり、取り組んでいたとしたら、なぜそうなったのでしょうか？
8. プロダクトロードマップの作り方はどのようにしていますか？
ロードマップのプランニングは、ポートフォリオのプランニングと同様に継続的に行われます。プロダクトオーナーは、組織のプロセスを詳細に説明できる必要があります。
9. プロダクトバックログはどれくらいのサイズですか？
私は、スクラムチームが 3 〜 4 スプリントで対応できない大きさのプロダクトバックログが有用だとは思えません。プロダクトバックログがこの閾値を超えている場合、このようなプロダクトバックログの潜在的に不利益な混雑化を防ぐために、プロダクトオーナーにはサポートが必要かもしれません。結局のところ、新任スクラムマスターは、プロダクトバックログから価値のあるシグナルを探しているのです。
10. プロダクトバックログの作業アイテムの典型的な消費期限はどれくらいですか？
すでに5ヶ月も経っている作業アイテムの価値は疑ってしまいます。「でも、それに取り組んできたのです」と言う言い訳が浮かんできます。
PRO TIPS: 「Product Backlog forensics」は、組織がどのように機能しているかについての多くのインサイトを与えてくれます。プロダクトバックログのアイテム数、アイテムの消費期限、アイテムを作成したのは誰なのか、アイテムについてコメントした人、アイテムを変更した人など、データには多くの有益な情報が埋もれています。
11. 検証すべきアイデアの選び対応する作業アイテムをプロダクトバックログに追加するまでの平均リードタイムはどれくらいですか？
これは、実際にはいくつかあるメトリクスの1つです。この指標は、実際にどのように「アジャイル」なプロダクト発見が行われているかのインサイトを得ることができます。
12. プロダクトバックログに現在のチームの誰も知らない作業アイテムがありますか
もしあるならば、現在のチームメンバーと共にそれらのアイテムを再度見返してください。
- 作業アイテムは、今でも価値を提供するか
- アイテムの性質について、チームメンバー全員の間で共通認識できているか
13. どれくらいの頻度でプロダクトバックログのリファインメントをしていますか？
プロダクトバックログのリファインメントは継続的な活動とすべきです。私の経験では、スクラムチーム全体が参加する定期的なリファインメントのイベントを少なくとも1回*は開催することが有益であることがわかっています（訳注: スプリントに1回）。
14. プロダクトバックログのリファインメント中に並行して取り組んでいるアイテムはどれくらいあるりますか？
私の経験では、プロダクトオーナーは、次の 1 〜 2 スプリントで扱える以上のプロダクトバックログアイテムを作るべきではありません。そうしなければ、決してスプリントバックログに入らないような作業アイテムにリソースを割り当てるリスクが非常に高くなります。
15. 典型的な作業アイテムのリファインメントにどれくらい時間がかかっていますか？
リファインメントは、1 〜 2 スプリントに跨がるべきではありません。コンテキストの切り替えの危険性や仕掛かり制限は、リファインメントのセッションにも適用されます。
16. 作業アイテムをどのように作っていますか？
作業アイテムを、チームの協働作業として作っているのでしょうか。あるいは、プロダクトオーナーがユーザーストーリーを書いて、チームがそれらを見積もっているのでしょうか。プロダクトオーナーは、開発チームが見積もるための作業アイテムに対して一種の「テクニカルライター」になってしまう傾向があります。しかしながら、作業アイテムの作成は、チーム全体の協働作業とし、共通認識を持つことを強く提案します。詳しくは、「 Essential XP: Card, Conversation, Confirmation」をご覧ください。
17. プロダクトバックログのアイテムの議論をどこでしていますか？
リファインメントセッション中だけですか？または、Slack やアイテムのチケットのコメントで議論していますか？例えば？
どのチームにもそれぞれの習慣があります。Confluence, Jira, GitHub, Slack を活用してコメントすることは、組織内のコミュニケーションとして有効な手段なのかもしれません。プロダクトオーナーが合意しており、開発チームがスプリントバックログに作業アイテムが選択する前に限っては問題ないでしょう。しかし、スプリント中に初めてその作業アイテムの基本的なことについて既論をするのは問題になることがありまます。
18. スプリントバックログのアイテムを変更していますか？もしそうなら、どのような状況で変更しているか？
プロダクトバックログのアイテムがスプリントバックログとして選択された後に、変更されることはありますか？
開発チームが問題に直面した場合に、作業アイテムを小さくすることは決して素晴らしいことではありませんが、受け入れることはできます。作業アイテムがまだ価値を提供しているならばです。しかしながら、スプリントプランニングのあとに、スプリントバックログを大きくすることは受け入れられません。スプリントバックログの構成をコントロールできるのは開発チームだけです。
19. 作業アイテムをいつ受け入れますか？
『スクラムガイド』（2017）では、プロダクトオーナーによる「受け入れ」は、スプリントの中止についての段落において一度だけ言及されています。
部分的にリリース判断可能なものについては、通常はプロダクトオーナーが受け入れる。
『スクラムガイド』
しかしながら、プロダクトオーナーとチーム（のエンジニア）が作業アイテムを「完成（done）」と考えている時に会話することは有用であることがわかっています。
20. 作業アイテムを却下したことはありますか？
作業アイテムを却下したことがあるならば、なぜそのようなことが起きたのか、また、再びおこらないようにするためにどのような対策が取れたのかを学びたいと思うでしょう。
まとめ
この質問集は、プロダクトオーナーと新任のスクラムマスターにおける最初の会話を手助けし、新任スクラムマスターのスピードを上げるのに役に立ちます。これらの質問は、パフォーマンスが高く価値を創造するチームの勝つ特性に焦点を当てています。
何か適切な質問で抜けているものがありますか？質問集に追加するものがありましたら、教えてください。
“Hands-on Agile” Slack team にぜひ参加してください。無料です。
関連記事:
長沢 智治
サーバントワークスでは、ソフトウェア開発をはじめとした複雑な業務を改善する支援サービスを実施しております。スポットから中長期まで探究と伴走による支援についてお伝えしたいことがあります。ぜひお気軽にお声がけください。
本記事の翻訳者:
長沢 智治 - アジャイルストラテジスト
- サーバントワークス株式会社 代表取締役
- Professional Scrum Trainer (PST) [日本人初]
- Agile Kata Pro 認定トレーナー [日本人初]
- DASA 認定トレーナー
認定トレーナー資格
『EBM実践ガイド』「プロフェッショナルアジャイルリーダー』『More Effective Agile』、『Adaptive Code』、『今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など翻訳・監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。
