見出し画像

VP of Products 1年目の振り返り ‐グロースフェーズのVPoPの役割‐

久保 拓也

※本記事はユアマイスター Advent Calendar 2021年の23日目の記事になります。

こんにちは、久保　拓也(@takuya__kubo)です。
年の瀬になりまして、皆様いかがお過ごしでしょうか？

「振り返るにはいい日だ。」ということで、この1年間の学びを共有する記事を書かせていただきたいと思います。

2021年は、引き続き社長室に席を置きながら、VPoPとしてプロダクト全体のマネジメントをしたり、新規事業責任者として法人SaaS事業立ち上げなど複数の役割を担ってきたこともあり、すべて振り返ろうとすると雑多になってしまいますので、今回はVPoPロールの部分に絞って書きたいと思います。

こんな方にどうぞ

  • 事業がグロースフェーズに至り、プロダクト組織が10名規模から30名規模へと急拡大するフェーズにいらっしゃる方

  • 1からプロダクト・マネジメントチームを立ち上げる方

  • Biz主導の開発からプロダクト主導へと方向転換を検討されている方

  • VPoPとプロダクトマネジャーの違いを感じたい方

  • ユアマイスターのプロダクト組織について知りたい方


上記の皆様を想像しながら、1年間を通じて起きたプロダクト組織における変化、その中で担ったVPoPとしての役割、成功したこと、発生した問題と学習ポイントなどを書かせていただきます。

また、上記以外の「プロダクト関連やスタートアップ関連で面白そうな記事読んでみようかな」という方にも楽しんでもらえる内容にできたらと思います。

それでは参ります。


プロダクト組織の変化

　この1年間ほどでユアマイスターのプロダクト組織にも様々な変化がありました。

まずは定量でわかりやすいところから行くと、プロダクト組織の人数は外部パートナーも含め、14名だったところから30名以上まで増加しました。


昨年12月の僕らからすると劇的な変化です。
（ただし、後述させていただきますが、僕らはその変化が生み出す問題の大きさに気づけていませんでした。）

そして、組織の拡大に紐づき、当然消化するバックログチケットの数は増え、、


てない。

あれ？


はい。増えていませんでした。笑

理由は明確です。

ユアマイスターでは大規模な新規開発に対し、プロジェクト型組織を組閣する形をとっていますが、昨年12月はこの大規模開発がほとんどなく、改善系の開発がメインでした。

一方、本年はプロダクト主導型の開発へと移り、ロードマップにある開発を次々と手がけていくことになっています。

実際、現在進行中の大規模プロジェクトは7つと昨年の7倍になっていました。

月間のチケット消化数自体は少なくなっているのですが、事業インパクトの大きい重要な開発は大幅に増えており、プロダクト組織の力が付いたことを実感します。

ただ、ここにも様々問題の種が潜んでおりました。
詳細は同じく後半に譲りますが、とても楽しい感じになっています。

このように少しずつではありますが、「Biz主導の改善型開発」から、「プロダクト主導の価値創出型組織」に変わった兆しのある良き1年でした。

VPoPがマネジメントする対象とは何か

　そのような組織成長がある中で、僕がこの1年間取り組んできた仕事について簡単にお話したいと思います。

　これはあくまで僕が実務を遂行する中で感じたものではあるのですが、VPoPがマネジメントする対象は以下の3つだと考えています。


Whole Product像とロードマップ

　プロダクトの理想の姿の設計、それらを実現するにあたってのロードマップの構築・リファインメントが一つ目の重要な役割です。

このあたりの構築の仕方や具体論につきましては、プロダクトマネジャーの諸先輩方がより高次元でお話しいただいておりますので、この場では詳細を割愛します。


プロダクトマネジメント組織

　プロダクトマネジメントを実行するPdMメンバーの採用・育成などの組織マネジメントも同じく重要な役割になります。

　ここでいうマネジメントは単に人の管理育成ではなく、「どんな組織にしたいか？」の組織ビジョン設定や職務要件の設定、採用など組織構築が多くの割合を占めることになるかと思います。
　

バックログとPRDの品質

　プロダクトバックログやPRDの品質についても同じく重要なマネジメント対象です。
　個別の開発内容について切り込んで品質を維持するというよりは、「誰のために・なぜ・何を創るのか？」を問うPRDやバックログ内の優先順位・チケットの品質をマネジメントすることで、プロダクト組織全体のアウトプットとアウトカムをコントロールすることが求められます

この1年間、時期ごとにその比重は違えど、上記3つの仕事を等しい割合で実行していたように思います。

実行した施策と成功ポイント

　これら3つのマネジメントを行うにあたり、様々な施策を実行してきました。書き切れないところもありますので、ポイントだけ記載します。
（と言いつつものすごく多くなりました笑）

Whole Productの創造

　そもそもWhole Product像が弊社内に見える形で存在しなかったことから、VPoEの星さんや技術顧問の明石さんと議論を重ね、形にするところから始めました。
　その中で、我々のプロダクトCoreはそもそも何なのか？、そのCoreを実現するにあたり提供すべきプロダクト価値は何かを明らかにし、Whole Product像を創りました。

ロードマップの再編

　既存のロードマップについては、Whole Productと照らし合わせながら、四半期ごとに見直すサイクルとし、Coreを実現するための骨太なプロダクト開発と、短期的な収益を実現するためのプロフィット開発の2種類が回る体制にしています。

Biz組織及び経営チーム意識統一

　Biz組織や経営ボードとそのロードマップを対話・適宜修正をしていく形になり、1年を通じてようやく回る体制になったと思います。
　代表や経営チームがこれを後ろ支えしてくれたことで、従来Biz主導の開発が多かった組織が、プロダクト主導の開発組織へと変貌を遂げていきました。
　実は、このアカウンタビリティには結構意識を割いています。よく「Biz組織や経営チームとの対話が重要」という話はあると思うのですが、VPoPはこのすり合わせと予算明確化が一番大事と言っていいかもしれません。
　イメージで言うと全体の仕事の10～15％ぐらいはアカウンタビリティや起案に充てていたように思います。

プロダクト・マネジメントチームの創設

　ユアマイスターには今年の3月まで「ディレクター組織」はあったのですが、プロダクトマネジメント組織はありませんでした。
　語弊を恐れず極端に言えば、プロジェクトマネジメントが主体で、納期に間に合わせる開発が主だったと言えます。

　「Why」を大切にし、「価値」を起点にプロダクト開発をする組織を創りたいと考え、今年の3月にプロダクトマネジメントチームを立ち上げました。　
　名前だけ変えても意味がなく、一方、名前さえも浸透しない恐れもあるものだったので、目的の共有や名称の伝達、社内のドキュメントの変更、noteを書いて社内外に発信するなど浸透を図っていきました。
　また、実際の業務においても従来やっていたタスクで捨てるべきものを決めるなど明確に仕事内容を変えていきました。

プロダクトマネジャーの職務要件定義と評価制度

　チーム立ち上げ時にこだわったのは、職務要件定義と評価制度の設計です。

　プロダクトマネジャーは非常に業務範囲が広く、期待されることも多くなりがちです。そのため、魅力的な仕事でありながら、自分が本来どう成長すべきか、どんな能力開発をすべきなのか、戸惑うことも多いと思っています。

　これを解決するために、既存のミッショングレード制度や評価制度と紐づけながら、個別のコンピテンシー要件を設定し、任せるミッション、成長のステップを粗いながら言語化しています。

　この職務要件や能力開発については、僕自身がリクルートで経験してきた人材開発の知識体系を用いて補完している部分があり、まだ誰もがマネジメントできる状態ではありませんが、少しずつそれらを移植し、誰でも組織マネジメント可能な状態にしたいと思っています。

僕はプロダクトマネジャーのプロではありませんが、組織マネジメントのプロが多く揃うリクルートで育ってきました。

　一流のプロダクトマネジャーでなくても、超一流のプロダクトマネジメント組織を育てられる証明をしたいと心に決め、ここには魂を込めて臨みました。

プロダクトマネジャーの採用成功

　これらの環境構築と並行し、PdM・UXデザイナー・PMMロールを担うメンバー5名の採用に成功し、現在、僕を含めて8名のメンバーがプロダクトマネジメントチームに属しています。

　上記のWhole Productや職務要件定義、採用のために書いたnoteが効果を発揮したのではないかと思っております。


　また、オファーレターとしては、必ず内定条件とは別に下記の内容をまとめたお手紙をお渡しするようにしていました。

＜お手紙内容＞
・ミッショングレードと職務要件
・担当するプロダクト
・組織拡大の予定
・待遇条件と決定の背景
・短期的に任せるミッションと期待成果
・中長期に任せるミッション詳細

こちらは坪田さんのこの記事を参考にさせていただきながら、項目を設定し、きちんと一人一人に対してオファー内容を考え抜くことを実践しています。

　ちなみにこちらのお手紙は、オンボーディングにも役立っており、入社後のギャップがほぼ発生せず、各メンバーの活躍を後押ししています。
　実際、ほぼすべてのメンバーが入社後3か月以内にMVPを受賞したり、重要なプロダクト開発を担ってくれている状況です。

PRDの導入

　プロダクトのWhy-Who-What-Howを整理し、適切な開発を行うためのドキュメントを推進していきました。
　これまでもドキュメント化はしていたのですが、より理想の状態の設定や目的を明確にすることで、迷ったときの指針になったり、コミュニケーションの起点になるよう導入しています。


発生した問題と学習ポイント

　おそらく成功ポイントよりも、こちらの方が学びになるかと思います。僕らも、頭では分かっていたにもかかわらず落とし穴にハマっている部分もありますので、同じようなチャレンジをされようとしている皆様は参考にしていただけたら幸いです。

プロダクトロードマップ実行にはテクノロジーロードマップが不可欠

　プロダクトロードマップに従い開発を推進している中で起きたことです。各開発に当初想定したエンジニアを充てているにもかかわらず、なかなかロードマップ通りに進まないという事態が、数か月連続で発生しました。

　振り返ってみた際に、時間がかかっていたのは基盤開発の部分でした。
5年も開発を継続していると、過去の技術的負債も一定溜まっており、アーキテクチャや、データモデルの見直しなど、基盤周りの検討を至るところで迫られていました。

上記が起きた要因の1つに、プロダクトロードマップは構築したものの、テクノロジーロードマップが未構築だったことがあげられます。

　プロダクトロードマップは、ユーザーに対して提供する価値を起点にロードマップ構築をするため、比較的アプリケーションレイヤーの内容が多くなります。
　しかし、プロダクト開発を実行する上ではその前提となる基盤開発が不可欠です。こういったインフラレイヤーやプラットフォームレイヤーにおけるロードマップが不十分だったために、都度アプリケーションレイヤーの開発に応じて検討すべき項目が膨れ上がり生産性が下がるという事象が起きていました。

　テクノロジーロードマップは、プロダクトロードマップ上で実現したい価値や機能開発の一歩手前で取り組んでおくべき技術的なテーマや基盤開発の内容をまとめたものになります。
　アーキテクチャの構想、技術選定やフレームワークのアップデートもここに含まれており、プロダクトロードマップの一歩先を行くものにしなければなりません。

　これは、今後プロダクトロードマップを置き、推進する皆さんに是非学習ポイントにしていただけたらと思います。
と言いつつ、プロダクトロードマップにそもそも基盤開発を組み込んでいらっしゃる企業が多かったとしたら、完全に僕らの力不足でしかないのですが。

　多くの企業では、テクノロジーロードマップはCTOが主体となって進めるものになると思います。弊社では、今年3月に入社したテックリードの福田が中心となって、アーキテクチャ構想やプラットフォームレイヤーの開発を推進してくれています。


Meetyで直接福田さんにお話も聞けたりしますので、良かったら是非！



コミュニケーションコストが広がり生産性が悪化

　次の問題です。これは、どこの組織やいろんな書籍でも扱われており、自分たちがまさかハマるわけなかろうと思っていたのですが、見事にはまりました。

少し書籍よりは具体的な事象に踏み込むことで、「自分たちもそろそろか」と感じていただくケースにできたらと思います。

昨年12月時点では、エンジニアが業務委託含め10名程度、PdM（当時はディレクター）が3名、デザイナーが1名程度でした。
今思えば、この10名強という人数が1チームとして推進する上での限界人数だったのだと思うのですが、ここまでは開発を阿吽の呼吸で進めることが出来ていました。

しかし、この人数が数人超えた段階から劇的にコミュニケーションコストやマネジメントコストが上昇します。

正社員採用、業務委託採用双方進めていった結果、

・PdM⇔エンジニアのコミュニケーション
・エンジニア間のコミュニケーション

両方で齟齬が出るようになり始めました。
今まではチームの全体MTGや1on1で補完していたものが、十分に補完出来ないサイズになっていった状況です。

しかもこの問題の難しい点は、ゆでガエル的に徐々に感じることになり、すぐには気が付けないところにあります。
予めそうなることを理解していない限り、必ず陥ってしまう類のものだと思います。（それらを見越して相当ドキュメントに力を入れている組織は異なります。）

これに気が付いたのは、恥ずかしい話2021年も半分以上が過ぎた段階で、そこから徐々に改善を進めていっています。

　最初に始めたのは、PdM⇔エンジニア間のコミュニケーション改善のためのPRD導入。その後、少しずつドキュメント化や情報共有の仕組みを見直していきました。

現在は、プロダクト組織全体で30名に差し掛かっており、この先の50名～70名組織に向けた改善を推進しています。
現在の延長線上に未来はないという認識を持ち、各開発プロセスの標準化、完了条件の明確化、チーム単位の分割などを進めています。

僕らは開発チームの拡大が通常のスタートアップに比べて遅かったこともあり、発生自体もかなり遅かったと認識しているのですが、遅かれ早かれどの企業も必ず迎える問題だと思います。

それらを見越して備えておくこと、それがすべてだと思っています。
プロダクト組織が10名を超える前後から備える。組織を預かる皆さんにはこの認識を是非持っていただけたらなと思います。

その他の問題

　正直非常にたくさんあり、ここには記せません。
スプレッドシートで振り返ったら溢れました笑　

個人的な課題感でいえば、PdMのデータモデリングの知識が不足していることは大きな課題で、何よりその不足は自分自身が感じていたので、一時期ひたすら本読んで勉強したりしていました。

　こういった問題を一つ一つ乗り越えることがこれからのプロダクト組織の拡大に不可欠なのだと思っています。

グロースフェーズのVPoPに求められる役割とは？

　この1年間は事業としてもプロダクトとしてもグロースフェーズに入ったタイミングとなりました。
　
　そういったグロースフェーズにおけるVPoPに求められる役割を、自分なりに記して本振り返りの「まとめ」とさせていただきたいと思います。

　この1年間でプロダクトの規模や開発テーマ、プロジェクトの数は激増したのですが、そのような環境下において、これまで同様Oneプロダクトとしてマネジメントすることに限界を感じざるを得ませんでした。

　各社においても、それまでは社長やPO、プロダクト責任者が1名ですべてのプロダクト、機能について見ることが出来たところから、すべての機能にハンズオンで入ることが難しくなり、「テーマ・プロダクト」と「人・組織」を1セットにして渡し、間接的にマネジメントを行う体制が必要となります。

　これは、プロダクトをポートフォリオに見立て、各開発をどう推進するかを盤面でコントロールする、いわばプロダクトの経営を行うことに近い状態です。

　企業経営が事業価値向上を目的としたポートフォリオマネジメントを行うとするならば、CPOやVPoPが担うプロダクト経営はユーザー価値向上を目的としたポートフォリオマネジメントを行うということです。

これを実現するには、「テーマ・プロダクト」と対にする「人・組織」が不可欠になります。そういった組織や人を成長させる、整えるマネジメント力がグロースフェーズのVPoPには不可欠になるのだと思います。

　僕自身は、まだまだ経験も実力も不足しているのですが、その一端を担い、実体験を得ることが出来た1年間でした。

　ユアマイスターはまだまだ小さなベンチャーですが、実は事業やプロダクトは多岐にわたり始めており、これからも益々そのポートフォリオは拡大していく予定ですので、是非楽しみにしていてください。


今回の記事はこちらで以上です。

この振り返りからは省いた内容が多々あるので、
それはまた改めて学びとして共有したいと思います。

ユアマイスターでは一緒にプロダクトを創る仲間を募集しています。
少しでも興味持っていただけましたら、ぜひご連絡ください。

ご連絡はDMやリクルーティングサイトにてお待ちしております。




この記事が気に入ったらサポートをしてみませんか？