ゲームとアプリの最初の体験⑤：作った本人には見えない迷いを、初見プレイで確かめる

※本記事にはアフィリエイトリンク（広告）が含まれます。Amazonのアソシエイトとして、ゲームのタネは適格販売により収入を得ています。

自分では迷わず進めるのに、初めて触る人は最初の部屋から出られない。画像を保存する場所が見つからず、加工の結果も確かめられない。作り手が手順を知っているほど、こうしたつまずきには気づきにくくなります。

連載では、小さな達成、教える順番、やり直し、支援を考えてきました。最終回は、その設計を初めて触る人に試してもらい、何が起きたかを記録して、次に直す箇所を選びます。ゲームの初見プレイだけでなく、アプリの最初の作業にも使える考え方です。

作品全体の感想より、確かめたい場面を一つ決める

「遊んで、気づいたことを教えてください」だけでは、何を見たいのかが曖昧になります。まず、作り手が確かめたい問いを一つ書きます。

例えば、短編探索ゲームなら「最初の部屋で、調べられる物に気づけるか」。画像の幅をそろえるツールなら「加工後の画像を保存し、目的の寸法になったと分かるか」です。どちらも、この連載で使ってきた説明用の架空例です。

不具合を広く探す準備は、既存のテストプレイ入門も参考にしてください。今回は、初めて触る人が何を理解し、どこで迷うかに絞ります。操作の完了だけで、面白さや満足まで確かめられたとは判断しません。

Portalは、観察したつまずきから練習の順番を変えた

『Portal』の開発者Kim Swift、Erik Wolpaw、Jeep Barnettは、『Game Developer』2008年1月号の開発記で、早い段階の粗い部屋からプレイテストを始め、作品を知らない人のプレイを観察したと記しています。

同じ記事には、エネルギー球の向きを二度変える課題で複数の人がつまずき、先に一度だけ向きを変える二つの場面を加えた例があります。その順番を再テストしたところ、以前の参加者より最後の課題の理解が早くなったと開発者は報告しています。開発者による記事「Thinking with Portals」（掲載号PDF）

これは当時の開発記であり、本記事で実機を試した記録ではありません。自作への応用で注目したいのは、感想を集めるだけで終えず、止まった場面を見て、教える順番を変え、もう一度試した流れです。同じ方法で継続率や売上が伸びると保証する資料ではありません。

試してほしい相手と、始める状態をそろえる

依頼先を考えるときは、想定する利用者に近い経験の人かを確認します。探索ゲームに慣れているか、画像加工を普段するか、キーボードとタッチ操作のどちらを使うかでも、迷い方は変わります。

知人に頼む場合も、作品を見たことがあるか、すでに答えを知っているかをメモします。詳しい友人が進めたことだけで、初めて使う人にも伝わるとは限りません。逆に、一人が迷ったことだけで、すべての人が使えないとも決めません。

ゲームの版、開始地点、使えるヒント、操作する端末を記録しておくと、何を見た結果なのかを後で確かめられます。画像ツールには観察用の画像を用意し、保存先も決めます。ここでは私物の写真や普段使いのファイルを使わずに試す案とします。

試してもらう前には、目的、メモ・録画の有無、誰が見て何に使うか、保管期間、中断や同意を取り下げる方法を伝え、同意を得た記録を残します。GOV.UKの資料も、こうした説明と自由意思での参加を重視しています。録画するなら、画面に写る範囲まで確認しましょう。調査参加への同意に関するGOV.UKの資料

依頼するのは目的。操作の答えは先に教えない

観察したい問いと、相手に渡す依頼文を分けます。「メモに気づけるか」を見たいのに、「机のメモを読んでください」と頼めば、探す必要がなくなります。

1200pxは説明用の寸法です。どんな用途にも適した値ではありません。観察を終える状態も、ゲームなら次の部屋へ進む、ツールなら保存した画像の寸法を確認する、と先に決めます。

GOV.UKの利用者テスト資料は、明確な目的があり、答えや操作方法をほのめかさない課題を勧めています。自作でも、使い方の説明文と、理解を確かめる依頼文を読み比べる手掛かりになります。利用者テストの課題設計と進め方

