PMMが仮説検証に向き合って気づいたこと〜CX改善とUX改善の違いと面白さ〜
この記事は2022年CAMPFIRE Advent Calendarの4日目の記事です。本日はCAMPFIREでPMMをしているsaoriが担当します！
今年の夏頃からPdMからPMMにちょっとずつ移行し、今年注力したことの一つにCX/サービスのスコープでの仮説検証がありました。これまでPdMとして行なってきたUX/プロダクトのスコープでの仮説検証とのギャップが大きく、学びが多かったのでその気づきをまとめてみようと思います。
※この記事では、CX・UXの言葉は下図のスコープを想定して使います。そして、このUXを実現するものを「プロダクト」、CXを実現するものを「サービス」と表現して説明に使うことにします！（いい言葉ないかな・・・）
🔥前置き①：CAMPFIREのPMMについて簡単に説明
今のCAMPFIREでは、PMM役割・機能として厳密な定義をしているわけではなく、プロジェクトごとに関わる範囲を変えています。
抽象度を上げた表現で恐縮ですが、私は主に下記のような関係者とアクションを行なっているので、一番フィットする職種名を当てるならばPMMかな？と言うことでPMMを名乗ってます。
・プロダクトチームに加え、セールス、キュレーター（クラファンの企画・実行支援をする役割）、カスタマーサポート、マーケティングなどと連携する
・顧客行動を分析して、課題や価値の仮説を見つけること
・仮説の検証を行うこと🌟
・顧客価値やビジネス価値の共通認識を現場レベルまでに落とし込むこと
・顧客との接点を全て見て価値を届けるためのボトルネックを解消すること
そのうちの「仮説の検証を行うこと」の部分が今日のテーマです。
今回の仮説検証は、お客さまとの接点をもつ役割を担ってきたメンバーと一緒に、新しいオペレーションや仕組みを試して、評価と実行を繰り返し最適解を探り当てる営みでの学びを中心に書いています。
4人のチーム体制で数ヶ月間行なったPoCにおける、あくまで私からみた気づきです。
🔄前置き②：仮説検証／PoCって何？
自分で読み返して仮説検証／PoCがわかってる前提で書きすぎたなと思ったので、馴染みがない方向けの説明です。わかってるよ！って方は読み飛ばしどうぞ。
仮説検証とは
グロービスの用語集によると仮説検証の説明は下記の通りです。
仮説検証とは、仮説の真偽を、事実情報に基づいた実験や観察などを通じて確かめること。
仮説検証は、以下の3つのプロセスを繰り返し行う「思考のプロセス」と捉えられる。
1．状況の観察・分析
2．仮説の設定：「仮説」（ここでは『物事に対する仮の答え』とする）を設定する。例えば、「この商品はこうすれば売れるだろう」「これをすることにより、こんな効果があるに違いない」といったことである。
3．仮説の検証：設定された仮説が正しいかどうかを検証するためには、仮説を設定した時以上の情報が必要になる。リサーチを行う、あるいは実際に行動してみて、その結果を分析し、仮説が正しいかどうかを判断するための情報を得て、検証をする。仮説が収集した情報と照らし合わせ、間違っていればその仮説を修正する。
プロダクト改善の場で最もよく行う仮説検証の手段はABテストです。CAMPFIREでは月に10個以上のABテストを並行して走らせていることもあり、プロダクトチームでは常に仮説検証が回っている状態になっているため、プロダクトチームメンバーにとっては馴染み深いのではないかと思います。
PoCとは
Proof Of Concept（概念実証）とは、事業のコンセプト（事業仮説）を顧客や市場に実際に提供し、事業として成立するかを確かめる実験です。
仮説検証の中でもコンセプトフェーズのものを検証することで、プロダクトマネジメント領域では、モック・プロトタイプを用いてアプローチを磨き込んでいくことが多いです。
PoCにおいては、下図における「調整の矢印」がとても大事です。仮説や計画は常に変わりうるものという前提で仮説検証を行い、アプローチを磨き込んでいくというスタンスがPOCのポイントです。
📝仮説の検証計画策定のプロセス
プロダクト改善とサービス改善の違い
プロダクトの仮説検証では、WEBやアプリの画面という固定化されたアウトプットをベースの検証なので、検証が始まる時には中身が固まっています。また、Google analyticsなど計測環境が整っていたり、この指標をとるべきというフレームがある程度固まっているため、検証設計のコスト・実現するコストが一定です。重要な指標が計測できている環境であれば、仮に検証設計がちゃんとできなくてもデータ分析さえできれば、Checkのプロセスを回すことは可能です。
一方でサービス提供の現場では人と人のコミュニケーションやオペレーションをベースとしたものなので、検証開始時には中身はかたまっておらず、検証のPDCAを通じて中身を固めていくことになります。PDCAを回すためには客観的にみて進化していくことが必要なのですが、サービス提供の現場では多かれ少なかれコミュニケーション/オペレーションのばらつきはあるので、指標を決めること・その指標を計測可能にすることの２つの難易度が高いです。
加えて、サービス提供の現場では仮説検証だけやっていればいいものではなく、目の前のお客さんに向き合う視点と俯瞰してみる視点の両方を切り替える必要があります。
そのため、サービス改善においての検証設計のプロセスの重要度は高く、プロダクト改善よりも考えきって実行に移すことが大事なのではないかと思ってます。コミュニケーション・オペレーションを行うことは漫然とできてしまうからこそ、仮説検証のための検証設計は肝なのではないかと思いました。
サービス改善ではなにを意識できるとよさそうなのか
目指すべきは目の前のお客さんに対しての価値提供と仮説検証を両立させること。それを考えると検証すべきものをシャープして振り返れる状態にすることが不可欠だと思います。
具体的にやることのポイントは下記の4点です。
大事すべきだと思うポイント４つ
1.検証の目的と明らかにすべきことをシャープにして、実行者に簡単にわかるようにする
2.想定しうるフローを一つずつ洗い出し、ファネルの全体像を捉える＋変数を洗い出す
3.ファネルの中で一番レバレッジが効きそうだと思うポイントにあたりをつける
4.実行で意識する指標を１つだけにして、実行者がお客さんに向き合うときに検証に対して余計な脳みそ使わせない
顧客志向が強い、良い組織ほど目の前のお客さんに向き合うことに追われてしまい、検証が疎かになってしまうので、お客さんに向き合う瞬間には必要最小限の脳のリソースで検証のことが考えるようなコミュニケーションデザインと検証設計をやっておけるのが良さそうだと思っています。
✅評価と調整のプロセス
プロダクト改善とサービス改善の違い
言葉にすると当たり前なんですが、サービス改善は「実行の不確実性の高さ」がプロダクト改善と段違いです。
プロダクトの仮説検証では、同一の体験を提供すること＋一定の母集団を担保することによって、統計的にみてプロダクトは改善できているか？を客観評価して改善を行なっていきます。一方でサービスの仮説検証では、人が介する以上完全に同一の体験を提供することはできません。そして、一人当たりの対応に一定の時間がかかるので、仮に検証の母集団を増やす場合、工数が膨れ上がってしまいます。
また今回の検証の途中で気付いたことなのですが、お客さんのために／チームのための改善アクションによって、ファネル（離脱可能性のある箇所）が増えていると言うことがありました。表面上追っている中間指標は改善しているはずなのに、何故か成果に結びつかない・・・なぜだ・・・と原因を探っている間に見つかったのですが、その場の判断としては適切なものであっても、俯瞰した時に成果に繋がらないアクションに変わってしまっていることがあると言うのは個人的に学びが大きかったです。
サービス改善ではなにを意識できるとよさそうなのか
大事すべきだと思うポイント３つ
1.改善指標で全体に対しての進捗を確認する
2.定性的な声、肌感覚もめっちゃ大事にする
3.ファネルを可視化したものに対して改善のアクションを当てはめてみる
違いを踏まえるとこの３つは大事そうだと思っているのですが、ちょっとイメージつきにくいこともあると思うので補足します。「改善指標で全体に対しての進捗を確認する」と言うのは、具体的のようなアクションです。
・改善指標が伸びれば喜ぶ
・その分他の指標が落ちてないかを気にする
・全体に対しても変化でているか確認する
・そしてまた一つの改善指標を決める
検証設計で述べたとおり、私が意識していたのはその時々で改善指標を一つにしていたのですが、これが振り返ったとき面白いくらいに伸びていくのはとにかく達成感を感じました。プロダクトではなかなか見られない改善幅が叩き出されるのは人の力って感じ。でも一方で、意識してない指標がめっちゃ落ちてしまってることがあったので、反省を込めて今後はこうしたいなというまとめです。
また、定性的な声を大事にすると言うのは、なかなかプロダクトの仮説検証では実現しにくいことなので新鮮でした。PdM脳になっていると数字を取ること、「定性とるならユーザーインタビュー」となりがちですが、お客さんに直接できるなら毎日が定性調査のチャンス。気づかない間に自分の中に蓄積されていたインサイトをみんなで出し合えている瞬間はめっちゃええやんって感じてました。みんなでインサイトを発見しようとするプロセスなので評価はちゃんとできると楽しいです。
💪実行のプロセス：サービス改善ではやりきるための仕立てが大事そう
ギャップはまあ言わずもがなですが、UX改善ではリリースが済んで一息つくプロセスなのに対して、CX改善の本番はここです。どこまでできるかは置いておいて、これをやれば成功確率上がるのでは？と思うことを書いておきます。
サービス改善ではなにを意識できるとよさそうなのか
1.モデルをつくってオペレーション導入をするなら、検証は複数人でやった方がよい
2.人を巻き込むための準備、実行者によるばらつきをなくすための努力を惜しまない
1についての理由を補足すると下記の通りです。
・定量的な成果が個人のスキルに依存するものなのか仕組みとしていいのか判断しにくい
・お客さんを感じる視点やコミュニケーションスタイルが複数あった方が気づきの構造化がしやすい
・目の前のお客さんに向き合う視点と俯瞰してみる視点の両方を切り替えを1人でやるのキツイ
・将来的に導入先となるチームのメンバーが仮説検証に入って入れるとなおよし。仮説検証の仕方、改善の仕方が身についていると本格導入後もちゃんと改善に繋げていけそう。
2についても具体的なアクションイメージを述べるとこんな感じ。
・目的がスライド1枚でわかる
・やるべきことをわかりやすくする（改善指標を１つに絞るなど）
・実行時のばらつきを最小化するための武器と仕組みをつくる
おわりに
実践の中でプロダクトとサービスの仮説検証の違いはとても大きくて、悩んだこととかフラストレーション溜まることはめっちゃ多かった半年でした。そのフラストレーションを今回書いて学びにしてみることでなんとなく昇華できたような気がします。「こうすればよさそう」も仮説なのでこれからもっと精度をあげて、CX改善に取り組んでいこうと思います。
勿論嬉しかったこともめっちゃありまして、ユーザーが目の前でありがとうって言ってもらえる距離の近さやその瞬間にお役に立てている実感は、昔セールスとしてお客さんに接してたぶりで高まりました。
また、私が主導権を握るのではなく、仲間たちが率先して楽しそうにお客さんに対しての仮説を出して、改善のアクションを進めるというPDCAをまわす活動が行われていると言う状態になっているのも変化実感が大きく、その一部として支えられたのが嬉しいなと思っています。
ちょうどこのプロジェクトをやっている途中で、CAMPFIREにBehavior(3つの合言葉)が策定されたんですが、私が今年1年で関わった数十個のプロジェクトの中で一番この合言葉が似合うプロジェクトだったと思っています。
CAMPFIREではMission(私たちの使命)とValue(10の行動指針)をよりしっかり連動させる潤滑油の役割としてBehavior(3つの合言葉)を設定しました🔥
— 株式会社CAMPFIRE (@CAMPFIRE_cp) September 28, 2022
1. 変化をもたらそう
2. みんなで成功に向き合おう
3. 火力マックス！！！
会社HPにもアップしています！https://t.co/or4asU0tKA
最後までお読みいただきありがとうございました！
CAMPFIREが変化しようとしている面白さ、PMMのやってること、仮説検証の学びなど、ちょっとでも伝わったり、誰かの参考になれば幸いです。
この記事が気に入ったらサポートをしてみませんか？