PdMは各部署を結ぶ“ファシリテーター”　入社4ヶ月の新入りPdMができること・できないこと

新入りプロダクトマネージャーの取り組み

永橋剛氏（以下、永橋）：今回私からはPdM、プロダクトマネージャーとして取り組んだことについてご紹介したいと思います。プロダクトマネージャーってなに？って方もおられるかもしれないので簡単にお伝えすると、世の中的には事業企画や製品企画が一番イメージに近いかと思います。そして弊社でのプロダクトマネージャーとしての取り組みについて本日はお話しさせていただくのですが、実は入社4ヶ月目であり、新入りプロダクトマネージャーなんです。というわけで本日は、新入りプロダクトマネージャーの入社4ヶ月の取り組みについてお話ししたいと思います。よろしくお願いします。

まずは自己紹介をさせてください。私、永橋と申します。経歴は、1社目がSIer、前職はオープンソースの製品を扱う会社に在籍していました。そして現在は2020年10月にラクスに入社し、入社4ヶ月がたったところです。（※イベント時）。普段の役割としてはお伝えしたとおり、「楽楽販売」という製品のプロダクトマネージャーをしています。

本日お話しする内容です。まずは事業の課題、プロダクトマネージャーの取り組みをお伝えした上で、メインである入社直後から取り組んだことをお伝えします。最後に、これはどちらかというと私の宣言に近いのですが、今後こういったことをプロダクトマネージャーとしてやりたいというところをお伝えします。

プロダクトの課題はどこにあるのか

さっそく入っていきたいと思いますが、まずはプロダクトの課題というところで、製品説明を最初にしたいと思います。

みなさん、会社で受発注の処理だったり、営業さんが見積もり管理をされていると思うのですが、（「楽楽販売」は）その販売管理をシステム管理する製品です。クラウドサービスとして提供し、Webデータベースがもとの始まりなので、カスタマイズもできるような製品になっています。

現在の状態について、簡単に事業面と、組織面、製品面について、IRの資料から引っ張ってきた内容をお伝えすると、おかげさまで昨対比でもかなり売上も伸び、組織としても開発と営業・CS（カスタマーサクセス）で分かれており、事業部制になっています。製品面に関しても、LTVも向上しているので、ありがたいことにけっこう順調です。

「順調ならいいんじゃないの？」というところですが、ここで、プロダクトの課題というか、事業面とプロダクトを合わせたような課題が出てきます。売上と、あとプロダクトの状態とともに順調であるがゆえに、会社から今後さらなる成長を求められています。

そのさらなる成長を維持するために、やっぱりプロダクトをさらに強化しないといけないねと。ただ、Webデータベースとしては成熟しているので販売管理でより強みを出していこうとなり、細かいところは割愛しますが、新たな領域の部分を今の製品でやって、機能別というよりは組織横断でいろいろと考えていかないといけないねとなっています。

プロダクトマネージャーとはなにか

ところで、「事業面・製品面、両方考えて作るの、プロダクトマネージャーの仕事なんじゃないの？」というところなのですが。

ちょっと順番が前後しますが、プロダクトマネージャー、たぶん本日開発をメインにされている方が多いと思うので簡単にお伝えすると、こうなっています。

何かというと、プロダクトを起点として、それをもとにどういう製品を作って、それを市場に届けて、ユーザーに使ってもらうかを描いていくと。一番下に書いているような、製品戦略や、ロードマップの作成、ビジネス側からの要件を業務要求に落とし込んでいき、システムをこういうふうに作っていくみたいな話で、間の橋渡しであったりプロダクトのあるべき姿を描いていくのがプロダクトマネージャーだと、世の中的には言われています。

この「プロダクトマネージャーとは？」で調べてもらうと、けっこう世の中的にブレているというか、明確に決まっていなくて、社内でも製品によって「どこまでの領域をプロダクトマネージャーが見るか？」みたいなところがあったので、入社してしばらくした時に、開発部内に対して「僕こんなふうに捉えています」みたいに整理した内容がこちらです。

