顧客の声が製品改善に届かない原因は、開発部門の姿勢ではありません。「使いにくい」という定性的な情報を、定性的なまま渡していることが原因です。

開発の優先順位は、影響する顧客数や解約リスクといった比較可能な値で決まります。比較できない形の情報は、届いていても順位が付けられず、結果として滞留します。本記事では、収集したフィードバックを比較可能な形に変える手順と、最も省かれやすい「顧客へ返す」工程までを扱います。

届かないのは熱意ではなく、形式の問題

現場から開発への伝達が機能しない組織では、次の状態が同時に起きています。

工程機能しない状態機能する状態
受付担当者ごとにチャット・メール・口頭で受ける入口を1つに集約する
記録顧客の言葉をそのまま書き写す分類のタグを付けて記録する
集計印象に残った要望を報告するタグ別に件数と影響範囲を出す
受け渡し定例会で口頭共有する集計結果を添えて起票する
還元採否が現場に戻らない採否と理由が起票者へ戻る

最初の2工程が崩れていると、後工程では回復できません。入口が分散していれば集計できず、タグが無ければ何件あるのかも数えられないためです。

「顧客の声を大事にする」という方針では、この構造は変わりません。変えるのは記録の形式です。

収集段階で決めるのはタグの設計

タグを付けずに集めたテキストは、後から分類できません。件数が増えるほど読み直しの負荷が上がり、結局は印象に残ったものだけが報告されます。

タグは最初から網羅しようとせず、次の3系統に絞って始めます。

  • 対象：どの機能・画面・業務に関することか
  • 種類：不具合、機能追加の要望、使い方が分からない、期待と仕様の不一致
  • 状況：導入直後、日常利用、更新前など、どの段階で出たか

3系統目は省かれがちですが、打ち手を分けるうえで効きます。導入直後に集中する「使い方が分からない」は、製品の改修ではなく案内の整備で解けることが多く、日常利用で出る同じ声とは対処が異なります。

タグを増やしすぎると、入力する側が選べなくなります。1系統あたり10個を超えたら、統合できないかを見直してください。運用の初期は粗い分類で構いません。

定性を、数えられる形に変える

タグが付けば集計できます。ここで数えるのは、要望の件数だけではありません。

数えるもの見方注意点
件数どのタグに集中しているか同一顧客の繰り返し起票を1件に寄せる
顧客数何社が同じことを言っているか件数より優先して見る
該当し得る顧客数同じ条件に当てはまる未発言の顧客発言していない層を推定する唯一の手がかり
発生段階どの段階で出ているか導入初期に偏るなら案内の問題を疑う

3つ目が重要です。問い合わせや自由記述に書き込むのは顧客の一部であり、書かない顧客の声は記録に残りません。記録された件数だけで判断すると、繰り返し起票する少数の顧客に開発資源が向かいます。同じ利用条件に当てはまる顧客が何社いるかを併記すると、この偏りを補正できます。

集計を人手で行う場合、確証バイアスが入ります。想定していた仮説に合う意見が拾われ、合わない意見が落ちる傾向です。対処は分析者を賢くすることではなく、手順を固定することです。集計の対象期間、タグ、出力する項目を先に決め、決めた通りに出します。例外的に目を引いた声は、集計とは別枠で「個別事例」として扱ってください。

なお、テキスト解析のツールは集計を速くしますが、何を数えるかの定義は代替しません。タグと入力ルールが無い状態で導入しても、得られるのは語の出現頻度です。

開発への受け渡し

集計結果を渡す際は、要望そのものではなく、要望から抽出した課題を渡します。「この画面にボタンが欲しい」は手段であり、解決したい状態ではありません。

起票に含める項目は次の通りです。

  1. 解決したい状態：顧客が何をできるようになりたいのか
  2. 影響範囲：何社、どの層の顧客が該当するか
  3. 現状の回避策：今どう凌いでいるか、その工数
  4. 放置した場合の見込み：更新時の論点になるか、他の手段で代替されるか

3つ目があると、開発側が緊急度を判断できます。回避策が存在しない要望と、手作業で凌げている要望では扱いが変わるためです。

順序付けの方法そのもの（要望の分類と優先度の数値化、断り方）は顧客の要望を断れない組織を変える要求管理の記事で扱っています。フィードバックループの設計としては、その判断に必要な材料を、判断する側に揃った形で渡すところまでが範囲です。

ループを閉じる：採否と理由を顧客へ返す

多くの組織で省かれるのが、この最後の工程です。集めて、渡して、実装するところまでは回っていても、結果が顧客に戻らないループは閉じていません。

戻さないと、次の3つが起こります。

  • 顧客は「言っても変わらない」と判断し、要望を出さなくなる
  • 実装済みの改善が使われないまま、同じ要望が繰り返し届く
  • 現場の担当者が、要望を受けること自体を避けるようになる

返す対象は2種類に分けます。

対象タイミング内容
起票した顧客採否が決まった時点判断結果、理由、代替手段、再検討の条件
同じタグの要望を出した顧客リリース時何が変わったか、どう使うか

2つ目を省くと、改善が伝わりません。リリース告知を一斉配信しているだけでは、自分が出した要望への回答だと気づかれないためです。該当する顧客に、その要望への対応であると明示して伝えてください。

この還元を担当者の善意に任せると実行されません。採否の決定とリリースを、連絡の発火点として運用に組み込んでください。接触の起点を仕組みにする考え方はカスタマーサクセスの御用聞き化を止める設計の記事で扱っています。

落とし穴

落とし穴1：タグが増え続ける。 新しい要望が来るたびにタグを足すと、数か月で選べない数になります。追加は定期の見直しの場に限り、既存タグで表せないかを先に確認します。

落とし穴2：集計が特定の担当者に固定される。 手順が文書化されないまま一人が続けると、その人の判断が集計結果になります。対象期間・タグ・出力項目を文書にし、別の担当者が同じ結果を出せる状態を保ってください。

落とし穴3：件数の多いタグから着手する。 件数は発言する顧客の性質に左右されます。顧客数と該当し得る顧客数を併せて見ない限り、順序は決められません。

落とし穴4：不具合と要望を同じ列で扱う。 不具合は当たり前に満たされるべき品質の欠落であり、要望との優先度比較には馴染みません。受付は同じ入口でも、起票の時点で分けてください。

まとめ

  • 声が届かない原因は熱意ではなく、定性的な情報を定性的なまま渡していることです
  • 入口を1つに集約し、対象・種類・状況の3系統でタグを付けます。網羅より運用可能性を優先します
  • 件数だけで判断せず、顧客数と、同じ条件に該当し得る顧客数を併せて数えます
  • 開発へは要望ではなく課題を渡します。現状の回避策を添えると緊急度が判断できます
  • 採否とリリースを顧客へ返して初めてループは閉じます。戻さないループは、やがて声が集まらなくなります