ゲームコミュニティのアンケート設計｜回答を改善につなげる質問例と分析方法

2026年10月30日

ゲームコミュニティでアンケートを取っても、結果を眺めて終わることがあります。「満足していますか」「意見があれば教えてください」だけでは、評価が低い理由も、次に何を変えるべきかも分かりません。一方で質問を増やしすぎると、強い不満や強い関心がある人だけが回答し、普段の参加者の声から離れていきます。

良いアンケートは、回答数が多いものではありません。一つの運営判断を行うために、必要な情報だけを集め、期限内に改善し、結果を参加者へ返すものです。質問を作る前に「この回答で何を決めるか」を一文にします。

Stult Partyなら、ゲーム募集、チャット、ボイスを一つのコミュニティへまとめて無料で始められます。募集から参加、会話までのどこに困りごとがあるかを確認し、改善後の案内も同じ活動基盤で共有できます。本記事では、外部フォームを使う場合も含め、5問から始めるアンケート設計を解説します。

決める、聞く、分類する、改善する、返すまでが一つのアンケートです。

質問より先に「決めること」を一つ選ぶ

アンケートの目的を「満足度を知る」にすると、結果が低かった後の行動が決まりません。次のように、変更可能な運営判断へ変換します。

一回のアンケートで決めることは一つ、多くても二つです。募集時間、ルール、ボイス、参加案内を同時に尋ねると、回答者が想定する場面が揃わず、優先順位も付けられません。

GOV.UKの質問設計ガイドは、すべての質問について「なぜ聞くのか」を先に理解すること、閉じた質問は自由記述より回答しやすいことを説明しています（Designing good questions）。コミュニティでも、回答後に使わない質問は削除します。

「知りたいこと」ではなく「回答後に決めること」から逆算します。

最初は5問で設計する

初回アンケートは、次の5問で十分です。例として「初参加後に再参加しやすくする」という目的で作ります。

1. 対象場面を確認する

過去30日で、ゲーム募集へ参加しましたか？ - 参加した - 参加表明したが参加できなかった - 募集を見たが参加表明しなかった - 募集を見ていない

体験していない人に満足度を聞かないための分岐です。「参加していない」を一種類にまとめず、どこで止まったかを分けます。

2. 最も困った段階を一つ選ぶ

最も参加しにくかった段階はどこですか？ - 自分に合う募集を見つける - 条件を理解する - 参加表明する - 開始時刻に集まる - チャットやボイスへ入る - 特にない

「当てはまるものすべて」では、全部選ばれて優先順位を失います。最も大きい一つを選んでもらいます。

3. 具体的な改善案を選ぶ

一つ変えるなら、どれが参加しやすいですか？ - 募集条件を詳しくする - 初参加枠を設ける - 開始前にチャットで案内する - 聞き専・途中退出の可否を明記する - 少人数の募集を増やす

運営側が実行可能な選択肢だけを置きます。提供できない機能や、担当者がいない施策を選択肢に入れてはいけません。

4. 次回参加の見込みを段階で聞く

同じ条件の募集へ、30日以内に再参加したいですか？ - 参加したい - 条件が合えば参加したい - 今は判断できない - 参加しない

0〜10点だけを聞くより、運営が次に取れる行動へ結びつきます。

5. 自由記述を一問だけ置く

一つだけ変えられるとしたら、何を変えてほしいですか？

「その他ご意見」より、改善対象を一つに絞れます。GOV.UKの満足度測定ガイドも、サービスをどう改善できるかを尋ねる自由記述を少なくとも一つ置く考え方を示しています（Measuring user satisfaction）。

対象確認、障壁、改善案、再参加、自由記述の順にします。

匿名か記名かは「回答後の行動」で決める

匿名なら率直、記名なら正確とは限りません。目的に応じて選びます。

匿名が向く場合

• 運営への不満や話しにくさを確認する
• 個別返信を必要としない
• 集計結果だけで改善できる
• 回答者を追跡する必要がない

記名・連絡先が必要な場合

• 不具合の再現条件を個別に確認する
• 希望者へ追加ヒアリングする
• 抽選や謝礼の連絡をする
• 重複回答を厳密に制御する必要がある

記名が必要でも、アンケート回答と連絡先を別フォームに分けられます。改善意見と個人を安易に結びつけないためです。Microsoft Formsでは、匿名回答を許可した場合、結果に氏名やメールアドレスを表示しない仕様があります。一方、結果の共有リンクはリンクを得た人が閲覧できるため、共有範囲を別途管理する必要があります（Microsoft Forms公式サポート）。

連絡先などの個人情報を入力してもらう場合は、取得前に利用目的を明確にします。個人情報保護委員会のQ&Aは、Web入力画面で本人から個人情報を直接取得する場合、原則として利用目的の明示が必要と説明しています（個人情報保護委員会Q&A）。具体的な義務は運営形態や取得内容で異なるため、必要に応じて専門家へ相談してください。

個別連絡が不要なら匿名を基本にし、連絡先は目的を明示して分けて扱います。

回答者の偏りを「回答率」だけで判断しない

回答率が高くても、常連だけが答えていれば初参加者の障壁は分かりません。回答を次の参加段階で分けます。

segment
  - organizer       運営者
  - regular         過去30日に複数回参加
  - first_time      初参加
  - attempted       表明したが未参加
  - observer        見たが表明していない
  - inactive        最近募集を見ていない

全員の個人履歴を保存する必要はありません。アンケート内で本人が近い状態を選び、集計時に区分します。全体平均だけでなく、各区分の回答数と傾向を並べます。回答が2〜3件しかない区分は割合を強調せず、「少数の示唆」として扱います。

