「もっと使いやすくしてほしい」をどう具体化する？顧客要望の確認方法
「もっと使いやすくしてほしい」と届いた要望を、どう開発へ渡せばよいか迷うことはありませんか。曖昧な顧客要望は、直近の作業、困った場面、望む結果を確かめると検討しやすくなります。最初から詳しい仕様を求めず、判断に足りない情報を一つずつ補う方法を紹介します。
要望を集めてから判断・回答までつなぐ全体像は、機能要望管理の基本で扱っています。
- 顧客の原文を残し、推測した仕様と分ける
- 直近の作業と困った場面から質問する
- 望む結果と未確認の点をまとめて引き継ぐ
顧客の原文を推測した仕様に置き換えない
最初に残すのは、顧客が実際に伝えた言葉です。「見づらい」を受け取ってすぐに「文字を大きくする」と登録すると、困りごとを確認する前に解決案が決まってしまいます。
たとえば、架空の申請管理ツールに「一覧をもっと見やすくしてほしい」という連絡が届いた場面を考えます。文字が小さい可能性もあれば、承認待ちを探しにくい可能性もあります。この段階では、どちらも受け取った側の推測です。
英国政府のサービス設計ガイドは、利用者のニーズを整理する方法で、解決策より利用者の問題に焦点を当て、調査の根拠に基づいて記述することを示しています。これを要望受付に応用するなら、原文と、こちらが確認したい点を分けて記録するのが実践しやすい方法です。
| 区分 | この時点で残す内容 |
|---|---|
| 顧客の原文 | 一覧をもっと見やすくしてほしい |
| 確認したい点 | どの一覧で、何を探していたか |
| まだ決めないこと | 文字サイズ、並び順、絞り込みの追加 |
顧客が「絞り込みを追加して」と具体的に書いている場合も、その提案は原文として残します。提案を否定する必要はありません。どの作業を終えたいのかも確かめると、提案した機能が必要な条件を検討できます。
直近の一回を尋ねると確認する場所が分かる
最初の質問は、実際に困った作業へ戻れるものにします。「どのように改善すればよいですか」だけでは、顧客に設計を任せることになり、困りごとの説明が増えない場合があります。
先ほどの例なら、「直近で一覧を見づらいと感じたとき、どの画面で何を確認していましたか」と尋ねられます。返答が「月末に未承認の申請を探していた」であれば、画面と目的が分かりました。次は、その作業のどこで時間がかかったかを確認します。
英国政府のインタビューの進め方も、答えを誘導しない開かれた質問と、実際の出来事や具体例に焦点を当てることを勧めています。ここでは、その聞き方を短い確認のやり取りに応用します。長い面談を行った結果として扱うものではありません。
一度の連絡で質問を詰め込まず、次に検討が進む点から尋ねます。「一覧の表示が遅かったですか」と原因を先に置くより、「探すとき、どのように操作しましたか」のほうが、顧客自身の説明を受け取れます。
画面を見ないと分からない場合は、表示名や操作の順序を確認します。画像を送ってもらうなら、顧客名や申請内容など、確認に不要な情報を隠してもらうと扱いやすくなります。画面全体を必須にせず、文章で説明する方法も残します。
困った場面から、望む結果を確かめる
操作の説明が得られたら、作業を終えたと判断できる状態を確かめます。「便利にしたい」という言葉を、顧客の業務で確かめられる内容へ近づけるためです。
架空のやり取りを続けると、「月末に未承認の申請を一件ずつ開き、自分が確認すべき申請かを確かめていた」という返答があったとします。ここでは「未承認だけを表示できれば十分ですか」と結論を急がず、「確認が終わったら、次にどんな作業へ進みたいですか」と聞きます。
望む結果が「自分の確認待ちを把握して、承認を終えること」なら、未承認の状態だけでなく、担当者の判別も検討対象になります。同じ「一覧が見づらい」でも、必要な情報が少し具体的になりました。
| 確かめること | 質問の例 |
|---|---|
| 実際の手順 | そのとき、どの順番で申請を確認しましたか |
| 困った箇所 | どの操作で迷ったり、確認し直したりしましたか |
| 望む結果 | 何が分かれば、次の作業へ進めそうですか |
| 現在の回避策 | いまはどのように確認を終えていますか |
影響の大きさが判断に必要なら、発生する場面や頻度も追加で聞きます。顧客が数字を把握していなければ、無理に時間を答えてもらう必要はありません。「月末の確認で起きる」「担当交代のときに迷う」といった条件でも、次の調査の手がかりになります。
確かめた内容と未確認の点を一緒に引き継ぐ
開発へ渡す前に、理解した内容を顧客へ短く返します。ここで確認するのは困りごとの理解であり、実装する機能や時期への合意ではありません。
先ほどの例なら、次のように確認できます。
月末に未承認の一覧から、ご自身が確認する申請を探すため、一件ずつ開いているのですね。まず確認待ちの申請を把握し、承認を終えたいという理解で合っていますか。
返答で補足されたことは記録へ戻し、まだ聞けていないことは未確認のまま残します。「ほかの担当者も同じか」「申請の件数で違いがあるか」は、回答がなければ事実として書けません。
引き継ぎでは、原文、確かめた内容、未確認の点を分けることが大切です。たとえば「原文：一覧を見やすくしたい」「確認済み：月末に自分の確認待ちを探している」「未確認：他の役割でも同じ作業があるか」と残せます。解決案を添える場合は、検討候補だと明示します。
確認を続けるか迷うときは、次の担当者が何を決められるかで区切ります。対象の作業と困る場面が分かり、追加調査の必要性を判断できるなら、まず渡してかまいません。すべてを聞き終えるまで受付担当者が抱える運用にすると、要望が共有されないまま止まってしまいます。
詳しい業務の流れを聞く必要があれば、ユーザーインタビューの質問と進め方へ進めます。短いやり取りで何度も同じ点を聞き直すより、確認したいことをまとめて時間を取るほうが、顧客も説明しやすくなるでしょう。
よくある質問
顧客から追加の返答がない場合、要望を削除しますか？
返答がないことだけで不要とは判断せず、届いた原文と確認待ちの点を残します。連絡した日時と次に確認する機会も記録し、未確認の情報を推測で埋めないようにします。
営業が顧客の代わりに要望を伝えた場合はどうしますか？
顧客が実際に使った言葉と、営業の解釈を分けて残します。まず営業が確認済みの情報を読み、不足する点だけを本人へ確認できるか相談してください。
AIで曖昧な要望を具体化してもよいですか？
確認質問の候補を考える補助には使えます。ただし、AIが補った利用場面や理由を顧客の発言として記録してはいけません。顧客に確かめた内容と、未確認の仮説を区別してください。
まとめ
曖昧な要望が届いたら、顧客の原文を残し、推測した仕様と分けます。直近の作業と困った場面から質問し、望む結果と未確認の点をまとめて引き継ぐと、次に判断することが明確になります。記録の置き方は、顧客要望の管理表テンプレートも参考にできます。
