ゲームの「わかりやすさ」を測る：初見プレイの観察項目

なぜ「初見プレイの観察」が設計改善に効くのか

完成したゲームを作者自身がテストしても、わかりやすさの問題はほぼ見つかりません。作者はルールを知っているため、プレイヤーが何に戸惑うかを想像しにくくなっています。これは知識の呪い（curse of knowledge）と呼ばれる認知のバイアスで、一度知ってしまった情報を「知らない状態」に戻すことが難しいために起きます。

解決策はシンプルで、まだゲームを見ていない人にプレイしてもらい、その様子を観察することです。ただし、ただ「遊んでみてください」と頼むだけでは得られる情報が曖昧になります。何を見るか、どのタイミングを記録するかを決めておくことで、観察が設計の改善につながるデータになります。

観察の前に決めておくこと

観察を始める前に、二つのことを固めておきます。

観察の目的を一つに絞る

「全体的な感想が知りたい」という目的では観察の焦点が散漫になります。「最初の30秒で操作方法が理解できるか」「ゲームオーバーになったとき次の行動を自分で選べるか」など、問いを一つに絞ると観察すべき場面が明確になります。

プレイヤーへの事前説明を最小にする

観察の前にルールや操作方法を口頭で伝えてしまうと、実際の初見体験ではなくなります。ゲーム内に表示されている情報だけで理解できるかを確かめたい場合は、「画面を見て自由に始めてください」とだけ伝え、それ以上は説明しません。逆に「チュートリアルを省いた状態での体験を見たい」など特定の条件を設けるなら、その条件だけを伝えます。

初見プレイで記録する観察項目

以下の項目を、プレイ中にメモまたは録画で記録します。プレイヤーに声に出して考えながら進んでもらう「思考発話法」を使うと、沈黙の理由が把握しやすくなります。

操作の発見に関する項目

• 最初のアクションを起こすまでの時間：スタートボタンや最初の操作を見つけるまでに何秒かかったかを記録します。明らかに長い場合、開始への導線が不明瞭な可能性があります。
• 押し間違い・クリック間違いの箇所：意図しない要素を操作した場所を記録します。同じ場所で複数回間違える場合、その要素の見た目や配置が誤解を招いています。
• 操作説明を読んだかどうか：表示した説明テキストやアイコンに視線が向いたか、またはスキップしたかを観察します。読み飛ばされた説明は、位置・量・タイミングのいずれかに問題があります。

目的の把握に関する項目

• 「何をすればいいかわからない」という発言や行動が出た時点：思考発話法では口に出してくれますが、無言の場合は手が止まる・同じ操作を繰り返すといった行動で判断します。
• ゴールを言語化できるか：プレイ開始から1〜2分後に「今、何を目指していますか？」と聞いてみます。正しく答えられない場合、ゲームの目的が伝わっていません。
• スコアやステータス表示の誤読：数値や残機の表示が何を指すかを誤解していないかを確認します。「これは時間ですか？」などの発言は設計の見直しサインです。

フィードバックの受け取りに関する項目

• 成功・失敗のリアクション：得点が入ったとき、ミスをしたとき、プレイヤーが気づいているかどうかを観察します。音・演出・テキストのいずれかが届いていない場合、フィードバックが弱いと判断できます。
• ゲームオーバー後の行動：リトライするか、やめるか、何かを探すかを記録します。「どこに進めばいいかわからなかった」という場合、終了画面の導線に問題があります。
• 想定外の操作への反応：プレイヤーがゲームの想定外の操作を試みたとき（例：関係のない場所をクリック、範囲外にキャラクターを動かそうとする）、何が起きるかを記録します。想定外の入力を無視すると「壊れた」と思われることがあります。

観察後の整理：問題の優先順位をつける方法

記録した観察事項をそのまま修正リストにすると、重要度の低い問題に時間を使いすぎることがあります。以下の基準で優先順位をつけます。

頻度と深刻度で分類する

• 高頻度・高深刻度、説明：多くのプレイヤーが、ゲームを続けられないレベルで詰まる、対応の目安：最優先で修正する
• 高頻度・低深刻度、説明：多くのプレイヤーが迷うが、最終的には自力で解決できる、対応の目安：次のイテレーションで改善する
• 低頻度・高深刻度、説明：少数だが詰まると完全に止まる、対応の目安：修正コストと照らして判断する
• 低頻度・低深刻度、説明：ごく一部が少し迷う程度、対応の目安：後回しにしてよい

「なぜそこで詰まったか」を設計に翻訳する

「ここがわかりにくかった」という事実を記録するだけでなく、なぜ詰まったかを設計の言葉に直します。たとえば「スタートボタンを見つけるまで10秒かかった」という観察は、「重要なUIが画面端に配置されており、視線誘導がない」という設計の問題として記述できます。原因の言語化が具体的な修正方針につながります。

観察できる人数と回数の現実的な目安

ユーザビリティ研究の一般的な知見として、5人前後の初見プレイを観察すると、設計上の大きな問題の多くが見えてくるとされています。人数を増やすより、異なる背景（ゲーム経験の有無、年齢層など）の人を組み合わせることが観察の質を上げます。

修正後に同じ問題が解消されたかを確かめる再観察も有効です。ただし一度プレイした人はもう「初見」ではないため、別の人に依頼する必要があります。友人・家族・SNSでの募集など、自分のゲームをまだ知らない人を確保する手段をあらかじめ考えておきます。

次の行動

まず手元のゲームを、ルールを何も伝えずに一人に触ってもらう場を設けてください。観察項目のなかから「操作の発見」と「目的の把握」に絞って記録するだけでも、優先度の高い問題が見えてきます。修正したゲームをアソバースに投稿・公開することで、より広い範囲のプレイヤーからの自然なフィードバックを得る機会にもなります。

参考資料

• Nielsen Norman Group「Usability 101: Introduction to Usability」
• Steve Krug『Don't Make Me Think』（邦題：『ウェブユーザビリティの法則』）
• 玉樹真一郎『コンセプトのつくりかた』