配布場所も偏りを作ります。活発なチャットだけで告知すると、すでに定着している人へ届きます。参加案内、募集後のチャット、休眠者へ普段使っている連絡経路など、対象者がいる場所で案内します。ただし、回答を強要したり、未回答者を個別に追及したりしません。

Stult Partyでは、ゲーム募集、チャット、ボイスを一つのコミュニティで扱えます。募集参加直後の声は該当するチャットで集め、改善結果も同じ場所へ返すと、どの体験についてのアンケートかを揃えやすくなります。基本の使い方はStult Partyのはじめ方で確認できます。

自由記述は感情ではなく「改善対象」で分類する

自由記述を「肯定・否定」で分類すると、否定的な意見が多い項目を直すだけになります。実装者の視点では、次のデータ構造にすると改善へつなげやすくなります。

response_id
segment             回答者の参加段階
touchpoint          recruitment / join / chat / voice / return
issue_type          missing_info / timing / size / safety / usability
evidence            回答の要約（原文を必要以上に複製しない）
frequency           同種回答数
impact              参加不能 / 遅延 / 不便 / 要望
actionability       now / later / outside_scope
candidate_action    実行可能な変更案
owner               担当者
review_at            再確認日

touchpointで募集・参加・チャット・ボイス・再参加のどこかを示し、impactで影響を分けます。「使いにくい」という回答も、募集条件が見つからないのか、開始時刻が分からないのかで施策が変わります。

原文を運営チーム全員へ無制限に共有せず、改善に必要な範囲で要約します。個人攻撃、健康情報、連絡先などが含まれた場合の閲覧範囲と削除基準も決めます。

参加段階、接点、問題の種類、影響、実行可能性を分けて記録します。

改善優先度は4条件で決める

票数が最も多い要望を自動採用しません。次の4条件を各0〜2点で評価します。

合計点は決定ではなく、話し合う順番です。安全に関わる問題は票数や合計点が低くても優先します。製品の未提供機能に依存する要望は、提供中と誤解させずoutside_scopeに分類し、現行機能でできる代替策がある場合だけ提示します。

一回のアンケートから実施する改善は一つ、多くても二つにします。同時に複数を変えると、どの変更が結果へ影響したか分かりません。たとえば「募集に途中退出可と明記する」を2週間試し、参加表明率や初参加後の再参加を比較します。

票数だけでなく、影響、対象範囲、実行容易性、検証可能性を確認します。

回答期限とデータの出口を先に決める

フォームを開きっぱなしにすると、回答時期が異なるデータを同じ改善判断へ混ぜてしまいます。開始時に次を決めます。

• 回答期間：通常3〜7日
• 対象者：どの募集・期間・参加段階か
• 集計担当：誰が閲覧できるか
• 結果共有日：いつ参加者へ返すか
• 改善実施日：いつから試すか
• 保管・削除：原回答と要約をいつ見直すか

Google Formsでは回答受付を停止でき、終了日時や回答数による停止も設定できます。また、メールアドレスを収集する設定と、収集しない運用を選べます（Google Forms公式ヘルプ）。ツールの初期設定を信じ込まず、公開前に回答者から見える画面と収集項目をテストしてください。

14日で回す改善サイクル

1日目：判断を一文で決める

「次月の初参加募集で、最初に改善する案内を決める」のように書きます。対象者と期間も決めます。

2日目：5問を作り、回答テストをする

運営者二人で別の選択肢を選び、分岐、匿名性、結果の見え方を確認します。回答しづらい質問や、使わない質問を削除します。

3〜7日目：対象者へ配布する

締切、所要時間、利用目的、結果共有日を明記します。「高評価をお願いします」と誘導せず、未回答でも不利益がないことを伝えます。

8〜10日目：分類し、改善を一つ選ぶ

参加段階別に集計し、自由記述をtouchpointとissue_typeで分類します。少数意見も安全や参加不能に関わる場合は確認します。

11〜14日目：変更し、参加者へ返す

「何件集まったか」だけでなく、何を変えるか、変えない項目と理由、試行期間、次の確認日を共有します。

回答：24件
分かったこと：初参加者は募集条件より開始前の案内で迷っていた
変更：開始30分前に集合場所と聞き専可否をチャットへ投稿
試行期間：11月1日〜14日
次回確認：11月15日

回答を集めたままにせず、14日以内に一つ変更して結果を返します。

よくある失敗

満足度だけを聞く

点数は変化の検知には使えますが、改善箇所を示しません。対象場面、障壁、改善案を一緒に聞きます。継続的な指標設計はゲームコミュニティのKPIも参照してください。

すべて自由記述にする

文章を書く負担が高く、集計者の解釈も増えます。選択式で比較可能な情報を取り、自由記述は一問にします。

常連の多数決で決める

常連と初参加者では見ている課題が違います。参加段階別に傾向を確認し、誰の課題を解くアンケートかを維持します。

結果を公表しない

何も変わらないと、次回の回答率と信頼が下がります。採用しなかった案も、現行機能の範囲、運営負担、対象範囲など判断理由を短く返します。

まとめ：アンケートの成果物は回答ではなく改善

ゲームコミュニティのアンケートは、質問を増やすほど良くなるものではありません。回答後に決めることを一つ選び、5問で集め、参加段階別に分類し、14日以内に一つ改善して結果を返してください。

Stult Partyなら、ゲーム募集、チャット、ボイスを一つのコミュニティへまとめて無料で始められます。募集から参加、会話までの接点を同じ活動基盤で確認し、改善後の案内も参加者へ返せます。まず次のアンケートを作る前に、「この回答で何を一つ決めるか」を一文で書いてください。