こんにちは、「Airレジ」でプロダクトマネージャー(以下PdM)として働いている日髙雄介です。新卒でリクルートライフスタイルに入社し、現在「Airレジ」開発チームで顧客要望担当をしています。

突然ですが、皆さんはプロダクト開発をしていく中で、以下のような経験をされたことはないでしょうか？

1年前は「Airレジ」においても上記のような課題がありましたが、現在は顧客要望を収集し、プロダクト開発につなげる仕組みが出来てきました。

その仕組みを作るにあたって重要だったポイントが3つあります。
①顧客要望に対する開発検討を、"定期的に"行うフローを整備する
②「やる」か「ここ3年はやらない」となるまでPdMが意思決定をすること
③組織に対して顧客要望の可視化と共有をする

この記事では、「Airレジ」で1年間顧客要望と向き合った私が、顧客要望を吸い上げ、プロダクト開発につなげるスキームを作った具体的な手順と、上記のポイントがなぜ大切なのか？を紹介します。
上記のような課題感を持っている方に役に立つ内容になっています。

前提：顧客要望はなぜ大切か

「受注のためには顧客要望が最も重要だ！」という方もいれば、「顧客要望を聞きすぎると表層的なプロダクトになってしまう」など、顧客要望をどのくらい重要視するかは、人によってもプロダクトによっても違いますが、
顧客要望はプロダクト開発に有用であることは一般的に認められているかと思います。

特に「Airレジ」においては、顧客要望は"宝の山"だと考えています。
「Airレジ」をはじめとする弊社の業務支援サービス「Air ビジネスツールズ」は『お店を取り巻く煩わしさを減らし、自分らしいお店づくりができるようにする』という「ブランドミッション」を持っています。「ブランドミッション」とは我々が果たす使命・目標・方向性を表すものです。

お店の方にとって煩わしい店舗業務を減らして、お店のオーナー様に自分らしいお店づくりに時間を割いてもらうべく、我々は日々プロダクトを磨き込んでいます。

そんなAirのサービスにとって、顧客要望は改善すべき点であると同時に宝の山だと思っています。
なぜなら顧客要望は、”煩わしい”と感じた時に発生すると考えるからです。顧客要望は、『こういう風に動けばいいな』『これができたらいいな』というユーザーの期待値と、現在のプロダクトのパフォーマンスのギャップから生まれます。裏を返すと、顧客要望を解消すれば、徐々にユーザーの期待通りのプロダクトに近づいていき、”煩わしい”と感じる機会を減らしてくことができます。そういった意味で、「Airレジ」にとって顧客要望は宝の山なのです。

課題：「Airレジ」では顧客要望が点在していた

私が「Airレジ」に配属された2018年7月時点で、「Airレジ」では顧客要望が集約されていませんでした。電話を受けるヘルプデスクや、対面でお客様に導入のご案内をするビックカメラ「Airレジ サービスカウンター」担当者など、お客様と接するチャネルごとにバラバラの状態で管理をされている状態でした。

この状態の何が問題かというと、どの要望がどのくらい重要なのかをプロダクト開発チームが判断ができず、どの案件を開発へ進めるかの意思決定ができないという点です。

「Airレジ」は業界・業種を問わず使っていただく、無料のモバイルPOSレジであり、業務支援サービスです。多くの顧客に使っていただくためには、特定の顧客に合わせたオーダーメイドではなく多くの顧客の要望をコスパよく満たすことが求められます。 よって、多くの顧客に対して汎用的にメリットを生み出せる顧客要望を見極めることが重要になります。
そのために、まず顧客要望を集約し、課題の洗い出し、優先度付けを行う必要がありました。

行動：何をしたのか

１）顧客要望の収集・整理・検討するフローづくり

１−１）顧客要望を収集・整理

「Airレジ」で顧客要望を受け取るチャネルはたくさん存在していました。

