2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
川東大悟氏(以下、川東):では、Chatworkの松下さま、役割のご紹介をお願いいたします。
松下三四郎氏(以下、松下):はい、ありがとうございます。こんなに資料を作り込んでいるのかっていう……自分が登壇前に手作業でDIYで作っちゃった資料でちょっと申し訳ないんですけど(笑)。
川東:いえいえ(笑)。
松下:全社の組織図は特になくて、自分が関わっているところだけ作りました。左からCEO、COOで、コミュニケーションプラットフォーム本部というのがChatwork事業になります。ここの執行役員で、次のユニットというのがVPレイヤーで、部が部長、その下に実行部隊であるチームがあります。
まず私の主務というか、立ち位置を知っていただいたほうが全体感が見えると思うので、一応このコミュニケーションプラットフォーム本部の直下に私が主務としています。あとは全社側のプロダクト戦略室と、その実行チームのグロースも兼務でやらせてもらっています。次の……。あ、ごめんなさい(笑)。このスライドで一応イメージ的にはChatwork事業はProduct-Led Growthという戦略でやっています。
Webで検索してくだされば全体像が見えると思うんですけど、Product-Led Growthなのでプロダクト戦略がすごく重要になってきています。その中で、その戦略に携わりながら実行までやっているというのが一応私の特徴で、戦略も実行もやらせてもらえるという、なんとも贅沢な役割をやらせてもらっているんですけど(笑)。一応そういったところとか、マーケティング、プロダクトのブリッジ役として私が入ったりしています。
実際にユニットの一番下に「プロダクト開発ユニット」というのがあるんですけど。先ほどのLegalOnさんと同じようなかたちで、プロダクトマネジメント部の横にデザイン部もあって、プロダクト開発ユニットの開発部がたくさんあるんですが、それらとマトリクス組織みたいなかたちになっている感じです。次のスライドでそれがもうちょっとわかります。
グロースチーム、コアチームにPdMがウン名います(笑)。その中でそれぞれのグロースチームは役割を持つ。黄色い背景のところなんですけど、Product-Led Growthのプロダクト領域の計画・実行。「計画・実行」と一言で言ってはいるんですけれど、まさにステークホルダーとの調整も含めて、自分でSQLを書いて、ふりかえりもして、次は何だという打ち手も全部考えるという感じで、けっこうアジャイルな組織になっています。それは次に説明します。
もう1つコアというところが基盤領域というのを支えるようなプロダクト。プロジェクト型っぽい案件が多いです。「プロダクト」と書いちゃっていますね。けっこう長期のロードマップのものが多くて、そういったことをやっています。2024年1月、まさに先月ぐらいからそれぞれ新たな取り組みも始めています。次のスライドをお願いします。
松下:ちょっと特徴を出してみたんですけれども、私がリードさせてもらっているグロースチームにいる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と言いますか、そこがおもしろいなと思いました。
川東:じゃあせっかく、みなさんからもチャットに質問をいただいていますので、最初にちょっとこちらを取り上げていきたいと思います。
まず、これはラクスに対してのご質問かと思うんですけれども。「採用サイトを見ていたのですが、製品ロードマップはBiz側のように見えているのですが、ロードマップ作成の際はPdMはどのスコープや納品時期、開発の制約はどのように調整するのでしょうか?」ということで、このへんの絵(スライド)がよろしいですかね?
稲垣剛之氏(以下、稲垣):はい。松下さん、ご質問ありがとうございます。
松下:お願いします。
稲垣:おっしゃるとおり、Biz側が製品ロードマップをメインで作っています。私が入るまでは、製品ロードマップをかなり大きく出していて、やはり開発の実現性がかなり加味されていないようなかたちでした。営業だったりCSの方に「こういったロードマップで」といったところを伝える目的ではあったんですけど、それにしても実現可能性はかなり見えづらいような状態でした。
なので現状で言うと、製品ロードマップの全体で事業戦略とか製品戦略の大まかな部分はPMMが決めるようにしてもらっています。その大まかな項目の中で具体的にどれぐらいのものを課題設定としてやっていくのかをPdMが入って、そのタイミングでけっこうラフなPRDみたいなものを作るようなかたち。「ラフなPRD」というのは、それがあることで開発側の規模感がわかるところのレベルで作っています。
それまではけっこう事業側が「こんなことをやりたい」みたいなかたちで開発の規模感が見積もりようがないような状態だったので、我々PdMが入って、そこの課題をもう少し具体的にだったり、方向性がある程度開発で概算が見積もれるぐらいの粒度のPRDを作る。そうなってくるとだいたいどれくらいの規模感でだったり、どの順番でやるほうが開発的にいいのかが明らかになってくる。
なので、大まかなテーマはBiz側が作って、そこを細分化していく部分でPdMが入って、製品ロードマップはより現実的に近いようなかたちで作る。かと言って、3年先になってくるとちょっと見えないので、1年ぐらい先だったり1年半ぐらい先のところはある程度開発も見通せるし、そこまでリリースアイテムが大きくズレるようなことがないようにというところで、なんとかしているようなかたちですね。
やはりお客さまに価値を出していくのは重要なので、大きな案件でいうとけっこう分割をしていくところは、PdMもしっかり入って開発と相談をしながら本丸の解決ももちろんするんですけど、小さく解決できるものは分割をして価値提供をしていく。というところで、できるだけ製品ロードマップ自体があまり絵に描いた餅にならないように、PdMが入っていくようなかたちを取っている感じですね。
川東:ありがとうございます。
稲垣:ちなみにChatworkさんとかLegalOnさんは、そのへんはどうされていますか? ここらへんは難しいかなと思うんですけれども。
泉真悟氏(以下、泉):LegalOnの場合でいくと今はちょっと新しいチャレンジもしているので、ロードマップはけっこうPdMが敷いたりしています。今課題に挙げているのはちょっと夢が大きくなっちゃっているなという感じで、そこをこれから調整しようかなというところです。
稲垣:なるほど(笑)。
泉:それは試行錯誤しているという感じですね。
稲垣:なるほど。そうですよね、ありがとうございます。
松下:Chatworkの場合は、そうですね。年間のロードマップみたいなかたちはあるんですけれども、けっこうアジャイルな開発もやっているということもあるので、どちらかというと「このテーマを問いていこう」という感じで決めています。例えばグロースのところでは、コンシューマーとかだったらよくあるんですけど、初日にちゃんとお客さまにやってほしい設定だったりとか、お客さまにアハ・モーメント。
どういう瞬間で体験を作っていくかというFTUXという、日本ではまだあまり浸透していないFirst Time UXなんですけど、FTUXに特化して、そこを継続してDay 7 Retention Rateを何パーセントに上げることを目標として、テーマとしてそういったロードマップを敷く。そういう感じになりますね。
稲垣:おもしろいですね。僕もECをやっていたのでやはりリテンションとか、入ってどれだけ使ってもらえるかでそのあとの継続率が変わるというところがあったので。けっこうデータを見てそこを伸ばしていくみたいなかたちは……当社だとそこに「データを見て」というのがなかなか難しいので、違う話が聞けておもしろいですね。
松下:ありがとうございます。Chatworkの場合はもちろんSaaSなのでどうしてもARRとかは大事なんですけれど、お客さま一人ひとりがチャットを使いこなしているかという観点がものすごく大事なので、どうしてもアクティブユーザーという観点が外せないんですよね。なので一人ひとりの継続率をすごく重視しているのはありますね。
稲垣:そうですよね。
川東:ありがとうございます。おもしろいですね。開発のやり方の違いによってこのロードマップも違うんだろうなと思いました。ありがとうございます。
(次回へつづく)
関連タグ:
1日何百回触ってもらえるサービスに携わることはそうそうない ChatworkのPdMになって感じた凄いこと
リーガルテックと業務効率化の企業でPdMは何をするのか LegalOn TechnologiesとラクスのPdMの役割
PdMの責任と役割とはなにか ラクスとLegalOn Technologiesの事例から学ぶ製品開発組織のあり方
プロダクトマネージャー(PdM)の役割と組織構造 ラクス、LegalOn Technologies、Chatworkの事例を比較
プロダクトマネージャーの役割と顧客アプローチ ラクス、LegalOn Technologies、Chatworkの事例から学ぶ
プロダクトマネージャーの顧客理解と戦略 ラクス、LegalOn Technologies、Chatworkの事例から学ぶ実践的アプローチ
プロダクトマネージメントの実践手法 ラクス、Chatworkに学ぶ顧客理解と組織づくりの戦略
近日公開予定
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには