「ドメイン知識がある人→PM」と「エンジニア→PM」 採用市場で起きている2つのパターン
財部優一氏（以下、財部）：3つ目の質問にも関連するかもしれませんが、PMになる前のよくある職種とそれぞれの特徴について。佐々木さんは前職で事業開発をされていましたが、それ以外だとどんな職種の方がいて、それぞれどんな特徴があるのでしょうか？
佐々木真氏（以下、佐々木）：これは明確にあります。良いか悪いかは置いておいて、今の採用市場で起きているパターンは次の2つが多いです。1つ目が、ドメイン知識がある人をコンバートさせることですね。SaaSを作る時は、そのドメイン知識が必要になります。それがあったほうが良いプロダクトを作りやすいので、まずはその人にPMスキルを学ばせるパターンです。
もう1つは、エンジニアからのコンバートですね。これは先ほど言ったのですが、エンジニア経験がないと、PMになれないと考えている人が多いからなんですね。だから結果的にエンジニアからのコンバートが起こるのですが、僕はこれはあまりよくないと思っているんですよ。アメリカだと、別にエンジニア経験があってもなくてもできるんですよ。向こうは学歴社会で、大学でコンピューターサイエンスの修士を出ているのが前提だったりするので、ちょっと事情が日本とは違います。
一方で、エンジニア経験以外でもコンバートする人が今後もっと増えてほしいと思っていて、機会がないだけで、セールスの人はセールスの人の強みがあるので、できると思っているんですね。そういった時にPM Schoolで学ぶとか、コミュニティに入ってもらいたいなとも思います。今の時点では、この2つが多いのですが、今後はより増えていくと思うし、そうなってほしいし、そうなるように僕自身もなにかやりたいなと思いますね。
財部：なるほど。ドメイン知識がある人は、確かにバーティカルSaaSのPMをやっていたり、いろいろキャリアがありそうですが、その中でPMとしても優秀な人は多くいるものですか。微妙にスキルが違うなと思ったんですけど。
佐々木：そうですね。ドメイン知識は違いますね。例えば、僕は車の産業はまったくわからないのですが、やはりそこの不文律や業界商習慣があるので、自動車向けのSaaSをやっている会社にいる人が、それをわかった上でPMのスキルを学ぶのは、ゼロからやるより遥かに速いと思います。PMスキルがある人にドメイン知識を付けるのは、その人自身に興味関心がないと難しいので、けっこうコントロールしにくいんですよ。
そうなった時、ドメイン知識がある人にPMをやらせるほうがコントロールが利きやすいです。事業リスクが小さいので、そういう現実的な理由もあります。
財部：おっしゃるとおりですね。自分自身も興味関心がテーマなのかなと。ドメインエキスパートの人にPMスキルがあるとは限らないですが、ドメインへの情熱は誰よりも持っていると思うので、好奇心があるから思考が深くなっていくところはあるのかなと思います。
佐々木：まさにそうですね。
板挟みになりやすいポジションでどうストレスと向き合うか
財部：悩み②に関しては以上です。ここでまた質問に戻ってみたいなと思っています。「プロダクト企画とPMは何が違うのでしょうか」一緒な気もしますが、どうですか。ここはなにかお考えがありますか？
佐々木：これは明確にあって、プロダクト企画と呼ばれるものはPMの仕事の1つで、PM上の概念になりますね。僕がプロダクト企画という言葉を使う時は、先ほど申し上げたユーザーの課題を特定すること、その解決策を見つけることの、2つ目のことを指していることがほとんどですね。
ここの言葉は人によって揺れています。先ほどの僕のNotionのリストでも、プロダクト企画という言葉を使うんですが、それは要するに課題を解決するための機能の方向性を考えることなので、先ほどの2つのうちの仕事の1つという感じですね。
財部：なるほど。ありがとうございます。先ほどから上位に残っているこちらの質問（板挟みとなりやすいポジションで、ストレスと向き合うにはどうすればいいか？）も、セクション2とは関係ありませんが、メチャクチャあるあるだと思っています。
（一同笑）
佐々木：そうですね。
財部：このへんもちょっとお答えいただければと思うんですけど。
佐々木：PM Schoolの事前登録の悩みの中でも、コミュニケーションの悩みはメチャクチャ多いんですよ。PMの人には優しくしてあげないと辞めちゃうので、ここにいる上司の方には優しくしてもらいたいなと思っています。これは本当にあるあるなんですよ。ギャップを埋める存在なので、板挟みになりやすいんですね。
先ほど申し上げたところとも似ているのですが、組織を変えようと思ってもPM1人の力ではほとんど不可能なので、そうなると僕は「無理です」と転職をおすすめしちゃうんですね。
財部：なるほど（笑）。
佐々木：組織の問題なので、1人の力では変えられませんとなった時に、プロダクト組織に理解のある会社に転職するのが現実的ではあるんですね。ですが、それをやると身も蓋もありません。現時点でできることをがんばるとなった時の発想で、向き合うというところでいうと、やはり社内に啓蒙するしかありません。
「PMというのはこういう存在。まわりの人にはこういうのをやってもらう。私の仕事はこういうことです。だからこのミッションからは外してください」と順に交渉する。ミッションとして持ちすぎるとパンクしちゃうのは、やはり人間誰でもそうなんですね。それはPMに限らずあると思うんですよ。
組織の優秀な人に仕事が過集中して、ミッションが10個ぐらいあるのってリクルート時代にもあるんですよ。若手は3つぐらいしかないのに、メチャクチャ優秀な人は10個近くミッションを持っていて、それを半年でやってねというのはけっこうあるんです。それはPMに限らずあるんですが、それはもう上司やまわりの人と交渉するしかないんですね。
啓蒙をして理解をしてもらい、交渉するしかありません。ストレスを感じているポイントの詳細は書いていませんが、例えば、上司からむちゃぶりがあるとか、上司が理解していないから苦労するというパターンと、現場から突き上げられるパターンの2つがあります。上司からむちゃぶりされて降ろすと現場から突き上げられるという、この中間になるのがPMのストレスとして多いです。
そうなった時には、双方を啓蒙する以外にないんですね。今いる環境を変えるのであれば、そこはがんばるしかないんですね。
財部：冒頭の話にもつながりそうですね。定義を明確にする、組織をすり合わせるのが、やはりストレスを減らす上でも重要だということですかね。
佐々木：そうなりますね。
「機能を出す」が目的になると「課題を解決する」が目的じゃなくなる
財部：次は、プロダクトマネージャーの成果計測ですね。プロダクトマネージャーの定義が曖昧だという話もありましたし、そもそも仕事が複雑で企業によって求められることも異なる中で、仕事の成果をどう測っていくのかについておうかがいしたいなと思っています。
（スライドを示して）『Japan Product Management Insights 2022』という弊社の出したレポートでも実際にアンケートを取りました。これはあくまでプロダクトマネジメントチームの成果で、やはり売上やロードマップの達成率、あとは利用率が上位の結果となりました。その中でよくあるパターンで、成果計測におけるアンチパターンとうまくやる方法をおうかがいしてもよろしいでしょうか？
佐々木：ここはすごく難しいところなんですよね。これはたぶん、エンジニアのパフォーマンスをどう評価するかと似ている難しさがあると思っています。例えば、エンジニアに対する評価の軸をプルリクを出した数とすれば、無駄なプルリクを出しまくることになってしまうし、セールスもアポ数にするとリードの質が悪いアポを取りまくることになります。それは結局誰のためにもならないと思っています。
PMもそれに近くて、（評価の軸を）「機能を出す」にすると、出すことに主眼を置いちゃうんですよね。長期的に本当にやるべきなのかという、課題の仮説検証をしないことになります。そこの計測は非常に難しいです。PMの成果計測をするにはより優れたPMが必要ですが、そんなに市場にいないので、さらに難しさに拍車がかかっています。
その中で、「PMとして現実的にこういう成果を測ったほうがいいよ」というところでいうと、ロードマップもありますが、個人的におすすめしているのは、最初にした2つの話の1つ目の、課題の特定をきちんと含めることです。僕はこれを含めている組織を見たことがないんですよ。なので、ほとんどのプロダクトは目標がリリースベースになるんですよね。
もちろん、プロダクトはリリースすると保守・運用コストが永遠にかかり続けます。機能が多いほどそのコストはかかるので、使わない機能を増やすと保守・運用コストがどんどん増えるんですよ。そうなるとエンジニアを増やしても新機能開発が増えなかったり、リファクタリングにメチャクチャ時間がかかったりします。
ビルドトラップという言葉がありますが、リリースすることが目的になると、課題を解決することが目的ではなくなります。なので、リリースに（評価の軸を）置くのもいいんですが、そこじゃないよねと個人的には思っています。お客さんの熱狂的な課題を見つけること。そしてそれを見つけている場合、それを解決する機能のリリースでもいいと思うのですが、やはりここの原則の仕事2つに紐づくKPIだとより良いなと思っています。
財部：なるほど。
佐々木：1個目の仕事は定量的にするのは難しくて、定性になりがちです。ただ、課題を見つけられている状況と、見つけられていない状況には雲泥の差があるので、やはりここはミッションでやったほうがいいと思います。アンチパターンはリリースやロードマップ達成率で、ロードマップの達成率になると、例えば仮説が間違っていた場合のピボットが利きにくくなったりします。
PMはロードマップを埋めないと自分の給料が下がるから、とりあえず出すのですが、そうなると結局お客さんの課題とはかけ離れた解決策がどんどん出てくるので、これはやはりよろしくないです。
確実にプロダクトのマーケにフィットしていて、あとはやるだけだったらロードマップの進捗でもいいと思うんですが、まだこれからとか、揺れ動いている業界で、リリースやロードの達成率にすると、ビルドトラップになりやすいので、ここもアンチパターンとしては注意かなと思いますね。
財部：なるほど。この良い課題を解決しているかどうか、特定しているかどうかは、現実的にどうやって計測するといいんですか。
佐々木：そこは非常に難しいですよね。
財部：リリース後の効果検証をしている企業はあるので、そこで一定の課題が解決されたか（データ）を取ったり、ヒアリングをしたり、課題の解決が想定どおりにきちんとされているのかアウトカムを計測したりなど、そういう取り組みの仕方はありますかね？
佐々木：そうですね。僕がよく顧問先で言うのは、やはり評価者も含めてお客さんと会ったほうがいいということです。お客さんの定性のニーズを捉えていたら、リアクションが確実に変わるはずなんですよね。「これこれ！」みたいなリアクションになるはずなんですよ。それが特定できたら、あとは基本的にはやるだけになるはずなんですよね。
なので、そこは基本的に定性っぽくなっちゃうんですが、そこをしっかり見に行くのは、評価する上では大事だと思います。もしくはすでに売上が立っているプロダクトであれば、それが結果的に売上につながることはあっても、売上をKPIにするのはよくないと思うんです。
ほかには、今使っているお客さんのアクティビティが上がるとか、もしくはアップセルができるとか、プロダクトによってはそういうのが出てくると思います。いずれにしても定量だけだと危険なので、そこは定性と混ぜたほうが良くて、プロダクトのフェーズや状況によってもかなり変わっちゃうので、ここが難しくしている原因ですね。
（次回へつづく）
