昨今、プロダクトマネージャー（以下、PdM）の重要性が認知され、多くの会社が採用強化や組織づくりに取り組んでいます。

しかし、PdM組織の現状や、今後直面する課題について語られることは少なく、知見も多くありません。

今回のオンラインイベントにはユニコーン企業であるMoT(Mobility Technologies)とSmartHRのプロダクト責任者が登壇。お互いにPdM組織の現状を明かしながら、今後の業界全体の展望を探った様子をレポートします。

PdMは「要件定義をして終わり」ではない

ーまず、それぞれのプロダクトマネジメント体制について教えてください。

安達：SmartHRのプロダクトは「SmartHR本体」と複数の「プラスアプリ」で構成されています。まず本体がかなり大きなプロダクトで、LeSSという大規模スクラムのフレームワークで開発しています。本体の開発チームは5チームに分かれており、PdMも5名。その中のひとりがプロダクトオーナー（以下、PO）です。

プラスアプリはそれぞれ1つのチームで開発しているので、PdMも1名ずつ。POの役割も担っています。

黒澤：MoTにもタクシーアプリ「GO」以外に複数のプロダクトがあるので、それぞれにPdMがアサインされています。また、「GO」ひとつをとっても、ユーザー向けアプリ、タクシー乗務員向けアプリ、後部座席タブレットなど、同じく複数のプロダクトが存在するため、プロダクトや開発プロジェクトに応じて複数のPdMをアサインしています。SmartHRではPdM以外にプロダクトマーケティングマネージャー（以下、PMM）もアサインされていると聞きました。

安達：そうですね。PMMにビジネスサイドとの橋渡し役を任せて、PdMの業務を開発に集中させることが狙いです。PdMを“なんでも屋さん”にしないために。そのあたりの考え方は、MoTと似ているところかもしれません。

黒澤：お聞きしていると、MoTと非常に似ていますね。MoTでもサービスマネージャー（以下、SM）というポジションがあり、事業計画の達成に向けて必要な分析や、開発を要さず実施できるさまざまな施策を担ってくれています。

立ち上げ間もない事業であれば、その辺りをまるっと見るフェーズもありますが、「GO」のようにプロダクトマーケットフィットして、ユーザーが爆発的に増加していくフェーズになると、機能を正しく訴求したり、マーケティングも含めたユーザーコミュニケーションや、価格調整なども含めた丁寧な事業オペレーションが必要になってきます。

一方で、PdMの仕事に目を向けてみると、要件定義をして終わりではなく、開発がスタートしてからも予期しない問題やコンフリクトの解決にあたらなければいけません。さらに並行して、新機能の要件定義や、リリース後に生じるシステムやプロダクトのさまざまな課題解消にもあたる必要があります。

そのため、MoTではSMというポストを用意して、PdMと二人三脚でプロダクト開発を進めています。

安達：グローバルでは、私たちのような体制のテックカンパニーが多いように思います。PdMはあくまでもプロダクトに向き合う立場で、PMMのようなポジションもあって、それぞれが専門性を発揮してプロダクトを開発するやり方がスタンダードになってきています。

黒澤：事業やプロダクトの新規立ち上げフェーズでは、また違ったアプローチもありますが、特にマーケットにフィットし始めたプロダクトをしっかり成長させていくフェーズでは、各々の専門性を高めて取り組むアプローチは非常に重要になってくると思います。

安達：そうなんですよね。プロダクトをスケールさせるためには分業をしていかないと、PdMがボトルネックになってしまう可能性もあると思っています。

黒澤：エンジニアとの関係性においても一緒ですよね。以前は僕自身がPdMとエンジニアリングマネージャーを兼務していたのですが、分業化が進むことで、いつしかエンジニアメンバーのアーキテクトに対する考え方やスキルがどんどんレベルアップしていって、気づいた頃には下手に口を出せないところまで達していました（笑）。

より質の高いプロダクトを提供していくためには、スペシャリティに応じた分業化が進むことは自然な流れだと感じています。

MoTとSmartHRにおけるプロダクトマネジメントの違い

ー逆に違いだと感じるのはどのあたりでしょうか？

安達：SmartHRの場合はプロダクトごとの裁量で開発を進められるようになっているのですが、MoTの構成を見ると新機能のリリースの際にもかなり密に連携をとっている印象を受けます。そのあたりのリリースマネジメントはどうしていますか？

