プロダクトマネジメントの最前線　ラクス、Chatwork、LegalOn Technologiesが語る顧客理解と組織づくりの実践手法

KPIドリブンな企画プロセスの構築

川東大悟氏（以下、川東）：では泉さま、稲垣さま、どうでしょう？　これ、おもしろいみたいなのでも（笑）。質問があれば。

泉：そうですね。前のスコアのところですかね。どういうふうに開発項目を決めるかという計算の仕組み。自分も昔はRICE※のほうでやったらいいのかなと思ったり、そこがなかなか、どういうふうに変数を作ってとか、そこらへんが難しいなと思いながら。実際に効果とかはどうですかね？

※優先度のスコアをつける手法。Reach、Impact、Confidence、Effortの頭文字から。

松下：効果に関しては実際に施策に取り組む前提で、数値の調査もある程度しておいて、「この画面のページビューはこのぐらいだよね？　ページビューとユニークユーザーはこのぐらいだよね？　じゃあ、この人がどのくらい使うんだっけ？」とか。その中で例えば「じゃあこのボタンを押す人が何割だっけ？」と、ある程度試算はできるので、その視点をみんなで揃えて試算するという感じです。

工数に関しては、要求なんだけれどもあえて、やることリスト的な感じにHOWとしたらこんな感じだよねというので、ある程度見積もってもらって、そこからもう1回企画化に立ち帰って、あえて要求までに留めるみたいな。けっこうそういう事前に見積もってもらうみたいな感じでこういう計算式を入れています。

泉：HOWにどこまで踏み込んでいいのかが、なかなかの悩みどころで。

稲垣：悩みますよね。

川東：開発が大変そうだなと思いましたね（笑）。

稲垣：けっこうそこは、うちのPdM内でも話題になります。HOWがある程度ないと開発も考えづらいし、踏み込んじゃうと踏み込んじゃうで開発を限定的にしちゃう。なので僕も説明会をしっかりするようにしているんですけど。

松下：そうですよね。PRDはやはり要求なので、開発要件ではないから。

稲垣：そうなんですよね。

松下：基本的にそこの接続はあまりないんじゃないかと最近思うことが多いです。

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

稲垣：ちなみに先ほどの「て・に・を・は」は、松下さんが見られているんですか？

松下：私が見ています。

稲垣：すばらしいですね。

松下：なので、実は私がチェックする項目も「こういうものをチェックします」というドキュメントを作っているんですね。それをオープン化しているんですよ。

稲垣：なるほど。松下さん自身の再現性も取っているということですね。

（一同笑）

松下：そうです（笑）。じゃないと、私もメンタル的に適当にやっちゃったら良くないので。

稲垣：そうですよね（笑）。

松下：私自身もハックしているという感じです。

稲垣：なるほど。さすがです。

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

製品イシューへのフォーカスと情報共有

川東：じゃあ、そうですね。次にいきたいと思います。じゃあ、ラクスの仕組み化ですね。

稲垣：僕ですね。

川東：はい。稲垣さん、お願いします。

稲垣：ちょっと時間もないので、再現性において考えているところの話をチラッとだけ。たぶんみなさんそうだと思うんですけど、PdMが取り巻く環境はかなり広いし変数が多いので、そこに対して全部の仕組み化は無理だなというところで、とにかく仕組み化は本来、我々PdMが注力すべきことに注力することができるような手段なのかなというところで基本的に考えています。

指針的にはやはり製品のイシューにできるだけフォーカスできるような、周辺のところで僕らが気を遣わなくてもいいような状態をとにかく仕組み化していく。とにかくこのイシューにフォーカスができるようなところと、あとは複数人のPdMがそのイシューとなる根拠をしっかりとお客さま課題が同じ解像度でできるような状態。

Aさんだけそこの解像度が高いとかではなくて、情報ソースはみなさん同じになって、それを踏まえてその案件を担当している人が、より深く考えて新しいものの要求だったりを詰められるように、情報はできるだけ平等にあるようなかたちを取る。そこにさらに実力でハッキリしていくということで、周辺の部分を基本的には仕組み化するようなかたちを取っています。次のページにいっていただいていいですか？

ここは先ほどと一緒で、星が付いているところが今けっこう仕組み化をしっかりやっている部分で、点線の部分がまだちょっと足りていないかなという部分なので、今後しっかりやっていく。

特に失注側のところがまだ少し営業側からの解像度の部分が上がっていないので、このへんはしっかりやっていけるといいかなというところです。今星が付いているところは、より洗練させていくみたいなかたちで、先ほどの松下さんのお話とかを聞いて非常に参考になったので、そのへんでさらにブラッシュアップができるといいかなと今思っています。以上です。

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

ディスカバリーの効率化と多様性の活用

川東：じゃあ、どうしましょう。ちょっと時間がかなり押してきていますので。

稲垣：泉さんのほうにいっちゃってください。

川東：はい。それからちょっと最後にもう少しディスカッションができればと思っています。泉さま、ちょっとご説明いただいてよろしいでしょうか？

泉：はい。弊社のポイントは組織と個人に分けて書いているんですけど、やはりディスカバリーの生産は先ほどみなさんがおっしゃったようにテンプレートを作るとか、そういうものをしっかり作っていくのが大事かなと思います。あと、今我々はドメインごとにチームがいる中で連携が弱かったので、ちょっと場を作りながら横ぐしでどういうふうにお客さまの課題解決をしていくか、そういうことをいろいろ議論する場づくりから始めたりしています。

