プロダクトマネージャー（PdM）の役割と組織構造　ラクス、LegalOn Technologies、Chatworkの事例を比較

Chatworkの開発組織

川東大悟氏（以下、川東）：では、Chatworkの松下さま、役割のご紹介をお願いいたします。

松下三四郎氏（以下、松下）：はい、ありがとうございます。こんなに資料を作り込んでいるのかっていう……自分が登壇前に手作業でDIYで作っちゃった資料でちょっと申し訳ないんですけど（笑）。

川東：いえいえ（笑）。

松下：全社の組織図は特になくて、自分が関わっているところだけ作りました。左からCEO、COOで、コミュニケーションプラットフォーム本部というのがChatwork事業になります。ここの執行役員で、次のユニットというのがVPレイヤーで、部が部長、その下に実行部隊であるチームがあります。

まず私の主務というか、立ち位置を知っていただいたほうが全体感が見えると思うので、一応このコミュニケーションプラットフォーム本部の直下に私が主務としています。あとは全社側のプロダクト戦略室と、その実行チームのグロースも兼務でやらせてもらっています。次の……。あ、ごめんなさい（笑）。このスライドで一応イメージ的にはChatwork事業はProduct-Led Growthという戦略でやっています。

Webで検索してくだされば全体像が見えると思うんですけど、Product-Led Growthなのでプロダクト戦略がすごく重要になってきています。その中で、その戦略に携わりながら実行までやっているというのが一応私の特徴で、戦略も実行もやらせてもらえるという、なんとも贅沢な役割をやらせてもらっているんですけど（笑）。一応そういったところとか、マーケティング、プロダクトのブリッジ役として私が入ったりしています。

実際にユニットの一番下に「プロダクト開発ユニット」というのがあるんですけど。先ほどのLegalOnさんと同じようなかたちで、プロダクトマネジメント部の横にデザイン部もあって、プロダクト開発ユニットの開発部がたくさんあるんですが、それらとマトリクス組織みたいなかたちになっている感じです。次のスライドでそれがもうちょっとわかります。

グロースチーム、コアチームにPdMがウン名います（笑）。その中でそれぞれのグロースチームは役割を持つ。黄色い背景のところなんですけど、Product-Led Growthのプロダクト領域の計画・実行。「計画・実行」と一言で言ってはいるんですけれど、まさにステークホルダーとの調整も含めて、自分でSQLを書いて、ふりかえりもして、次は何だという打ち手も全部考えるという感じで、けっこうアジャイルな組織になっています。それは次に説明します。

もう1つコアというところが基盤領域というのを支えるようなプロダクト。プロジェクト型っぽい案件が多いです。「プロダクト」と書いちゃっていますね。けっこう長期のロードマップのものが多くて、そういったことをやっています。2024年1月、まさに先月ぐらいからそれぞれ新たな取り組みも始めています。次のスライドをお願いします。

ChatworkのPdMの役割

松下：ちょっと特徴を出してみたんですけれども、私がリードさせてもらっているグロースチームにいるPdMが、もともとBiz側にいたんですよね。それで、デザイナーとのコミュニケーションで「グロースのPdMって何なんだ？」というところ……私がジョインして半年とか7ヶ月ぐらいなんですけど、そういったことを定義させてもらってこういうこともやっています。その定義に基づいてやっていこうという感じですね。

ちょっと読み上げると、もともとPdMはお客さまに価値を提供するんですけど。価値を提供するだけじゃなくて、結果として数字を上げないといけないというのがまずあります。Product-Led Growthなので、数字を上げることを前提として価値を提供しようというところにフォーカスしているということです。

左下はなんかいろいろとドキュメントとかのタイトルだけを引っ張ってきていたり、右下はやはりグロースなので、とにかく施策の最適化ではなくて最大化を意識してやっていこうみたいなことを思想として掲げたりしています。

この図は、私が今日のためにちょっと作ったんですけど（笑）。「Growth PdM Pentagon」と自分で名付けているんですが、プロダクトマネジメントに関わる各5要素を一応出してみました。私はちょっとプロダクトビジョン側も入っているんですけど、Growth PdMの役割はまさに価値を決めた右下のプロダクトバックログから、価値を提供しようという企画だけじゃなくて、KPIドリブンでやっているというところをかなり特徴的にやっています。

なので左下のKPIツリーもプロダクトKPIツリーの全体像があって、その中でターゲットになるKPIに相関のあるKPIをしっかりと出しきった上で、そのKPIを上げるために施策をやっていくのが特徴的で、それでプロダクトバックログとPRDという流れになってきて、デリバリーしていくというところ。それぞれの領域で価値を上げてお客さまの課題解決をしてグロースしていくという流れになっています。

なので特徴的なところは右上に、KPIツリーを常にアップデートしていく。そしてその中でターゲットKPI。いくらでもKPIは出てくるので、ターゲットをしっかり決めて、そこに対してKSFとして価値と数字を近しく突き合わせる。その中でプロダクトバックログをアップデートしながら企画化していくという、そういう流れになります。