このあたりで、私、永橋が一番下に矢印で書いてあるところを今後担っていくつもりで現在動いています。このへんは参考程度に見ておいてください。

ということで、社内の課題の状況は、「PdMしたくても、開発メンバーも、管理職も手一杯で、どうしようか？」というのが、私の入社前の状況でした。そこで「じゃあ採用しようよ」となって募集があり、私が採用されました。

プロダクトマネージャーとして取り組んでいること

そして、ここからが私の取り組みになります。

前職でもプロダクトマネージャーに近いことはしていたんですが、今回弊社で行うににあたって、「よし、がんばろう！」と、さっそく取り組もうと思ったのですが、まぁどんな仕事もそうですが、入社1ヶ月目の人間では務まりません。特に「製品はこうあるべきだよね」みたいなところを入ってすぐの人間が言えるわけもなくて……ということが最初にありました。

そんな中この4ヶ月で取り組んだことは大きく3つです。全体を押さえるということ、他部署とのネットワーク構築、あとはファシリテーターになるということで取り組んでいきました。

全体を押さえるということ

1つ目、全体を押さえることというのは、自社の製品、あとは競合の製品、社内状況です。数名で作っているプロダクトではなく、開発メンバーも十数名いて、営業に関してはもっとたくさんいるので、社内の状況も押さえないといけない。

じゃあどうやって押さえる？　どこまで知ればいいの？　プロダクトマネージャーとして、やっぱある程度ひととおり押さえないといろいろ決められないので、どうしようかなと。

私がちょっと仕事とは別で勉強している、あるフレームワークを使って整理してみました。これは検索していただいたらよく出てくると思いますが、「3C分析」と言いまして、自社と競合、あとは外部環境で、顧客と市場の状況を整理するフレームワークです。

あとは「STP」「4P」といって、マーケティングのフレームワークですね。「どこをターゲットとして、どういうポジションを取って、どういう販売戦略・価格戦略で売っていくか？」みたいな現状の整理を、フレームワークを使い自分の中で整理しました。

ただ、ここを完璧にやり始めるとキリがないので、ポイントとして「Quick&Dirty」で、ちょっと簡単にさらっと作って、上司にはもちろん知見があるので、上司とすり合わせて私の認識を揃えていくということを、積極的に進めていきました。

一応参考程度になのですが、すみません、このへんがけっこう核となる情報なのでほとんどお見せはできないんですが、（スライドの）右下のかたちで、「セグメンテーション、ターゲティング」「どういうポジションをとるか」みたいなのを左側にまとめて、右側の4Pというフレームワークで「製品の特徴」だったり、あと「価格」「どういうかたちで売っていて、どういう販売のプロモーションをやっているか」を整理しました。

ここちょっとポイントとして伝えようと思っているのは、けっこう幅が広いので「何の情報を集めたらいい？」「何を調べていったらいいかわからない」というときに、こういうビジネスフレームワークを使うと、埋めたいという欲求にけっこう人間は駆られるので、例えば「Promotion」というところ。私も開発出身なので、どういうふうにプロモーション、マーケティング戦略しているかわからないので、「ここを埋められていないな。ここを把握するために営業のほうにちょっと聞いてみようかな」というかんじで進めるので、枠にはめるというのがよかったと思います。

というところと、あとは「So What？」と言いまして、この情報からつまり「社内の状況とかプロダクトって今どういう状況なの？　良い状況なの？　悪い状況なの？　こういうところに課題があるんじゃないの？」の結論まで書くと、全体の整合が取れているかが見えるので、ここまで意識してやるといいかなと思います。

他部署とのネットワーク構築

2つ目は他部署とのネットワーク構築です。1つ目で全体を押さえる情報を集めたいんですが、この入手先を見つけないといけないですよねと。私1人でイチから調べていると時間かかるので、どうしようかというところで、他部署とのネットワークを構築しました。

