POに1mmも興味がなかったエンジニアがBizDevになった話

こんにちは。2023 年新卒入社でデジタルエンターテインメント事業部の Web3 開発グループに所属の Hidetomo Shimaoka( @hyde_dev )です。

今回は僕がこの新卒研修を通してプロダクトオーナーオーナー(PO) を経験することで、エンジニアとして事業開発（BizDev）に関わるキャリアを選択することになった体験記を紹介したいと思います。

特に読んでほしい人

エンジニアだけど、ビジネスサイドの仕事にも関わりたいと思っている人
PO や PdM などの仕事に興味はあるけど、やれるイメージがなかなか湧かない人
漠然と 1 人では成し遂げられないスケールの大きいことがやりたいと思っている人

入社時は PO というキャリア選択は無かった

僕が DeNA にエンジニアとして入社したときのキャリア像はエンジニアリングマネージャー(EM)になることでした。当時の理由はかなりざっくりしていて

個人の能力だけでは成し遂げられない、より大きな成果を残すことに興味を持っていた
エンジニアリングも好きだが、ビジネスをスケールさせることにも興味があった
少ない実務経験のなかでも、優秀なマネージャーがいるチームはより遠くまで効率的に辿り着けると実感していた
（学生インターンで毎日 1 人でコードを書き続ける状態に飽きてきていた）

といったものでした。 1 人のエンジニアとしてスペシャリストを目指すのではなく、チームを率いて 1 人では成し遂げられない成果をあげる役割を担いたいと思ってなんとなく「マネージャー」という存在を意識していただけです。

もちろん事業責任者・CEO などのリーダーとしての役割にも尊敬や憧れのような感情はあったのですが、『エンジニアの自分がビジネスサイドで活躍することは難しいのではないか』と心にブロックをかけていたのだと思います。エンジニアの自分がリーダーとして事業や組織の不確実性をコントロールすることは難しいと半ば諦めており、 PO という役割を知ることもなく、なんとなくマネージャーになればエンジニアリングの知識を活かしつつビジネスサイドにも関わる仕事ができると思っていたのです。

PO の機会は突然やってきた

新卒エンジニアとして研修を受けるなか、6 月にアジャイル開発研修研修が行われました。これはアジャイル開発を学ぶコンテンツの一環として社内向けのプロダクトを 0 から作り 1 ヶ月でリリースするものです。

日程	メインイベント	何をするのか
Week1	デザインスプリント	「解くべき課題の設定〜プロダクトアイデアの提示」をする
Week2	開発 ①	スクラム開発キックオフなど
Week3	開発 ②	開発とスクラムイベント (1)
Week4	開発 ③	開発とスクラムイベント (2)
Week5	開発 ④ ・成果発表	プロダクトのリリースと成果発表

スクラムキックオフにて

1 ヶ月をともにするスクラムチームのキックオフが 6 月のはじめに行われました。チームはビジネス職 1 名・エンジニア 5 名で結成する形で、事前に「プロダクトオーナー（PO）とスクラムマスター（SM）をやりたいか」と希望アンケートが取られます。僕はこのアンケートにも「PO を希望する」といった回答はしていませんでした。

キックオフでは PO や SM を決める前に『せっかくなら最高のプロダクトを作ろう。この先も社内で使われるものを作る』とチームの方針が決まったため、「最高のものを作るために一番 PO としてふさわしい人を選ぼう」という方針になり、1 人 1 人が

このプロダクトでどんな世界観を目指しているか
自分が PO/SM をやるならどんなことをするのか
このプロダクトを作ろうと思った原体験

などをスピーチで共有していったのです。その結果、僕が目指す先や提供できるスキルがチームメンバーの意志やスキルセットと一番合致すると分かり、PO に選ばれたという形です。

他のチームは PO をビジネス職が担当することが一般的だったため、エンジニアの自分が PO をやることに不安はありつつも挑戦してみようと思いました。

PO の役割

スクラムの原則を書いた"Scrum Guide"では Product Owner（PO）の仕事は以下のように定義されています。

プロダクトのゴールを定義し、チームへ明確に伝える

プロダクトバックログを作成し、優先度をつける

バックログをオープンに公開し、チームメンバーに理解してもらう

つまり PO の仕事は「顧客にとって最適なプロダクトを作る責任を持ち、チームを先導しながら実現していく」という仕事になります。

よって PO は明確にリーダーであり、マネージャーではないのです。与えられたリソースの中で"やりくり"をしていくのではなく、What to do を決めてどこにどのリソースを配分していくかを責任を持ちながら決定していくことが必要です。このことから『PO をやるなら顧客に価値を出せる仕事はすべて関わろう』という意識を常に持っていました。

プロダクトに対してのロードマップやメッセージを持つことは当たり前として、チームのカルチャーを創り、そのプロダクト・チームの顔として顧客の前に現れる覚悟を決めます。

苦しみながらスタートするゴールの見えないマラソン

初めての PO としての仕事は順調なものではありませんでした。

プロダクトのアイデア創出〜プロトタイピングのフェーズにおいて、

チームメンバーの原体験
想定ターゲットを観察するなかでの行動事実
リサーチによって現れるマクロ分析結果

などのあらゆる要素をコントロールしながら実際の具体的なプロダクトとして落とし込まなければならないのは非常に難しいことです。

自分のなかでざっくりとした理想像やプロダクトのユースケースは想定されていても、やはり具体的なプロダクトとして落とし込むとギャップが生まれて「本当にこれが正しいものなのか？」と自信がなくなっていきます。ユーザーインタビューや競合プロダクトのリサーチを重ねても正解がはっきり見えてくるわけでは無いため、分からない部分は検証する仮説として持っておき、分かっていないことを認めながらリーンにスタートすることに踏み切ります。

他人の失敗や成功から学んでチームをつくる

PO を初めてやるにあたって、全てを自分のオリジナルで進めていては当然うまくいきません。

そこで最初に取り組んだこととしては、徹底的に過去の成功した/失敗したプロダクト・会社を分析しながら「どうやると失敗する可能性が高いのか」「成功した例のなかで自分たちにフィットしそうな参考例はあるか」を見つけて試してみることです。

全ての例がそのまま自分たちのチームに適用できるわけではないので、少しづつチームに導入していって良質なアウトプットに繋がるかを検証しなければなりません。このように参考例を検証していくなかでチームにフィットできた施策としては以下の 3 つがあったと振り返ります。

1. プロダクト創成憲章でビジョンを統一する

よいプロダクトと組織には独自のカルチャーが定着していると思います。

Amazon なら"Customer Obsession（地球上で最も顧客を大切にする）"、Apple なら"Simple, not complex（シンプルこそ最高の洗練）“のようなものです。

そこで我々のチームはプロダクトを開発する前に「今後僕らがプロダクトを開発する上で死守しなければいけない価値観はなんだろうか」と認識を統一させました。これによってチームのカルチャーが創出され、最後までメンバーの共通認識が取れた状態で意思決定を行えたことは非常に有効でした。

THANCS プロダクト創成憲章

このプロダクト創成憲章を作成した理由としては、「どんなときでもチームが立ち返り、個人の能力・感情に依存しない判断軸がほしい」と思ったからです。

PO や一部のメンバーのみが意思決定に参加するモデルを取り続けると、中心メンバーの特化した能力やその日の感情などでチームの重要な判断が揺らいでしまいます。そこで明確なカルチャーとルールを設定してチーム全員が意思決定を行い、チームとしての判断を理解できるようにプロダクト創成憲章を設定しました。

2. リリースを繰り返してデータドリブンで意思決定を行う

Facebook の創業者マーク・ザッカーバーグはこう語ります。

アイデアは完成してから目の前に現れることはない。最終的な目的地が最初から見えている人なんていない。

かくいう僕も PO ながら開発していたプロダクトの完成像が見えていなかった人間です。（残念ながら天才ではありません）

新しいプロダクトを世に出す際は、既存のソリューションよりも合理的なメリットを提示してもユーザーに好まれるとは限らないため「どのような体験価値がユーザーやコミュニティに好まれるのか」を見えていない状態で地道に検証していく必要があります。

我々のチームでは、仮説検証に以下のようなルールを設けていました。

各リリースごとにユーザーへの価値を表す明確な指標を用意する
各指標はユーザーの行動データから測量可能なものにする
仮説検証の成功・失敗を判断する明確な基準を用意する
意思決定はこれらのデータをもとに判断していく

毎回のリリースでこのルールを徹底することで、ユーザーが価値を感じる体験をデータとして明確に判断できるようになり、チーム内での意思決定のブレを無くすことができました。データとして落とし込むことで「見えなかったものが見えてくる」のです。

3. リリースの単位は 1 つの顧客価値

1 ヶ月間において計 7 回にわたってリリースをしたのですが、ただがむしゃらにリリースをしてきたわけではありません。「ユーザーに提供価値を正確に理解してもらうため、またチームが仮説検証を正確に行えるためにリリースにノイズを含めない」ことには細心の注意を払っていました。

僕のチームは ↓ のようなインセプションデッキを作成し、各リリースでどのような 1 つの顧客価値を実現するのかを確認していました。

我々はなぜここにいるのか

リリースの単位を 1 つの顧客価値に絞らないと以下のような副作用が生まれると考えています。

顧客がリリースに対して「自分にとってどんな価値があるのか」をシンプルに把握できなくなる
顧客が「このサービスはどんな方向に向かっているのか」を誤解しやすくなり、ビジョンへの期待が薄まる
開発チームが各リリースの目的について認識が揃わず、実現スピードが落ちる
リリースごとの成功・失敗要因が正確に分析できなくなる

これらの懸念を考慮して、リスクマネジメントの観点からこのルールを徹底していました。データドリブンで意思決定を行なっていくチームとして、このルールがないことには継続的な前進ができなかったと振り返っています。

結果を出すために天才性は必要なかった

1 ヶ月にわたる開発期間を終えて、僕らのプロダクトは無事にユーザーアンケートで高いスコアを叩きだし、社内プロダクトとして運用されることが決定します。

もちろん 1 ヶ月順調に進んだわけではなく、自信を持ってリリースした機能が全くユーザーから反応されず、1 週間かけてチームで設計・開発した機能を PO 判断でストップしなければならなくなったこともありました。

「仮説を外してしまって本当にごめん。僕は PO だけど正解は持ってない。仮説を外してしまうこともあるけど、最後までこのプロダクトのために全力であがくことだけは約束する。だから僕と最後まで戦ってほしい」そのとき僕はやり場のない悔しさを元にチームメンバーにピボットすることを伝えます。ただチームの仲間は嫌な反応 1 つせず、「完璧に進むことなんて無いから大丈夫。ここからまたゴールのないマラソンを一緒に楽しもう！」と前向きにリアクションしてくれました。

『本当にいいチームメンバーに囲まれた。このチームならどこまでも遠くに行ける』そんな感覚になりながら、チームの重要性を実感します。最初は良いプロダクトを作るためにスティーブ・ジョブズやイーロン・マスクのような天才が必要なのかと思っていましたが、1 人の天才ではなく最適なスキルとカルチャーが整ったチームこそが継続的な成功に繋がると実感できました。

エンジニアが PO をやる意味

僕もエンジニアとして PO に挑戦することはハードルを感じていました。今までは誰かが決めた要件・仕様に基づいて忠実にエンジニアリングをしていくだけの仕事だったので、自ら"何を作るか"を決めてチームに伝えるようなものは初めての体験です。

しかしながら PO をやるなかで自分のエンジニアとしての経験が生きた瞬間も少なからずありました。

実現・ユーザビリティリスクを減らした上で開発チームにプロダクト仕様を伝える

PO は開発チームに"何をなんのために作るのか"を伝えなければいけません。それらは PRD やラフな UI/UX 設計図などのアウトプットで渡されることが多いですが、作るものの実現可能性や UX イメージなどに PO <-> 開発サイドで解釈の齟齬があると、期待しない完成品ができてしまったり、開発途中に手戻りが発生してしまうので大きな時間やお金のロスが発生します。

僕はエンジニアとしてフロントエンド〜バックエンドまで基礎的な開発経験があったため、

実現したいユーザーの体験
実現するにあたってのソリューション/UX 原則
実現スコープ
実現可能性についてのリスク
UI/UX イメージ（ラフ図）

などを PO として定義した上で開発チームとコミュニケーションをとることができました。これによって期待しないアウトプットができてしまうリスクや手戻りが発生してしまうリスクを減らすことができたのはエンジニアとして強みが出た部分だったと思います。

重要な意思決定に関与して改善サイクルを最速で回す

プロダクトをリーンに検証していく上で、 1 度リリースをしてしまったら後は「Be Great or Pivot（偉大になるか変わるか）」の世界です。初期リリースからホームラン級のプロダクトが作れていない限りは、後は改善サイクルをいかに早く回して、ヒットを多く打つためにいかに打席に多く立てるかという勝負だと僕は捉えていました。

よって PO として重要な意思決定すべてに関与して、チームが高速に改善サイクルを回せるように開発チームと同等にコミュニケーションをとることは非常に重要です。

ピボットで〇〇機能をクローズすることになってしまったが、モデリングから変更すべきなのか？コードベースを削除するだけでいいのか？
□□ 機能が思った以上にウケた。この体験を長期的に伸ばしていきたいが、リレーションモデルは長期的なビジョンを踏まえてどう変更したら良いのか？
デプロイに関して問題が起きた！この問題を解決するためにどこまでコストを払ったらよいのか？そのままリリースしても妥協できるレベルの問題なのか？

…など、あらゆる意思決定に PO は関与しなければなりません。これら開発チームと調整していくトピックについてエンジニアリングの経験が生きたのは間違いないです。これらの判断を PO が高速に対応することでチームがアジャイルに前進し続けることができ、よりマーケットにチャレンジできる回数が増えます。

こうしてエンジニアとしての知見が活かせたことによって、"最も改善・リリースサイクルが速いチーム“として最後まで走り切れたことが一番の収穫だと思っています。

さいごに

今回のブログは、昔の自分のような「キャリア選択に悩んでいるエンジニア」「PO や PdM などに興味はあるけど自分がやれるイメージが湧かない人」に向けてヒントになればと思って書きました。

PO というキャリアの選択があること
未経験でも PO/PdM などの事業開発サイドに挑戦することは楽しいということ
エンジニアであってもキャリアの方向を制限する必要はないということ

僕の体験談からこれらのメッセージを参考にしていただければ幸いです。

また、この研修を通して関わることができた最高のチームメンバー・メンターさん・研修チームの方々、これらの人々がいなければ今の僕は存在していません。心から感謝を申し上げて結びとさせていただきます。