黒澤：そうですね。MoTでは常に多くのプロダクト開発が同時進行で進んでいます。プロジェクト単位でマネジメントしていると「うちのチームはこの案件があるので、半年先まで手がつけられません」みたいなことが頻繁に起きてしまい、ドラスティックな打ち手が打ちにくくなってしまうため、全体のリソースやスケジュールを横軸でマネジメントできるプロジェクトマネージャー（以下、PjM）の存在が非常に重要です。複数のプロダクトを横断して一貫したユーザー体験を設計し提供するためにも、横軸でプロジェクトマネジメントするスペシャリストをアサインしています。

安達：なるほど。SmartHRにはPjMはいないので、その点が両社の大きな違いかもしれませんね。

ーSmartHRではどのようなところに難しさを感じていますか？

安達：プロダクトごとに独立して開発を進められるが故に、部分最適になりがちなところはあるかもしれません。人事労務の仕事はすべてつながっているので、プロダクトを分けるポイントが非常に難しい。

プロダクトの切れ目については総合的な判断が求められるので、ステークホルダーと議論しながらいろいろと試しているところです。開発スピードとユーザー体験を両立させるためのバランスを探っています。リリースして初めてわかることもあるので、実験を繰り返しながら線引きを決めている感覚ですね。

黒澤：私自身も過去に経験があるので、すごく難しいポイントだと感じています。単純に「PjMをアサインすればOK」という話ではなく、PdM一人ひとりが連携への意識を高めていく必要性が出てきますよね。

安達：おっしゃる通りです。最近は「横連携、横連携」と言い続けているので少しずつ意識が変わってきている感覚はあるのですが、まだまだ課題もたくさんありますね。

PdMがプロダクトと向き合える意義

ー続いては、PdMとしてのチャレンジややり甲斐について教えてください。

安達：プロダクトマネジメントに集中できることですね。受動的な働き方をしていると、ユーザー対応やビジネスサイドとのコミュニケーションで1日が終わってしまうこともありますが、分業体制だからこそ目の前のプロダクトと向き合えている手応えはあります。

またSmartHRは日本の全企業がユーザーになりうる事業を展開しているので、社会に与えられるインパクトも大きいし、「自分の仕事が社会の役に立っているのか自信が持てない」ということもありません。採用面接でも志望動機として「社会にとって正しいことを手がけているプロダクトに関わりたい」と言ってくれる方は多いので、そのあたりはすごくモチベーションにつながっています。

黒澤：共感できるところは非常に多いですね。特に「PdMがプロダクトと向き合える」はすごく重要なことだと思っていて。

たとえばプロダクトの要件定義をするにしても、PdMの想いや熱意だけで決まるものではありません。ビジネスサイドの事情やエンジニアの想いなどが複雑に絡み合ったさまざまな条件や要望を整理し、かつ集約させなければいけないわけです。

正解か不正解かわからないところをきちんと見極めて、プロダクトを前に進めることには非常にパワーを要します。そういう意味でも、PdMがプロダクトマネジメントにフォーカスできることには意味があります。

ーお互いに聞いてみたいことはありますか？

黒澤：以前安達さんが「BtoBtoE」や「Employee First」という考え方を話されていたのですが、「GO」のようなBtoBtoCサービスはtoBをケアするとtoCにしわ寄せがいくようなコンフリクトが当たり前のように発生するんですね。そのあたりのバランスやEmployee Firstを実現するために意識していることや苦労があったらぜひ聞いてみたいです。

安達：SmartHRにとってtoBは企業の人事労務担当者で、toEは一般の従業員を指しているのですが、どちらにフォーカスするかは「GO」同様非常に難しい問題ですね。Employee Firstを追求するために、一般の従業員目線で「こういう機能があるといいよね」というものを無邪気につくると、人事労務担当者の業務が一気に増えることが起こり得る。

例えば、人事労務担当者に「従業員が人事労務担当者に気軽に質問できるような機能はどうですか？」と聞くと「従業員数1万人に対して労務担当者は2名しかいないので、そんな機能があったら回答できなくて、逆に従業員の不満が溜まってしまいます」みたいなこともあります。

ですから、Employee Firstを考えるのであれば、まずは人事労務担当者に寄り添うことが大事なのかもしれません。ただ、もちろん会社ごとにいろいろな事情があるので、そのあたりはきちんと加味していく必要があると思います。MoTではいかがですか？

黒澤：実はtoBの課題を解決する際に一番簡単なのは、toCにシワ寄せしてしまうことなんですよね。これはまた、逆も然りです。もちろん、それをしないことが僕自身のPdMとしてのポリシーでもあり、MoTでは「全方よし」という考えを大切にしてプロダクトを開発していますが、だからこそ悩むことは多いです。

