本記事は Calendar for estie Advent Calendar 2021 | Advent Calendar 2021 - Qiita 4日目の記事です。
estieでPdMをしております ゆーぶんです。
今回はestieでVoice of Customer（以下VOC）を導入し、運用して3ヶ月たった効果について皆様に発信していきたいと思います。 なので下記の様な方にとって有益な情報になればと思っております。
- 開発チームとビジネスチームの連携に課題感を持っている方
- 感覚に頼った開発方針を脱却し、顧客の声を根拠とした開発方針に変更していきたいチームの方
- VOCをふわっと導入したいと思いつつ、なにから手をつければいいのか不明な方
弊社もまだVOCの運用についてはこれからですが、それでも十分効果を感じておりますのでぜひお読みいただければと思います。
VOCとはそもそもなにか？
VOC（Voice of Customer）はその名前の通り、顧客の声であり、顧客との定例会議やユーザーヒアリングで得た顧客の声をバックログのように蓄積させたデータベース・仕組みのことです。 会社によってはユーザーボイスと呼んだりするようです。
具体的なイメージで言うと、下記のような要項が記入され、蓄積されていくものです。
タイトル（なにについての声かわかるタイトル） 起票企業名（実際にフィードバックくださった企業様） 起票者名（実際にフィードバックくださったユーザー様） 内容（実際にユーザー様がくださった声）
具体例を入れてみると以下のようになります。
タイトル：物件検索機能への要件追加 起票企業名：株式会社estie 起票者名：ゆーぶん 内容：物件検索においてよく検索する条件を保存できるようにしてほしい
上記のとおり、顧客の生の声のみを蓄積していったものがVOCであり、定例会議の議事録からプロダクトに関する部分だけを抽出したり、お問い合わせの内容がそのまま一つのデータベースとして蓄積しているものと考えて頂けると近いかと思います。
VOCは別名「宝の山」と呼ばれ、実際のユーザーの声であり事実の蓄積であるため、開発時に貴重な情報となりえます。 次章でestieでVOCに注目し、実際にどういう期待を込めて導入したのかについて説明していきます。
VOCを導入した目的
VOC導入に至った経緯として、事業の拡大による顧客の増加が大きなきっかけとなります。 プロダクトをリリースして1年間ほどは顧客の数もそこまで多くはなく、私が直接定例会議にでたり議事録を追うことで機能要件やロードマップ作成は顧客の求めるものに近い解像度で作成することが比較的しやすい環境でした。 しかしながら嬉しい悲鳴で事業が拡大するとともに導入企業様も増加し、私一人ですべての定例会議に出ることは不可能になり、また各ユーザー様でユースケースも異なるため、機能開発の優先度決定が非常に困難になっていきました。 PdMですら顧客との距離が少し遠くなったため、実際に開発を担うエンジニアやデザイナーはより顧客が見えづらくなり、開発の議論もなかなか活発になりにくくなりました。
また、こちらは導入企業数増加による課題とは異なりますが、弊社が事業展開を行っている不動産業界は開発チームがなかなかイメージしにくいドメインであり、もっと顧客や顧客の窓口となっている営業チームと議論することで、開発チームの業界理解やビジネス理解を進めたいとも感じておりました。
上記により、弊社CEOや営業サイドと議論をし、下記3つの目的を達成するためにVOCを導入する意思決定をいたしました。
目的①：プロダクト開発の際、顧客の抱える課題を解像度高く仮説立てしたい
- 開発優先度決定時にVOCから顧客の数を参照し、仮説の確度の指標として採用する
- 議事録や定例会議で出た自身の所感となると、どうしても自身の解釈が入ってしまうため、逐語録として顧客の生の声を蓄積できるようにしていきたい
- 顧客の数が増えてきても共通の開発方針やカスタマーサクセス方針がぶれないようなバックデータを蓄積したい
目的②：開発チームの顧客解像度を上げ、開発議論をシャープにしたい
- 議事録だと開発チームの興味外の情報もあるため、顧客の声だけに絞ったVOCを導入することで、開発チームの情報入手の敷居を下げる
- 開発チケットの背景を理解する際に、実際の顧客の声をバックデータにすることで実装者の理解を深める
- 実装時に見失いがちな提供している顧客の価値を振り返りやすくし、開発チームのビジネス理解を深める
目的③：開発と営業サイドの議論を活発にしたい
- 開発も営業も関係なく、同じ業界課題を解決することを意識づけ、お互いが対等に意見を言えるように顧客の意見をベースに議論したい
- 不動産という開発チームがイメージしにくいドメインにおいて、顧客の声を通じて不動産ドメインを学びやすくいしたい
- 営業チームも気軽に開発チームに相談できる関係性を築くために、営業チームと開発チームのコミュニケーションのきっかけにしたい
VOC導入に際して行ったこと
VOCを導入します！だけではもちろん浸透しませんし、ただVOCが蓄積するだけで上記目的が達成されるわけではありません。 またVOCを導入するにも投稿者にとっては負担が増えることになるので、しっかりルールを設定することで投稿コストを下げたり、VOCが活用される仕組みを作ることでモチベーションを保つ必要もあります。
そこでestieでは下記VOCの運用ルールを整備しました。
運用ルール①：投稿ルール
- タイトルは開発チームや他のAccount Managerが見てもざっくり内容がわかるように書く
- ふわっと書きすぎると情報がなく、読むコストが高くなるために業務名や機能名＋動詞で意味が通じるように書く
- 声の内容にラベルを付ける
- UIの改善に関する内容なのか新規機能の要望なのかをわかりやすくするために指定のラベルをつける（estieでは機能要望/質問/その他で分けてます）
- 個人の解釈や仮説ではなく、顧客が実際に話していた内容を逐語録で投稿する
- 解釈や仮説が入ってしまうと開発チームで仮説検討する際に若干顧客の求めるものと異なり、投稿者の求めるものになってしまうことを防ぐ
- 個人的にはここが重要だと考えており、かなり徹底しています
運用ルール②：VOCレビュー会の運用開始
- 週に1時間レビューする会を設定し、PdMがオーナーとして司会進行をする
- 強制的にVOCを見る場を作り、投稿のきっかけやVOCを見る習慣付けを行う
- 営業チームも開発チームも参加可能な限り参加してもらう
- 営業チームだけでも開発チームだけでも議論の効果は半減してしまうため、幅広く参加者を募ってます
- 実況形式で議論を行う
- 何よりも楽しい場にするため、実況形式でワイワイする雰囲気を作り、コミュニケーションが自然発生することを目指す
運用ルール③：四半期に一度レトロスペクティブを実施し、運用ルールを見直す
- KPTのスキームを用いてしっかりと振り返りを行い、継続点と改善点を洗い出す
- まだ導入したてだと運用ルールが整備しきれずに目的が達成されない可能性があるので、運用ルールを見直す場を作る
- PdMが主導するものではなく、みんなで文化を作っていくものとして運用をすることで会社の資産となる
（ちなみに弊社ではVOCの運用に当たり、Flyle様のプロダクトを活用させて頂いております！）
VOCを導入して変わったこと
VOC導入前と導入後で変わったことを書き出してみたいと思いますが、総論はめちゃくちゃ良くなりました！
💡良い方向で変わったこと
- 開発チケットにVOCがエビデンスとして載るようになり、優先度決定や仕様に納得感が増した
- 顧客にヒアリングするべき点が明確になり、開発チームの顧客ヒアリングの数が増え、顧客価値提供の質が上がった
- 開発チームと営業チームのコミュニケーションが倍増し、各所でPdMが繋がなくても議論が自然発生するようになった
🌀悪い方向で変わったこと
- 投稿コストが上がり、Account Managerの労力が増えた
- 運用ルールの設定等を考えるPdMの労力が一定かかる
悪いこととしては基本的に新しいことを導入して価値を生もうとするための労力的なコストの話になります。 一方で見合うリターンは十分あるのではないかと感じております！
また、レトロスペクティブで下記のような意見が出ました。
- 週の中でも一番好きな時間で、毎週VOCレビュー会を楽しみにしている（エンジニア）
- VOCレビュー会は盛り上がりやすい会議体かなと思う。結構この時間好きです（営業）
そう、VOCを見ながら議論するのはすごく楽しいのです。 まさしく会社全体が同じ方向を見てプロダクトづくりをする時間となっており、1+1が10にも100にもなるような感覚を覚えます。 上記のような姿はPdMとして理想状態に近く、VOCの運用を更に良くしていこうと思っております。
VOCはプロダクトマネジメントにおいて、営業と開発を同じ方向に向かってプロダクト開発を促進させるツールであり、一定数導入企業が増えてきたtoB企業様に導入を声を大にしておすすめできます！
終わりに
今回はestieのプロダクトマネジメントにおいて、開発を加速させることになったVOCについてお話させていただきました。 estieのプロダクトはまだまだ拡大させていきたいと思ってますので、興味を持たれた方は是非ご連絡ください。 もちろんVOCについてのご意見や、アドバイス等ございましたら是非お願いいたします！
↓estieについて知りたくなった方はこちら
