顧客に「要望を聞いて」機能開発してしまっていた過去　解像度を高めて“評価される開発”になるための3つの取り組み

植木氏の自己紹介

植木遼太氏：私からは「新PdM組織で実践した顧客解像度の上げ方」というテーマで発表します。簡単に自己紹介をしてから本題に移らせてください。

私は植木遼太と申します。先ほどの紹介にあったように、今現在は「楽楽精算」のPdMをしています。約2年前に入社しています。キャリアとしては2010年に新卒からインフラエンジニアとしてスタートして、その後、プロジェクトマネージャー、プロダクトマネージャーと役割を変遷させていったかたちのキャリアを歩んできました。

顧客解像度向上のための取り組みBefore／After

では本題に移ります。先ほどのテーマにあったように、「顧客解像度の向上って」という話があります。発表の流れとしては、「そもそもこの顧客解像度を上げたことによってどんなうれしいことがあったんだっけ？」というお話をして、「じゃあ、それってどんな背景で何をやったんですか？」といった流れでお話しできればと思っています。

最初に効果からです。（スライドを示して）こちらに5つの主要なトピックのBefore／Afterを挙げています。

オレンジの太字の部分が変わった部分になっています。トピックを1つずつ洗っていきます。、調査手法に関して言うと、恥ずかしながら楽楽精算はアナリティクスのツールを使っていなくて、ログをけっこう漁っていたようなかたちで調査をしていました。ですが、「Googleアナリティクス」だったり「タグマネージャー」だったりを使い始めて、顧客の動向をチェックするようなかたちをしています。

調査対象についてもけっこうランダム性が多いものが多かったんですが、そうじゃなくて、ちゃんと顧客セグメントを切って、ターゲティングして、顧客にインタビューだったりアンケートを取りにいくようにしています。

仮説についてもペイン・ゲインというところだけだったんですが、ペイン・ゲインを含めた上で、ジョブ理論というかたちで、もっと詳細にまとめるようになりました。

ここがけっこう大きなポイントにはなるんですが、調査内容の部分です。要望をお客さまに聞いてしまっていた部分がけっこう多かったなと思っています。ですがそうではなくて「お客さまがどういうことをしていて、それはなぜか？」みたいなところの事実を押さえにいくかたちに変わっています。

調査結果のまとめについても定性的なものが多かったんですが、そうじゃなくて、定性と定量はちゃんとセットにしようというかたちに変わっています。

得られた効果は「コミュニケーションの情報量と明確さ」

実際どんな効果があったのかを見てみると、いろいろあるんですが、一番はコミュニケーションの情報量と明確さがかなり上がったなと思っています。

（スライドを示して）例を下に書いています。例えば調査手法だったら、「この機能は多く使われている」みたいな表現だったのが、「アナリティクス上でどれだけ使われている？」と、ちゃんと数字で見ることができるようになっている。

対象についても、改善要望を挙げてもらったお客さまにインタビューをするようなかたちだったのが、「戦略上狙うセグメントってここだよね」「ターゲティング条件は何だろう？」「（ターゲティング条件は）これだから、じゃあこの会社にインタビューしようか？」というかたちで、ちゃんとスクリーニングしていっているというところですね。

仮説についても、ペイン・ゲインの部分だけで「なになにが嫌だ。困る」みたいなものだったところを、ジョブ理論的に「『お客さんの成し遂げたい成果は何で、それは何が障害になっていて、今は代替策として何でやっていて、それってなんでやっているんだっけ？』みたいなところを知りたいよね」という話を内部でもするようになりました。

調査内容についても、要望を聞くのではなく事実を押さえにいくというところで、「どういった流れでなになにの機能を利用していて……。これって背景になにかあるんですか？」みたいなかたちで、ちゃんと事実を押さえにいく。これは聞き方の一例ですけどね。

調査結果についても手法と同じで、「多数いる」みたいな表現ではなく、「YYな業務をZZの流れでやっている、行っているターゲット顧客が何社です」みたいなかたちで、定性と定量が両方セットで報告されるようになってきたなと思っています。

「顧客解像度向上のための取り組み」を行った背景

効果はわかりました。「どういう背景で、何をやったのか？」を説明いたします。

まずは背景の部分です。これはどこの会社さんでもはまるものだとは思うんですが、顧客に評価されない機能開発をすると、解約リスクは当然増えます。失注理由もどんどん増えます。開発的な負債もどんどん増える状況になると思います。

これはみんな嫌だと思うと思います。だけど、楽楽精算自体ではやってしまっていた可能性が高いなと個人的には思っています。

その一番の理由のところ。先ほどBefore / Afterの「ここが重要」と話していた部分ですが、要望を聞いてしまっていた部分です。

フィリップ・コトラー教授の言葉をお借りして言うと、「顧客は、自分にとって何が必要かを知らない。なので、顧客に答えを聞こうとしてはいけない」と。これを地でやっているような状態です。ここが一番大きな原因だったなと思っています。

なので、そうならないために、「きっちり調査をして開発をします。最終的に顧客に評価される機能開発をした上で解約リスクを下げ、失注理由も減らしていく。ただ、開発をするので、どうしても開発負債だけは増えるというかたちを目指しましょう」という背景で開始しています。開発負債自体も減らしたいは減らしたいんですが、それは別軸で進めるというようなかたちです。

3つの実行内容

実際にやった実行内容です。サマリとしては大きく3つです。役割分担をきっちり決めた上で顧客に調査をして、PRD（Product Requirements Document、要求仕様書）を作成するというかたちを取っています。取っていますというか、実行しました。

最初の役割分担の部分です。（スライドを示して）これは既視感がある方も多いかとは思いますが、プロダクトの4階層として、『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』という書籍から抜粋しています。

今回顧客調査をする部分はどこかというと、Whyの部分ですね。「誰をどんな状態にしたいのか」「なんで自社がやるのか」をきっちり調査しましょう。

（スライドを示して）これに対して使ったフレームワークはこちらです。DACIというフレームワークがあります。DがDriver、推進者ですね。AがApprover、承認者。CがDに対する貢献者です。IがInformed、報告を受ける人です。

基本的にはDのDriverの人が責任を持って進めるというフレームワークを使いました。その上で、それぞれが「このWhyの時に出さなきゃいけないよね」と決めたアウトプットが何で、「作る上で工程はこれだけあるよね。その工程に対して誰がDなんだっけ、Cなんだっけ？」というかたちを埋めていった。これによって役割分担をしています。

その上で、いきなり「調査してください」と言われてもどう動けばいいかわからないので、調査計画を作っています。

（スライドを示して）これが、実際の調査計画のアジェンダになります。大きくいろいろ書いてあるんですが、誰に、どんな仮説を持って、何を聞くのかをまとめていっているようなアジェンダになっています。

この中でも、3C×SWOTの部分の2つについては補足したいなと思っています。これをなぜ調査計画でやるのかですが、この課題の時にどのセグメントを狙うべきなのかの根拠をちゃんと洗い出しましょう。かつ、「これってそもそも調査すべきなんだっけ？」というところの根拠も洗い出しましょう。

かつ、「今我々は何がわかっていないんでしょうか？」というところを洗い出しましょうということを目的にして、3C×SWOTを使っています。なので、初回の調査計画を作った時は、3C×SWOTが完璧なかたちでは埋まらない状態ですね。わからない部分がどうしてもあるので。

次に仮説ペイン・ゲインに関しては、「その調査すべき仮説をちゃんと洗い出しましょう」という目的でやっています。これにはジョブ理論を使っていて、Jobs To Be Doneのフレームワーク。プラス、ジョブパフォーマー、誰という部分。あとはバリア。「何が障害で代替手段は何なのかもちゃんと紐づけて仮説を出しましょう」というかたちにしています。

最後に、PRDの作成です。（スライドを示して）これが実際のPRDのアジェンダです。この中でもアジェンダとしては基本的に「誰の、どんな課題を、どんな行動変容して、実際、業務フローはどうなるのか？」みたいなところが書いてあるんですが、中でも一番重要な「誰の、どんな課題を」というところに対して調査結果からフィードバックするかたちを取っています。

ここがずれると、3以降のものがまったく絵餅の状態になってしまう。まったく違う課題に対して考えてしまうことになるので、ここが一番重要だなと考えています。

取り組みの際に注意したこと

実際にやった時に注意したことです。

役割分担の際に注意したことですが、いろいろな書籍だったりブログだったり、「Twitter（現「X」）」、記事。いろいろなところでPdM、PMMの役割、エンジニアなどの役割みたいなところのリソースがあると思うんですが、個人的には「これは理想だな」と思ってしまうようなものが多いと思っています。

それをそのまま使うのではなくて、今のラクスの楽楽精算チームで持っているスキルやリソースを鑑みた上で、ちゃんとリアルなものを作るようにすることをかなり注意しました。

その際に、先ほど稲垣（稲垣剛之氏）からも話があったような、関係者へのリスペクトと、「お互い何が得意なんだっけ？」というところをちゃんと洗い出していくことが重要になってくるかなと思っています。

次に調査計画の部分です。こちらはアジェンダを作って、それぞれのフォーマットも作ってある状態にはなるんですが、フォーマットを作っても、中身の記載レベルが揃わない（と運用ができない）というリスクをかなり感じました。

なので、まずは私が自分で書いて、「最低ここまではやろうね」というかたちのサンプルにしたものを作成した上で、最低品質を揃えるというところに気をつけました。

お客さまに評価される開発への道はまだまだ途中

こちらは復習にはなるんですが、実行した上で、最終的にはコミュニケーションの情報量と明確さがかなり上がったなと思っています。

ですが、お客さまに評価される開発を行う道の途中だなと思っています。なので、今までやってきたことを継続してブラッシュアップ、もしくは変える。そもそも違うものにすることも含めた上でブラッシュアップして、お客さまに評価されるような開発をした上で、失注要因を減らし解約を少なくしていくようなところを目指していきたいなと思っています。

発表としては以上です。ありがとうございました。