ちなみに、コロナ禍になって人の移動は抑制されましたが、「GO」経由の配車数は着実に伸びています。外出の機会が減ったからこそ、たまのお出かけがすごくスペシャルなイベントになっているわけです。その移動時間をより快適に過ごしたい。こういう快適さは不可逆なので、移動は今後、さらなる快適さを求めてよりパーソナライズされていくと考えています。

ただ、パーソナライズな移動とは、すなわち満員電車と全く正反対の、極めて非効率なものになるわけです。「こういう乗務員さんを呼びたい」「こういう車種じゃないと嫌だ」といった要望に応えていくと、移動の満足度と反比例してどんどん非効率になっていきます。そうした「より快適な移動の未来」を、テクノロジーとプロダクトのアイディアを駆使して効率的に実現していくこと。難しいチャレンジではありますが、一番のやり甲斐だと考えています。

安達：確かに。そもそもタクシーが通りを流して乗客を見つけること自体、相当非効率ですよね。

黒澤：そうなんです。MoTが目指すのは、快適に移動したいユーザーと、それを実現する乗り物をマッチングさせるプラットフォーム。タクシーだけでなく、自動運転の車だったり、あいのりの車だったり、シェアリングされた車だったり……私たちの子どもや孫の世代まで使ってもらえる移動プラットフォームをつくり上げていきたいと考えています。

安達：「いかに効率的に社会貢献するか」ですね。まさに両社の共通項ですね。SmartHRとしても、バックオフィス業務が紙ベースのところはまだまだ多いので、効率化を進めていくことには意味があると思っています。

たくさん失敗することが成長への近道

ーPdMの育成や評価についても聞かせてください。

黒澤：私が重視しているのは2つ。

1つ目は、PRDレビューです。そもそもPRDにまとめる理由としてPdM自身のヌケモレのチェックだけではなく、開発やテスト、UXなどのズレをなくすことが目的ですが、育成の観点でも非常に重要だと思っていて。PdMが一番成長するタイミングって、自身がまとめたPRDをエンジニアやビジネスサイドにレビューしてもらい、多くのフィードバックをもらうときなんですよね。

2つ目は、プロダクトマネジメント本部というセクションをつくっている点です。同じ本部にPdMだけでなく、PjMやデザイナー、データアナリスト、UXリサーチャー、テストエンジニアが所属しているのですが、これもまた成長の観点で非常に重要だと思っています。PdMは職種柄、どうしても孤独になりがちで、誰にも相談できなくなることが多々あるんですよね。

でも、身近なところに他のPdMをはじめ、要件定義や開発プロジェクトの進行・管理に携わる各職種のメンバーがいれば、いつでも気軽に相談や壁打ちができるので、結果、チーム意識も生まれ、プロダクトの質も高められます。プロダクト開発に関わるさまざまなスペシャリストがワンチームで取り組めるメリットは大きいですね。

今後目指したいのは、たくさん失敗できる環境を提供すること。自分自身もこれまでプロダクトを設計するにあたって失敗したことがたくさんありますし、その失敗から多くを学び、成長にもつながったように感じます。プロダクトに正解はありませんからね。失敗できる機会を提供し、それを受け止められる組織をつくっていくことが、私の役目です。

安達：私たちは成長機会を提供して、飛び込んでもらうことが多いですね。「ちょっと難しいかな」というレベルの課題をポンと渡して「まぁやってみてください」と。それこそ、黒澤さんと同じ「失敗を恐れず、どんどんやりましょう」というスタンスです。

あとは、1on1でのティーチングやコーチング、アウトプットのレビューなどですね。10名規模の組織なので育成プログラムなどはなく、実地で学んでいくスタイルです。

“BtoBプロダクトの会社あるある”だと思うのですが、難しいのは評価ですね。BtoBプロダクトはマーケが広告を打って、セールスが提案して、CSがサポートしてようやくサイクルが回り始めるので、PdMの活動がそのまま売り上げに直結することはあまりない。

業務用プロダクトなので、デイリーアクティブユーザー数の推移を追って成功を計るといったこともナンセンスですし、新機能をリリースしても顧客側の都合ですぐには使えないこともあるので、定量化がしづらいんですよ。ですから「今季はユーザーがこういう状態になることを目指しましょう」といった定性的な目標になりがちです。

黒澤：わかります。なかなか定量化しにくいですよね。機能自体は複雑ではなくても売上貢献が大きいものはありますし、逆もあります。ですから、より定性的なところを細かくチェックするようにしていますね。

