【翻訳】プロダクトオーナーになりたい人が知っておくとよいこと

みなさんこんにちは。@ryuzeeです。

スクラムにおいて、プロダクトオーナーはとても難しいロールですが、これからプロダクトオーナーになりたいと思っている人（だけでなくすべてのプロダクトオーナー）向けの「Do You Want to be a Product Owner? You Better Know What Awaits!」という記事が素晴らしい記事だったので、翻訳したものをご紹介します。

翻訳に際しては、著者のDavid Pereiraさんに快諾いただきました。なお、著者のDavidさんはほかにもスクラムに関する有用な記事を多数書いているので、参考にするとよいかと思います。

以下翻訳です。

私がプロダクトオーナーの旅を始めたのは2012年のことでした。そのときにプロダクトオーナーが何を意味するのか知っていればどれだけ良かったことか。そうすれば毎日をもっと簡単に過ごし、多くの問題を避けることができたはずです。私は以下のように多くの失敗を経験しました。

フィーチャーファクトリー: 毎スプリントの最後に全体の一部を届け続けましたが、意味のあるものは何もありませんでした
価値の誤解: ステークホルダーを喜ばせたり、ベロシティを増やすことが良いことだと思っていました。ですが、それは価値とは何も関係ありませんでした
ソリューションへのフォーカス: 問題を理解することなしに、誰も欲していないプロダクトを作ってしまいました
焦点の欠如: 多くの要望を受け入れてしまい、本当に重要なことに集中する余裕がありませんでした

本当にプロダクトオーナーになりたいですか？

プロダクトオーナーになりたいなら、あなたを待ち受けているものが何なのかを理解する必要があります。プロダクトオーナーは決して退屈な仕事ではありません。常に何かが起きます。

プロダクトオーナーとして成功するためには、いくつかの特性を備えている必要があります。自己評価してみましょう。以下の質問に答えてみてください。

毎日たくさんの人と話すのは楽しいですか？
頻繁に衝突が起こる覚悟ができていますか？
会議をリードするのを楽しんでいますか？
喋るよりも多く人の話を聞いていますか？
交渉は得意ですか？
いつでも意思決定する準備ができていますか？

質問に対する答えがすべてイエスであれば、プロダクトオーナーになることはあなたにとって驚くべき旅になるでしょう。ですが、どれかにノーと答えたのであれば、プロダクトオーナーとして成功するためには、コンフォートゾーンから抜け出すよう準備しなければいけません。

プロダクトオーナーとは何なのかについて定跡を知りたい場合は、ここからスクラムガイドを参照してください。私も、プロダクトオーナーが失敗する理由や、プロダクトオーナーがどんなスキルを持つべきかを説明した記事を書いているので、このロールを詳しく知りたい場合は併せて参照してください。

毎日たくさんの人と話すのは楽しいですか？

プロダクトオーナーになることを選んだなら、さまざまなコンテキストで多くの人と会話できるようにしてください。プロダクトオーナーとして成功するにはコミュニケーションは不可欠です。それがなければ問題を明らかにすることもできません。コミュニケーションの例をいくつか見てみましょう。

スポンサー: スポンサーはWhy、目標、予算を示します。プロダクトオーナーはスポンサーの意向に沿う必要があります。そうしないと致命的な誤解が生まれます
顧客: 顧客のペインは何ですか、どんな希望や期待を持っていますか？どうすれば顧客がより良い生活を送る手助けになりますか？
開発者: プロダクトオーナーはチームとともに、解決したい課題、なぜそれが重要なのかを説明します。ですが、注意しなければいけないのは、プロダクトオーナーはWhyとWhatに責任を持ち、開発チームはHowに責任を持つという点です
スクラムマスター: スクラムマスターと同じように、プロダクトオーナーもチームのサーバントリーダーです。プロダクトオーナーとスクラムマスターは協力して、確実にスクラムからメリットを得るようにします。そうすることで水増しされたスクラムがチームの成功を阻害することもなくなります
UX/UI: 顧客とその人たちか抱える問題を理解するには、UX/UIの人たちとプロダクトオーナーの協力が必要です。そうしないと誰も好いてくれないプロダクトが出来上がってしまいます
Cレベル: プロダクトオーナーは企業の最上位レベルの人たちとやりとりすることが多々あります。素晴らしいプロダクトオーナーは勇気を持ち、プロダクトの最善のアウトカムを実現するのに必要ならいつでもCレベルの人たちにも物申します。