このコロナ禍なので必ずしもできるわけではないんですが、可能であれば一度リアルで会うことは、やっぱり重要だったなと思いました。

そのあとはオンラインでもいいので、定期的に営業・サポートの方と今は3名で週次のミーティングをやっていて、そこで情報共有・情報交換して、（ネットワークを）構築して情報を集めるために日々動いています。

ファシリテーターになること

最後のポイント3つ目です。「ファシリテーターになる」というところ。これまで、フレームワークで全体を押さえて、そのあとネットワークを作ってちゃんと情報も取れました。「社内調整もうまくできるんじゃないの？」「情報も一定数頭に入ったし、僕はもうあと決めるだけじゃないか？」と思ったんですけど、「楽楽販売」の開発トップと事業部長とミーティングしても、まったく発言できませんでした。

「あれ？」と。PdMとして各部署の話を聞いて、方向性である「こっちやりましょうよ」とか「こういう機能作ったらいいんじゃないですか？　なぜならこうです」みたいにやっていくのが一番あるべき理想の姿なんですが……できないですと。

というわけで、スタイルを変えました。まだまだ知識が足りないということはいったん受け入れて、ファシリテーターとしてこの1〜2ヶ月は進めています。

冷静に考えたら、1〜2ヶ月調べたぐらいで先頭を走れるわけがないんですよね。なので、社内の知見をもっている人はたくさんいるので、その方々の各部署の議論を円滑に進めるためにファシリテートに意識を集中しました。開発は開発、営業は営業、サポートはサポートで、やっぱりそれぞれ重要だと感じているところに濃淡があるので、2つ目のところに書いてあるとおり、そこを言語化し明文化し、それを「みなさん同じ認識ですか？」と確認を取りつつ、決定スピードを速めることに今取り組んでいます。

まとめと今後について

というところで、これまでのまとめです。

まずは全体を押さえるためのフレームワーク。これ以外もあるんですが、この2つはビジネス系のフレームワークとしてはよく出てくるので、このあたりを押さえるのをおすすめします。

2つ目は他部署とのネットワーク構築。ファシリテーターになって、社内の知見をもっている方々をうまく統合させてスピードを速めるように、今まで取り組んできました。

メインは以上で、最後に私の今後について。プロダクトの方向性、あるべき姿として、プロダクトマネージャーはこういうことをしないといけないので、というか私個人としてももちろんやりたいので、そこを定性・定量データをもとに判断できるようにしたいと思っています。

あとは、PdM以外にPMMというマーケティング寄りのプロダクトマネージャーもあり、その領域にも興味があるので、徐々にでも入っていき、そのあたりの知識も貯めていきたいなと思っています。

以上になります。ありがとうございました。

PdMが来る前はどうしていたか

藤澤貴之氏（以下、藤澤）：ありがとうございました。今日はPdMという文脈でしゃべってもらいましたが、わりと転職や異動などで新しい組織に入っていくときのアプローチの仕方としても使えそうな話でした。

池田智裕氏（以下、池田）：最初に「社内の部署をつなぐ役割に徹したということなんですね」という質問とも感想とも言えないものがきていますが、そういう感じでしょうか？

永橋：そうですね。プロダクトマネージャーに関しては、もう本当に業界のドメイン知識などをすごくもっていて先頭を走る人もいれば、つなぎ役にずっと徹するという場合もあったりするので、それぞれのスタイルでいいのかなと思っていて、私は今はまずはつなぎ役が一番役に立てるかなと考え動いていますね。

池田：ありがとうございます。「ちょっと聞きそびれたかもしれないですが、以前からPdMはいらっしゃったんでしょうか？　PdMがいなかった時代の開発はどう取りまとめていたんだろうと思いました」という質問がきています。

永橋：弊社ではPdMを推進しようと、私以外も開発部のほうでPdMを増やしていっています。

