見出し画像

プロダクトマネジメント組織、ゼロから20名までの変遷

adachi

SmartHRのプロダクトマネージャー（以下、PM）組織は、最初のPMが入社してから4年半で20名の規模に成長しました。（正確にはこの原稿を書いているうちに21名になったのですが、キリがいいのでタイトルは20でやらせてください）

20という数字に特に意味はないのですが、すでに過去の記憶がだいぶ曖昧になってきており、このまま忘れてしまうのはちょっと寂しいな、というのと、ちょうど採用コンテンツのネタに困っていたこともあり、この記事を書くことを思い立ちました。

私は1人目のPMが入社した3か月後に入社しているので、PM組織ができてから現在まで、ほぼ全期間を経験していることになります。また、2年目からはPMの責任者としても組織に関わってきました。

この記事では私個人の視点から、私たちの組織が辿ってきた変遷を時系列で紹介していきたいと思います。書き始めた当初はできるだけ客観的なものにしたいと考えていたのですが、わりと早々に諦めました。スタートアップのカオスな4年半を、当事者が客観的に記述することなどできるでしょうか？（反語）

結果的に、本稿はかなり私的な備忘録に近いものになりました。そのような期待値で読んでいただけたら嬉しいです。

それでは、2019年から話を始めましょう。


2019年：ギルド

ARR：10億前後
プロダクト数：3 → 4
社員数：100 → 150名程度
PM組織：5名

PMという職種が一般的になってきた今の感覚からするとやや驚きですが、SmartHRにはこのフェーズまでPMがいませんでした。SmartHRのローンチは2015年11月なので、PM組織ができたのはそこから約3年後となります。
なぜこのタイミングでPMが必要になったのか、詳しい経緯は知らないのですが、2018年の末から2019年の頭にかけて一気に5名のPMが採用され、私はそのうちの5人目でした。

当初の社内におけるPMへの期待値はかなり曖昧で、「複雑な要件定義をやってくれる人」くらいの認識からスタートしたように思います。職種名も「ディレクター」でした。（関係者の名誉のために補足しておくと、当時は多くのスタートアップがそんな感じだったと思います）

私は入社時に「ディレクターグループのあるべき姿の定義」というミッションを渡されていました。まずは職種名を「プロダクトマネージャー」に改名するところから始め、

  • PRD（プロダクト要求仕様書）のフォーマット整備

  • 既存仕様の調査とドキュメント化

  • 同時期に立ち上がったPMMとの棲み分け整理

  • 採用計画やフローの整備

といった最低限の仕組みを作っていきました。これらはマネージャーの仕事のように見えると思いますが、当時のPM組織には専任の管理職がおらず、全員がCTOの直下に置かれていました。私の立ち位置も完全にプレイヤーで、いちPMとしてプロダクトを担当しつつ、余力で組織的な整備も担当していた形です。

ところでこの記事を書いていて気付いてしまったのですが、この時点では前述した自分のミッション「グループのあるべき姿の定義」はまったくやっていないんですよね。全然ミッション達成してない。評価のときに突っ込まれた記憶もなく、全体的にゆるめで牧歌的な時代でした。

プロダクト開発のやり方もまだ未整備で荒っぽい部分が多く、非常に影響範囲の大きな機能2つと新規プロダクトをすべて同時にリリースした結果、深刻なトラブルが頻発し、のちに「ビッグバンリリース」として語り継がれる事件が起きたりしていました。

この頃はPM間の連携も少なめで、個人事業主の集まりみたいな雰囲気でした。自分はマネージャーでもないのに後から入ってあれこれ決めちゃって大丈夫なんだろうか、といつも不安に思っていたのを覚えています。

2020年：組織化

ARR：20億前後
プロダクト数：4 → 6
社員数：150 → 300名程度
PM組織：5 → 8名

2年目は、個人の集まりだったPMチームが徐々に組織化していった年でした。

まずは私がPMのチーフ（プレイングマネージャーのポジションです）になり、数ヶ月後にVPに任命され、続いて後任のチーフも置かれました。これにより、PMチーム内でVP - チーフ - メンバーというレポートラインが作られ、組織としての形が整っていきました。LeSS（大規模スクラム）を導入したのもこの年からで、ひとつのプロダクトになんとなく複数のPMがいるという状態から、よりお互いの役割分担が明確になっていきました。

このときの私はマネジメント経験がほぼない状態で、まったく自信がありませんでした。どうしたら自分がボトルネックにならないか考えた結果、とにかく優秀な人を採用して成長してもらおう、という他力本願な結論に至ります。これが採用広報への注力と、極端なまでの権限委譲というスタイルにつながりました。PMは裁量がなければ成長できない、というのは私自身のプレイヤーとしての経験則でもありました。

この年は新たに3名のPMが入社しています。1年目は全員がほぼ同時期に一斉スタートしたこともあり「誰もわからないからそれぞれがんばろ」みたいな雰囲気だったのですが、2年目に入ると「新しい人に教える」というわかりやすい協働の機会が生まれ、1 on 1 やPRDレビューなどを通じた壁打ちが増えてきました。

ただ、この時点では知っている人が教えるという一方通行の連携がほとんどで、各自が学びを持ち寄ってお互いに教え合うといったレベルのことはできていなかったし、まだその必要性も感じていませんでした。

コロナ禍により開発チーム全体がフルリモートになったのもこの年からです。もともとSmartHRはオフラインのコミュニケーションをとても重視する会社だったのですが、やってみたら意外とすんなりリモートワークに適応できてしまい、組織面での影響はあまりなかったと記憶しています。

事業的な観点では、この年の後半にタレントマネジメント領域の新規プロダクトがリリースされ、この領域に積極投資していくぞという流れが作られ始めた時期でした。一方、祖業である労務領域では競合が次々に参入し、競争が激化してきたのもこの頃からです。またエンタープライズ企業の攻略が進んだ結果として、機能不足による失注も増え、開発チームへの要望の温度感がだんだんと高くなっていきました。

当時はあまり意識していませんでしたが、このような事業環境の変化が、PM組織の翌年の方向性にも大きな影響を与えました。

2021年：再定義

ARR：50億前後
プロダクト数：6 → 8
社員数：300 → 500名程度
PM組織：8 → 11名

前年に起きたことは要するに、自社の領域に入ってくる他社と戦いつつ、既に他社がいる別の領域に突っ込んでいくというのを同時にやり始めたということです。

結果としてなにが起きたかというと、プロダクトへの要望が爆発しました。PMは要望の優先順位付けに追われるようになり、とにかく要望の多い順に作って出すという状態になっていきました。こういう状態をフィーチャーファクトリーと呼ぶらしいのですが、まさに開発チームが言われた機能を作るだけの工場になりつつあるのでは？という危機感がありました。

そこで年初に「WhatだけでなくWhyを語れるPMへ」という方針を掲げ、アウトプット志向からアウトカム志向への転換を呼びかけました。PMはプロダクトの目指す姿と戦略を考え、「なぜ今これを作るのか」に責任を持たなくてはならない、ということが、このとき初めて明文化されました。そう、私が1年目にミッションとして与えられながら完全にスルーしていた「あるべき姿の定義」が、ここでようやく果たされたのです。（これもこの記事を書いていて気付きました）

なお、このあたりの流れは国内でプロダクトマネジメントという概念が普及し、書籍などの情報源が増え、業界全体での理解が進んだことにも大きく影響を受けています。上記のようなPMの責務は、今から見ればすごく当たり前に見えると思いますが、当時はわざわざそれを言う意味が少なからずあったのです。

ただ、「Whyに責任を持つ」というのは理念としてはわかりやすいものの、現場での具体的なアクションには落としにくく、すぐにPMの仕事のやり方が劇的に変わったわけではありませんでした。

当時の私はまだプレイヤーとして担当プロダクトを持っていたので、ロードマップの作り方を工夫してみたり、OKRを導入してチームの目線を揃えたりなど、いろいろと実験をしながらうまいやり方を模索していました。

この年、事業面ではタレントマネジメント領域でさらに2つのプロダクトを投入するなど、マルチプロダクト化が加速していきました。プロダクトが増えるということは、個々のPMが全体最適な判断をすることがより難しくなるということでもあります。

ここまでのPM組織はメンバーの自律性を重んじ、良く言えば個人の裁量が大きい、悪く言えば丸投げのスタイルを取ってきていました。しかし事業が急成長し、PMの仕事の難易度もどんどん上がるなか、もっと組織的な支援が必要だと感じるようになりました。

2022年：学び合い

ARR：80億前後
プロダクト数：8 → 10
社員数：500 → 700名程度
PM組織：11 → 17名

どうやって事業の成長に個人の成長を追いつかせていくか、というのが前年が終わった時点での私の問題意識であり、そこから出てきたのが「学び合い」というコンセプトでした。

急成長するマルチプロダクトSaaSのPMをやったことのある人は私も含めて社内にいないし、おそらく社外にもそんなにいない。ならば現場のメンバーがそれぞれ実験しながら、学んだことを共有してみんなで成長していくしかない、という考えだったのですが、この試みは当初あまりうまくいきませんでした。

定期的に社内で座談会的なものをやってはみたものの、具体的になにを共有すればいいかのイメージがつきにくく、すぐにネタ切れになって参加者の温度感も下がっていきました。本来はもっと業務の相談をメンバー同士でやってほしかったのですが、そもそも気軽に相談できる関係性が作れていないことに気がつき、途中で「学び」から「チームビルディング」に方向転換をしました。

それまでの私は「仕事の信頼関係は仕事のなかでしか作られない」という考えで、飲み会などもあまり積極的にやってきていませんでした。しかし上記の学び合いがうまくいかなかったことに加えて、新しく入ってくるPMたちが一様にチームに馴染むのに苦戦しているのを目にするなかで、考えを改めました。心理的安全性、大事。マネージャー3年目にして初めてチームビルディングの必要性に気付いたという、大変恥ずかしい話です。

学び合いの試行錯誤と並行して、この年はPMの仕事の標準化が少しずつ進んでいきました。前年に私がプレイヤーとしていろいろ実験していたことは先に述べましたが、ここでうまくいった「型」が徐々に他のPMに使われるようになっていきました。具体的には

といった道具立てが社内に浸透し始めたのがこの時期です。そして狙ったわけではないのですが、このような標準化は「学び合い」に大きく貢献しました。共通言語ができたことで、PM間での相談や共有が少しずつ増えていったのです。個人的にフレームワークとかベストプラクティスみたいなものはあまり信用していなかったのですが、型があると知識の移転が起こりやすくなるというのは学びでした。

また、この年は組織構造にも大きな変化がありました。ここまでは労務領域のみがユニットとして独立し、それ以外のPMは私の直下に置かれていたのですが、新たにタレントマネジメント領域がユニット化し、チーフが置かれました。次にCEO直下にあったドメインエキスパートのチームがPMグループへ移管となり、PMグループ全体で3ユニット17名の体制となりました。

さすがにこの規模で私がプレイヤーをやり続けるのは良くないと思い始め、この年の夏頃にすべての現場業務を手放し、マネジメントに専念することになりました。結果として一時的にすごく暇になってしまい、なにかやりたいなと思って動かし始めたのが「プロダクト基盤」です。

マルチプロダクト化が進むと、プロダクト間の連携を司る機能や、複数プロダクトから利用される共通機能といった基盤の部分が重要になってきます。実はこの年の始め頃から、この領域の技術検証をじわじわと進めてはいたのですが、会社として十分な投資はできていませんでした。

暇になって頭がスッキリした私は、どう考えても今すぐここに注力しないとマズいと思い立ち、いろいろと動き回りました。結果、翌年からプロダクト基盤を作るチームが組成されることになり、これが翌年のPM組織に少なからず影響を与えることになります。

2023年：深い連携

ARR：100億前後
プロダクト数：10 → 13
社員数：700 → 900名程度
PM組織：17 → 21名
※ 8月時点

前年に「学び合うぞ〜！」と宣言したものの、短期的にあまり成果が出なかったのは前述のとおりですが、この年に入ってからは急にPM同士の連携が加速しました。一時は各自が淡々と報告をするだけの場になっていたPMの週次定例も、目に見えて議論や相談が活発になっていきました。

要因はあまり分析できていないのですが、前述した仕事の標準化の動きに加えて

  • プロダクト基盤など横断的な動きをするチームが増えた

  • タレマネ領域のプロダクトが増え、相互連携するフェーズに入った

  • OKRが浸透し、アライメントのためのコミュニケーションが増えた

  • 前年に引き続き、横連携をPM組織の方針に掲げて言い続けた

  • 地道なチームビルディングの効果が出始めた

といったことが積み重なり、大きな流れを作っていったように思います。連携の中身や質にも変化があり、単なる情報交換には留まらず、普通に業務で必要だから協働するという場面が一気に増えていきました。

また全社的にもマルチプロダクトをやっていくぞ！という方針が打ち出され、今まで点として作っていた個々のプロダクトを線で繋げていく動きが本格化してきています。このあたりは事業上の要請に組織の成長がうまく噛み合ったというか、ギリギリ間に合ったということなのかもしれません。現場のPMの動きを見ていても、他のPMと連携せずに完結する仕事はどんどん減ってきています。

一方、マルチプロダクト化が進んだことでPMのオペレーション面での課題が大きくなってきており、対策のひとつとして4月にProduct Opsというチームを作りました。このチームでは全社的なロードマップ運用やリソース配分の仕組みを整備したり、要望管理の方法をプロダクト横断で見直すなどの取り組みを始めています。このあたりはまだ本当に手探りという感じなのですが、また別の機会に詳しく紹介したいなと思っています。

まとめ

だいぶ長くなってしまいました。冒頭でもお伝えした通り、以上はあくまで私から見えていた景色であり、私たちのPM組織が経験した4年半のごく一部でしかありません。組織の歴史というのは、関わった人の数だけあるのだと思います。

なにが言いたいかというと、私たちの組織は、ここでは語り切れなかったメンバーひとりひとりの努力や熱意、創意工夫、勇気、少しの遊び心などによって作られてきたということです。また、そこにはSmartHRという会社の稀有なカルチャーと、他部署からの理解や支援も不可欠でした。その点は、最後に強調しておきたいと思います。

私たちはまだ何かを達成したわけではないし、模範になるような事例でもないと思います。むしろ未完成で、行き当たりばったりで、なんとか無理やりやってきた様子が伝わったら嬉しいなと思います。

まだまだPM募集中です

この4年半でいろんなことが変わりました。大変だけど飽きなくて楽しいなというのが、いち関係者としての率直な感想です。私たちは今後も、人事労務に限らずさまざまな領域でプロダクトを提供していく予定で、既存のプロダクトも更に成長させていきたいと考えています。

大きくなることを恐れない、変化が好きなPMがもっと必要です。気になった方はぜひお話しましょう。

補足：PMの人数と採用計画について

プロダクト数とPMの人数の比率について気になった方がいるかもしれないので、少し補足です。

2023年8月時点でプロダクト数が13、PM組織の人数が21名となっており、1プロダクトあたりの人数が結構多いな？という印象を持たれたかもしれません。内訳を書くと

  • 本体プロダクト：スクラムチーム8に対してPM 7名

  • その他のプロダクト：スクラムチーム12に対してPM 11名

  • ドメインエキスパート：3名

となっており、実はスクラムチームの数よりもPMの人数が少ないのです。まだリリースしていない複数の開発中プロダクトは上記に含めていないので、実際の差はさらに大きいです。足りない部分は兼務で補っている状況ですが、今後はできるだけ解消していきたいと考えています。

採用計画については「プロダクトもしくはスクラムチームが増えるタイミングでPMを増やす」という素朴な考え方で作っていますが、だいたいは急に新規プロダクトが動き出して慌てて採用に動き、間に合わなければ兼務をお願いするという、スタートアップ味あふれる運用となっています。現状はアソシエイトという概念がないのでPMの人数バッファを持っておくことが難しく、このあたりも今後の課題に感じています。


いいなと思ったら応援しよう！