自作ゲームを初めて遊んでもらう：五つの観察項目で改善を探す

招く前に決めること：参加条件と同意

テストプレイで最初に決めるのは「誰に遊んでもらうか」ではなく「どんな条件で遊んでもらうか」だ。参加条件を曖昧にしておくと、観察した内容を比較できなくなる。

決めておくべき項目は次の四点。まず、ゲームのジャンルや難易度に対してどの程度の経験を持つ人に来てもらうか。次に、制作の背景や意図をどこまで説明するか（何も伝えない／ジャンルだけ伝える／目標まで伝えるなど）。三つ目は、観察した内容を今後の記事や告知に使うかどうか、使う場合に匿名化するかどうか。四つ目は、セッション中に制作者が口を出さない範囲をどこに置くか。

観察を記事や投稿に活用したい場合は、事前に参加者の同意を取ることが前提になる。「観察した内容を匿名で公開に使う」と明示したうえで同意を確認し、本人が特定できる表現は削除する。少人数のカジュアルなやりとりでも、後から「使っていいか」と確認するより事前に整理しておく方がトラブルが少ない。

五つの観察項目

テストプレイ中に記録しておきたい観察は、感想より行動だ。「面白かった」は制作者を安心させるが改善の手がかりにはならない。以下の五項目は、行動として観察できる現象に絞っている。

① 手が止まった場所

プレイヤーが操作を止めて画面を眺める場面が、説明の欠如か設計の複雑さを示すことが多い。「どこで止まったか」だけでなく「何秒止まったか」「その直前に何を操作していたか」を記録する。止まった後に自力で進んだのか、諦めてやめたのかも区別する。

② 声に出した言葉

「あれ？」「こっちかな」「え、そういうことか」といった独り言は、理解の瞬間や混乱の瞬間を映している。制作者が「わかるはずだ」と思っている部分で独り言が出ていれば、その箇所は説明が足りていない可能性がある。言葉の内容より、どの操作タイミングで発話したかを書き留める。

③ 試みたが機能しなかった操作

クリックできると思ってクリックしたが何も起きなかった、スワイプしたがドラッグだった、という操作の誤解は、インターフェースの設計が「想定外の期待」を生んでいるサインだ。どのUI要素で、何を期待した操作が行われたかを記録する。同じ誤操作が複数回起きていれば優先的に検討する。

④ 目標を理解したタイミング

「ああ、これはそういうゲームか」という理解がどの段階で起きたかを観察する。タイトル画面で理解できた人と、三分遊んでようやく気づいた人では、導入部の設計が異なる。制作者には自明のゴールが、初見のプレイヤーには最後まで曖昧なままだった、という事例は珍しくない。

⑤ プレイを終えた理由

「クリアしたから」「飽きたから」「エラーが出たから」「もう一回やりたくなった」「時間が来たから」——プレイが終わった理由を本人に尋ねるか観察で補足する。制作者が「ここがゴール」と考えた地点で終わっているか、それより前か後かを確認するだけで、ゲームの「長さ感」に関する問題が見えてくる。

観察を記録するシンプルな様式

凝ったスプレッドシートは後回しにして、まず一枚のメモで記録を始めると続けやすい。以下は一セッション分の記録に使える最小の構成だ。

• 日時・ゲームのバージョン番号（またはビルド名）
• 参加者のプロフィール（ゲーム経験の程度、ジャンル親しみ度）
• 事前に伝えた内容（何も伝えなかった／ジャンルのみ／目標まで）
• 観察項目①〜⑤のメモ（場所・時刻・内容）
• セッション後に参加者が話したこと（感想・提案・疑問）
• 制作者が気になった点（観察時の印象・仮説）

セッション後の感想は「いちばん難しかった場面はどこか」「最初に何をすればいいかわかったか」という具体的な質問で引き出すと、「面白かった」以外の言葉が出やすい。ただし、制作者が答えを誘導する質問（「このボタンわかりにくかったよね？」）はプレイヤーが同意してしまいやすいので避ける。

参加者が特定できるメモ（フルネーム、アカウント名など）は、同意がない限り記録に残さない。「ゲーム経験3〜5年、パズルゲーム好き」のような属性で十分なことが多い。

観察から変更判断へ：変えるかどうかの基準

テストプレイの記録が手元にあっても、「どこを直すか」の判断は難しい。すべての指摘に応えようとすると、ゲームの核心が失われることがある。変更を検討する順序として、次の三段階を目安にするとよい。

最優先：複数の人が同じ場所でつまずいた

一人のプレイヤーが止まった場所は「その人の特性」かもしれないが、参加者の半数以上が同じ場所で止まったなら設計に問題がある可能性が高い。特に「③試みたが機能しなかった操作」が複数人に共通していれば、UIの変更を先に行う。

検討する：目標の理解が意図より遅かった

制作者が「最初の画面で伝わるはず」と思っていた目標が、プレイの三分後まで理解されていなかった場合は、導入の情報量か提示順序を見直す。ただし、意図的に謎を残しているゲームでは、この「遅さ」が設計上の特徴でもある。観察と設計意図を照合してから判断する。

後回し：個人の好みや提案

「こういう機能があれば」「色をもっと明るくして」という提案は、参加者の善意からくるが、一人の意見として受け取る。複数の参加者から同じ提案が出たとき初めて検討候補に入る。また、ゲームの方向性と合わない提案は丁重に保留し、記録に残しておくだけでよい。

変更後は、変更前の問題箇所と変更後の状態を比較できる形で手元に残す。スクリーンショットや変更ログでも構わない。「なぜ変えたのか」を後から確認できると、次のテストプレイで同じ議論を繰り返さなくて済む。

一人でも始められるか：最小構成のテストプレイ

テストプレイというと複数人を集める必要があると思われがちだが、一人から始めて記録を積み重ねることもできる。最初のセッションは「完璧なテスト」ではなく「観察の練習」として位置づけると気が楽になる。

一人だけに遊んでもらった場合、その観察は一事例に過ぎない。「一人がつまずいた」を「全員がつまずく」と結論づけないことが重要だ。ただし、一事例でも、手が止まった場所の記録は次のバージョンへの仮説になる。仮説をもとに修正し、次の一人に試してもらう、というサイクルを回すことで、少ない参加者でも改善の根拠を積み上げられる。

制作者が同席できない場合（URLを送って遊んでもらう場合など）は、プレイ後にフォームで五項目に対応した短い質問を送る方法もある。「どこかで詰まった感覚がありましたか。あれば場面を教えてください」「最初の操作で何をしましたか」「プレイをやめた理由を教えてください」という三問だけでも、観察の代わりになる情報が得られる。

アソバースでゲームを公開したあとにテストプレイを行い、観察をもとに更新した場合は、ゲームの説明欄に「v1.1：導入画面を修正」のような形で変更内容を書き添えると、後から遊んだ人に変化が伝わりやすい。

変えなくていいものを守る

テストプレイの記録を読み返すと、「全部直したい」という衝動に駆られることがある。しかし、すべての問題を解消しようとすると、ゲームがどこにでもある無難な作品になりやすい。

変えないと決める根拠も、観察記録から引き出せる。「この難しさは意図的なもので、乗り越えた人が達成感を感じている」ことが観察から読み取れれば、難易度を下げる必要はない。「変えるかどうか」の判断には、変えない理由を言語化する作業が含まれる。観察メモの隣に「この問題は意図的に残す／理由：〇〇」と書いておくと、次のテストプレイで同じ議論が再燃したときに自分の判断軸を確認できる。

テストプレイは「全員が迷わず楽しめるゲーム」を目指すツールではない。制作者が伝えたいことを、より確実に届けるための観察の場だ。五つの項目を記録し、変える根拠と変えない根拠を両方持つことで、改善の判断が感覚ではなく観察に基づくものになる。