「PdMがなかった時代は誰がやっていたの？」は各製品によってバラバラですけれども、「楽楽販売」に関しては、開発のトップの方が最終製品のレビューも含めて見ていたんですが、管理職なので、やっぱり両方、両立ってけっこう難しいところではあるので、今回、別で立てようという意見になったと聞いています。

藤澤：いろいろな役割を兼務しながらPdM的な要素もやっていた人がいたと。それをわりと専任みたいな感じで今、永橋さんがやっていますということですかね。

永橋：そうですね。私も前職でPdMに近いかたちで、かつ、管理職に近いようなかたちでメンバーを見ていたので、そうするとけっこう脳内でコンフリクトが起きるんですよね。

管理職なので、残業はさせられない。でも、PdMってプロダクトのことを考えるので、極論を言うと、メンバーの残業とかではなく、プロダクトがあるべき姿に早くなってほしいので、そこでコンフリクトが起きるので、分けるほうがいいかなと私自身も感じているところですね。

藤澤：そっちはどちらかというと、プロジェクトマネージャーとかが、差配をちゃんとするというところで折り合いをつけていく枠組みのほうがよいのでは、という感じですかね。

永橋：そうですね。よく言われるのは、プロジェクトマネージャーはWhenとHowに責任をもつ。いつ・どのように終わらせるか。プロダクトマネージャーはWhyとWhat。なぜそれをやるのか・何をやるのかを決めるところで、役割が分かれるかなと思います。

藤澤：今ちなみにプロジェクトマネジメントしている人との間で、コンフリクトって起きたりはしているんですか？　

永橋：僕はまだ起きていない認識です。私もPMの経験もあるので、気になっているだろうなというので極力伝えていますし、PMもまだ入ったところというのもあるので、配慮してもらっているのかなというところがあります。

技術用語などを非エンジニアとも共有する工夫

池田：けっこう続々と質問がありまして。「言語化という点で技術用語などをうまく非エンジニアにも共有できるような工夫など、何かされていますか？」。

永橋：ここは正直、体系立ててとかは、本とかあまりなくて、私は1社目で受託のシステム開発をしていて、けっこうお客さんとのやりとりをしていたので、そこでそういう意識はあるかな。とか、エンジニアに見せる資料と営業に見せる資料は変えたほうがいいなというところで。うーん、ちょっと難しいですね。

でも、けっこう最近思っているテクニックとしたら、Zoomでやるときに2画面で反応を見るというのをよくやっています。「伝わっているかな？」って。

藤澤：ああ、どこまで通じるかみたいな。

永橋：はい。

池田：逆に私たちの会社の営業とか企画側って、古い方とかだと技術的なことを書いても理解してくれたりする人も中にはいるので、そういうのに甘えちゃうと、新しい人が入ったとき、専門的な用語を使っちゃって、とかやっちゃうかもしれないですね。

藤澤：ご質問に対する回答という意味だと、言い換えるとか表現の仕方を変えるという工夫をしているということですかね。

永橋：そうですね。変える工夫はしています。あとは、ふだんエンジニア以外と付き合うというところかなと。仕事以外とかプライベート、友人とかも。だとすると、伝わらないなというのがわかる。

藤澤：どういう言語、言葉の中で仕事をしているのかとかも変わってきますもんね。

池田：ちょっと似ているかわからないですが、2つ質問ありまして。1つは「製品の把握、今の『楽楽販売』の製品の把握と、外部の競合とかの把握の、そのどちらに比重を置かれていますか？」という質問と、もう1つ似たようなやつで「海外のそういった競合のサービスをウォッチしますか？」というようなご質問がありまして。

永橋：まず1つ目が、比重を置いているのが、現状は社内がまだ多いですね。

池田：2つ目が「海外の競合のサービスも調べていますか？」というところで。

永橋：販売管理という領域では調べていないという結論になります。むしろもっと広く「クラウドサービスでどういうことやっているか？」などのニュース程度にはウォッチしているかなというところ。

