ラクスの顧客課題収集と活用方法
川東大悟氏（以下、川東）：では次に、ラクスですね。稲垣さん、お願いします。
稲垣剛之氏（以下、稲垣）：はい。私のほうは、これが当社のお客さまの課題とか、声の収集と、その活かし方です。たぶん見てもビックリするようなことはなくて、だいたいみなさんこうやっているよねと思っていただければと思います。基本的にはカスタマーサクセスの部隊に、運用中のお客さまへのヒアリングをしっかりやっていただいて、日々チケット化するようなかたちを取っています。
なので、データが自動的に集まるような仕組みで、内容や書き方はかなりPdMがしっかり入っています。けっこう要望になりがちなんですけど、要望で書かれてしまうとわかりづらいので、やはりジョブ理論とかを使ってしっかりと課題が何なのかとか、その課題に対してどういう代替案を書いているのかとか。そういうところをしっかりと書いてもらえるようなかたちでCSの方に各社のヒアリングをしてもらい、日々上がってくる問い合わせを踏まえてデータ化というところをチケット化するようなかたちです。
あとは、新規のお客さまを営業の方が導入で動いてくれている。右上のほうの「導入検討のお客さま」というところは営業の方が、失注理由だったりをSFAを活用してしっかりデータ化してくれています。このへんのデータがしっかり集まってくると、PdM・PMMのほうでどういった方向性でいくのかだったりとか、PMMでいうとデータの全体を見た時に製品の方向性でどこを攻めていくのかを決めていただけるようなかたちになるので。
そこの方向性を決めるとそのお客さまのセグメントに絞って、さらに具体的にアクションしていくかたち。なので、そこのPRDを作っていくためのアンケートやインタビューをしたり、我々はCSにヒアリングをしたりというところで、よりその課題の解像度をPdMがしっかりとアクションしていくことが、この黄色く書いてあるところになっているかたちですね。
けっこう横道なやり方だったり、今は楽楽精算は16,000社いるので、この16,000社のデータをうまく活用しつつ、どうやって優先度を決めていくのかだったり。やはり先ほどの人によって声の大きさが違ったり、お客さまによって声の大きさが違うってもちろん重要なんですけれども。その16,000社の中で長くいるお客さまを全部優先するかというと、なかなか難しいです。
なので、できるだけデータをしっかりハッキリさせて、そのデータの中身をさらに精査して、お客さまの声を製品に活かしていくようなかたちを取っています。次のシートをお願いします。
顧客志向の組織づくり
稲垣：じゃあ顧客志向の組織作りというところでいくと、やはりPdMは当然、顧客志向にならざるを得ないので、開発側の部分を当社としてはしっかりやっていく必要がある。というところで、やはりどうしても事業部から伝わる事業戦略と、PdMを通しての事業戦略は開発の伝わり方がやはり違うかなというところがあるので、それはPdMからしっかりと事業戦略・製品戦略をお伝えする。
あとは、当社でいうと複数の案件が動いていて、開発がその案件をお互いで共有できているかというと共有できていない部分もあったりするので、そういう部分はPdMがサポートして案件の価値や目的をしっかりやっていったりとか。あとは、事業部とのミーティングも、基本的に議事録は完全に共有するようにして、それを見れば興味のある開発の方はしっかりわかるようなかたちというところ。
あとは、製品要求仕様の説明会を、特にWHYとかWHAT。なんでこれをやるんだっけ？ どのスコープでやるんだっけ？ ゴールはどのへんなんだっけ？ というところで、けっこう解決方針を踏み込んで書いてはいるんですけど、どちらかというとWHYとWHATの部分にフォーカスをして開発側にしっかり伝えるようなかたち。
開発側でよりすばらしいHOWがしっかり考えられるようにというところで、説明会を1時間ほぼ要求仕様の説明というか。WHYとWHATの説明をお客さまの危機感をしっかり伝えるような会議にすることで、よりHOWにフォーカスが当たるようなに開発とかデザインに考えてもらうようなかたちを敷いて、組織全体としてお客さま志向になるように取り組んでいる最中になります。
川東：ありがとうございます。
PRD説明会の重要性
川東：泉さん、松下さん、こちらはいかがでしょうか？ 気になるところがもしありましたら。
松下三四郎氏（以下、松下）：じゃあ私から。
川東：はい。
松下：PRDの説明会の重要性を、最近すごく意識していまして（笑）。
稲垣：いいですね。
松下：餅は餅屋で、そのアウトプットを人に渡すというところで、けっこう接続ポイントで要点だけをうまく伝えられたらOKかなという前提があったんですけど。改めてみんなに説明するという、すごく重要なところ。もちろんですけど、PMMの方が能動的にPRDをずっと探してくれていたみたいなのがあって、そこからプレスを書いてもらえみたいなことをやっていたんですけど。「それって最初から巻き込むべきじゃない？」というところとか、ステークホルダーでもちゃんと見据えた上でみんなに説明するというのがすごく大事だなと思いました。
稲垣：そうですね。
松下：なので、ミニマムであるべきじゃなくて、多少リッチでも説明するというところは……。その解が出る・出ないの選択肢は聞いてよくて、その機会を作ることが大事だなとすごく思いました。
稲垣：そうですね。当社も最初はけっこうできていなかったんですよ。どちらかというとPRDをわかりやすく書こうみたいな感じにフォーカスを合わせていたので。やはりPRDのわかりやすさというか、PRDの生々しさを伝えたほうが、開発の方にもしっかり伝わる、デザインの方にも伝わるかなというところがある。
なので方針というか、やはり「なんでこれをやるんだっけ？」というところをPdM自身が自分の言葉でお客さまの危機感をしっかり伝えるのは非常に重要。それによってやはり生まれる新しい価値はあるのかなというところで、けっこう時間はかかるんですけど、重要なのかなと思います。
あとは、おっしゃるとおり基本的に私も出る・出ないの選択はお任せするかたちを取るのと、自分の案件じゃなくても出てもいいよというかたちにはしていこうかなと思っているので、興味があるフェーズの方はどんどんいろんな会に出て、よりお客さんの解像度が上がっていくというかたちが取れるといいかなとは思いますね。
川東：ありがとうございます。
泉真悟氏（以下、泉）：ちなみに、このPRDの説明会の時はMRDもセットでやる感じですか？
稲垣：セットで、PRDでかなりMRDの内容も吸収するようなかたちを取っているので、そこで一気に説明をしていくようなかたちを取って……。これからやろうとしているかたちなんですけど。その予定です。
泉：なるほど。やはりエンジニアはけっこう大元の要求を知りたがるところがあるので。それはあとの仕組み化のところにもつながりますけど、PRDのフォーマットを改善する時にそこだけをどう盛り込んでいこうかなというところは悩んだりします。
松下：難しいですよね。
稲垣：なんか「これをやりたい！」と言っても、本当にそのお客さまだけでいいんですか？ というMRDに近い部分のツッコミも入ってくるので、そこをしっかり納得感を持っていただいたりとか。仮説ではあるけれどもみなさんがそこのリスクはわかって進んでいるというだけでも、たぶん開発側の理解も深まるのかなとはすごく思いますね。なので、我々もそこの工夫が必要かなと思っています。
松下：ありがとうございます。
川東：ありがとうございます。
Chatworkにおける仕組み化への取り組み
川東：今仕組み化の話も少し出てきたんですけど、時間がだいぶ押して参りましたので、最後のテーマにいきたいと思います。本当はここがすごくおもしろいところかなと思ったんですが、ちょっと時間が押して参りましたので、よければ重点的なところを簡単にご紹介いただけたらなと思うんですけど。松下さん、Chatworkで今取り組んでいる仕組み化のご紹介をいただいてもよろしいでしょうか？
松下：はい、ありがとうございます。ちょっと私が入って半年で取り組んだものを全部羅列したんですけれど。
川東：すごく多いですね。
松下：私はどちらかというと仕組み化が得意なので、そればかりやっているという感じなんですけど。グロースPMの観点でいうと、やはりKPIドリブンであるKPIの大元のプロダクトKPIツリーを理解するというのでKPIツリーを作ったりとか。KPIツリーじゃなくて、プロダクトKPIツリーです。なのでKGIが何なのか、アクティブ的な指標とかをKGIにして、そこからKPIツリーを作っています。
そのKPIツリーを使ってどうやって運用するかというところの仕組み化もしています。なので、その仕組みとプロダクトバックログが連動している。例えばバックログにそれぞれに対して工数と効果が付いていて、その工数と効果の効果を計算すると、ロードマップで半年後の目標値を達成するかどうかを計画するみたいなもの。けっこう運用が難しいので、常にうまくグルグル回っているかというと難しいんですけど、その仕組みを定義してやり始めているという感じです。
あとは、企画の入口・出口という言い方をしているんですけど、企画するために必要な前提条件をどうやって揃えるかみたいなところをいくつか書いています。まさにPRDのところもテンプレ化しています。そのあたりの事例として他のスライドにも書いているんですけど、デザイナーとのワークフローの構築だったり、あとはちょっと特徴的なものでいうと、プロトタイプ。
餅は餅屋みたいな話を先ほどしたんですけど、グロースさせることが目的なので、例えばデザイナーがプロトタイプを作った時にちゃんとデバイスでそれを見て、「このUIは本当にお客さまが増えるんだっけ？」とか、「定着するんだっけ？」という観点で見るためのチェックリストを作ったりしています。「この観点で全員UIを見てください」とか、そういうことを仕組み化しています。
あとは企画の出口というので、例えばA/Bテストの勝ち負けの考察を全員でやるとか、それで学びは何なのかをちゃんと定義するというのを最近取り入れ始めて好評です（笑）。
あとは他部署との取り組みは機能ごとに部署を分けているという前提なんですけれども。やはりそのつながりというところは描けていないので、FlywheelをChatwork事業で作ったりとか。やはり戦略がつながってこそ、それぞれの機能が活かされていくということで、そういう前提のつながりを作ったりしています。PMの領域だと上の企画の出口ぐらいまでですかね。
プロダクトマネジメントの効率化
川東：ありがとうございます。こちらがPRDのテンプレートですね。
松下：そうですね。なんかみんな得意なツールが違ったので、とりあえず揃えましょうという、僕の当時の投稿とかですね。なので個性は必要ないと思っていたので、先ほど稲垣さんがおっしゃった読みやすさみたいなところはかなり重視しています。どの職種が読んでも可読性が高いみたいなところも「2行で書いてください」とか、けっこうそういうレベル感。「て・に・を・は」も全部フィードバックしています。
川東：すごいですね。
稲垣：すごいですね。
松下：とにかくそれをやるという感じですね。ただ、すごく良かったのは「可読性が上がりました」という声は実際にいただいているんですけど、「要求定義をやる上で思考がすごくシャープになった」と。フレームワークとして一番重要なので、このフィードバックをもらったのはうれしかったですね。
川東：巻き込み方が本当にすごい、えぐいですね。すごい。こちらは先ほどのワークフローの話ですね。
松下：そうですね。
川東：ありがとうございます。
松下：このフローのいいところは例えばチームの運用のKPTをする時に、「あのフェーズの時は、こうですよね」みたいな感じで、この図を見ながら振り返れるところです。やはりみんなが「あの部分なんですけど」みたいな。「その『あの』って、どこを指しているの？」みたいな。「このフェーズの時は、ここが問題点ですよね」というところをちゃんと立ち返る場所という意味で図式化しておくのはすごく大事だと思いました。
川東：ありがとうございます。
（次回へつづく）
＜続きは近日公開＞