上記のチャネル毎に、バラバラのフォーマット、ツールで顧客要望を集約、管理し、適宜プロダクト開発チームに連携している状態で、要望のフォーマットや粒度が全く違う状態だったため、プロダクト開発チームもうまく咀嚼しきれていないという課題が有りました。
そこで、要望のフォーマットを統一し、要望用のスプレッドシート(GoogleFormから入力可）に集約し始めました。こうすることで課題の粒度が揃い、各チームが認識を揃えることができます。

当然、今までの運用を変更することになるため、各チームのスイッチコストは余計にかかることになります。そのため最初は、各チームからバラバラに頂いた要望を自分で目見していき、課題の粒度を揃えてシートに手で集約していきました。大変な作業でしたが、配属当初にこの作業を行ったことで、顧客理解が深まり、PdMとしての自分の財産になったと感じています。解釈が加わったりする前の顧客の『生の声』に触れることは本当に大切で、「Airレジ」の機能開発を検討するにあたっても、PdMは『生の声』には必ず触れることになっています。

こうして、声を半期かけて集約・整理していき、250件ほどの機能要望にまとめ、全チャネルにくる要望数を総合し並べました。
ここまでで、どんな機能要望がどのくらいのユーザーに求められているかということがわかる状態になりました。
例）『機能Aの要望は1ヶ月に5件、機能Bの要望は1ヶ月に7件きている。』

１−２）改善につなげるため、課題を堀り下げ、抽象化

顧客要望がまとまり、要望数順位がつくと、『よし、開発するぞ』となるわけではありません。ここで一度課題を抽象化をする必要があります。
顧客から受け取った要望をそのままプロダクトに落とし込むと、いわゆる表面的な『機能要望』対応をしてしまうことになります。
顧客が本当に解決したい課題、具体的には業務上の課題を深堀り、プロダクトに反映させるために、一度要望を深堀り、抽象化しました。

大切にしていたのは、起票者には解釈や加工をなるべくせずに、お客様の生の声を書いてもらうことです。
具体的には要望用のスプレッドシートの左側にユーザーの生声、要望を記載していただき、それを基に深堀りや抽象化をした結果をPdMが右側に記載する、といった流れですすめました。

ここまでで、どんな機能要望がどのくらいのユーザーに、何の業務を達成するために求められているかということがわかる状態になりました。
例）『機能Aの要望は1ヶ月に5件、機能Bの要望は1ヶ月に7件きている。さらに、機能Aの要望と機能Bの要望は同じ業務課題から来ているので、機能Cを提供すればどちらも解決できそうだ』

１−３）今後開発するかどうかを週1回決裁者と検討

要望を収集し、課題を深堀りし並べた後に、いよいよプロダクトとして機能開発をするかしないか『やるやら』を判断します。

週1回のペースでプロダクトオーナーと決裁の場を設け、プロダクトとして機能を開発する、しないを振り分けていきました。

上記の『顧客のジョブはなにか？』という観点に気をつけつつ案件をぶつけ続け、1年間で約250件の案件をぶつけ、80件の『やる』という案件を創出しました。

２）検討結果を可視化、共有する仕組みづくり

しかし、 顧客の声に対する開発体制の構築はできたものの、要望を収集した結果、新たな問題が発生しました。

要望を上げてくれたチームメンバーから、『要望に対する検討はどうなったのか？』と問い合わせが入るようになりました。

大きい案件であれば議事録とともに共有されるが、1つの改善や機能の開発内での詳しい検討内容はブラックボックスであるため、開発されるまで顛末はわかりません。このままでは

といったことにつながってしまうと考えたため、私は要望の検討内容、収集状況をフィードバックする仕組みを作ることにしました。

２−１）顧客要望が上がった段階でslackで共有

前述したとおり、顧客要望はチャネルによって数や温度感が偏ってしまうので、質と量を担保するため1人のプレイヤーではなく組織みんなで集める必要があります。
少しでも多くの要望を上げていただくために、要望が起票されたら、自動で他の組織の人も分かるようにslackの『#airregi-voc-request』という要望チャンネルに流れるようにしました。
このチャンネルには開発組織のほとんどの人が加入しており、日々上げられた要望がリアルタイムに確認できる状態になっています。
また、顧客がアプリ上から上げた要望も自動で流れるようにし、なるべく一次情報に近い声に1日5-10件ほど触れることができるようになっています。

このチャンネル上で詳しい担当者をメンションして直接質問したり、いろんな部署の人間が入り乱れて要望を検討することが出来ます。

２−２）決裁者による検討内容もslackで共有

更に、要望が検討され「やる」「やらない」が判断されたタイミングで、その結果も同じチャンネルで共有するようにしました。
こうすることで、起票者は上げた要望が結局「やる」と判断されたのか？されたとしたらどのフローに載って、どのように開発につながるのか、などを把握することができます。

また、もし「やらない」とした場合も、その理由を明記することを徹底しました。こうすることで要望が上げっぱなしになることを防ぐことができ、より要望を上げるモチベーションにつなげることが出来ました。

「うちの組織では顧客要望を大切にしている」という認識からより多くの声が集まるという好循環に入れると、収集が大変楽になり、協力者も徐々に増えていきました。

結果：どうなったか

上記の活動を通して以下の変化がありました。

1)  要望数がコンスタントに集まるようになった　について
プロダクト、ユーザーは常に変化します。よって顧客要望は常に収集、精査し続ける必要があります。上記活動を通して、「Airレジ」では毎月100件以上の組織内要望が寄せられるようになりました。

