toB・toCにおけるプロダクトマネジメントの違い
司会者：まず1つ目の質問です。ベルフェイスさんは、いわゆるtoB的な側面が強いプロダクト、ビビッドガーデンが運営する「食べチョク」はtoCの側面が強いプロダクトかなと思っています。
そのtoB、toCという切り口で、プロダクトマネジメントの手法だったり、考え方だったり、「ここは共通項だろうな」と思ったところだったり、逆に「ここは明確に差分としてあるな」と思ったところがもしあれば、教えていただきたいと思います。では、いったんLTの順番で、森さんにこの質問を投げかけてもいいですかね。
森洋一郎氏（以下、森）：toB、toCで共通するところはすごく多いと思いますし、僕も勉強になるところが多いなという印象をまず一番に受けました。toCは、自分自身がユーザーとして体験しやすいですが、toBはユーザーが法人でで、自身が直接ユーザーではないこともあると思うので、お客さまの声の重要性だったり、それをもとにした改善のアプローチにも違いがあるのかなと思います。
司会者：ありがとうございます。吉本さん、今のを聞いて（いかがでしょうか？）。
吉本猛氏（以下、吉本）：おっしゃるとおり、自分事化しにくいという、まさに解像度を上げるという話だと思います。要は、意図的に（解像度を）上げにいかないとまず上がらないというのは、toCでも結局プロダクトの種類によるとは思いますが、使ったことがないtoCのサービスであれば、ユーザーの気持ちはわからないよねというのと一緒です。
ですが、より身近かどうかという観点と、あとは体験しにくいという観点でいうと、toBだと当然、プロダクトによってはまったく畑違いなものに対して解像度を上げていかなければいけないというのがあります。
やはり意図的にやっていかなきゃいけないよねという意味では、プロセスをきちんと回さないと、本当に当たり外れが大きいというか、肌感だけでなかなか意思決定はできないところではありますかね。
あとは、基本の手法が大きく変わるというよりは、強いて言うなら、これもプロダクトの種類によるのかもしれないし、toCでもぜんぜんあり得ることだと思いますが、ステークホルダーとか、登場人物の多さが違うと思います。
ほかには、承認とか稟議などを含めての、いわゆる法人ならではといわれる階層みたいなところとか、権限のところとか。ああいったところは、やはりそれぞれ登場人物がいて、それぞれがユーザーになり得る状況なので、考慮しなければいけないことが増えはするかなと思います。
それは個人向けでも一緒だと思うんですけどね。ご家族で使う際に、誰が主になるのかとか、そういうものと近いんですけど。より階層の深さ、多さみたいなところで、法人、toBのほうが考慮しなきゃいけないかな。あとは、業務の一環みたいなところは一定考慮しなきゃいけないかなというのはありますかね。
司会者：ありがとうございます。各会社のメンバーがプロダクトの解像度を上げるところのアクションとして、先ほどお話に出たプロダクトビジョンだったり、プリンシプルの制定というのがあったのかなと思いました。
プロダクト開発する中で承認フローの上の人たちに合わせにいこうとしたら危ない
司会者：では、次の質問にいければなと思っています。今日、ビルドトラップに関して話をしているわけですが、いわゆるはまってしまう状況ですね。そうなる時の兆候だったり、そうならないためにやり続けようと思っていることって、どんなものがあるのか、ちょっとおうかがいできればなと思っています。こちらは順番を逆転して、まず吉本さんにおうかがいしてもいいですか？
吉本：「こうなったら確実に」みたいになると、ちょっと難しい表現にはなってきますが、特に初期のフェーズのなりやすさで言うと、なにかを作る上でも「代表だったら、きっとここの部分を指摘してきそうだね」とか、だんだんと承認フローの上の人たちの好みではないですが、そこに合わせにいこうとするコミュニケーションが社内でなされてしまう。
もちろん承認者のほうがよりいろいろな視点を持っていて、レビューをする立場だからというのはわかりますが、例えば実際に現場でインタビューしている人とか、リサーチして分析している人と比較すると、本来であれば解像度はそちらのほうが高いはずで、「こうだから、こういう仕様にしています」と言えなきゃいけないのに、そのあたりのコミュニケーションの端々でついついそういうのが出てしまうと、「誰のために」というところが、少しずれていっているリスクを感じる部分ではあります。
ちなみに承認プロセス自体をなくせということではないです。それをやっちゃうと、それはそれで別の問題が出てきたりはするので。なので、コミュニケーションの節々で出てくると、ちょっと危険かもというのはあると思います。
そうならないために、PM間でのレビューを承認とは別で入れるとか……いわゆるレビューみたいな位置付けで入れるのは、あってもいいかなとは思いますね。
司会者：ありがとうございます。
とにかく出しっぱなしにしようとするのはビルドトラップが起こる兆候
司会者：森さんにもおうかがいしていいですか？
森：ビルドトラップが起きる兆候……「そうじゃない状況」だったのにそうなるという点で言うと、「アウトカムが生めていないな」という空気が充満した時に、変える方法としてよりスピードを上げようということが議論に挙がることがあります。これは何も考えないと、ビルドトラップを生む兆候になりかねません。
そこでビルドトラップにはまらないようにと意識をしたことですが、例えば私たちは「スピード月間」を設けてメチャクチャスピードが上がったのですが、そこでもきちんとなぜ作るのか目的を明確にし、仮説をもち、それの検証をやっていたので、ビルドトラップを避けられたと思っています。
とにかくいっぱい出そう、とにかく出しっぱなしにしようとする、これはビルドトラップにはまっている状況だと思うんです。私たちは、適切にデータアナリストとABテストをしていたし、きちんと結果も出ているし、ユーザーに価値も届けられていた。きちんと、「なぜこれを作るのかから入れている」という状況にできたので良かったんです。
これが、「アウトカムが生めていない。だから、スピードを上げる必要がある」と単純にそれだけになるとビルドトラップに入るかもしれないので、そのタイミングできちんとそこを意識しておくことは大事かなと思いますし、そこは兆候になるところかなとは思います。
司会者：ありがとうございます。お二方の話を聞くと、顧客の方々をいかに主語として捉えられるかというところが、すごくありそうですね。なにか施策した時は、顧客の方は何をそれで体験できたんだろう、いい体験につながったんだろうというところをきちんと検証し続けるのが大事なのかなと、お話を聞いて思いました。
（次回へつづく）