ですが、製品観点でいくと、やっぱり海外と日本って言語が違うというところと、販売管理のところだと商習慣がけっこう違うので、海外のものがそのまま当てはまらないことがけっこうあるので、あまり意識しなくていいかなというのが今はありますね。

池田：あと、「PdMの主体の事業部、ビジネスサイドということなんですが、具体的にどのような役割分担や棲み分けが行われているか教えてほしいです」というような質問が。

永橋：一言で回答すると、これから棲み分けていくというところ。どちらかというと今は「開発は開発、営業は営業」と役割を分けていたので、そこの領域を私が今両方入って、一定仕組みができてきたら「ここまでは営業のほうで情報をください。ここからは開発でやります」みたいに。なので、そこのグラデーションのところを今私が入っているという状態ですね。

PMとPdM、どちらの話を聞けばいい？

藤澤：なるほど。もう1つ「現場でPMとPdMがいる状態だと、『どっちの話を聞いたらいいのだろうか？』といった混乱が起きませんか？」ということなんですが。

永橋：まぁ、起きる場合もあると思いますが、現状はまだ起きていないかなと思います。

藤澤：さっきの「コンフリクトって起きるんですかね？」という話と同じ？

池田：そうですね（笑）。永橋さんの中でコンフリクトしていたのが、役割を分けると、その中でコンフリクトしませんかという感じでしょうか。

永橋：そうですね。だから、どっちに責任をもっているかというのをちゃんと会話できていれば、WhyとWhatのPdMと、PMはWhen・Howなので、僕は「何を作ってください。一定のロードマップはこの時期まで」だけ今後ちゃんと描ければ、あとは「どう作るか、いつまでに作るか」はPMの管轄で、大幅に遅れない限りは私が入る領域ではないですし。というので棲み分けをしていけたらなと思っています。

藤澤：そういう意味で言うと、製品戦略上の優先順があるから、「ここまで絶対押し込んでくれ」みたいなのはそもそもあんまり起きにくいという感じなんですかね。

永橋：うーん、私の経験では起きないですけど、社外を聞いていると、あると思います。どっちのほうが力をもっているとか、社内的にとかっていうのはあるので、そこはパワーバランスが。

PdMを立ててなくて、例えば社長が製品を決めている場合とかだと、社長のほうがやっぱり力が強いので、開発に「これをいついつまでに作ってくれ」とけっこう開発がつらいとかもあったりするでしょう。なので、起きる会社もぜんぜんあると思いますね。

池田：目的と手段で、プロジェクトマネージャーは手段の部分になるんですが、手段先行にならないために、というところでプロダクトマネージャーという存在の価値があるのかなとは思いますね。

永橋：そうですね。今質問いただいているみなさんとか本日の参加者を見るとおそらく開発の方が多いと思うので、僕の首は締まるんですけど、あえてお伝えすると、開発側からするとPdMに言えることって、「いっぱい作れ」って言われたときに、「それって何のために作るんですか？　ユーザーにとって価値あるんですか？　売上どれぐらい見込んでいるんですか？」ということと、開発として「詰め込みすぎじゃないか？」というところだと思います。

それがPdMとしてちゃんと描けていれば論理的に説明ができるので、「じゃあ作りますか？」というものをたぶん開発側も納得できますし、逆に「うーん、なんとなく」という場合は「いやいや、だったらここまでそんな詰めなくていいよね」って論理的に会話できるので。

池田：うん。なんか工数も少ないほうとかに行きがちですよね。そうなると。

藤澤：そうか。だから、全体の納得感の醸成で言うと、そもそもコンフリクトしないようにするための役割がPdMですね。

池田：そのための存在でもありますよね。

永橋：それもあると思います。なんで作るかをちゃんと説明できないといけないので。でも、やっぱり「なぜ？」がなかなか作れないというのはよくあると思いますね。

藤澤：なるほど。どうもありがとうございました。

池田：ありがとうございました。

永橋：ありがとうございました。