友達のゲームを遊ぶとき、何を伝えるとよい?テストプレイの会話例
遊びを見つける執筆にClaudeを使用しています。

友達から「作ったゲーム、遊んでみてほしい」と言われたとき、どう答えればよいか迷ったことはないでしょうか。「面白かった!」だけでは感謝されても参考にならないし、かといってバグを探して指摘するのも気まずい。この記事では、作り手が本当に欲しい情報——プレイヤーが迷った瞬間、予想外の反応をした理由、やり直しを選んだきっかけ——を自然な会話の中で伝えるための考え方と、すぐ使える言葉のパターンを整理します。
この記事の目次
「楽しかった」だけが伝わらない理由
ゲームを作った人が「感想を聞かせて」と言うとき、多くの場合、知りたいのは評価の点数ではありません。「このルールは伝わっているか」「あの場面で詰まると思っていたが実際はどうか」「やり直したくなる設計になっているか」といった、具体的な体験の手がかりです。
「面白かった」「難しかった」という言葉は気持ちを表しますが、作り手が何かを変えようとするときの判断材料にはなりにくい。逆に、「3面のあの分岐で左を選んだ理由」や「チュートリアルを読み飛ばした瞬間」のような具体的な動きと理由の組み合わせは、設計を見直すための情報になります。
感想を言いやすくするには、「何を観察するか」をあらかじめ決めておくことが役立ちます。この記事では、特別なツールや記録装置を使わなくても実践できる観察のポイントと、遊んだあとの会話でそれを伝える方法を紹介します。
遊びながら注目する3つのこと
テストプレイ中に意識すると感想が具体的になる観察のポイントは、大きく3つに分けられます。
① 迷いが生じた場面
「次に何をすればよいかわからなくなった」「ボタンやルールの意味が一瞬わからなかった」という瞬間を覚えておきます。迷いを感じたとき、その場面のどの要素が原因だったかを後で思い出せるよう、「どこで・なぜ止まったか」をざっくりメモするか、終わってすぐに口に出すのが効果的です。バグかどうかより、「自分が何を読もうとしたか」の方が大事な情報です。
② 予想と違った瞬間
操作や結果が自分の想像と違ったとき、それはプラスの驚きか、マイナスの驚きかを区別しておきます。「こうなると思ったらそうならなかった」という違和感は、ルールの伝わり方の手がかりになります。「これは意外で面白かった」という驚きも、設計者が意図したものかどうか確認する価値があります。
③ やり直した・やめようとした理由
リトライを選んだとき、その動機が「悔しくてもう一度やりたい」なのか「操作ミスで納得できない」なのかは大きく違います。反対に、「もうやめようかな」と感じたタイミングがあれば、それは何ステージ目でどんな状況だったかを伝えると参考になります。ゲームを途中でやめることへの遠慮は必要ありません。「ここで気持ちが離れた」は有益な情報です。
遊んだあとで使える会話の例
以下は、テストプレイの後に実際に使える会話のパターン例です。作り手に許可を得てフィードバックを伝える場面を想定しています。どれも「何が起きたか」と「そのときどう感じたか・考えたか」の2点をセットにするのがポイントです。
- 迷いを伝えるパターン:「最初の画面で、どのボタンを先に押せばいいかわからなくて、10秒くらい止まった。説明を読もうとしたけど、どこにあるかもわからなかった」
- 予想と違った驚きを伝えるパターン:「あのブロックは壁だと思って避けてたけど、実は乗れるやつだったんだね。気づいたときはちょっと嬉しかった。でも最初から乗れると思っていたら全然違う動き方をしてたと思う」
- やり直した理由を伝えるパターン:「3回やり直したのは、自分のミスだとわかってたから。もう少し上手くやれると思って続けてた。でも4回目で急に難しくなって、そこでやめようかなと思った」
- 気持ちが離れた場面を伝えるパターン:「最後のステージに入ったときに、ルールが増えすぎてしまって、覚えきれないと感じた。その前まではずっと集中できてたから、そのギャップが大きかった」
会話例はこの記事のために構成した説明用の文例です。特定のゲームや実際のプレイセッションを記録したものではありません。
伝えにくいときに使う質問テンプレート
感想をうまく言葉にできないときは、作り手の方から質問してもらうか、自分でこのテンプレートを手元に持って遊ぶと整理しやすくなります。
- 遊び始めて最初に「何をすればよいか」がわかったのはどの時点でしたか?
- 止まった・迷った・戻った場面はどこかありましたか?そのとき何を考えていましたか?
- 「こうなるはず」と思って操作して、違う結果になった場面はありましたか?
- やり直したとき、その動機は「悔しい・もう一度やりたい」でしたか、それとも別の理由でしたか?
- 「ここで少し気持ちが離れた」と感じた瞬間はありましたか?それはどの場面でしたか?
- 全体を通じて、もう一度やりたいと思いましたか?そう思った(思わなかった)のはなぜだと思いますか?
これらの質問は全部答える必要はありません。思い当たるものだけ選んで答えるだけでも、作り手にとって十分な手がかりになります。「特に何も気になる場面がなかった」という回答もそれ自体が情報です。
感想の伝え方で関係を壊さないために
友達の作品への感想は、批評でも評価でもなく、「自分が体験したことの報告」として伝えると受け取られやすくなります。「このゲームはここが悪い」という判断ではなく、「自分はここで迷った」「自分はここで面白いと感じた」という一人称の事実に近い形で話すのが基本です。
「自分はここで迷った」が出発点——この形式は、感想をもらう側にとっても受け取りやすい。「あなたの設計が悪い」ではなく「この人はこの場面で詰まった」という情報は、改善の検討に直接使えます。
また、改善案を一緒に提案する必要は必ずしもありません。「ここが気になった」だけで伝えて、「どうすればよいと思う?」と聞かれたときに初めて考えるくらいの距離感で十分です。感想を伝えることと、設計を直すことは別の作業です。求められていないのに「こうすべき」を付け加えると、かえって会話が重くなります。
気になった点だけでなく、「ここは面白かった」「ここは期待通りに動いた」という場面も伝えると、作り手が「この部分は意図が伝わっている」と確認できます。ポジティブな情報も設計の判断材料になります。
観察した内容を記録・共有する場合は、事前に作り手の同意を確認しておくと安心です。スクリーンショットや画面録画を使う場合も同様です。
感想を受け取った作り手がするべきこと、そして次の遊び手へ
感想を受け取った側は、すべての意見に応える義務はありません。「迷わせないようにしたい」という意図があった場面で実際に迷いが起きていたなら修正を検討する価値がありますが、「ここが面白くなかった」という意見が自分の設計の意図と合わないなら、そのまま残す判断も十分ありえます。感想は命令ではなく情報です。
感想は命令ではなく情報——この区別を両側が持つことで、テストプレイの会話は気軽に続けられるものになります。
感想をもとにゲームを調整し直したら、次は知り合いの枠を超えて公開してみることも選択肢のひとつです。アソバースでは、HTMLファイルや完成したゲームのURLを登録して公開できます。友達1人からもらった「ここで迷った」という言葉は、次の遊び手100人にも当てはまることがあります。
テストプレイは特別なスキルではなく、「自分が体験したことを正直に話す」ことです。「何を感じたか」「なぜそう動いたか」を言葉にする習慣が、作り手にとっても遊び手にとっても、次のゲームをより面白くする一歩になります。




