アンケートを作成したチームにとってどれほど自然に見えても、回答者にとっては答えにくいことがあります。「レポートをどのくらいの頻度で共有しますか？」という質問はシンプルに思えますが、リンクの送信を思い浮かべる人もいれば、スライドでのプレゼンを指すと考える人もいます。あるいは、他の人のレポートを転送することが含まれるのか迷う人もいるでしょう。その結果、ひとつの質問項目のもとに、まったく異なる複数の行動が混ざり合ったデータが集まることになります。

アンケート設計とは、回答者に届く前にそうした曖昧さを見つけ出す作業です。回答者が自分で入力する場合でもインタビュアーが聞き取る場合でも、言葉遣いや選択肢、順序、見せ方などを整えていきます。優れたアンケートとは、質問の意図を明確にしつつ、チームが想定していない回答を受け止める余白も残されているものです。

意思決定から逆算して設計する

あるチームが、レポートの共有機能を改善すべきか、それともエクスポートの形式を増やすべきかで悩んでいるとします。回答者にその両方のアイデアを評価してもらえば、どちらが好まれているかは分かるかもしれませんが、回答者が今どのような点に不便さを感じているかはほとんど見えてきません。それよりも、直近で共有したレポートの内容や相手、その際の手順について尋ねる方が、チームにとって深掘りする価値のある示唆が得られます。

設問を書く前に、どのような分析を行う予定かをイメージしてみてください。ライトユーザーとヘビーユーザーを比較したいなら、両者を納得感のある形で分類できる質問が必要です。また、回答結果が今後の判断に影響を与えないのであれば、その設問自体を外すことも検討しましょう。「後で何かの役に立つかもしれない」という理由だけで情報を集めても、アンケートの質が高まることはほとんどありません。

正直に選べる選択肢を用意する

質問はひとつずつ行いましょう。プロダクトについて「動作は速いが安定性に欠ける」と感じている回答者の場合、「速度と安定性にどの程度満足していますか？」と問われると、どう妥協して答えればいいか迷ってしまい、分析する側もその意図を正しく読み取れません。また、具体的な期間を指定するのも効果的です。その期間の出来事を無理なく思い出せる範囲であれば、「普段」と尋ねるよりも「過去7日間」とした方が、回答のブレを抑えやすくなります。

選択肢にも言葉遣いと同じ配慮を

選択肢の設計は、言葉遣いと同じくらい重要です。数値の範囲が重複していると分類が曖昧になり、「使ったことがない」という選択肢がないと、単なる利用経験のなさがネガティブな評価として現れてしまうことがあります。「どちらでもない」「わからない」「該当なし」はそれぞれ異なる状況を表しているため、これらをひとつにまとめてしまうと、後々重要になるはずのニュアンスが埋もれてしまいます。イギリス政府の分析機能（Government Analysis Function）が公開しているアンケート設計ガイドラインは、言葉遣いや選択肢の精査、テストを行う際の実践的な参考になります。

質問全体の流れを意識する

それぞれの質問は、その前にあった質問の文脈に影響されます。たとえば、不満点に関する質問が長く続くとその後の総合評価が下がりやすくなったり、早い段階でメリットのリストを見せると、その後の自由記述で回答者自身の言葉が出にくくなったりします。自由な回答を得たい質問は関連する選択肢リストの前に配置し、経年変化を追う場合は質問の順序を変えないようにしましょう。

条件分岐を活用して、回答者に関係のない質問をスキップさせる配慮も欠かせません。スキップ設定や任意の設問も含めてすべての分岐パターンをテストし、PCの大画面だけでなくスマートフォンでも確認してください。編集画面ではコンパクトに見えるマトリクス形式の設問も、回答者が使う実際の端末では、スクロールするだけでも負担の大きい作業になり得ます。

本番の配信前に理解度をテストする

パイロットテストでは、回答にかかる時間だけでなく、回答者がどのようなプロセスを経てその答えにたどり着いたかを確認します。想定される対象者数名に、解釈が分かれそうな質問をどう理解したか説明してもらいましょう。その上で、本調査が完了したと仮定して回答データをチェックし、想定していた分析が本当に成立するかを検証します。

この段階で自由記述の質問を取り入れると、不足していた選択肢に気づくことができ、一見問題なさそうな重複した質問が回答疲れを引き起こしていることにも気づけます。アンケートの設計が固まったら、Ballparkのアンケート機能を使って回答を収集できます。最終的に得られるデータの質は、設問の設計、回答者の集め方、そして回答者の属性をどれだけ丁寧に読み解けるかにかかっています。