【モノグサPdMシリーズ vol.2】メガベンチャーとスタートアップのPdMの違いをつらつらと並べてみる
はじめに
こんにちは。モノグサ株式会社でPdMチームのManagerをしている大野と申します。
(PdM = Product Managerを指します、念の為）
カジュアル面談などでプロダクトマネージャーの方とお話しさせていただく中で、「モノグサってどんな会社？」「モノグサにおけるPdMの仕事範囲は？」「PdMやそれに関わる社員の人たちはどんな人がいるの？」というようなご質問をよく頂戴いたします。そういった点を中心に、少しでも当社から定期的にPdMに関する記事を発信できると良いかなと思い、チームとして始めたこのPdMのnote記事シリーズですが、第一回目は PdMチームのメンバー紹介記事をメンバーの岩楯さんに寄稿いただきましたので、こちらもご興味あれば是非是非是非ご覧ください。
さて、今回は第二回ということで、Managerである自分が筆を取らせていただきました。何をテーマに書こうかな、よく質問いただくPdMの仕事の範囲を中心に書こうかな、と思っていましたが、いくつかのテーマ候補について社内でアンケート取ったところ、予想外に自分の前職であるメガベンチャーと（当社も属する）スタートアップのPdMの違いが知りたい！と多くの方からコメントいただきました。
あまり第二回の内容にふさわしくないかもしれませんが、社内だけでなく多くの方からも興味がある？テーマかなと思い、つらつらと書いてみようかと思います。（当社PdMの仕事範囲詳細については、次回以降の記事に譲ろうかと思いますw）
軽く自己紹介
第一回記事でも簡単に紹介いただいていますが、本記事の前提となる自分のキャリアについて少し自己紹介させてください。
この業界に既に20年以上おりますが、自分のキャリアとしては当社は3社目になり、他の当社社員と比較してもそこまで経験社数が多いわけではないかなと思います。
1社目は大手SIerに新卒SEとして入社いたしました。文系出身ではありますが当時のSIerは新卒研修が手厚く（今も？）、全くの無知識からスタートしたエンジニアキャリアではありましたけれども、7年間ほどエンジニア職を経験させていただきました。最後2年ほどは非常に大きな開発プロジェクトにも参画させていただき、血反吐を吐くようなプロジェクトではありましたけれども今の自分にとっても非常に良い経験だったと思います。
その後、SasSプロダクトのPre-salesやITコンサル、事業企画という仕事も4年ほど経験させていただきました。（とても素晴らしい会社でした！）
2社目は楽天です。入社したのは今から10年以上前ですが、楽天では当時から「Producer」という職種があり、当時はまだ「Product Manager」という言葉はなかった時代ではありますけれども、仕事内容はほぼ「Product Manager」と同義だったのではないか、と思います。自分が担当したサービスは楽天の中でも有名なサービス、というわけではありませんでしたが、「Producer」として（2016年ごろ？からProduct Managerという呼び方もし始めました）約10年間で合計5つ以上のサービスを担当させていただき、メンバー -> Manager -> Senior Managerというキャリアを経験させていただきました。（自分にとって楽天は本当に素晴らしい会社・環境でした！いろいろ言われてますが頑張ってほしい！w）
そして3社目として、モノグサにPdMチームのManagerとして入社いたしました。転職を決めた理由としましては「もとよりスタートアップ／教育サービスに強い関心」「モノグサの無限大の可能性に共感」「経営層含めた社員の人柄・カルチャーに感動」というポイントです。
このようなキャリアではありますが、本記事は前職の楽天時代10年間のPdM経験（と一緒に仕事させていただいた他社を含む PdM100人以上の人たちを見て思うところ）と、現在のモノグサのPdMメンバー・業務やスタートアップ界隈で見聞きした内容を比較して思うところをつらつらと書いていこうと思います。
（記事タイトルや後述は抽象度をあげて「メガベンチャーvsスタートアップ」と表現させていただきましたが、業界全てを知り尽くしているわけではなく、あくまで いち個人の意見としてご理解いただけますよう）
メガベンチャーもスタートアップも同じところ
まずはどちらも同じところから。これは唯一にして絶対的なところかなと思いますけれども、「大きな意味でのPdMの役割とミッション」は同じだと思います。
「プロダクトを成功に導く存在」として、「プロダクトを作り、育てる業務」「エンジニアやデザイナー、ビジネス関係者をリードする業務」という、抽象度の高い表現としての業務はどのメガベンチャーでもどのスタートアップでも同じではないかと思います。（それがProduct Managerという仕事だからあたりまえだ、というツッコミは受け付けませんw）
また、主たる業務、例えば、ロードマップを作成したり、要求仕様の整理、開発の優先順位付け、プロジェクトリードなど、粒度の違い（後述）はあれど同じだと思います。一般的にPdMの業務範囲は広いと言われ、会社によってその範囲は違うという話もよく聞きますが、それはまさにその通りかと思いますけれども、「メガベンチャーかスタートアップか」で分かれるというよりも、本当に「会社によって異なる」のではないかと思います。（その会社の文化や歴史、組織の役割分担などによって異なると思います）
それぞれに在籍するPdMの方々のキャリアパス・バックグラウンドについてもメガベンチャー・スタートアップとで大きな違いがあるとは思いません。pmconf 2022のアンケートでは「PdMになる前のキャリア」というアンケート結果がありますが、こちらと同様にどちらでも特定のキャリアパスの傾向があるということはなく、PdMは多種多様なキャリアパスを経由してなられている方が多いという印象は変わりません。
（ただ、例外としてメガベンチャーでは「新卒PdM採用」をしているところがあり、スタートアップ界隈ではあまり聞かない、という点は異なります）
メガベンチャーとスタートアップで違うところ
さて、本題です。自分の主観ベースではありますが、以下に違うところを挙げていきます。基本的には「組織・サービス規模の大きさが起因によって生ずる」ものが多いかなと思っております。なお、どちらが良い悪い、というものではなく、どちらにもメリット（とデメリット）があると思っておりますし、「必ずこうだ」というよりも「その傾向がある」というように理解いただければと思います。（自分の現場はそうじゃないよ、というケースも当然あると思いますので）
1. 細分化された役割定義 vs より広範な領域での活躍
PdMに限った話ではないですが、組織の人の数が多くなりますと、役割分担を進めてそれぞれの役割の専門性を高めていく方が全体効率が良くなります（PdMの存在自体、この思想から生まれた職種かと個人的には思っています）。PdMについても例外はなく、メガベンチャーではプロダクト規模も組織も大きいため、個々のPdMは役割分担でプロダクトの中の「特定の領域」「特定の業務」にフォーカスされるケースが多いと思います。
一方で、スタートアップにおいても基本的な役割分担はあるものの、分担では拾いきれない仕事も多く（組織が完全に成熟しておらず、仕組みが不十分な部分もあるという意味も含めて）、より自担当の領域や業務を超えた広範囲での積極的な活躍が求められるケースが多い印象です。
あくまでイメージではありますが、例えば「特定の領域」の例として、メガベンチャーではサービスを多方面で展開するケースが多いと思いますが、共通基盤となるIDログイン機能やデータ分析基盤などは担当が部署ごと異なり、サービスサイドでは外部APIを扱うが如く自担当領域で連携する、というようなことがあるかと思います。部署それぞれにPdMが自領域について担当しており、当然連携などはするものの、基本的には役割分担で自担当領域にフォーカスが当たり前、という傾向で、隣の部署が抱える課題などはあまり聞こえてこないし把握していたとしても静観するケースが多いかなと思います。（ここを乗り越えるPdMは激アツ）
一方でスタートアップではそれらの担当はいるもののすぐ隣におり、システムもそこまで疎結合でない（というより密である）ため、設計や課題対応など他人事ではなく担当以外も一緒に考えていくようなスタイルの方が好まれる傾向と思います。
2. プロジェクトマネジメントのウェイトの違い
プロジェクトマネジメント・プロジェクトリードはPdMの業務の中でも大切な仕事の1つです。「プロダクトを作り、育てる業務」「エンジニアやデザイナー、ビジネス関係者をリードする業務」の中核業務であるからです。
プロジェクトは規模が大きくなればなるほど（=関わる人の数が多くなるほど）難易度が高くなります。当然ながら、メガベンチャーはプロダクト開発規模が大きいケースも多く、またプロジェクトの成功要否がサービス向上や業績（と評価）にも大きく影響するため、PdMがプロジェクトマネジメントに多くの時間を費やしがちになる、と思います。別途、PjM(プロジェクトマネージャー）がいるケースは必ずしもそうではないかと思いますが、PdMによっては仕事の8割9割がプロジェクトマネジメント関連業務、という人もたくさん見てきました（上記1における「特定の業務」にフォーカス、という話の典型例）。とは言え、「優秀なプロダクトマネージャーは例外なく、優秀なプロジェクトマネージャーでもある（出典：『プロダクトマネージャーになりたい人のための本』）」というように、プロジェクトマネジメント力を培うには良い場であるとも言えます。
一方で、スタートアップPdMも、もちろんプロジェクトマネジメントを行いますが、仕事全体における時間のウェイトはメガベンチャーのそれよりずっと少ない印象です。これはプロダクト規模がメガベンチャーと比較すれば大きくないですし、社内ステークホルダーも少ないため、難易度はメガベンチャーと比較すれば高くないケースが多いことに起因すると思います。一方で、スタートアップは常に新たなサービス価値やユーザ体験の向上・実現が急務であるケースも多いため、プロジェクトマネジメント以上に戦略立案やユーザ理解、課題対応の優先順位付けといった業務に時間を費やすことが多い印象です。
3. 整備されたプロセス vs やや人依存のプロセス
メガベンチャーはスタートアップと比較して、組織人数もプロダクト年数も当然ながら多くなります。組織・プロダクト成長の過程で、プロセスの効率化とアウトプットの品質向上を目的としてPdMの業務や開発プロセス、アウトプット・ドキュメントやレポートラインなどが細かく整備され、誰が担当しても同じテンプレートに沿ったプロセス・アウトプットになるようになってます。それは数多の経験・ベストプラクティスから整備されたものであるため、全体最適観点からすれば優れものであることは間違いない一方、特定案件にはそれが非効率なケースであったとしても、場合によっては盲目的にそれをなぞることが必要だったり、スピードが犠牲になるケースも散見されました。
一方で、スタートアップはメガベンチャーと比較して組織もプロダクトも成長過程のものが多く、プロセスやアウトプットの標準化よりも成果優先の考え方で個々人のやり方に依存したりスピード優先の考え方になる傾向があると思います（何より、スタートアップが大きい会社に勝てる1番の要素は「スピード」の部分でもありますしね）。もちろん、スタートアップでも「きちんとプロセスなど整備されている」ところもあると思いますし、標準化・整備にトライしているところも多いと思いますが、メガベンチャーのそれと比較するとその粒度や徹底度合いは異なるのではないかと思います。このような背景からスタートアップは、組織としての成果は良くも悪くもその担当個人の能力度合に強く依存する傾向もあるかと思います。
4. 解決策選択肢の豊富さ vs 承認スピード
PdMとしてプロダクト課題を明確にできれば、その次は解決策を検討することになりますが、選択肢は「新規プロダクト開発」だけでなく、「外部サービスの利用」や「新たなアライアンス」など様々なケースがあると思います。メガベンチャーであればある程度の予算があったり、その知名度から新規アライアンスとのWin-Winが描きやすかったり、というような選択肢も取りやすく、PdMキャリアとしても自分の引き出しをより増やすことができる機会がある印象です。スタートアップでももちろん解決策の選択肢としてそれらは候補にあがりますが、予算制限がよりシビアであったり、アライアンス実現度が高くなかったり、ということがある印象です。
一方で、解決策に限らずですが、戦略立案にせよプロジェクト起案にせよ必ず会社・上長からの承認というプロセスが必要になるケースがあるかと思いますが、スタートアップの場合はこれが非常にスピーディです。理由は単純に必要な承認者の数が少ないためで、スタートアップとは言え組織規模にもよりますが、1名もしくは2名（場合によっては＋経営陣）というケースが多いかなと思います。これがメガベンチャーの場合は承認者の数も3-4倍にもなるケースも多く、あまり内情に詳しくない人にも承認を取る必要があるため、資料準備も膨大になりがちだったり、事前根回しの必要度合いが高まったり、承認を得るにも戦略が必要、みたいな傾向があると思います。
5. 事例共有の豊富さ vs 事例共有のスピード
人員が多ければ多いほど会社としては成功事例・失敗事例というナレッジが蓄積され、それを効果的に共有することによって成功の再現、失敗再発抑止の可能性が高くなります。自組織・自担当領域だけでなく、様々な事例に触れることができるので、自身の経験ではない知識レベルということにはなりますが、PdMの成長の礎となる情報を豊富に貪ることができるのがメガベンチャーの醍醐味かと思います。
一方で、事例を共有するにも、準備とその機会の調整にも時間がかかる印象です。やはり内情に詳しくない人に伝えるため、多くの人に伝えるため、資料の準備も多段階レビューが入る印象ですし、実績が出た数ヶ月後に事例報告、というケースも多々ある印象です。
スタートアップは規模が小さいため、メガベンチャーと比較すれば事例の数としては当然ながら多くはありません。しかし共有文化があればその点はより密に、より詳細に、よりスピーディーにできるというのが強みかと思います。（最近それはあまり生産的な仕事ではないというような記事をお見かけしましたが、他人の貴重な事例の追体験は組織としても個々のキャリアの成長のためにも有益なものであると自分は思ってます）
6. （おまけ）技術負債の大きさ と 全社対応案件
これはメガベンチャーあるある的な話かもしれませんが、メガベンチャーはサービス・プロダクトも成熟期のものが多いため、溜め込んだ技術的負債も大きいケースが多いです。特にセキュリティ面での対応などは早期の対応が求められるため、技術的負債対応・リファクタリング、というのが機能開発を犠牲にしてまでの大きな投資・一大プロジェクトになりがちだったりします。もちろん、プロダクトとしてはとても大事な対応ですので、PdMも（主にプロジェクトリーディングとして）参画するケースが多いのですが、サービスを利用するユーザからはその価値向上は一見わかりづらいものであり、ダイレクトに業績KPIを伸ばすものではないケースも多いので、ユーザやビジネスサイドとの（投資するコストに対しての）理解を得るための調整・接渉など、ややPdMのモチベーションが上がりづらいプロジェクトになりがちです。（繰り返し言いますが、プロダクトとしては非常に大事なことでして、決して軽んじているわけではありません）
また、現場の意思とは関係なく、「全社一律対応」として、プロダクトで利用するツールが変更になったり、仕事のプロセス変更を余儀なくされたりするケースがあります。もちろん、会社としてはより良いサービス向上だったり効率化だったりが目的ではありますが、個別最適目線では100%はそれにつながらないケースもあり、現場PdMもときに困惑するケースを見てきました。
スタートアップでも技術的負債への対応というものは当然ありますが、プロダクトのステージ的にもクリティカルな課題でもない限りはそれに多大なコストをかけるフェーズでもなく、PdMがそれに時間を取られるケースは少ないように思われます。（ただし大局的に見れば技術的負債を蓄積させないようにしていかないと、数年後に大きな投資が必要になるため注意が必要です）
最後に
いかがでしたでしょうか。やや主観にまみれた内容ではありますが、このテーマを知りたいと思った方の一助になれば幸いと思います。
ちなみに当社モノグサはまだまだスタートアップであり、上記のスタートアップの特徴はそのまま当てはまるところが多いのですが、会社全体・PdM組織も拡大しつつあるため、スタートアップの良さは残しつつ、PdMプロセスの標準化や新規ビジネス立案という役割を少し拡大した業務への挑戦など、常にtryを続けるcultureかなと思っております！
そして、こちらが真の本題ではありますが！w
私たちモノグサ株式会社ではPdMを積極的に採用しております。上記の中で興味を持たれた方はぜひご連絡ください。カジュアル面談も大歓迎です！
↓↓↓カジュアル面談の申し込みはこちら↓↓↓
↓↓↓採用情報はこちら↓↓↓