リストはいくらでも長くできそうですが、ヒントにはなったと思います。

頻繁に衝突が起こる覚悟ができていますか？

プロダクトトーナーとして成功するには、人としてコミュニケーションに秀でていなければいけません。適切な人たちに対して、適切なタイミングで、適切なフォーマットで、適切なメッセージを届ける方法を理解するのは、とてつもなく難しいものです。しかしプロダクトオーナーならこれが毎日の仕事です。

毎日なんらかの衝突があることを想像してみてください。開発者が異議を唱えることもあれば、あなたとCEOで見解の相違があることもあります。ステークホルダーが自分の欲しいものをリリースするように押し付けてくることも多々あります。こんな状況で、どれだけ心地よく感じられるでしょうか？

プロダクトオーナーの日常は、さまざまな関心を持つ人たちを扱うという衝突の連続です。それがなければ価値あることは達成できず、プロダクトオーナーの役割も退屈なものになってしまいます。

プロダクトオーナーとして顧客のために最善を尽くしたいと考えていれば、衝突は不可避です。輝かしいソリューションはコラボレーションによってしか見つかりません。つまり、意見を率直に話し、みんなのさまざまな視点を共有することが必要ですが、これが衝突を引き起こします。

衝突への恐怖 - 信頼関係が築かれると、メンバーは、破壊的、批判的などと解釈される可能性のある発言をしても大丈夫だとわかるため、激しく、ときに感情的なやりとりにもためらわず飛び込んでいく
パトリック・レンシオーニ、The 5 Dysfunctions of a team、邦題『あなたのチームは、機能してますか？』

では、あなたがいつも遭遇することになる衝突をいくつか紹介しましょう。

ステークホルダー: ステークホルダーはいつもやりたいことをたくさん抱えています。そのためプロダクトオーナーは、何が顧客にとって意味があるかを判断する必要があります。これはステークホルダーと対峙しなければいけないことを意味します。プロダクトオーナーとしてはやらなければいけませんが、そもそも人間は人と対峙するのが嫌なものです。ですが、人と対峙するのは、その人との関係性が維持できていれば難しいことではありません。プロダクトオーナーは、成功のためにステークホルダーと一緒に働き続けなければいけません。

シニアマネージャーが「説明不要だ。私が欲しい。それだけで十分だ。私は幹部で何が必要か分かっている」と言ってきたら、こう答えます。「背景を理解しなければ、先には進められません」。その後、シニアマネージャーはなぜ欲しいかを共有するようになります。私たちは、問題を解決するのに、最初に言われたものとは違う別の良いやり方を見つけることもできるのです。衝突がなければ無意味なものを作ってしまうことになります。

テックリード: ここは議論の余地がありますが、境界を理解するようにしましょう。テックリードは技術的なトピックを優先するよう依頼してくるかもしれません。プロダクトオーナーは、なぜそれがビジネスにとって不可欠なのか、優先しない場合にどうなるのかを評価する必要があります。つまり、ビジネスと技術の間のバランスを取るために、深いところまで会話する必要があります。
十分とは: いつプロダクトをリリースできるか？十分とはどれくらいか？UX、UI、開発チームのあいだで意見が割れることもあります。このような衝突は歓迎すべきものですが、決定はプロダクトオーナーです。ですが、みんなの視点を取り入れるようにして、プロダクトにとって最善の選択をする必要があります。
トップダウン: 誰かが自分のところに来て「緊急」だとか「最優先」だとか言って何かをするように依頼してくることはよくある光景です。誰が言ってこようとも、それに対峙しなければいけません。プロダクトのビジョンを持っているのはあなただからです。プロダクトオーナーは価値を最大化する人なのです。

