開発者は画面を機能の集合として見がちです。しかし利用者が欲しいのは「検索機能」や「送信ボタン」ではなく、必要な情報を見つける、申込みを終える、課題を提出するといった結果です。問い合わせは、その結果へ向かう途中でプロダクトと利用者の認識がずれた記録です。
問い合わせ対応の目的は一件を閉じることだけではなく、次の利用者が同じ場所で困らない状態を作ることです。
定義と結論
顧客の声（Voice of Customer）とは、問い合わせ、インタビュー、アンケート、レビューなどから得られる、利用者の目的・期待・体験に関する情報です。大切なのは、発言をそのまま仕様にするのではなく、発言の背景にある課題を仮説として扱い、行動データや再現確認と組み合わせることです。
結論から言えば、よい改善は「利用者の発言」「実際に起きた事実」「事業と技術の制約」の重なる場所にあります。一件の強い要望だけで優先順位を決めるのも、アクセス解析の数字だけで理由を推測するのも危険です。
なぜ必要なのか
開発環境では入力値も操作順も分かっています。利用者は用語を知らず、スマートフォンを片手で操作し、通信が遅く、締切直前かもしれません。この差はコードレビューだけでは見つけにくいものです。
問い合わせを分析すると、次の改善機会が見えます。
- エラーではなく説明不足で止まっている場所
- 開発者の用語と利用者の言葉が食い違う場所
- 成功したのに完了したと伝わらない場所
- 特定の端末、支援技術、通信環境でのみ起きる問題
- 個別案内で何度も回避している構造的な欠陥
サポート担当者が毎回説明している手順は、画面が説明できていない可能性があります。
登場人物と役割
利用者は目的と困り方を知っていますが、原因や最適な解決策まで知っているとは限りません。サポート担当者は声が集まる場所と頻度を知り、開発者は再現条件と技術的な原因を調べます。デザイナーは情報設計や操作の分かりやすさを検討し、プロダクト責任者は対象利用者、効果、費用、戦略を踏まえて優先順位を決めます。
この連携で重要なのは、原文を失わないことです。「使いにくい」という要約だけでは判断できません。個人情報を除いたうえで、利用者が使った言葉、目的、端末、時刻、画面、試した操作を残します。
問い合わせを改善へつなげる流れ
1. まず利用者の目的を確認する
「ボタンが押せない」に対して、すぐボタンの調査を始めるのではなく、「何を完了したかったか」「どこまで進めたか」を聞きます。目的が分かれば、一時的な回避方法も案内しやすくなります。
2. 事実と解釈を分ける
「送信を押した」「読み込み表示が10秒続いた」「完了メールは届かなかった」は観察事実です。「サーバーが遅い」「送信に失敗した」は解釈です。調査の初期段階では混ぜません。
3. 再現に必要な条件をそろえる
対象URL、発生日時、端末、OS、ブラウザ、アカウント状態、入力内容の特徴、表示された文言を確認します。パスワード、決済情報、本人確認書類などは収集せず、ログにも残さない設計にします。
4. 複数の証拠を突き合わせる
同種問い合わせの件数、アクセス解析の離脱、アプリケーションログ、エラー監視、セッションの状態、再現結果を比較します。問い合わせが少なくても、対象が少数の重要利用者だったり、問い合わせることすらできず離脱していたりするため、件数だけで切り捨てません。
5. 課題を一文で定義する
「確認画面を追加する」ではなく、「スマートフォン利用者が送信完了を判断できず、再送信してしまう」のように、対象、状況、困りごとを記述します。解決策を課題の文章に混ぜないのがポイントです。
6. 小さく改善し、結果を見る
完了表示の改善、ボタンの多重送信防止、エラー文の配置変更など、仮説に対応する変更を行います。公開後は同種問い合わせ、完了率、重複送信、エラー率を確認します。
声の読み方：主要な4パターン
| パターン | 例 | 主な確認 |
|---|---|---|
| 不具合報告 | 保存すると消える | 再現条件、ログ、影響範囲 |
| 理解のずれ | 「公開」の意味が分からない | 用語、ラベル、事前説明 |
| 要望 | CSVで出したい | 背景の仕事、頻度、代替手段 |
| 感情・評価 | 怖くて押せない | 取り消し可否、結果の予測可能性 |
要望は特に注意が必要です。「CSVボタンが欲しい」の背景が、表計算ソフトへの転記ならCSVが候補です。しかし目的が月次報告なら、共有リンクや定型レポートの方が適切かもしれません。利用者の解決案を尊重しつつ、解決したい仕事まで一段掘り下げます。
具体例：課題提出画面で二重送信が起きる
「提出ボタンを押しても反応しない」という問い合わせが届いたとします。調査すると、通信中もボタンの見た目が変わらず、数秒後に利用者が再度押していました。サーバーでは最初の要求は成功し、二度目も別の提出として登録されていました。
この場合、回答で「一度だけ押してください」と伝えるだけでは再発します。改善候補は、送信中にボタンを無効化する、処理中であることを表示する、サーバー側で同一操作を重複処理しない、完了後に受付番号を示すことです。確認指標は、二重送信件数、提出完了率、同種問い合わせ件数になります。
優先順位の付け方
すべての声を同時には直せません。少なくとも「影響を受ける人数」「困りごとの深刻さ」「発生頻度」「事業上の重要性」「修正と検証の費用」で比較します。障害、安全性、個人情報、決済、アクセシビリティに関わる問題は、単純な要望投票より高く扱うべきです。
声が大きい人の要望と、対象全体の代表性は別です。反対に、少数者のアクセシビリティ上の障壁を「件数が少ない」で後回しにしてよいわけでもありません。数と重大性を分けて評価します。
よくある誤解
「利用者の言うとおり作ればよい」
利用者は課題の専門家ですが、設計の責任者ではありません。発言は重要な証拠であり、命令書ではありません。
「問い合わせがないから問題はない」
離脱した人、諦めた人、問い合わせ方法が分からない人の声は届きません。利用テスト、解析、ログと組み合わせます。
「説明文を足せば解決する」
文章が必要な場合もありますが、制御の配置、初期値、入力制約、状態表示そのものを直す方が有効なことがあります。説明を読む負担もコストです。
「問い合わせ件数をゼロにするのが成功」
相談窓口を見つけにくくすれば件数は減ります。成功は、目的達成率や満足度を保ちながら回避可能な問い合わせが減ったかで判断します。
注意点とベストプラクティス
- 問い合わせ原文へのアクセス権を絞り、分析用データは匿名化する
- 顧客名ではなく課題単位で分類し、同じ原因をまとめる
- タグを増やしすぎず、定期的に分類基準をそろえる
- 回避策と恒久対応を分け、恒久対応の担当と期限を決める
- 改善しない判断にも理由を残し、前提が変わったら見直す
- 本人の同意や組織の規程なしに通話・画面を記録しない
デバッグと効果確認
調査では、問い合わせの時刻を起点にブラウザのNetwork、サーバーログ、監視イベントを追います。再現環境では同じ端末幅、権限、入力条件、通信速度を近づけます。ログに利用者の入力を無制限に出すのではなく、追跡用ID、処理結果、所要時間など必要な情報だけを記録します。
公開後は「直ったように見える」で終えません。変更前後の同種問い合わせ率、完了率、エラー率、処理時間を同じ期間・対象で比較します。別の利用者に新しい混乱を生んでいないか、キーボード操作やスクリーンリーダーも含めて確認します。
改善の完了条件には、コードの公開だけでなく、利用者の困りごとが減ったことを確かめる方法を含めます。
まとめ
問い合わせは、不具合一覧ではなく利用者の目的とプロダクトのずれを示す観察窓です。目的を聞き、事実と推測を分け、複数の証拠で課題を定義し、小さく改善して結果を測ります。声を盲目的に採用せず、無視もせず、設計判断に変換することがプロダクト開発の仕事です。
参考資料
- GOV.UK Service Manual: User research
- GOV.UK Service Manual: Using moderated usability testing
- Digital.gov: Customer Experience Toolkit