2)ヘルプデスクが詳細な課題のヒアリングを行ってくれるようになった　について
「要望をしっかり収集し、それを基に開発をするぞ！」という姿勢が伝わり、ヘルプデスクがお客様のお問い合わせに関して、より詳細な課題のヒアリングを行ってくれるようになりました。このヘルプデスクの取り組みが取り上げられた社内広報用の漫画をご覧ください。

※社内に掲載された「Air ビジネスツールズ」の広報新聞。ヘルプデスクのある北海道の旭川でも掲載されました。

当然、問い合わせに対して課題のヒアリングを行うと一件あたりの対応時間は長くなります。ヘルプデスクは日々、お客様からの問い合わせにどのくらい応答できたかという「応答率」をKPIとして持っているため、課題のヒアリングを行うのはかなり難しいことです。ですが、プロダクト開発に要望を活かしていることをお伝えし続けた結果、上記のように課題のヒアリングを行ってくれるようになりました。

3) 開発工数を獲得し、顧客要望に基づく案件専用のプロダクト開発チームを発足した　について
要望の収集、精査、『やるやら』判断を配属当初、2018年7月から行い続け、2019年4月より、『顧客要望に基づく案件専用のプロダクト開発チーム』が発足しました。
6人の小さなチームですが、私がプロダクトオーナーとして2019年5月〜9月までの半年間で9個の案件をリリースしました。それ以降も継続して開発工数を確保し、顧客要望に対する開発を続けています。

↓チームのリリース案件の1つ、入出金をわかりやすくするUI変更。レジにお金を入れる入金操作とレジからお金を出す出金操作を間違えて行ってしまう店舗が多いことから、UIを変更した。

結果、リリースから1ヶ月で毎月2400回ほどの訂正作業を減らすことが出来た。

まとめ：顧客要望をプロダクト開発に反映させる際のポイント

この取組を通して得た、顧客要望をプロダクト開発に反映させるために大切だと感じたポイントは3つです。

①顧客要望に対する開発検討を、"定期的に"行うフローを整備すること
これを行うことで、以下のメリットが有ります。
・常に案件が精査される状態になるので、塩漬けになることがない
・常に案件を創出する必要があるので、顧客要望を効率的に収集する方法を考えざるを得ない
・ある一時の優先度ではなく、常に最新の顧客体験に基づく優先度になる

上記のメリットにも有るように、定期的に検討を行うことで、結果的に顧客要望の量と質を担保することが出来ます。

②「やる」か「ここ3年はやらない」となるまでPdMが意思決定をすること
顧客要望は集めた際は温度感が高いのですが、結局どうなったんだっけ？となりがちです。
「やる」として積むか、一旦「ここ3年はやらない」という判断をしてクローズするかどちらかにすることで、中途半端な検討をしなくてすみます。

③組織に対して顧客要望の可視化と共有をすること
顧客要望は、質と量を担保するため1人のプレイヤーではなく組織みんなで集める必要があります。
その際に大切なのは、こういう声がこういうチャネルでこれくらい来ている、という認識を合わせることです。これにより部署間で受ける要望の差分が明らかになり、一部の強い声に惑わされることが少なくなります。
「うちの組織では顧客要望を大切にしている」という認識からより多くの声が集まるという好循環に入れると、収集が大変楽になり、協力者も徐々に増えていきます。

顧客要望に基づくプロダクト開発は、単純にプロダクト自体の価値を向上させるだけでなく、組織全体が納得感を持ってプロダクトを作ることができるという社内組織的なメリットもあります。
この記事の内容を参考にして1つでも多くの顧客要望をプロダクトに取り入れていただければ幸いです。