理解できたと思いますが、プロダクトオーナーの日常は飽きることがありません。衝突では害ではありません。それが起こるのは、それぞれが別の視点を共有しているからなのです。衝突がなければ、隠れたチャンスを明らかにすることなどできないのです。

会議をリードするのを楽しんでいますか？

プロダクトオーナーはたぶん毎日のように会議に参加します。その多くで、プロダクトオーナーが進行役を務めることになります。プロダクトオーナーになりたいなら、会議に継続的に参加していることに馴染まなければいけません。それがプロダクトオーナーの日常だからです。

会議では、以下の点に気をつける必要があります。

どの会議への招待を受け入れるか: あなたは多くの会議に招待されることになります。参加するものと参加しないものを見分ける責任はあなたにあります。明確に優先順位をつけてください。さもないと会議に埋もれて生きていくことになってしまいます。
誰が参加すべきか: 自分が会議を主催する場合は、その場にふさわしい人だけを集めるようにしなければいけません。ほかの人の時間を無駄に浪費してはいけません。よくある間違いは、人をたくさん呼びすぎて結論が出ず、別の会議をしなければいけなくなってしまうことです。
会議で何を決めるか: プロダクトオーナーは準備をして会議に臨まなければいけません。中身が空の招待を送るなどもってのほかです。会議が最後にどうなっているかを踏まえて計画しなければいけません。つまりアウトカムを想定した上で、そこから議題を用意してください。

辛い事実だが、悪い会議からは常に悪い判断が生まれる。これが凡庸のレシピだ。
パトリック・レンシオーニ、Death by Meeting

以下にプロダクトオーナーとしてリードする会議を紹介しましょう。

プロダクトバックログリファインメント: プロダクトオーナーは解決すべき問題を明らかにし、それが確実にプロダクトバックログに書かれているようにします。プロダクトオーナーは開発チームと協力して、プロダクトバックログアイテムを洗練します。そうすることでスプリントにあった大きさになります。
スプリントプランニング: プロダクトオーナーとして、スクラムチーム全体で協力してスプリントゴールを定めます。それからスクラムチームは、スプリントのコミットメントを合意します。
ブレインストーミング: 新しい展望のアイデアを考えたり探したりする機会がたくさんあります。ブレインストーミングはできる限りたくさんのアイデアがほしいときに使うテクニックの1つです。
ユーザーストーリーマッピング: 新しいプロダクトを作るときは、カスタマージャーニーの観点で考えて、そこからプロダクトに入るものを定義するようにすると便利です。そうすれば、リリースの範囲を決められるようになります。

これらはほんの一例に過ぎません。

喋るよりも多く人の話を聞いていますか？

記事をここまで読んで、プロダクトオーナーはさまざまな人たちと多くの関わりがあるのが分かったと思います。ここで重要な質問があります。あなたは聞き上手でしょうか？プロダクトオーナーなら、喋るよりも聞かなければいけません。

私は自分の旅を通じてこのことを痛感しました。結論を急いでしまい何度も失敗しました。質問の仕方を変えることで結果は改善しました。プロダクトオーナーは急いで結論を出すのではなく、隠れた宝石を見つけることを目指すべきです。例を見てみましょう。

なぜ不可能なのか？: 開発チームが「これは不可能だ」と何度も言うことがあります。それが不可能な理由を明らかにするようなオープンクエスチョンを投げかけて、それについてもっと詳しく理解するのがあなたの役目です。たとえば、「可能にするにはどうしたらいい？」とか「その結論に至った障害はなに？」といった質問をしてみてください。不可能だというのは、単なる認識に過ぎません。変えられるのです。
本当の顧客ニーズは何？: やりたいことはたくさんあります。ですが、顧客が必要としているのは何でしょうか？本当のペインは簡単に見つかるものではなく、調査的な質問を投げかけることで本当の問題に近づきます。たとえば、「この機能からどんな利点が得られますか？」「これを使って解決したい問題は何ですか？」というような質問をしてみましょう。
なぜ緊急なのか？: 問題が起こると人間はパニックを起こします。そしてこう言います。「緊急だ、すぐ直さないと」。これをいつも真に受けていると、プロダクトオーナーではなく消防士になってしまいます。こんなときは、挑戦的な質問をすることで、本質に迫れることもあります。「あなたから見て緊急なのはなぜ？」「何もしなかったらどうなるの？」といったものです。

