日本国内でも徐々に認知されつつあるプロダクトマネージャーという仕事。第2回Product Manager Conference（#pmconfjp）は、2017年11月14・15日に開催された。
今回のテーマは、「広げる、深める」。昨年に比べてPMの認知は増え、「広げる」についても一定進歩していると考えられるが、今後さらに広げる、または組織としても個人としても「深め」ていくには、何が足りないのか。
Googleでプロダクトマネージャーを務めた経験のある及川卓也氏をファシリテーターに、楽天トラベルの齊藤満氏、メルカリの伊豫健夫氏、LINEの御代田亮平氏、サイバーエージェントの藤田和司氏らが論を交わした「プロダクトマネージャートークセッション」の全容を、2回に分けてお送りする。
楽天株式会社 Senior Manager
齊藤 満
株式会社メルカリ 執行役員
伊豫 健夫
LINE株式会社 開発1センター プロダクトマネージャー
御代田 亮平
株式会社サイバーエージェント アドテク本部 アドテクスタジオ チーフプロダクトオフィサー
藤田 和司
Product Manager Conference 実行委員・フリーランス
及川 卓也
各登壇者の詳しいプロフィールはこちら
PMの認知は増えているが、採用は難しい
及川：皆さんの所属する組織において、PMは現在どのように捉えられていますか？
伊豫： 去年もこちらのカンファレンスに登壇し、メルカリUS版を含めたグローバルなプロダクトマネジメントというテーマでお話させていただきました。その際に会場でいろんな方のお話を聞くと、確かに及川さんの仰るとおり、去年時点だと「PMとは」といった話にひたすらフォーカスしていると感じました。ですが今は、そういったことは世の中にだいぶ浸透してきたのかなと感じています。
ぼくの感じている「広がる、深まる」でいうと、PMのやることをより具体的な言葉で定義をして、「自分はいったいどこに当てはまるんだ」という軸から、我が事としてPMを捉えられる人を増やしていける輪が広がっていくといいなと思っています。
メルカリ社内の事例でいいますと、ものをディレクションするとか、プロダクトを企画することに加えて、エンジニアに立脚したPMというのを主眼に置いていた時期もありました。今はエンジニアリングに立脚してなくてもいいから、コンテンツ設計がしっかりできる等がPMの採用要件になるなど、幅も広がってきている印象があります。
なので、ぼく自身が今感じているのは、PMの役割が広がりつつも、言葉に落とすタイミングに日本も来てるのかなという感じです。
及川：認知の広がりで言うと、皆さんも採用をやっていると思います。プロジェクトマネージャーは来るけれどプロダクトマネージャーは来ないだとか、以前はちょっとずれてると感じていたのが、最近は応募が増えたとか、認知されていると感じたことはありますか？
齊藤： 楽天ではPMになりたい人の応募が増えています。昨年以前ですと社外からが多かったんですが、最近では日本でも「こういうプロダクトをつくりたいから、PDMを目指しています」「私はPJMではなくPDMだと思います。なぜならば……」といった面接が増えていますね。
御代田： ちょうどぼくも採用面の話をしようと思ったんですけど、ちょっとまだ弊社では苦労しているというところですね。サービスが大規模なので、巨大なサービスのプロダクトマネージャーをやってきた人がまだ日本のマーケットにはそこまでいなくて。プロジェクトマネージャーの応募はけっこうあるんですけれど、まだ我々が求めているような人の応募はいないという印象ですね。
とはいえそういった方が増えるのを待つわけにもいかないので、会社としては社内でエンジニアリングマネージャーをプロダクトマネージャーにするとか、プロジェクトマネージャーとして入っていただいて社内で育てるとか、そういった方向に舵を切るのが重要なんじゃないかなという話をしています。
藤田： 弊社だと広告の知識があって、かつ、ものづくりができないといけないので、どちらかというと伝統的に社内でキャリアパスの一つとしてPMを育てていく、という育て方をずっとしてきました。
昨年一昨年前のアドテク大ブーム時はプロマネをやりたい人が社内でも多かったんですが、実際プロマネがやらないといけない業務の範囲が社内でも徐々に認知されてきて、「迂闊になりたいと言うと大変だな」とわかってきたのかなというところで。単純な憧れみたいなところからはちょっとトーンダウンしているのかなという感覚もあります。
及川：藤田さんの話でいうと、広がってはいるんだけれども、薄く広がっていると。ヘタに広がりすぎたところからちょっと違う人が入ってきたりすると、扱いが大変になるといったことですかね。
藤田： そうですね。やってみようとする人にはやらせてみる文化のある会社なので、チャレンジはしてみるものの、仕事が多岐に渡るんですね。
プロダクトの方向性を決めるのもそうですし、特にBtoBの場合、関係者をしっかり巻き込んでいかないとプロダクトそのものが立ち上がっていかないですし、コンセプトが正しくてもなかなか立ち上がっていかないみたいなところもありますので。そこまでやりきらないとという認識なしに取り組んじゃうと、なかなか立ち上がらないんじゃないかと。
及川：採用育成という軸で話が進んできましたが、社内からの転籍というかたちのサイバーエージェント藤田さんのような話もあれば、LINE御代田さんのところでもプロジェクトマネージャーからのプロダクトマネージャーという話もありました。
外からの採用も増えてきているという話もありますが、どちらにしても元々はプロダクトマネージャーじゃない人も多いと思います。バックグラウンド的にどんな人が多いのか、もしくはみなさんの組織ではどういった経歴だとかスキルを持っている人をプロダクトマネージャーとして登用したいかについてお聞かせいただけますか。
藤田： 私はエンジニア的な経験があるので、技術のベースラインをちょっとは理解できます。ビジネスを長くやってきたことからサービスの定義もできるので、それを立脚点として、同じようなこういうバックグラウンドの人を一時期頑張って探していたんですがあまりいなくて。
今は特に広告事業に関して我々の領域に精通しているというところと、要件をしっかり現実可能な範囲で言葉にできるというか要件定義の見極めができる人間を育てようと思っています。
御代田： 求めるスキルセットを箇条書きにしていくと、だいたいはそんな人間はいないということになってしまいます(笑)。
弊社はエンジニアだけで2,000人ほどいるので、その中をうまくかいくぐるようなコミュニケーション力は必ず必要です。ある程度ベーシックな開発のナレッジがあれば、ステークホルダーと話すときにも必要なコミュニケーション力と、どういったスケールで大きく捉えられるかといったところの方が、わりと重要になってくるかなという感じがします。
伊豫： 弊社は扱っているプロダクトが利用者としてもイメージが湧きやすいので、お客様のことが好きだったり、プロダクトギークであるだとか、お客様対して愛情深いだとかが重要になってきます。
以前はこれくらいのエンジニアリングは理解しておいてほしいとか、わりとスペシフィックな要件を列挙していたんですが、日本国内のコンシューマ向けサービスの競争が激しいことを考えると、もっとバラエティを出していかないといけないと感じていて、そういう意味でPMの要件に関しても比較的抽象化して考えています。
齊藤： 私たちはプロダクト愛が1番大事だと思っていて、日本語で言うとものづくりが好きな人っていうのは第一条件になるのかなと思っています。私が面接の時に見ているのは、ゼロベースで考えられる人。
自分の思いや、これまでの経験、環境から、こういうものだって決めている人よりも、ゼロベースからロジカルシンキングをもって、「こうこうこういう条件ならばこういうものをつくります」っていう話を面接でしていただける方、もちろんジェネラライズというテクニカルな側面やサービスの側面を踏まえた上で前に進めるような人がPMなのかなって思います。
PMのKPIは数字であるべきか
及川：ここからは会場からの質問について、登壇者にお答えいただきたいと思います。では最初の質問です。
Q1. 会社によってもちろんProduct Managerのカバー範囲も違うと思いますので、みなさんのケースでよいのですが、責任を負っている具体的なKPIは何ですか？それはご自身の責任でContorolableなKPIですか？
御代田： KPIはユーザーやレベニューのグロースにつながることだと思うんですけど、直接的につなげられるKPIってつくりづらいですので、発行されたトークン数だとかアクティブなトークン数だとか、どれくらいQiitaで書いてくれただとかを指標にしていたりしますね。そういうのってディベロッパー的な活動の結果じゃないですか。そういったものもKPIに入っています。
伊豫： 日本でのメルカリの流通総額がKPIですね。流通総額は取引の成立によって成されるものなので、それすなわちお客様の満足度であるというふうに社内では考えています。これがコントローラブルであるかというと、コントロールしないといけない立場にあります。
私には何人かPMのメンバーがいるんですけども、彼らは流通総額をブレイクダウンしたいくつかの指標を持っています。KPIってすごくたくさん設定したくなるし、あれもこれも大事ってなってきますが、できるだけシンプルにひとつに決めることが重要だなと思っています。
齊藤： KPIとしての数字は持ってないです。どちらかというと影響力という言葉が1番KPIとして設定されているのかなと思っています。例えばプロダクトに対する影響力でいうと、ディベロッパーとQAとデザイナーの方々と話をして、正しく仕様書をつくり、それが正しくプロダクトとしてリリースされたら、その後でコンバージョンとかUUとかを補足的に見るようにしています。
私はIT業界とトラベル業界の両方に属していると思っているので、それらに対してどれくらいメッセージを発行できたかとか、業界の何が変わったかというものをソフト的に見るようなKPIを、KPIというと数字になるのでこれが答えになるかわからないのですが、そういうようなかたちではかっています。
伊豫： なぜそうされているんですか？
齊藤： 楽天トラベルがPMの組織をつくったのが4年前くらいなんですが、UUやコンバージョンだけを追いかけていると、おそらくイノベーションは起きないだろうと考えたからです。小さな改善の積み重ねがイノベーションという考え方ももちろんあるんですが、そこを追いかけ続けていると、おそらく、結果世の中から遅れてしまう。
日本では勝っていたとしても、トラベル業界は世界も強くなっていますので、そういった方々が日本に入ってきて、全部取られてしまうだろうというような議論があって、少しKPIの数字は持ちながらも、できるだけ大きな観点で育ってもらいたいと話し、そのようなKPIにしました。
藤田： 私が担当しているのは広告で、特にデマンドサイトと呼ばれる、広告主さんのマーケティング上の問題を解決するというものなので、これはもうシンプルに効果に向き合ってやっていくというかたちになります。別の事例で言うと、アドテクの製品を作る前にアメーバブログのマネタイズを3〜4年とやっていたときのKPIは、斎藤さんとちょっと似たところがあるのかなと思ってまして。
ユーザーの出面に広告を掲載させていただくかたちになるので、何につけてもまずユーザーがイヤじゃないかとか、気持ち悪くないかとか、ダサくないかとか、みたいなところを見極めるのが第一にあります。デザイン的にそんなにダサくないね、イヤじゃないねみたいなところが第一で、そのあとにCTRだったりとかコンバージョンレートだったりだとか、みたいなところをしっかりと追いかけていくことをやっていました。
及川：いまの質問に関連するところなんですが、PMと事業責任者は別物なんでしょうか？
伊豫： メルカリでは事業責任者として位置づけられています。ただ、私は自分のことをPMだと思っていますね。メルカリではプロダクトをよくすることでお客様の満足度が向上するのをひとつの信念として取り組んでいることもあり、事業責任者も優れたPMでありましょうということがフィロソフィーとしてあると思っています。
じゃあ役割分担はどうしているかというと、各PMは自分の担当しているプロダクトラインにおいて全責任を負っているというようなイメージです。私はそこに横串のようなかたちで、社外との調整であったりとか、関係省庁とのやり取りであったりとか、各PMたちが自分たちのミッションを果たせるようにサポートしたりしていますね。
藤田： 弊社のアドテクでは製品によって体制を変えています。エンジニア出身のPMだと事業サイドのところを全部をみるのは難しいので、数字を見ることができる人間をビジネス担当として別につけたり、逆にビジネス出身の人間の場合は技術的なところが足りなかったりするので、上流工程をやっていきたい人間とセットで行なうだとかですね。
キャリアとしては、その先に事業責任者がひとつのゴールとしてはあるものの、そこに寄らないようにしています。
御代田： APIやSDKのチームのPMは、CTO配下でみんな納まっていますね。エンジニアリングとプロダクトをはっきりわけて、エンジニアリングはCTO、プロダクトはCPOの配下みたいな組織構造もあるかと思うんですけれども、LINEの場合、だいたいはCTO配下にいますね。
そういう意味で、API、SDKのチームのPMは事業のビジネスの数字を積極的には背負っていません。一方で、事業チームからのリクエストは頻繁に受けていて、彼らのKPI達成のためにフィーチャーを追加していくというのはよくある流れだと思います。
齊藤： 楽天もほぼ同じで、事業は事業、PMはPMで完全に分かれています。これはたぶんタレントとカルチャーのかたちで結果そうなっていると思っていて。
長らくPMが数字を追うもしくはサービスオーナーという経験を積んできていないので、そっちの方向に進むというのはまだなくて、カルチャー的に事業の方々がサービスをオンするというようなかたちで、事業側からこういうフィーチャーがあるとこういうビジネスを起こすことができるといったリクエストをもらうことが多いと思います。
及川：PMは職種なのか役割なのかという議論があって、エンジニアがプロダクト開発においてはプロダクトマネジメントをやりますというような、役割として定義されている組織もあると思うんですね。
職種として日本の組織として確立されていくには、やはりその人のキャリアパスを考えてあげる必要があり、その人がそのまま能力を開発し実績を出していった先には何があるのかっていうことをやることが、今回のカンファレンスのテーマである深めるというところにもつながっていると思います。
PMに必要なコミュニケーション力の質
Q2. 経営者や他部署（営業等）とのコミュニケーションで気をつけていることはありますか？PMが方針を決めてもステークホルダーが多すぎて利害関係を調整しきれないし、要件を持って来すぎれば自部門（製品開発部）からそっぽを向かれてしまうし、結局残業で頑張ってる感を出す位しか認めてもらえない状況です。あなたならどう落とし所を作ります？
藤田： 広告の場合は広告主さんがいて、売ってくれる代理店さんがいて、掲載してくれる媒体社さんがいて、利害が一致しないところが多々ありますと。
気をつけているのは、必ず相手にとってのお客さんを主語にするようにすること。社内でもあると思うんですけれども、「私はこう思う」というよりは、ステークホルダーの人から見て利益のあるような話し方をする、というところには気をつけています。
伊豫： こういった話はよくありますが、個人で解決するには難しい問題であることも多く、そもそも経営としてきちんと権限委譲するとか、PMに任せきるとか、そういうテーマで社内でディスカッションするとかが大事かなと思っていて。そこが解決されないと、PMはけっこうつらい面が多いなと思ってます。
齊藤： 楽天トラベルで私が個人的にやっていて、今は組織としてなのか気をつけているのは、ビジョンを語ってあげること。私たちは最終的にこういうプロダクト体系をつくってこういうビジネスモデルに対応していこうと思っていますという話を、個人的には年に１回、必ず事業の方、もしくは開発者、ディベロッパー、あとPM自身にもしてあげるようにしています。
その方向に向かうんであれば、たとえば事業の人が何か変えないといけないとするならば、こう変えましょうという議論もするようにしています。
藤田： それは一斉にですか、それとも1on1の形式なんでしょうか。
齊藤： 今は基本３つにわけています。PMに対するセッション、事業の方々・マーケティングの方々に対するセッション、ディベロッパーに対するセッションの３つです。
ビジョン自体は一緒なんですが、話す内容を少し変えていて、事業の方だとできるだけ数字とビジネスモデルが多めの話を、PMにはプロダクト全体の話を多めにしていて、ディベロッパーにはこういうAPI、こういうプロダクト、こういうフレームワークが必要になると思うといったテクノロジーの話と、少しずつ意味合いを変えて３つのセッションにしております。
機能の取捨は、数字よりもユーザーを見て決める
Q3. ある程度育ってきたプロダクトだと「なにをしないか」「なにを捨てるか」の判断が業務の大半になってきます。組織としてもどんどん身動きが取れなくなり、なにもできなくなってしまいがちなのですが、みなさんのオススメの「捨て方」を教えてください。
及川：特にモバイルのアプリケーションって機能を追加していくと、UI上も置く場所が無くなったりメモリも増えるしということで、機能という意味でも削ぎ落としていくような定期的な棚卸しのようなものが必要だと思うんですね。そのときのみなさんのオススメの仕方について教えていただけますか。
御代田： やっぱり数字を全部見るしかないんじゃないですかね。常にありとあらゆる数字を全部取って過去の数字もログを取っておくと、その機能が使われているのかがわかると思うので。クオータリーとは言わないですけれど、6ヶ月に一回とかレビューするとか。
実際に使ってもらっているエンドユーザーとの会話の中で、あれだけがんばってつくった機能が全然使われてないことがわかったら、しれっと3ヶ月後にこの機能消えますみたいなアナウンスをしたりしています。そういう方法がいいんじゃないかなと思います。
及川：メルカリでは機能を削ったことはあるんですか？
伊豫： 一応ありますね。メルカリにはコメント機能があるんですが、ぼくがやっていたアメリカ版でプライベートチャットに移行しました。コメントを消すのが怖くて、しばらくコメントとチャットという2つの機能が共存していたんです。
おもしろいことに数字を見ると、2つコミュニケーションルートがあった方が購入が伸びるんですよね。ですが、最終的には捨てるという判断をしました。お客様から見て、あるいは直接お話を聞いて、どっちがより便利だと思っているかということからPMが決めたっていう。そういったところに勘所を効かせるのもPMのセンスかなと思うんです。
「えいや」でやるっていうのは、現実問題よくある話なんじゃないかなと。数字を見ると2つあったほうがいいよねみたいなこともあるので、数字では判断できないこともあると思います。
御代田： 最終的に誰かが悪役になることってありますよね。
伊豫： ありますね。それは「お客様がこっちだって言ってる」とPMが言うべきことを言うような。ぼくらが何を目指している、かということですね。
齊藤： ビジョンを決めるとお話したんですけれど、その中でどうやってビジョンを決めていくという話もあって、正直ここは私自身も、私のいる組織も、すごく悩ましいところではあります。
私が心がけているのは、あるユーザーシナリオからきている機能は、実はこういうかたちで達成できるんだっていう、少しに逃げの言葉で言うとワークアラウンドを用意してあげることで、いらなくなった機能を切っていくのを心がけています。
ユーザーがシナリオとして何をされたいのか、だからこの機能は使われている、だけどもある問題があってこの機能は切りたい、であれば一旦立ち戻って、このシナリオができればいいんですよね、であれば問題が解けた状況でこの機能を足しておけばこの機能は切れますよねっていうようなディスカッションをするように心がけています。
及川：確かに、ものごとを決めるときに手段と目的が混同してしまうことがあります。その手段自身が目的になっていないのならば、その手段の代替手段を用意することで、その手段をなくすということはあると思う、というお話ですね。
後編はこちら
