ブログ

ryuzeeによるブログ記事。不定期更新

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

みなさんこんにちは。@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つです。
  • ユーザーストーリーマッピング: 新しいプロダクトを作るときは、カスタマージャーニーの観点で考えて、そこからプロダクトに入るものを定義するようにすると便利です。 そうすれば、リリースの範囲を決められるようになります。
これらはほんの一例に過ぎません。

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

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

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

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

交渉は得意ですか?

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

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

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

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

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

プロダクトオーナーとしていちばん大変なのは、常に意思決定する準備ができているようにすることです。 プロダクトオーナーは日々意思決定します。単純なものもあれば難しいものもあります。 優秀なプロダクトオーナーは、意思決定も非常に上手です。
優柔不断な癖をつけるくらいなら、間違った意思決定をするほうがマシだ。 優柔不断で苦しんでいたら、間違いなく行動できない。行動は成功の基本だ。 考えすぎたら、前に進めて変化を起こす決断など決してできない。

リチャード・ブランソン

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

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

最後に

私のプロダクトオーナーの旅は2012年に始まりました。 そこにはかなり多くの学びがありました。 これまで毎日新しいことを学んできました。 プロダクトオーナーであることは私に大きな意欲を与えてくれます。 仕事ではなくパッションです。 プロダクトオーナーとして素晴らしい成功を収めるには、以下が必要です。
  • 素晴らしいコミュニケーターであること
  • 重要なことに優先順位をつける方法を知っていること
  • 全員に明確な期待を示すこと
  • 協力しながら交渉することを理解していること
  • 聞き上手であること

なお、僕がFounder兼CTOを務める株式会社アトラクタでは、8/24および10/5にオンラインスクラムトレーニングを開催します。経験豊富なアジャイルコーチに質問しまくれる機会ですので興味のある方はぜひこちらをご覧ください。 それでは!。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック