ナレッジや経験則がシェアされ、全体として常に成長志向が止まらないのは、スタートアップの良いところでもあります。一方で、それらの学びから「こんな人材が欲しい」と思ったとしても、その職種の定義や必要なスキル、活躍できる人材の共通点などが曖昧なまま、ということもよく目にします。
その職種の一つが、近年はスタートアップでも採用ニーズが急速に高まっているPdM（プロダクトマネージャー）ではないでしょうか。特にSaaS企業においては、初期フェーズからPdMの採用を進める重要性が説かれています。
PdMへの理解を深めていくべく、株式会社SmartHRでVP of Productとして活躍している安達隆さんに、SmartHRでの挑戦や日々の学びからの考えをお話しいただきました。
安達さんは「企画職として作るものを決める立場にいたい」と考え、新卒で入社した会社では受託開発のディレクターを4年経験。PdMとしての転機は、その後に友人たちと起業したことでした。セールスが得意なCEO、コードが書けるCTOがメンバーにいたことで、安達さんは要件定義など「PdM的な動き方」を担うことに。世間一般でもPdMが認知されるにつれ、自らの職域を意識するようになったといいます。
そして、成長したSaaS事業を会社と共に売却した後、メルカリへ。PdMとして1年勤め、現在はSmartHRに転職し、VP of Productとしてプロダクトマネジメントの責任者に就いています。
「SmartHRで実践するPdMの組織づくりの工夫」や「PdMとして成すべき目標設計」といった実践論から、「PdMとして活躍しやすい人材の共通点」や「選ぶべき会社の要素」などの求職者目線での考え方に至るまで、ALL STAR SAAS FUNDのManaging Partner・前田ヒロが“PdMの仕事”について伺いました。
「まだPdMを採用すべきでない」スタートアップとは
前田：SmartHRに入社された時期と、その当時の社員数はどれくらいでした？
安達：2019年4月です。社員番号が115番でしたから、規模としては100人前後ですね。
前田：SmartHR内にはPdMという職種はもうあったのですか？
安達：ちょうど入社の3カ月ほど前に定められ、僕が5人目のPdMでした。SmartHRは長いことPdMが不在だったようです。厳密に言うと、それまでも「PdM」の肩書きを持つ方はいたのですが、人事・労務に詳しい方がプロダクトオーナーとして実体験や知識から提案をして、それをもとにエンジニアが作っていくような体制がずっと続いていて。
ただ、社員数が100人を超えるくらいのタイミングで、専門的に要件定義をできる人を交えないと今後の開発が難しくなっていくだろうと見越して、PdMの採用に至ったと聞いています。
前田：もし、スタートアップ経営者から「どのタイミングでPdMを入れるべきか」と相談されたら？
安達：僕がPdMだからというのもありますが、「創業者＝PdM」でなければ、最初から居てもよいくらいだとは思いますね。SmartHRの場合は、創業者の宮田昇始さんがもともとシステムを企画する人でプロダクトを見ていましたが、僕が入社した時点で、すでに宮田さんは経営者の仕事に注力していて、プロダクトにほぼ口を出さない状態だったんです。
そういうふうに現場へ権限移譲できる状態が作れていると、PdMとしても動きやすいだろうとは思います。逆に、創業者や社長がプロダクトにしっかり口を出したい環境下でPdMを入れてしまうと、PdMが社内受託案件のプロジェクトマネジャーみたいになってしまうと思うので、お互いに不幸な図になりやすいのではと危惧しますね。
前田：プロダクトのビジョン設計はPdMがやるべきなのか、それとも別のところでなされるべきなのか。それでいうと、安達さんはどちらのお考えですか。
安達：ケース・バイ・ケースです。ワンプロダクトかつプロダクト中心の経営ができている会社なら、ほぼコーポレートミッションに近いので、PdMより上位のレイヤーで決めるべきでしょう。SmartHRのようにプロダクトが分かれているなら、個別プロダクトのビジョンはPdMがリードしつつ、ステークホルダーを巻き込んで決めるのがいいかなと思います。
PdMは「何を作るか／なぜ作るか」、PMMは「何が売れるか／どう売るか」
前田：SmartHRのケースでは、プロダクトマネジャーとしての仕事のスコープは、どのあたりまでの範囲になってくるのでしょう？
安達：製品ロードマップの決定、開発するアイテムの起案と優先順位決め、ユーザーや顧客に一次情報を取りにいくインタビュー、スクラムにPOとして加わって開発チームのファシリテーション……といったところが、PdMの主な仕事です。
現在SmartHRにはPdMが10名ほど在籍していて、PdM一名あたりプロダクトを一つ担当するといった分け方が基本です。ただ、「本体」と呼ばれる最も大きなプロダクトだけは、規模が大きいのでPdMが5名付いています。
前田：やはりスコープの範囲も会社によって異なりますか？
安達：そうですね。採用活動で他社のPdMと話をしてみると、その違いを実感します。
多いのは事業責任者がほぼPdMになっているケース。プロダクトマネジメントに加えて、予実などの数字を見ている会社も結構ありますね。あとは顧客からの問い合わせ対応といったサポート業務、ビジネスサイドへのセールスアイテムの提供、新機能の社内説明など、SmartHRではPMM（プロダクトマーケティングマネージャー）が担うような業務をPdMが受け持っていることもよくあると聞きます。
その点では、SmartHRは国内では比較的PdMの仕事の範囲が狭いほうなのでしょう。
前田：PMMとの役割分担は、どのように決めているのですか？
安達：ざっくり言うと、<yellow-highlight-half-bold>「何を作るか／なぜ作るか」はPdMの領域で、「何が売れるか／どう売るか」はPMM<yellow-highlight-half-bold>ですね。
あとは、プロダクトごとにPdMとPMMが1名ずつアサインされるのが通常なので、お互いに得意分野やプロダクトの周辺状況などを話し合い、それを踏まえながら柔軟に役割分担してもらうスタンスで進めています。
前田：何かしらの決め事や目線合わせをしているからこそ、意見が割れにくいという効果もあるのでしょうか。
安達：むしろ決め事がないからこそうまくいってるのかもしれない、と今問われて思いました。PdMとPMMでやるべき範囲に厳密な線を引かなかったり、双方のやり取りに「あるべき」フレームワークもなかったりと、とにかく「PdMとPMMで協力してプロダクトを成功させてほしい」としか僕からは伝えていないです。
そこで、いかに協力すべきかを、それぞれの文脈で考えて行動しているからコンフリクトが起きないのかもしれないですね。
PdMの目標は「NSM」や「状態目標」で考える
前田：PdMは目標設定に難しさを感じます。目標設計の仕方や重視しているポイントはありますか？
安達：できるだけ、自分でコントロール可能なものを目標に置くようにしています。
SaaSの場合、売り上げを目標に置いてしまうと、セールスやマーケ、CSといった複合的な要因で作られていく数字なので、達成してもしなくてもPdMとしてのフィードバックが得にくいんですよね。
そうではなく、プロダクトでは「NSM（North Star Metric）」のような指標を設定し、いかに近づけるのかを考えます。定量化が難しいプロダクトであれば、「いつまでに、お客さまが、こういう状態になっている」といった“状態目標”を設定し、そこに対しての達成度を測るやり方をすることが多いです。
前田：“状態目標”は、プロダクトの利用率やログイン率といった値で測るのでしょうか？
安達：そうですね。まずは、プロダクトとしての「理想のあるべき姿」を擦り合わせます。そして、それが実現している状態を定量的に考えた際の数値設定、あるいはお客さまが得ているはずの便益といったアウトカムから逆算していく、と言いますか。
前田：目標設定で失敗しがちなこと、言わば「よくある落とし穴」って、あったりします？
安達：先ほど挙げた「達成や未達から学びが得られない目標設定」は、やはり失敗ですね。評価する側の立場としても、その結果は最終的には給与にもつながってきますから、評価のしやすさや被評価者の納得感にも関係してきます。
本来、評価を行う目的からすると、「そこから学びを得て、本人が成長できるか」であったり、「組織としてもラーニングが得られるか」であったりが、僕は大事だと考えています。だからこそ、数字の上下からデジタルに評価が決まるだけで、学びが得られないような目標は避けるべきなんですね。
チームメンバーに反論されると、僕は嬉しい
前田：安達さんが「PdMに求めるもの」を挙げるなら？スキルなのか、メンタリティーなのか……。
安達：いやぁ、いっぱいありますね（笑）。
パッと思いついたものですと「思考の独立性」は欲しい。言い換えると、できるだけバイアスを排除して考えられる力です。目の前にある事象や、直近で誰かに言われたこと、会社の方針、僕からのリクエストといったものに影響を受けがちなのは、人間であれば仕方のないことです。
その上で、本当に難しい思考でありますが、そもそも自分がどうするべきか、このプロダクトはどうしていくべきか、会社から求められたことは本当に正しいのか、といったフラットな立場で考えてほしいのです。
前田：社内の声や会社の方針ではなく、「プロダクトとして」本当に正しいかどうかを確かめ、考え抜けることを期待していると。
安達：そうそう。なので、反論されると僕はうれしいですね。「安達さん、言ってることが違うと思います」なんて言われると、「おお！詳しく聞かせて」みたいな感じで（笑）。
前田：いいですね（笑）。他にも何かしら「PdMに期待すること」はありますか？
安達：チームについて真剣に向き合ってほしいのは常に伝えているし、期待していることでもあります。プロダクト作りって、当たり前ですけれどチーム戦なんですよね。PdMだけがしゃかりきになってもうまくいかないんです。
PdMがうまくチームのポテンシャルを引き出せることを期待しているし、PdMは「プロダクトのリーダー」であってほしいとも思っています。もちろんレポートライン上はPdMには何の権限もありませんから、エンジニアにPdMが指示することはできません。組織上、あくまでもフラットな立場で開発チームは存在していますから。
フラットな立場で、きちんと理屈と感情を使いこなして、チームを一つの方向にまとめて引っ張っていくことがPdMには求められます。さまざまな人間が集まる以上、チームには課題も出てくるので、そこへいかに向き合うか。1on1でもよく出る話題ですね。
前田：「感情」について、感情の伝え方やコミュニケーションの仕方は、どうするのが望ましいですか。
安達：「感情の話をちゃんとするスタンス」が重要だ、と最近は思っていて。大人が集まっているチームだと、つい理屈の話だけを続けてしまうというか……仕事の場で自分の感情について語るのはよくないことなんじゃないか、と考えがちな気がして。
「社会人として正しい振る舞いをしなくてはいけない」みたいな無言のプレッシャーもあるとは思うんですけれども、そうではなく、たとえば「嫌な仕事は嫌だと一旦言ってみよう」と。その「嫌だ」と思う気持ちと理由を、まずは言語化してみましょうと。
あるいは「やりたいこと」なら、まずは「やりたい」と言ってみて、やるかやらないか、いかに実行するかはみんなで話し合って決めればいい。他にも「こんなことを言われて悲しかった、腹が立った」というのも一旦は言ってみるのが大事なのかな、と。
そうすることで、常にガス抜きされた状態になれます。見えないところでのストレスが溜まりにくいですし、チームメンバーがきちんと自分の感情に向き合った上で、全体の方向性を一つにそろえていけると思っています。
目の前の小さな課題解決は、時に失策である
前田：安達さんはこれまで「壁にぶつかったとき」に、どういったアクションを取ってきましたか。常にやりながら模索するのか、何かを調べてから進むのか。
安達：複雑な業務用システムの要件定義を初めて担当したときに、それまでのやり方で全くうまくいかなかったことがあります。ユーザーインタビューをして、いきなりワイヤーフレームを書き始めるといったやり方では、「手持ちの道具や武器がどうも足りない」と感じて。
そこで、世の中で複雑なシステムを作っている人たちは、どのように取り組むのかを知ろうと考えました。浮かんだのは、金融系システムを作るSIerです。まずは参考書で勉強してみると、きっちりとしたウォーターフォールな手法で、そのままスタートアップで実践するわけにはいかないけれども、エッセンスは参考になりますし、吸収できる部分もありました。
要件定義の進め方、開発者と認識をそろえるためのドキュメントの書き方、抜け漏れがなくなるコミュニケーション方法といったことを学んで、それを実地で試してきましたね。
前田：過去にした「大きな失敗」はありますか。
安達：失敗はいっぱいしていまして……しかも、コンテキストに依存している問題が多いので、皆さんに「参考になる失敗例」を切り出すのが難しいんですよね。
ただ、最近になって一つ抽象化できたのが、<yellow-highlight-half-bold>「小さな課題を解決してしまうこと」<yellow-highlight-half-bold>です。ある程度のユーザーがついてたり、PMFをしていたりするプロダクトでは、とても多くの要望が寄せられます。その中には、すぐに解決までの道筋を想像できるものもあります。それに飛びついて解決すると、確かにお客さまは喜んでくれる。一方で、本当に解決しなければいけない、どう解決すればいいかわからないような問題が放置されてしまうんです。
このミスは陥りやすいですし、陥っているときにも気づきにくいものです。僕自身、最近も反省しましたね。これを防ぐためにも、OKRをしっかり運用しようとしていて。
「なぜOKRか」に飛躍を感じる方もいるかと思いますが、プロダクトとして優先すべきことや実現したいことを言語化し、チームで認識をそろえ、進捗を振り返ることで、目先の課題解決を避ける効果があるのではないか、と。
「本当に行きたいところはここだ」と常に確認し続けるためのフォーマットはないかと考えるとOKRだったわけです。当然OKRのことは知っていたし、運用してもいたはずなのに、きちんと活用できていないことがわかったんです。失敗して初めてOKRの良さに気づいたところもあり、他のチームにも目標設定の仕方を含めて、頑張って広めようとしています。
PdMの能力は「会話」に表れる
前田：PdMの採用についても聞かせてください。気をつけて見ている点は？
安達：一番はカルチャーマッチングです。SmartHRは「チームで成果を出すこと」を大事にしている会社なので、うまくみんなを巻き込みながら進めていくことに喜びを感じるタイプのほうが向いていると考えています。
前田：インタビューや面接で、安達さんがよく使う「好きな質問」はありますか？
安達：実は質問表みたいなのは作っていなくて、毎回アドリブで面接するんです。ただ、「ファクトの深堀り」は必ずします。まずは、過去の仕事における意思決定と、そこでの行動という事実を聞きます。そして、「それはなぜですか」と裏側にあるその人のカルチャーを見ていく。そのために、いろいろな角度から、いろいろな質問をしますね。
前田：見極める際には、ワークサンプルの提出も用いますか？
安達：ワークサンプルは、あるにはありますが、あまり出していません。というのも、PdMのワークサンプルはすごく難しいと思っていて。やろうとすると、候補者に大きな負荷がかかってしまうんですよね。
僕らも正解を持っていなくて苦労しているところなのですが、やはり会話をしながら見極めていく感じです。「筋道を立てた会話ができるか」と「PdMとして成果が出せるか」には相関関係が結構あるので、それをPdMの能力として捉えて、メインに見ていますね。
前田：もし、PdMとして多くの企業で活躍できる人に共通するスキルを、ブレイクダウンするとしたら？
安達：身も蓋もないことを言うと、地頭の良さが最も大事なんです（笑）。ただ、それも定義がなかなか難しいので一旦置くと、一つはコミュニケーション能力。どの会社でもPdMが一人でプロダクトを作ることはあり得ません。人をうまく巻き込む、動かす、交渉する、ファシリテーションするといった技術は、PdMとしてのポータブルスキルといえます。
あとは、データやファクトに基づいて仮説を導き出し、実際に検証するという一連の仮説検証を回せること。これは慣れの問題もあるのですが、やはり必要なスキルですね。
「PdMが働きやすい環境」の絶対条件
前田：今のお話を踏まえると、ポテンシャル採用もされているのですか。
安達：明確にポテンシャル採用と即戦力に分けているわけではないのですが、「現状ではうちのPdMと同じような業務経験はないけれども、過去の経歴を含めて、おそらくうまくいくだろう」というオファーを出すことはあります。
前田：そういう方々は、どういった経歴や経験を積まれていることが多いですか？
安達：いくつかのパターンがあります。一つは、完全なPdMとはいえないけれども、ほぼ自社プロダクトに近いような作り方をしていた方。受託開発メインの会社で働かれていたような経験ですね。
あとは、例えばC向けのような全く畑の違うプロダクトのPdMを経験していた方も、向き不向きが分かれるところですけれども、オファーを出しやすい。逆に、全く別の職種や未経験者を採用したことは未だないです。
前田：これからPdMを目指していきたい方もいるとは思うので、安達さんから見て、コンバートしやすい職種やポジションがあれば聞いてみたいです。
安達：エンジニアやデザイナーは親和性が高いのではないでしょうか。スクラム開発に慣れていたり、PdMの近くで仕事をしていたりする方たちなので、使い回せるスキルや知識も多いはずですから。
前田：求職者目線で「PdMが働きやすい環境」は、どういうふうに見定めるべきですか？
安達：「PdMに与えられている裁量の大きさ」は絶対に必要です。最終決定権者は別にいて、現場のPdMが調整役でしかない企業もまだまだありますが、やはり活躍しにくい環境だとは思いますね。PdMは意思決定する仕事と捉えているので、その機会を奪われてしまうと、かなり厳しい。
あとは、身も蓋もないことですが、伸びている業界に身を置いたほうがPdMとしてもいろいろな経験ができるので楽しいでしょうし、成長もできるはずです。むしろ、一人の転職者として考えるならば、そこが最も大切かもしれません。今伸びている、あるいは今後伸びることに賭けられる業界や会社に進むのはマストかなと。
前田：それは間違いないですね。「伸びている＝機会が多い」といえますから。新たなプロダクトやニーズで、新たな需要を捉えにいくといったチャンスも増えるでしょう。今日はPdMの仕事について一段理解が深まりました。ありがとうございます！
