プロダクトオーナー、やめました。 UbieにおけるPOの役割とチャンス。
こんにちは。Ubie Discoveryチーム、「元」プロダクトオーナー（PO）の、まつむら（@matsumura_ubie)です。タイトルの通り、1年以上務めていたPOをやめました。
プロダクトオーナーとは、スクラム開発（アジャイル開発）において、プロダクトの価値を最大化する結果に責任を持ち、顧客課題の探索や、開発テーマの優先順位づけなどを行う役割のことです。
Ubieでは実は、驚くほどあっさり、かつ高頻度にPOが入れ替わります。
私がPOを辞めた経緯と、UbieにおけるPOの役割・アサインについて、簡単にご紹介します。
詳しく話を聞いてみたい！という方は、カジュアル面談も受け付けていますので、お気軽にどうぞ。
【この記事は、こんな人向け】
・PdMやPOのキャリアに興味がある人
・PdMやPOの役割分担などを考えている人
・プロダクト開発に興味のある全ての人
1.なぜプロダクトオーナーをやめたのか？
拍子抜けかもしれませんが、実はPOを辞めたことに特段大きな理由はありません... 出だしからすみません...
最大の理由は、なんと言っても「だいぶ長い期間務めていたから」に尽きます。1年3ヶ月でした。（ちなみに、7月に開発スクラムチームが少し減り、POが余ったからという理由もあったりします。）
そもそもUbie Discoveryでは、POに限らず、同一のチーム・役割で1年以上働くのは、相当長く職にとどまっているとみなされます。次の2つの理由で、社内のポジションとアサインの流動性を高く保とうとしているためです。
理由①：メンバーの学習を促進して、組織の柔軟性を担保するため
Ubieは”多拠点同時突破”をうたっており、日々様々な事業や機能が立ち上がったり、時に消えていったりするスタートアップです。チームや役割は、四半期、何なら月次週次レベルでどんどん新陳代謝させ、その時フォーカスするテーマに応じて柔軟に作り変えていきます。
そのため、ある役割は特定の人にしかできない、またはできる人が少ない、という状態は望ましくありません。日頃からアサインを流動的にすることで、各メンバーが強みを伸ばしつつ、経験やCanの幅を広げていけるようにし、事業の状況に応じて臨機応変な体制が取れるようにしています。
POに関して言えば、例えば「次の事業の種になるプロダクトコンセプトを複数同時に検証しよう」というタイミングが来たことがあります。スクラムチームを今の倍くらい立ち上げるため、その分POも必要になりますが、経験者が何人かいれば、スタートダッシュも切りやすくなるわけです。
また、あるチームで学んだ知見を、別のチームに持ち込むことで、相互に学習が進む効果もあります。うまく回っているスクラムのメンバーが別のスクラムに異動し、劇的にチームの学習が進んだ例もあります。
理由②：メンバーが全社視点を持ち続けるため
もう一つの狙いは、メンバーが様々な事業・プロダクトを経験して、全社目線で広く事業を理解しつづけるためです。同一ポジションで長く働くと、そのドメイン・事業には詳しくなりますが、どうしても他の事業への解像度が低くなりがちです。
事業最適ではなく、あくまで全社最適な活動をモットーにしているUbie Discoveryでは、コラボレーションを起こすためにも、事業部レベルでの定期的な異動が推奨されています。
以上のように、私がPOを辞めたのは全社のアサイン戦略によるものでした。もしかしたら、またいつかPOをやることがあるかもしれません。
2.プロダクトオーナーをやめて、今何をしているのか？
次に担う役割は人によって様々です。その時点での全社の事業状況などに左右されます。私の場合は、POを辞めた後、引き続き同じtoB事業の「マーケット検証・型化・移管のBizdev」や「フロントマン」として活動しています。
「マーケット検証・型化・移管の役割」
簡単に言えば、カスタマーサクセスの型化などです。特に、POの経験を活かし、サクセス状況からプロダクト課題を抽出したり、逆にプロダクト施策をサクセス活動にいち早く反映したり、といった「プロダクトフィードバック」を作ることに取り組んでいます。
「プロダクト開発のフロントマン」
スクラムチームの中でも顧客の課題を集めたり、作ったプロダクトの検証に重きをおく役割です。POと似た役割ですが、開発優先順位の決定権や社内との調整業務を持たない代わりに、より顧客に近い形で活動し、情報を集める仕事です。
こんな感じで、その時その時で、必要なポジションを見つけて飛び込んでいくため、何か特定のキャリアパスが存在しているわけではないのもUbieの特徴です。
3.UbieにおけるPOの役割とは？
ここからは、時々質問を受ける「POはどんな役割で何をするのか？」「どうやったらPdMやPOになれるのか？」について、Ubieでの例を簡単に記載します。
そもそもPOとは？
はじめに、一般的なPOの役割から簡単に説明します。
よく聞かれるのは、プロダクトマネージャー（PdM）とPOとの違いです。詳細な説明はしませんが、簡単に私の解釈を記載します。
スクラムガイドには、
『プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること の結果に責任を持つ。』と定義されています。
つまりPOは、スクラムチームのイチ役割であって、”プロダクトに対しての立ち位置”は定義されていません。プロダクトの進むべき方向は示しますが、プロダクトや事業へのオーナーシップを持つとは限りません。
PdMは、それより広い概念と考えられます。プロダクトだけでなく時に事業そのものの責任を担い、場合によっては採用や育成を含むリソース調整も行います。まさしく「事業責任者」というニュアンスです。
したがって一般的には、（さらに分業はあれど）PdMはやや広く事業を、POはやや狭くプロダクトの成功を、見ているという違いがあるかと思います。
UbieにおけるPOの役割は？
Ubieでも、POはプロダクトの価値最大化に一番の重きを置き、中長期の事業目線でのプロダクトビジョンは、他の役割の人と一緒に考えます。
あまり正確ではありませんが、下記の図のように、プロダクトオーナーは中長期のOKR（=目標）に対して情報提供したり意見をしつつ、スクラムの短期目標に責任を持つ、といったイメージです。
※OKRやホラクラシーなども含め、Ubieの組織設計・運用を簡略化して表現しています。
4.UbieではどうやったらPOになれるのか？
Ubieでは、POになるためのスキルや経験の要件は定めていません。現に、私もコンサル出身で開発経験がないまま、POになりました。POのアサインは、例えば次のような考えに基づいて決まります。
最重要：マーケットと向き合える
プロダクト開発は仮説と検証の繰り返しです。例えば「まだドメイン知識の不足で仮説が立てられない」といった場合には、まずは開発メンバーやBizdevとして一定期間活動してから、アサインの機会を待つことになります。
重要：スクラムを理解し体現できる
スクラムマスターがチームのサポートをするとはいえ、POはスクラムへの理解が深いほうが良いです。POとはあくまでチームの中のイチ役割であるため、チーム内での最適な動き方が求められます。
本人のWill/Can/Mustと、全社進捗のバランス
POに限りませんが、基本的には、本人のWill（〜を経験したい、〜で全社に貢献してみたい）が重視されます。一方で、Can（全社意識があるか、関係する経験があるか、など）と、Must（全社のために今◯◯をやる必要がある）も含めたバランスでアサインが決まります。
全社で特定のテーマにフォーカスすべきタイミングでは、比較的CanとMustを重視して決まりがちで、逆にやや余裕がある時にはWillが重視されるなど、一定の幅があります。
toBとtoCの事業特性の違い
基本的にtoBでは、顧客への提案や期待値調整、現場での交渉や実験の遂行など、対顧客向けのスキルが多少必要とされます。そのため、UbieではBizdevやUXデザイナーなどがPOになるケースが、過去多かったです。
もちろん、そういった顧客交渉はフロントマンに任せるなど分担もできるので、何らかのスキルが無いとなれないことはありません。
一方でtoCは、ユーザーインタビューなども行いますが、適切なサンプリングや定量データの分析、マーケ専門家や外部ベンダーとの協業などがやや多いイメージです。こちらも、適切に役割分担できれば、ほぼ誰でもPOになることはできそうです。
...と、基本の考えはこれだけです。顧客課題を理解でき、適宜他の役割の人と相談しつつ、取り組むべき課題を決定できさえすれば、誰でもPOに挑戦することができるのが、Ubie Discoveryの特徴です。
5. 最後に。Ubieでプロダクトオーナーをやってみませんか？
Ubie Discoveryチームでは、プロダクトオーナーは全てのメンバーに開かれ、かつ入れ替わりも大きいので、経験するチャンスがきっとあるはずです。
プロダクトや顧客課題を深く理解できるだけでなく、全社の目標設定や事業進捗、スクラムへの深い知見なども得られる、非常にエキサイティングな仕事です。
ぜひご興味がある方は、カジュアルにお話しましょう！
↓ カジュアル面談の申込みはこちら（どちらでもOKです）
↓Ubie Discoveryメンバーの投稿はこちら！
この記事が気に入ったらサポートをしてみませんか？