パワフルクエスチョンを使うことで、話すより聞く素晴らしい機会が得られます。プロダクトオーナーになりたくて、まだこれをやっていない人は、まずここから始めてください。

交渉は得意ですか？

すでにあなたは交渉がプロダクトオーナーの日常の一部であることに気づいているのではないかと思います。もし交渉が好きでないなら、プロダクトオーナーとしては厳しい状況に遭遇することになります。

何よりもまず理解しなければいけないのは、交渉であなたが勝たなければいけないという意味ではありません。ゴールはプロダクトにとって最善なものを手に入れることです。コラボレーションが不可欠です。なので、全員と協力しながらアイデアを重ねていくような形で交渉してください。勝とうとして交渉し、たいしたことのない結果に終わるような罠にはまらないようにしてください。

プロダクトオーナーが交渉しなければいけないシナリオをいくつか見てみましょう。

プロダクトバックログリファインメント: スクラムチームでプロダクトバックログアイテムを洗練しているとき、プロダクトオーナーは開発チームとの交渉が必要です。開発チームはたとえば、なにかをやりたくないと言ってくるようなことがよくあります。これはチームがプロダクトの健全性にとって危険だと信じているために起こります。そのため、プロダクトオーナーは代替案を見つけるためにチームと交渉が必要になります。
ロードマッププランニング: プロダクトオーナーが何がロードマップにあうかを計画するとき、多くのトピックが候補にあがります。みんな優先させたいものがありますが、実現性はキャパシティの制約を受けます。つまり、プロダクトオーナーは交渉して、全員の賛同を得なければいけません。プロダクトオーナーは全員の声を聞いた上で、何を計画に入れて何を外すのか交渉することになります。
技術タスク: 開発チームはプロダクトオーナーに対して、リファクタリングやバージョンアップ、調査を求めてくることがあります。それらすべてにイエスと言ってしまうと、ビジネスには何も届けられなくなってしまいます。また全部にノーを言ってしまうとチームのモチベーションは下がります。つまり、丁度よいバランスが見つかるまで交渉して、チームは自分たちの意見を聞いてもらえていると感じられるようにし、その上で、プロダクトにとって何が最善なのかを合意します。

交渉の機会はたくさんあります。そして学習可能なテクニックもたくさんあります。以下の記事を読んでみるとよいでしょう。

いつでも意思決定する準備ができていますか？

プロダクトオーナーとしていちばん大変なのは、常に意思決定する準備ができているようにすることです。プロダクトオーナーは日々意思決定します。単純なものもあれば難しいものもあります。優秀なプロダクトオーナーは、意思決定も非常に上手です。

優柔不断な癖をつけるくらいなら、間違った意思決定をするほうがマシだ。優柔不断で苦しんでいたら、間違いなく行動できない。行動は成功の基本だ。考えすぎたら、前に進めて変化を起こす決断など決してできない。
リチャード・ブランソン

プロダクトオーナーがしなければいけない意思決定には次のようなものがあります。

リリース計画: 開発チームもビジネス側も、どんな頻度でリリースするか、いつリリースするか、それまでに誰とコミュニケーションすればよいか、といったリリースプロセスを定義することを期待しています。
開発の選択肢: 開発チームがある機能で複数の選択肢を見つけることは多々あります。そして、プロダクトオーナーに「どれでいくべきか？」を聞いてきます。プロダクトオーナーが決めなければチームは動けません。プロダクトオーナーがそれを決めるオーナーシップを持っていると想定しているからです。
何を優先するか: たくさんのプロダクトバックログアイテムのうち、最終的に優先するのはどれでしょうか？プロダクトオーナーは開発チームを率いてビジネス価値を最大化しなければいけません。
機能をいつリリース可能とするか: 開発チームは自分たちの作業結果をプロダクトオーナーに示します。プロダクトオーナーはそれがいつリリース可能なのかを判断します。完成の定義が役に立つでしょう。