あとは、仕様変更を含めてちゃんと認識していきましょうというのをやっていますね。ただ、我々は会社として文章が大好きでけっこう「Notion」にいろいろとドキュメント化しているんですけど。情報量が増えすぎて認知がいっぱいいっぱいになっているので、こういうのでみなさんいいアイデアをご存じだったら教えてくださいと思っているんですけど。

（一同笑）

泉：あと個人でですね。先ほどディスカバリーをけっこうがんばっている、そこに重点を置いているという話があったんですけど。けっこうそのアプローチとかもバラバラだったりするかなというのに個人的には課題感を持っています。

やはりそのドメイン経験、エキスパートだったり、どちらかというとエンジニアサイドだったり、そういうPdMの人が増えることによって多様性、これはいいところなんですけど、そこの経験値や考え方というのはやはり違うので。それをどうやって再現性のあるものにするかをちょっとこれから検討していこうと思っています。

ディスカバリーで何をどこまでやるかとか、ここまでやって早いところPRDをPEM（Product Engineering Manager）に渡して次のことをやるのがいいのかとか、そういうところはちょっと今再考中というところですかね。簡単ですが以上です。

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

プロダクトマネージャーの多様性と情報共有の重要性

川東：松下さん、稲垣さん、どうでしょう？　この課題といいますか、検討中のところの良いアイデアがあれば（笑）。

稲垣：なんか、あらためてそんなに自分のやっていることが大きく外れていないんだなと思えたのがどちらかというと良かったのかなというところで、やはり難しい部分はみなさん一緒なのかなということが非常にわかりました。感想ですけど（笑）。

松下：ディスカバリーでいうと。

川東：このあたりのところ……。

松下：あ、どうぞ。

川東：いやぜんぜん、まさに松下さんのほうがいいアイデアをお持ちなのかなと、ちょっと思いましたね。

松下：いや（笑）。なんか、ディスカバリーのところで、人それぞれ個性とか能力とかが違うというのは本当にそのとおりで、もちろんディスカバリー以外のいろんな領域で起こっていると思うんですけど。なんか仕組みそのものを製品と思って常にさらして壁打ちするみたいな。けっこうそういうのを自分は意識していまして、PRDのフォーマットも1日で8割作って「まずはこれでやってほしいです」というので、2週間ぐらいずっとイテレーションを回しながら完成させたみたいな感じなので。なんか仕組みを製品と思うみたいなこと。

（一同笑）

松下：このディスカバリーにおけるところの仕組みを製品として……。何だろうな。フレームワークとしての製品とした場合に、どうやるといいんだろうなというのは今ちょっと妄想しながら思っていますね。

川東：おもしろいですね。

稲垣：多様なPdMでいろんな経歴の方がいらっしゃるので、やはり情報の受け取り方はぜんぜん違うかなと思っています。なので、できるだけしっかり情報はみなさんに伝わるようなかたちで、その情報の受け取り側の多様なPdMがその情報をたぶん活かしてくれるようにしっかりしていく必要があるのかなとは、今改めていろんな話を聞いて思いました。

泉：けっこうエンジニア経験者とそうじゃない人ってぜんぜん違いますよね。

稲垣：ぜんぜん違いますよね！

泉：違いますね。

稲垣：ぜんぜん違いますよね。やはりデザイナーから見るとデザイナー側の意見もありますし、我々でいうと経理経験者だとぜんぜん見え方も違うところがあるので。それを限定的に渡すよりも全体としてしっかり渡して、その情報をどう処理していくかは各PdMの多様性の力でなんとかしていって、組織とかチームでよりいい製品ができるといいのかなというのは改めてすごく思いました。

松下：なんか、やらないことを決めるって大事だなと今ちょっと話を聞いて思いました。

（一同笑）

プロダクト開発における優先順位付けと「やらないこと」の決定

泉：そうですね。

松下：なんか「ここで重要なのはこれですよね」というシャープさをどうやって決めるか。たぶんPdMがそこをコントロールしないと。いろんな職種の方が意見をくださって、もちろんすごく参考になることも多いと思うんですけど、「ここでは必要ない」というのを言い切れるのかもすごく大事なんだろうなとは思いました。要求を作る時にHOWの話や、それが正しくてもあえて外すとか。もちろん背景のWHYの部分はすごく手厚くすべきだと思うんですが、弊社は、けっこうHOWにつながるところはすごく気をつけるようにしています。

稲垣：まさにやらないことを決めるって、やはり大量のお客さまの情報があるとすごく重要だなと。どうしてもやってあげたくなっちゃったりするので。

松下：それはそうですよね。行動しないよりしたほうがいいと、やらないことを決めて、まずやってみようというスタンスを心がけたいなと思いましたね。

稲垣：そうですね。そう思います。

泉：立ち返って「我々の製品の提供価値って何？　一言で言ったらどうなの？」という、そこに振らないと、けっこうみんな盛りだくさんになっちゃうので。

稲垣：そうですよね。やはり使っている不便を解消してあげようと思いますけど、どちらかというと製品価値が一番重要なところなのかなと思うと、どうしても捨てないといけないというか。重要視する部分をしっかり決めないといけないというのは改めて感じました。

泉：盛り込みすぎると今度は製品が難しくなってわかりづらくなるんですけど。

稲垣：そうですよね（笑）。

川東：ありがとうございます。ちょっと会話が盛り上がっているところ申し訳ないんですけれども、時間が来てしまいましたので。すみません、ご視聴者のみなさま、Q&Aの時間が今回もうなくなってしまいましたので、いったんちょっと一時的にここで締めさせていただきたいと思います。