Reddit、X、Hacker Newsから製品フィードバックや機能リクエストを収集する方法

通常のフィードバックチャネルが見落としてしまう理由

多くのチームは、サポートチケット、アプリ内ウィジェット、営業電話の3つの場所からフィードバックを収集しています。これら3つにはすべて同じ偏りがあります。すでにあなたと対話している人々の声しか届かないということです。

公開スレッドは異なります。先月解約したユーザーがアンケートに答えてくれることはありませんが、Redditでなぜ利用をやめたのかを喜んで説明してくれることはよくあります。ツールを比較検討している見込み客は、「どれを選ぶべき？」という投稿の中で、あなたの製品に足りない機能を挙げます。これらは他の方法では決して得られないフィードバックであり、多くの場合、賛同や反論の返信が付くため、その問題がどれほど一般的であるかも把握できます。

課題となるのは情報量です。製品名を週に1回検索しても、見つかるスレッドはほんの数件で、返信するには手遅れであることがほとんどです。一方で製品名の単純なアラートを設定すると、製品とは無関係なものも含め、すべてのメンションが届いてしまいます。コツは、フィードバックに特化して検出するアラートを作成することです。

フィードバックを検出するアラートの作成

KWatchのアラートはリスト内のすべてのキーワードに一致するため、カンマはAND条件として機能します。これこそがフィードバックアラートが効果を発揮する理由です。製品名単体のアラートを1つ設定する代わりに、製品名と、ユーザーが何かを変更してほしいときに使う単語を組み合わせます。

製品名を「acme」とした場合の基本設定例をご紹介します：

1. acme, wish および acme, would be nice 機能リクエスト向け
2. acme, bug および acme, broken バグ報告向け
3. acme, switched および acme, cancelled 解約理由向け
4. acme, missing および acme, doesn't support 導入検討中にユーザーがつまずいた不足点向け

各行はそれぞれ別のアラートです。これらすべての単語を1つのアラートに入れると、同じ投稿内にそのすべてが含まれている必要があるためです。実際のユーザーがどのように話しているかを確認しながら、1週間ほど経った頃に表現を調整するとよいでしょう。「機能リクエスト」という言葉をそのまま入力する人はほとんどいないため、「〜だと嬉しい」「〜があればいいのに（would be great if）」など、実際に使われるフレーズを探してください。

いくつかのフィルターを使うことで、大部分のノイズを整理できます。RedditやHacker Newsでは、製品名が短い場合や一般的な単語である場合は「Whole Words Only」を有効にして、「acme」が「acmeplex」に一致しないようにします。自社チームのアカウントを「Excluded Users」に追加すれば、自社の返信や告知投稿でアラートがトリガーされるのを防げます。自社製品専用のサブレディットがある場合は、「Included Subreddits」でそのサブレディットを対象とした個別のアラートを作成し、2つ目のキーワードを完全に省略することも可能です。そこに投稿されるほぼすべてがフィードバックだからです。

除外キーワードは、必須キーワードとは逆の仕組みで動作します。必須キーワードはすべて一致する必要がありますが、除外キーワードはいずれか1つでも現れると、その投稿は除外されます。このリストは短く具体的にとどめてください。さもないと、ノイズと一緒に本物のフィードバックまで除外してしまいます。当社の キーワードアラートのノイズを減らす方法に関する記事 で、各フィルターについてさらに詳しく解説しています。

まずどこに耳を傾けるべきか

すべてのプラットフォームで同じようなフィードバックが得られるわけではありません。RedditやHacker Newsは、長文で具体的な不満が書き込まれる場所です。Xはより短文で感情的な投稿が多く、リリース不具合を迅速に検知するのに役立ちます。Linkedinは称賛や告知が中心であるため、業務ツールについて投稿する層を対象に販売しているのでない限り、このリストの中では優先度が低くなります。

更新速度もプラットフォームによって異なり、各アラートの使い方も変わってきます。以下は公式ドキュメントからの更新頻度です：

フィードバックの収集において、これらはいずれも遅くはありません。この表が示しているのは、Hacker Newsのスレッドがトップページに掲載されている最中に通知を受け取ることができるということであり、それこそがチームメンバーによる返信が最も効果を発揮するタイミングです。

製品チームへのフィードバックの伝達

誰も読まないアラートは、単に少し便利な検索機能に過ぎません。多くのチームが見落としがちなのは、フィードバックがどこに届き、誰が確認するのかを決めることです。

最もシンプルな設定は専用のSlackチャンネルを用意することです。KWatchではアラートごとにSlackウェブフックを設定でき、個別のアラート設定はアカウント全体の設定よりも優先されます。そのため、営業アラートは営業チャンネルに送り続けながら、フィードバックアラートは#product-feedbackのようなチャンネルに届けることができます。閲覧のみが必要なプロダクトマネージャーやエンジニアは、通知を受け取ることはできるがアラートの作成や削除はできない「Reader」権限でKWatchチームに参加できます。

リクエスト数を時系列で集計したい場合は、同じアラートをAPIウェブフックに送信します。一致した各投稿はJSONペイロードとして届きます。公式ドキュメントからの例は以下のとおりです：

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

これをZapierやn8nのウェブフックに連携し、フィールドごとに1列を割り当ててスプレッドシートへ行を追加します。 query フィールドによってどのアラートがトリガーされたかがわかるため、要望アラートとバグアラートを自動的に分類できます。 sentiment フィールド（positive、negative、またはneutral）を使えば、不満の声が含まれる投稿をすばやく抽出できます。連携の設定が初めての方に向けて、 Zapierおよびn8nのセットアップ手順 をステップ・バイ・ステップで詳しく解説しています。

メールアラートも利用できますが、長文の投稿はメール内で途切れてしまいます。機能リクエストは長くなる傾向があるため、ここではSlackやウェブフックの方が適しています。

見つかった情報への対応方法

フィードバックが届き始めると、すべてに返信したくなるものです。しかし、少し控えめに対応することをお勧めします。製品の開発に携わっていることが明らかな人物からの簡潔で有用な返信（「その機能はロードマップに入っています。当面はこちらの回避策をお試しください」など）は大きな効果をもたらします。一方で、文末がすべて登録リンクで終わるような返信を連投すると低評価を受け、一部のサブレディットではアクセス禁止（BAN）になります。

より価値のある習慣は、週に1回の確認です。週に1度、製品チームの担当者がチャンネルやスプレッドシートをチェックし、各項目に「リクエスト」「バグ」「解約理由」「無関係」といったタグを付けます。1か月後には、公開の場で求められているものとチケットで求められているものの概算が並びます。この2つのリストの内容が一致しないときこそ、通常最も興味深い発見があります。

最も有益なフィードバックの一部が、キーワードではなく特定の既知の人物（パワーユーザー、アナリスト、競合の創業者など）からもたらされる場合、当社の姉妹製品である MultiFollow は特定のLinkedinおよびXアカウントをフォローし、投稿時に通知します。これはキーワードアラートを補完するのに最適です。