ただし、普段も必要な操作説明や利用条件まで隠すわけではありません。実際には表示する案内を消して、わざと迷わせるテストにしないようにします。

すぐに教えたくなったら、まず起きたことを残す

始める前に、作品の分かりにくい箇所を探すために協力してほしいと伝えます。うまく進めなくても気にしないでよいと知らせましょう。思ったことを話してもらう場合も、話し続けるように急かさず、操作と反応を見ます。

迷った瞬間に「その机を調べてください」と教えると、どこまで自分で分かったのかが見えにくくなります。まず、画面で確認できた操作や反応、そのときの発言を残します。「保存ボタンが分かりにくいですよね」と誘導するより、区切りのよいところで「今は何をしようとしていましたか」と聞く方が、考えていたことを確かめやすくなります。

長く止まって負担が増えているときや、相手が中断を望むときまで、黙って続けさせる必要はありません。助けた場合は、どこで何を伝えたかを記録します。助けを受けて完了した結果と、案内を追加せずに完了した結果を分けて扱います。

操作できなかった原因が、不具合や端末の状態にある場合もあります。初見の理解の問題と決めつけず、まず同じ条件で動作を確かめます。

行動・発言・解釈を、同じ欄に混ぜない

「説明が足りない」とだけ書くと、何が起きたのかが消えてしまいます。次の表は、記録の仕方を示す架空例です。実際の参加者の行動や発言ではありません。

沈黙や長い停止だけから、「退屈した」「説明を読まない人だ」と気持ちや性格まで決めません。発言の意味が分からなければ、終わったあとにその場面を振り返って聞きます。記録が曖昧な言葉は、正確な引用として残さないようにします。

課題の開始・終了、助けの有無と内容も添えます。名前や私的な情報を増やすより、参加者番号と利用経験、端末など、改善を考えるために必要な条件を残す方針にします。

次に直す箇所は、回数だけで決めない

記録を読み返したら、進めなくなった箇所と、進めたけれど迷った箇所を分けます。保存したつもりで画像が残らないなど、成果を失う問題は、一人で見つかった場合も影響を確かめる価値があります。一方、「部屋をもっと増やしてほしい」という希望は、最初の操作で止まる問題とは別に扱えます。

何人中何人に起きたかを書く場合は、試した人数と条件を添えます。少人数の観察を、利用者全体の割合や、価格・継続率の予測には広げません。誰にも起きなかったことも、問題がない証明にはなりません。

例えば机に気づけない場面なら、まず近づいたときの案内を見直し、次の人にも同じ目的で試してもらう。画像ツールなら、保存前と保存後の表示の違いを直して確かめる。変更は、観察した事実と結び付けて選びます。

同じ人にもう一度頼めば、変更後の操作は確かめられますが、初見ではなくなります。最初に気づけるかを見たいなら、まだ作品を知らない人に依頼する方が問いに合います。版や条件も残し、慣れたことと修正の効果を混同しないようにします。

今回は、一つの場面を観察するメモを作る

最初の達成が曖昧なら第1回、操作と結果が結び付かないなら第2回へ戻れます。失敗後の負担は第3回、助けの選び方は第4回と照らし合わせてください。

全5回で考えた設計も、まずは仮説です。一つの場面を試してもらい、起きたことを残し、次の変更を選ぶ。最初からすべてを作り直すより、観察した迷いから直す場所を絞っていきましょう。

第4回：ヒントと支援機能の考え方／連載目次

観察や改善の進め方を本で学びたい方へ

ゲームデザインや利用者の体験（UX）を扱う本では、プレイテスト、使いやすさの評価、観察記録から改善を選ぶ方法が載っているかを目次で確認してみてください。個人で試せる準備や依頼の例があると、自作の場面と照らし合わせやすくなります。

Amazonでゲームデザイン・UXの本を探す（広告）

リンク先は書籍の検索結果です。特定の本を読んだ感想や、改善効果の保証ではありません。試し読み、刊行年、対象読者、価格を確認し、今知りたい内容に合う本を選んでください。

資料は2026年11月3日に開発者の記事とGOV.UKの原文で確認しました。本記事で実在ゲームのプレイや利用者テストは行っていません。架空例は手順を考える材料であり、満足・継続率の実測や、調査に関する法令全体への適合を示すものではありません。