川東：以上ですかね。ありがとうございました。3社のみなさまのPdMの役割と組織の話をさせていただきました。もう、おもしろいですね。三者三様と言いますか（笑）、特にこのGrowth Product Managerというところの、何というんですかね。かなり攻めのPdMと言いますか、そこがおもしろいなと思いました。

ロードマップ作成の際に、PdMはどのように調整するのか

川東：じゃあせっかく、みなさんからもチャットに質問をいただいていますので、最初にちょっとこちらを取り上げていきたいと思います。

まず、これはラクスに対してのご質問かと思うんですけれども。「採用サイトを見ていたのですが、製品ロードマップはBiz側のように見えているのですが、ロードマップ作成の際はPdMはどのスコープや納品時期、開発の制約はどのように調整するのでしょうか？」ということで、このへんの絵（スライド）がよろしいですかね？

稲垣剛之氏（以下、稲垣）：はい。松下さん、ご質問ありがとうございます。

松下：お願いします。

稲垣：おっしゃるとおり、Biz側が製品ロードマップをメインで作っています。私が入るまでは、製品ロードマップをかなり大きく出していて、やはり開発の実現性がかなり加味されていないようなかたちでした。営業だったりCSの方に「こういったロードマップで」といったところを伝える目的ではあったんですけど、それにしても実現可能性はかなり見えづらいような状態でした。

なので現状で言うと、製品ロードマップの全体で事業戦略とか製品戦略の大まかな部分はPMMが決めるようにしてもらっています。その大まかな項目の中で具体的にどれぐらいのものを課題設定としてやっていくのかをPdMが入って、そのタイミングでけっこうラフなPRDみたいなものを作るようなかたち。「ラフなPRD」というのは、それがあることで開発側の規模感がわかるところのレベルで作っています。

それまではけっこう事業側が「こんなことをやりたい」みたいなかたちで開発の規模感が見積もりようがないような状態だったので、我々PdMが入って、そこの課題をもう少し具体的にだったり、方向性がある程度開発で概算が見積もれるぐらいの粒度のPRDを作る。そうなってくるとだいたいどれくらいの規模感でだったり、どの順番でやるほうが開発的にいいのかが明らかになってくる。

なので、大まかなテーマはBiz側が作って、そこを細分化していく部分でPdMが入って、製品ロードマップはより現実的に近いようなかたちで作る。かと言って、3年先になってくるとちょっと見えないので、1年ぐらい先だったり1年半ぐらい先のところはある程度開発も見通せるし、そこまでリリースアイテムが大きくズレるようなことがないようにというところで、なんとかしているようなかたちですね。

やはりお客さまに価値を出していくのは重要なので、大きな案件でいうとけっこう分割をしていくところは、PdMもしっかり入って開発と相談をしながら本丸の解決ももちろんするんですけど、小さく解決できるものは分割をして価値提供をしていく。というところで、できるだけ製品ロードマップ自体があまり絵に描いた餅にならないように、PdMが入っていくようなかたちを取っている感じですね。

川東：ありがとうございます。

Chatwork、LegalOn Technologiesの場合

稲垣：ちなみにChatworkさんとかLegalOnさんは、そのへんはどうされていますか？　ここらへんは難しいかなと思うんですけれども。

泉真悟氏（以下、泉）：LegalOnの場合でいくと今はちょっと新しいチャレンジもしているので、ロードマップはけっこうPdMが敷いたりしています。今課題に挙げているのはちょっと夢が大きくなっちゃっているなという感じで、そこをこれから調整しようかなというところです。

稲垣：なるほど（笑）。

泉：それは試行錯誤しているという感じですね。

稲垣：なるほど。そうですよね、ありがとうございます。

松下：Chatworkの場合は、そうですね。年間のロードマップみたいなかたちはあるんですけれども、けっこうアジャイルな開発もやっているということもあるので、どちらかというと「このテーマを問いていこう」という感じで決めています。例えばグロースのところでは、コンシューマーとかだったらよくあるんですけど、初日にちゃんとお客さまにやってほしい設定だったりとか、お客さまにアハ・モーメント。

どういう瞬間で体験を作っていくかというFTUXという、日本ではまだあまり浸透していないFirst Time UXなんですけど、FTUXに特化して、そこを継続してDay 7 Retention Rateを何パーセントに上げることを目標として、テーマとしてそういったロードマップを敷く。そういう感じになりますね。

稲垣：おもしろいですね。僕もECをやっていたのでやはりリテンションとか、入ってどれだけ使ってもらえるかでそのあとの継続率が変わるというところがあったので。けっこうデータを見てそこを伸ばしていくみたいなかたちは……当社だとそこに「データを見て」というのがなかなか難しいので、違う話が聞けておもしろいですね。

松下：ありがとうございます。Chatworkの場合はもちろんSaaSなのでどうしてもARRとかは大事なんですけれど、お客さま一人ひとりがチャットを使いこなしているかという観点がものすごく大事なので、どうしてもアクティブユーザーという観点が外せないんですよね。なので一人ひとりの継続率をすごく重視しているのはありますね。

稲垣：そうですよね。

川東：ありがとうございます。おもしろいですね。開発のやり方の違いによってこのロードマップも違うんだろうなと思いました。ありがとうございます。

（次回へつづく）