「課題を特定する」ためにPMがやるべきこととは？
財部優一氏（以下、財部）：「課題を特定する」というのは、具体的にプロダクトマネージャーはどんなことをするべきなんでしょうか？
佐々木真氏（以下、佐々木）：例えば、「プロダクトを作る」と一口に言っても考えることがけっこういっぱいあるんですよね。まずは、ユーザーを決めなければいけないのですが、どういうマーケットのどういうユーザーを攻めるかという領域は厳密にはプロダクトマネジメントの範囲外なんですね。
これを考えるのは事業戦略や事業開発の仕事で、僕は本来ここが専門の人間です。「このマーケットに対してこういうお客さんで攻めましょう」というのを考えたあとに、「どういう課題に対してどういうプロダクトを提供するのかを考える」というのが本質的にはPMの仕事になります。
一応そこでは区切るので、言い換えると、ユーザーを決めたあとにユーザーの課題が大小いろいろいっぱいある中で、「どれがもっとも大きい課題ですか？」と考えることです。なぜなら、大きな課題を解決しないと（ユーザーは）お金は払ってくれないからです。小さな課題を解いてもお金を払ってくれないのでビジネスになりません。
なので、大きくて解く価値のある課題を見つけるというのが、まず1つあります。そして、それを解きましょう。うちのプロダクトのやるべき方向性はなんですかとか、こういう方向で解決しましょうというところで、けっこう個性が出るんです。PMが変わると解決策が変わったり、プロダクトがガラッと変わったりすることがザラにあるんですね。
財部：なるほど。市場調査をしたり、事業計画を作ったりというのは範囲外になるんですね。
佐々木：市場調査というとそうなんですが、ユーザーヒアリングは対象になってくるんですね。だけど、TAM（Total Addressable Market）がどれくらいかとか、競合のセグメント分けとか、ポジショニングとか、そういうものは本質的にはプロダクトではなく事業の話で、事業は事業開発という別の仕事になります。
財部：なるほど。確かに、そこも含めて担っているPMの方は多そうな印象はあります。
佐々木：そうなんですよね。今僕が言ったのは完全に理想論です。こういう定義だとは言いつつも、僕自身も1人でやれちゃうので、自分の事業で全部やっちゃうんですけど、これをPMの人に求めると、ほとんどの人ができないんですよね。
財部：なるほど。
佐々木：「事業開発をやってほしい」と言っても、たぶんできる人のほうが圧倒的少数なので、そういうことを求めると採用に苦労すると思うんですよね。なので、お互いにあまりよろしくないと思います。
期待過多だし、期待され過ぎるのもつらいとなっちゃうと、本当はPMとして優秀なのに事業開発のスキルがないだけで、「うちに合わないね」と判断されるというのは、僕が見る限り採用でよく起きる問題で、ここの認知がもっと広まると、お互いに幸せかなと個人的には思うので、こういう場で話せるのはうれしいです。
財部：ありがとうございます。課題を特定することと、その解決策を考えていくことがPMの本質的な役割で、一方でいろいろなことをやらされてしまっているのが、今の状態ということですね。
佐々木：そうですね。
組織としてPMの役割を定義してすり合わせていくべき
財部：そういうフワッとした役割でプロダクトマネージャーを任されている方も、今の日本では多いのかなという印象があります。その状態の中で、どうやって自身の役割を会社とすり合わせていくべきなのか。会社の中で自分のポジションをどう作っていくべきなのか。そういうところはどうお考えですか？
佐々木：市場の成熟の話になるので、ここがすごく難しいんですよ。別の取材でも話したのですが、はっきり言うと、今の日本の採用市場はアメリカが10だとしたら日本は2ぐらいなんですよね。
成熟するのを待つのもいいのですが、PM1人が会社の文化や組織の考え方を変えられるかというと変えられないし、もっとはっきり言うと、その悩みはその会社が変わらない限りはほとんど解決が不可能だと思うんですよね。PM1人やエンジニア1人の問題ではなくて、組織全体の話になるし、考え方の問題です。
じゃあその中で、会社とどうすり合わせるか。まず、PMの定義を会社の上司や責任者が握っているんですね。（上司や責任者は）「PMとはこういうことをする役割で、僕はこういうことをやっていきたいと思っている、私はこういうことをやりたい」と思っているので、それに合意が取れないとお互い不幸なんですよ。
PMとして仕事をしているつもりでも、PMのスキルは伸びないので、結局転職もできないし、キャリアもつながらないし、採用をする側も「あれ？ 言ったことをやってくれないな」みたいになります。そうなるとお互いに不幸なので、お互いがプロダクト開発の知識を持ち、例えばPMとはこういうことをする、エンジニアはこういうことをする、デザインはこういうことをする、というのを全員が学ぶ必要があると思います。
PM Schoolを法人で導入していただく理由はそこが多いんです。組織を作らないと変わりません。PM1人を採用しても絶対に変わらないんですよ。よく「CPOを採用したい」と言われるんですが、PMが1人もいない組織にCPOは絶対に採用できないので、まずは組織を作りましょうということです。そこが一番大事なので、それを作るためにがんばったほうがいいですし、個人としてやるのであればまずそこを上司やまわりの人と握るのがすごく大事かなと思いますね。
財部：なるほど。おもしろいですね。組織としてPMの役割を定義してきちんとすり合わせるということですね。
佐々木：そうですね。
財部：一部の経営者とすり合わせただけではダメということですね。他の職種の方も含めてきちんとプロダクトマネージャーはどういう役割で、どういう仕事をすべきなのかをすり合わせていくべきだということですね。
佐々木：そうですね。僕がTwitterでアホみたいにPMのことを話しているのは、その認知も広まるといいなという思いもあるからです。
財部：確かに。いつも相当な数の連続ツイートもやられていますもんね。
佐々木：あれはけっこう大変なんですよ。
（一同笑）
財部：「いつどうやって作っているんだろう」といつも思っています。
佐々木：電車の中や仕事の打ち合わせの合間とか（笑）。思い付いたアイデアがあると下書きに書いています。
財部：なるほど。
採用のミスマッチの解消するためにPMスキルを言語化
財部：そのあたりもちょっと。（スライドを示して）これですね。
佐々木：そうですね。
財部：たぶん今の話に関連するところで、これは今PM Schoolで作られている資料ですよね。
佐々木：そうですね。
財部：どういったものなのか、説明していただけますか？
佐々木：先ほど申し上げたように、今はPMの仕事の期待値と役割が会社によって差がありすぎるんですよね。PMとしてのコアは何か、というところと経験年次によって（PMのレベルは）それぞれ違うというのが認識されていないんです。
例えば、プロダクトマネージャーを採用するというと、だいたいがこの表の中でいうレベル3以上を求めるんですよね。でも市場にいるのはレベル1、2がほとんどなので、そうなった時にかなりのミスマッチが発生します。採用する側は良い人が来なくて、応募する側はぜんぜん通らなくなる。でも実際はレベルが1、2の人でも大丈夫な組織やフェーズがあるんですよ。
言語化ができていないがゆえに、そこでミスマッチが起きているというのが非常にもったいないし、市場にもよくないと思っているので、そこをまず言語化するのがこのシートです。右のほうは見切れていますが、どういうレベルではどういうスキルが必要なのかもレベル別に分けています。
さらにPMは、専門性ごとにテクニカルです。例えばエンジニア出身のPMだったら、エンジニアリングが強くて、僕みたいに事業開発出身のPMだったらBizDevが強いです。それぞれのレベルをやって、最終的にはCPOやVice President of Productというキャリアになれるので、こういうキャリアを描いてそれぞれのレベルをどれぐらい横で見ればいいのかというのをこの表では定義しています。
かつ、そこに対するコンテンツが学習できるのがPM Schoolの強みなので、すべての始まりがここになるべきだと思いますし、この表はあくまで僕たちが考えているベストですが、こういう考え方があるといいなと思います。これこそGAFA……GoogleやFacebookにはこういうのが全部あるんですよ。
レベル1、レベル5、レベル10で、それぞれアソシエイトからシニア、VPoPと全部あります。日本はプロダクトマネージャーしかおらず、それでミスマッチが起きるので、私たちはそこの定義をがんばりたいなと思っています。
財部：おもしろいですね。日本で「PMが欲しいです！」と言っている企業は、この中でいうとどこのPMを欲しいと思っているのが多いんですかね。神レベルのCPOみたいな人を欲しがっている企業が多い印象があります。わりと何でも屋みたいなイメージで、PMを採用している企業も多い印象があったりします。
佐々木：そうですね。「PMを採用しています」と言って、レベル3を指しているかというと、実質的にこの表でいうとレベル4のテクニカルPMを指していることが多いです。「エンジニアのマネジメントをやってください」と言う企業もいますが、マネジメントをするのはマネージャーの仕事だから違うよと。「テックリードを雇ったほうがいいよ」みたいなことを、僕は顧問先でもよく言うんですよ。
PMはプロダクトマネジメントはするけれど、エンジニアのマネジメントは違います。それは人の評価だからまったく違う話だし、それこそエンジニア出身じゃないとエンジニアのデューデリジェンスや評価ができないので、そういうミスマッチが起こるんですね。この中でいうと、テクニカルPMが市場的にはニーズが高いですが、めったにいないんです。
財部：なるほど。確かにそうですね。「とりあえずエンジニアとの橋渡しをやってほしい」というニュアンスで採用しているケースも多そうですよね。
佐々木：そうですね。例えば僕もエンジニア経験がたくさんあるわけではないので、テクニカルPMはできないんですよ。僕は事業開発PMやCPOはやれるのですが、テクニカルの部分はどうしても弱いので、そこは限界があるかなと思います。デジタル庁の水島さん（水島壮太氏）とこの間話しましたが、たまに全部やれる、ああいう神レベルの人がいるんですよ。そういう人がいるので歪むんですが、あんなレベルの人は基本的にツチノコで、まず存在しないので（笑）。あんなのは無理ですよ（笑）。
財部：なるほど。
佐々木：だからそれに期待しないほうがいいと思いますね。
テクニカルPMとエンジニアリングマネージャーの違いとは？
財部：テクニカルPMと、いわゆるエンジニアリングマネージャーや、エンジニアの責任者としてエンジニアをまとめる人の違いはどうなりますか。
佐々木：大変すばらしい質問だと思います。エンジニアリングマネージャーは、あくまでエンジニアリングです。要はプログラムを書いて動作を保証したり、インフラ設計の保証をしたり、あとはそこで働くエンジニアのマネジメントをしたりするわけです。
それに対してテクニカルPMはあくまでPMなので、先ほど申し上げたとおり、「ユーザーの課題を特定して、ユーザーヒアリングをして特定すること」と「機能を考えること」が原則で、さらに自分の専門性を活かすことができます。
財部：なるほど。
佐々木：エンジニアリングとの橋渡しができるとか、細部まで考えられるというのもありますが、ベースとしてPMはエンジニアマネージャーが近く、PMはPMでエンジニアはエンジニアというところで、そこはシンプルに一番違います。
財部：なるほど。確かにデザインもテクニカルも全部を強みにすることは難しいので、どこのスペシャリティを持つプロダクトマネージャーなのかというのがとても重要なんですね。
佐々木：そういうことですね。例えば、最近はデザイナー出身のPMでコンバートされる方が増えているんです。そういう人はデザインの知識はあるので、簡単なワイヤーで自分で作れるのも攻めのポイントだと思います。例えば僕は、事業戦略を考えてそのままプロダクト戦略を作れます。そういったことが専門性としてあるので、そこが事業開発PMとしての強みですが、あくまでPMという感じですね。
財部：なるほど。ありがとうございます。非常に勉強になります。
（次回へつづく）
