この記事を書いた目的
初めまして、上野と申します。求人検索エンジンを開発している株式会社スタンバイにて、BtoCプロダクトのスクラム開発チームでプロダクトオーナー（Product Owner：PO）を担っています。キャリア的には広告代理店が長く、直近までスタートアップ支援をしてきており、事業会社でスクラムでのプロダクト開発経験は初めての経験でした。
あまり知られてないのですが、実はスタンバイは歴史的にスクラムに関する教育や開発の環境が非常に整っています。僕自身もありがたいことにOdd-e社様の認定スクラムプロダクトオーナー（CSPO®︎）トレーニングや同社CTO貝瀬様のコーチングも数ヶ月にわたって受けることができ、自分なりのプロダクトオーナー像が見えてきた頃でした。そこへちょうど今回のようなチャンスがあり、本記事執筆に至っています。
この記事で伝えたいこと
基本的にはスクラムにおけるプロダクトオーナーで僕が常日頃心がけていることやtipsを経験からお伝えします。どちらかというとマインド部分が多いのと、なるべく読了後にすぐ実践できることをコンパクトに書いているつもりです。 欲を言えば、スタンバイに興味を持ってくれる人がいたら嬉しいなと思っています。
逆に書かないこと
スクラムの教科書的な用語解説や小難しいことは書きません。「スクラムとは？」や個別のスクラムイベント、HOWなどについても割愛します（今後記事化する予定です）。ほかで体型的にまとめられている方もたくさんおりますし、僕自身がそうなのですが、小難しいことって、学んでも実は現場に活きづらかったりしますよね。結構この記事を読んでプロダクトオーナーとして明日からどう生かすか、の方がお役に立てるのではと思い、使えそうなことを中心にまとめてみました。
僕の考えるPO（プロダクトオーナー）十則
いきなりですが、僕の考えるプロダクトオーナーが守るべき「十則」をご紹介します。
PO（プロダクトオーナー）十則
1. 四六時中ROIを意識していること |
僕が1年近くプロダクトオーナーをやって思った結果がこれです。 正直、プロダクトオーナーは誰でも名乗ることができます。ただ、役割を全うするには弛まぬ努力が必要だと言うことを痛感しました。
ROIを最大化するためには手段を選ばない
プロダクトオーナーとは、スクラムチームから生まれるプロダクトの価値を最大化することの結果に成果を持つ人、つまりは「プロダクトのROIを最大化する」ことがミッションである人のことです。 「スクラムを始める際には、まずプロダクトオーナーを任命すること」と言われているほどスクラムチームには重要な存在であり、プロダクトバックログを左右する最終意思決定者のため、複数人いてはならず、必ず1スクラムチームに対して1名です。開発者やスクラムマスターなどとは利害関係が異なるので、兼務も非推奨と言われています。
ROIを最大化するための決まった手段はありません。つまり、あらゆる手段を講じることができる、もっと言えば、そのくらいオリジナリティを発揮すべき役割であると考えています。他社や他チームのノウハウも積極的に参考にすべきですし、人が足りなければ他チームに交渉するし、ROI的に、今はチームを休ませるべき！と判断すれば1か月休ませたって良いでしょう。
「ROI」と一口に言っても、取り扱う際は注意が必要です。
-Investmentはプロダクトオーナーが直接コントロールできる？ |
予算追加や人員増、ツール購入、計画など時間やお金を投資すべき対象はさまざまですが、Investmentはプロダクトオーナーがコントロールできるものでなくてはなりません。 直接Investすることで返ってくるReturnを最大化するのです。そのReturnは必ずしも売上等の定量的な事業インパクトに限らず、教育や文化形成など、社内向けの定性的なReturnがあることも忘れてはいけません。
見落としがちなのが、いつ発生するReturnなのか？です。次のスプリントで反映されるんだっけ？数ヶ月はたまた数年後のReturnなんだっけ？という点はROI最大化を考える上で非常に重要なポイントです。
また、ROI最大化に向けて、僕自身プロダクトオーナーとして心がけていることの1つは、多少の強引さです（笑）。スクラムチームメンバー全員に意見が賛同されなくても「否定されない」程度のロジックを詰めて進めていく、くらいの心構えも必要だなと感じています。とはいえ、やりすぎると単なる「わがまま」なので、伝え方や一貫した戦略はセットにはなりますが。サッカーでいうと、点さえ取っていればさほど文句を言われない、そんな世界に住んでいるのがプロダクトオーナーなのではないかな、と考えています。
つまるところ、プロダクトオーナーはROI最大化に向けて一歩でも二歩でもスクラムチームを前に進め続けること。転んでもタダでは起きないこと、本気でROI最大化を突き詰めるのであれば、そういったスタンスが必要とされていると感じています。
プロダクトオーナーとしてやらないこと
逆に、唯一僕が「やらない」と心がけているのはHOW（どうやるか？）まで踏み込むことです。プロダクトオーナーはWHAT（何をやるか？）とWHY（なぜやるか？）のセットでスクラムチームを動かす方が何かとうまくいくと言われています。 つまりは、何を、なぜ実現したいか？というストーリーをプロダクトオーナーが考え、語り、どのように実現したいか？は開発者に委ねるということです。チームによっては歓迎されることもあるのでしょうが、プロダクトオーナーが開発にまで介入してしまうと、開発者の心情的には「言われたことだけをやっている」感が増すことが多いと言われています。経験的にも僕は控えてきました。
上記を徹底するために実践しているのは以下です。
1. PBI(Product Backlog Item)にユーザーストーリー（WHAT）を記載すること |
１つ目は、PBIは必ずユーザーストーリーにしていることです。タスクを書くことはまさにHOWまで入り込んだ行為です。実現したいこと（Tobe）さえクリアであればスプリント内に最速で実現する方法（To-do）は開発者が検討すれば良いのです。 ちなみに、ACで実現したいことを書くだけでは開発者が判断しかねるケースも出てくるので、「やらなくても良いこと」を敢えて記載することもあります（AC1つに対して「やらなくても良いこと」2つが黄金比らしいです）。
2つ目は、実現したいユーザーストーリーの背景（なぜそれを実現したいか？）も、しっかりPBIに記載しつつ、納得いくまで説明することです。プロダクトオーナーがPBIを書くこともあるので、PBIは記載内容を型化するのも良いでしょう。 ただ、PBIの記載やスクラムイベントだけではどうしても伝えきれないストーリーの背景もあるはずです。ユーザーインタビュー結果のまとめやログ分析結果、競合情報など、共有したいんだけど、どこで話せばよいかわからない、といった類の情報も多い気がしています。 そのため、僕のチームでは、オンラインワークであることをうまく利用し、discordで「POラジオ」なるものを実践しています。週に30分ほど、プロダクトオーナーとプランナーがマーケットやユーザー動向、中長期で実現したいことなどの自由な雑談をただ単純に聞いてもらうという会です。任意参加なのですが、少々複雑な取り組みにおいても意思疎通がしやすくなってきている実感はあります。開発者からも継続希望の声が多く、数か月続けてこれています。
バックログ管理とその先にある大事なコト
ここでスクラムガイド書かれているプロダクトオーナーの責務に触れておきます。「プロダクトバックログ管理」です。
“『プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ』”
PBI自体は誰が作っても並び替えても問題ありませんが、最終的に優先順位の意思決定はプロダクトオーナーに委ねられています。その優先順位の基準はROIが最大化されること、且つ、そのロジックはブレることなく、常に一貫させることが必要です。
ただ、個人的に、バックログの優先順位付けよりも重要だなと感じているのは、その先にある開発者とのコミュニケーションです。優先順位が付けられたとしても、開発者が動けなければ意味がありません。プロダクトオーナーは何も生み出せないのです。プロダクトを前に進めるため、開発者が気持ちよく働ける環境を作っていくこともプロダクトオーナーにとって重要な役割であると考えます。
開発者の人柄や働く上での「やるべき」「やらないべき」ことをを知り、適切なコミュニケーションを取るよう心がけています。仕事とは言え、1人の人間です。プライベートな問題でどうしても気持ちが乗らないときだってあるでしょう。そうした心の変化も週次や隔週で1on1やオフライン出社を設けてコミュニケーションが取れる機会を作り、開発における障壁を極力無くすように心がけています。少し気持ちが乗っていなさそうだなということであれば負荷を減らしたり、逆に乗っている方には少々負荷を上げたりしています。
内容によって伝え方も気を付けています。例えば、良いニュースやポジティブなフィードバックは全体の場で盛大に話しますし、ネガティブなフィードバックが必要な時はなるべく個別で対面で話すようにしています。 DMを非推奨にしている企業さんもいらっしゃるようですが、全ケースに当てはめる必要はないと思っています。人によっては全体で語られることが嫌な人もいるはずで、特性に合わせて対応すべきでしょう。
ちなみに僕のチームでは四半期の最終日は全員で休暇を取るようにするなど、チーム独自のルールを設けたりもしています。
プロダクトオーナーとして意識していることとtips集
他にも書きたいことはたくさんあるので別記事にするつもりですが、今回お伝えしたかったのは、プロダクトオーナーを全うし続ける大変さとその反面自由度が高いゆえのやりがい、という点です。
つまるところ、プロダクトオーナーには特別なスキルや資格は必要なく、ROIへの執着、そして、プロダクトに対する熱い想いとチームメンバーへのリスペクトがあれば誰でもプロダクトオーナーを名乗れると思っています。
誰でも名乗れる、は裏を返せば、自分だけにしか出せない価値を常に問われていることに他なりません。「プロダクトオーナーとしてアナタだけにしかできないことってなんなんですか？」という呪いの言葉を常に視界の横にちらつかせながら活動していかなくてはならないのです。 オリジナリティを出し続けることは至難の技だとしても、少なくともプロダクトオーナーとしての自覚は持ち続けようと、僕がいつも戒めのためにPCの横に貼っておこうと考えたのが以下プロダクトオーナーの十則というわけでした。
PO（プロダクトオーナー）十則
1. 四六時中ROIを意識していること |
上記はあくまで個人的な「十則」ではありますが、読者のPOの皆さんにとっての十則をまとめてみると、自由度が高い職務の中でも軸がブレずに取り組めるかもしれません（Twitterで見つけ次第スタンバイアカウントがコメントするかもしれません）。
ちなみに、Odd-e社様が「プロダクトオーナーチェックリスト」というチェックリストを外部公開しているのでご興味あればぜひご確認ください。
最後に、本文でも「プロダクトオーナーとしてやらないこと」で触れた、僕がプロダクトオーナーを担う中で上手くいったtipsを少しだけ紹介します。
反響次第では関連記事を公開していこうと思いますので、感想等ぜひお待ちしております。
まとめ：スクラムtips
| 課題感 | 開発者にとって、POやプランナーが考えていることがわからないので、開発にアイデアを活かしづらい。 |
1.POラジオ
| 解決策 | 任意で毎週2回30分、discordでラジオ番組風トークを開催。 開発チームは耳だけ参加でOK。POやプランナーは直近のプロダクト課題やロードマップ、分析結果など、普段ビジネス側で会話するような雑談を準備なしに実施。 以下プロダクトオーナーtimesでつぶやいたことを拾って話したりもしている。 |
| 結果 | 比較的課題の目線合わせがしやすくなったと感じる。 開発者からも評判は良く、継続を求める声が多い。 |
２．プロダクトオーナーtimes
| 解決策 | slackに公開チャンネルを作り、プロダクトオーナーとして考えていることをTwitter感覚でslackにひたすら呟く活動。市場や気になるニュース、SEO、ユーザー体験、ログ分析結果、ほか業務以外の雑多なトピックなど、1日1投稿以上は心がけている。 他チームのPOらも参画。 |
| 結果 | 表にされづらい自グループのPOの考えを開発者や他メンバーが追いやすくなり、コミュニケーションにおける前提説明が減った（メンバーから「この前timesに投げてたアレのことですよね？」などで話をつなげやすくなったり）。 開発者との有益な会話に発展しチケット化につながるだけでなく、他グループと連携して施策につながるような副次的効果も。 |
スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。 www.wantedly.com
