顧客要望をプロダクトにフィードバックする技術
私は現在、ヘッドレスCMS「microCMS」を提供する株式会社microCMSでカスタマーエンジニアとして働いています。
カスタマーエンジニアの仕事のひとつに、「顧客の要望をプロダクト（開発チーム）にフィードバックする」というものがあります。これは、顧客からいただく「この機能をもっとこうしてほしい」といったサービスに対する要望をプロダクト開発チームにシェアし、プロダクトの改善に繋げる重要な仕事です。
例えば、いまあなたが読んでいるこちらのnoteの例でわかりやすいものをひとつ挙げるとすると、以下のようなものになるでしょうか。
要望
「noteで記事を読むとき、文字のサイズを大・中・小のように変更できるようにしたい」
例のためにあえてシンプルな分かりやすいものにしてみましたが、イメージとしては概ねこのような感じです。
ありがたいことに、こうした要望は毎日のようにいただきます。チャットサポートで直接お問い合わせいただいたり、顧客のオンボーディング支援の際にお伝えいただいたり、経路もさまざまです。microCMSのようなエンジニアフレンドリーなSaaS製品だと、Twitter上でも言及いただく機会も多く、そうした声を要望として取り扱うこともあります。
「顧客の要望をプロダクトにフィードバックする」。字面だけ見ると一見シンプルな営みに思えます。しかし、実はこの作業はとても奥深く、真に価値のあるフィードバックをするにはたいへんな技術を要するのです。
私はいまmicroCMSでカスタマーエンジニアとして働きはじめて1年経ちましたが、ある程度経験を重ねて、やっとその難しさに気づきました。
今回は、1年前の自分に宛てて書くような気持ちで、今考える要望フィードバックの技術について書いてみたいと思います。
すべての要望をフィードバックするわけではない
まず、顧客から要望をもらったとき、それをすべてプロダクトにフィードバックするというわけではありません。もちろん、ズバリ本質を突いており、直接挙げるものもありますが、そういった要望がすべてではありません。
想像してみてください。
ヘッドレスCMSのようにシーンごとにさまざまな使い方をされるプロダクトにおいて、顧客からの要望をすべて吸い上げ、それをプロダクトに反映していくとどうなるでしょうか？
おそらく、あちらこちらでちぐはぐな状態になり、本来目指すべきである「なめらかで使いやすい」プロダクトとはほど遠いものになるでしょう。
もちろん、要望を実際にプロダクトへ取り込むかどうかの判断はプロダクトマネージャーの責務になるかと思います。しかしそれ以前の段階で、最初に要望に接するカスタマーエンジニアがフィルターにかけ、本当に検討にしていくべき要望のみを選別することが重要だと考えています。
そういう意味では、カスタマーエンジニアはある種意図的に、批判的な目を持って要望に向き合う姿勢が求められるのだろうと思います。
本当に向き合うべき要望を見つけるための2つのフィルター
私たちが本当に向き合うべき要望を見つけるためにするべきことは何でしょうか？それは、いくつかの「フィルター」越しに要望を捉え、精査していくことだと考えます。
要望をもらったからといって脊髄反射でフィードバックするのではなく、まずはこれらのフィルターを通して、その要望の背景であったり、真意を探っていきます。
そのフィルターとは、以下のように大きく2つがあると考えています。
第一のフィルター：機能を正しく捉えているか
まず1つめは、「その顧客は機能を正しく捉えているか？」というフィルターです。
前提として、全ての顧客がプロダクトの機能を正しく理解し、使いこなせているとは限りません。多機能なプロダクトであればなおさらです。
サービス提供者側が想像している理想的な使い方の範囲を超えた用途で使われていたり、本来別の目的のために用意してある機能を、別の目的で使われていたりなど、想定外の使われ方をしているケースは少なくありません。
要望をいただいたときは、そもそも顧客はその機能を正しく理解し、使ってもらったうえでの要望なのかどうか、をまず明確にする必要があります。
もしそうでない場合、実はもっと適した機能があることを案内したり、別のアイデアを提案したり、要望として挙げる前にまずもっとやるべきことがあります。
第二のフィルター：そもそも、顧客が果たしたい目的は何なのか
次のフィルターは、顧客の目的についてです。
顧客は、なにか目的があってとある機能を使います。その目的を達成するための道筋のなかで、何らかの障害があり目的が果たせないと分かったとき、その機能について「もっとこうしてほしい」と要望を送ってくれます。
要望を正確に捉えるためには、この「目的」を正しく理解することが大事です。なぜなら、目的が分かっていなければ、要望の対象となっている機能にしか焦点を合わせることができないからです。
例えば、顧客からとある機能Aについての要望をもらったとします。その顧客は機能Aを使って、ある目的を果たそうとしているので、要望の対象は機能Aになります。
しかし、その背景にある目的について深ぼって話を聞いていくと、実は本来考えるべきなのは機能Aの改修ではなく、機能Bの改修、ないし機能Cの新規開発であった、というケースがあったりします。実際、要望についてプロダクトマネージャーと議論するとき、「いや…、これって実はこっちで実装した方がいいんじゃないですか？」という結論に至るケースは結構あります。
機能Aについての要望だからといって、すぐに焦点を機能Aに合わせない。その背景に思いを巡らせ、俯瞰し、想像することが大事なのではないかと思います。
フィードバックは砂金を採るかのごとく
要望に対するこれらのフィルターをかいくぐり、最終的に残った要望が、本当にプロダクトに対してフィードバックすべき要望なのだと思います。
もちろん、それ以外の要望に価値がないというわけではありません。基本的にすべての要望に目を通しており、傾向や需要を探るうえで重要な材料になります。
イメージとしては、金鉱山の近くを流れる川から砂金を採るようなもの。そうして掬い上げた要望は文字通りプロダクトに価値をもたらす、「金」のような存在です。
……と、ここまで要望への向き合い方について解説してきましたが、これをちゃんと実践するのは決して簡単なことではありません。むしろかなり難しいのではないかと、カスタマーエンジニアを1年経験した今、強く思っています。
なぜ難しいのかというと、第一、第二のフィルターをちゃんと通すには、適切にコミュニケーションをとってユーザーの真意を理解し、ときにはその背景にまで想像力を働かせる必要があるからです。加えて、そもそもプロダクトの機能についても熟知している必要があります。
また、このように要望に丁寧に向き合うことは、シンプルに時間的&コミュニケーション的なコストもかかります。目の前のタスクをこなすだけで精一杯な状態だと、ここまでじっくり考えるのは簡単なことではありません。
価値のあるフィードバックは一朝一夕でできるものではないのです。
フィードバックのスキルがあるのだとしたら、それを高める方法は、とにかくたくさんの要望と触れ合ったり、プロダクトへの理解度を高めることしかありません。そうした経験を積み重ねることで、少しずつフィードバックの精度を高められるのだと思います。
正直、自分はこの点ではまだまだ至らない点が多く、これからもよりよいフィードバックをするべく精進したいと思っています。このnoteが、プロダクト運営に携わる方の参考になれば幸いです。