あとは、「今のポジションからのジャンプアップ」という観点ですね。「スキルに対してどのくらいチャレンジングだったか」も評価の対象にしています。

会社やプロダクトのフェーズごとにPdMに求められる役割は変わるのか

ー続いて、質疑応答に移りたいと思います。「会社やプロダクトのフェーズごとにPdMに求められる役割は変化してきましたか？」という質問が来ています。

安達：役割の変化はあまりありませんでした。私が入社した2019年は、従業員数は100名程度で、開発チームのエンジニアが20名弱。ただ、プロダクト自体は拡大していて、ユーザーからの要望もどんどん寄せられており、「そろそろPdMがいないと厳しいな」というフェーズでの入社でした。ですから、最初からPdMとしての役割を期待されていました。

黒澤：私も本質的にはあまり変わっていませんね。より高度なプロダクト設計が必要になってきましたが、根本的にやっていること自体には変化はありません。

ー次は「多くの人が使うインフラにするためにtoCやtoEに負担をかけないよう意識していることを教えてください」という質問です。

安達：全社的なコンセンサスのひとつが「個社対応はしない」です。「この機能がないなら導入しない」と言われても、個社対応はしていません。1社のために他社が不利益を被ったり、コードが複雑になって生産性が落ちたりすることは本質的ではありませんからね。

ただ、現実的にそれだけだと厳しい部分はあるので、SmartHRではなるべくたくさんのAPIを提供しています。「御社にフィットしたシステムを組むのであれば、APIはあるので、連携開発をしてください」というコミュニケーションをしています。場合によっては、ベンダーを紹介することもありますよ。

黒澤：まったく一緒です。基本的には個社対応をせず、できる限り汎用的なプロダクト開発を心がけています。先ほど安達さんから「コードが複雑化する」という話もありましたが、コードがややこしいプロダクトはえてしてスケールしにくいんですよね。極力個社対応をしないことは、プラットフォーマーに求められる大切な資質だとも考えています。

もうひとつは繰り返しになりますが、toCとtoBのどちらかにシワを寄せて課題を解決しないことですね。

センスの良いPdMとは？

ー最後の質問です。「お二人から見て、センスの良いPdMとは？」とのことです。

黒澤：前提として「いろいろなバックグラウンド、個性のPdMがいていい」と思っています。大事なのは「専門性」と「多様性」。チームであればなおさらです。

そのうえで大切なのは、ステークホルダーたちとのコミュニケーションを通じて多様な意見を素直にインプットできて、かつ芯をぶらさずに、本質的に重要なことにフォーカスしてプロダクト設計できることです。

頑固さとも八方美人さとも違う、絶妙なバランス感覚ですよね。そのあたりの取捨選択の勘所がいい人は、PdMとしてのセンスがいいですね。プロダクト開発のいかなるシーンにおいても優先順位付け、トリアージ能力は重要で、その際にも大切な素養となります。

安達：PdMにとってのセンスには2つあると思っています。

1つは思考の独立性です。たとえば目の前のユーザーの言葉をそのまま受け取るのではなく、背景にあることをしっかり考えたり、既存のプロダクトの仕様に引っ張られずに本来あるべき姿を追求できたり……バイアスから離れて本質的な思考ができることです。私たちはよく「プランC」と言うのですが、プランAでもプランBでもないアイデアは、一歩引いて「でも、それってこうじゃない？」と考えられる人から生まれるような気がします。

もう1つは、言語化能力です。PdMとして開発の方向性やプロダクトのビジョン、優先順位を決めて、ステークホルダーに説明するときに、納得感があってわかりやすい言葉に落とし込む能力は一朝一夕に身に付くものではありません。そのあたりを瞬時に言葉にできる人は、センスがいいと思います。

ー最後に、どんな方に来ていただきたいか教えてください。

安達：やはり、プロダクト開発が好きな人ですね。あとは課題解決が得意な人。不の解消が好きな方に来ていただけたら嬉しいです。

今後向き合うべきは、組織としてのアジリティを落とさずにプロダクトやビジネスをグロースさせていくこと。非常に大きな壁が行手を塞いでいるので、一緒に議論しながら乗り越えていきたいと思います。

黒澤：PdMは他の職種と比べて事業やプロダクトへの共感が非常に重要だと思っています。苦手なところがあってもいい。「移動で人を幸せに。」というMoTのミッション実現に向けて、プロダクトを通じて貢献したいという熱意のある方であれば、ぜひご一緒させていただきたいです！