難しくしすぎた試作を初見の人に渡すと、どこで離脱するか:確かめる手順
遊びをつくる執筆にClaudeを使用しています。

作者が試作を毎日遊んでいる場面を考えてみます。敵の出てくる順番は頭に入っていて、ジャンプの距離は指が覚えています。ステージ3も「少し歯ごたえがある程度」に感じます。この感覚のまま調整を重ねると、難易度は作者の上達に合わせて上がり続けます。調整のたびに「まだ簡単かな」と感じられるので、行き過ぎにも気づきにくくなります。 初見の人は、その試作を作者とはまったく違う条件で見ます。ルールの説明は画面のどこにあるのか、失敗したのは自分の操作のせいなのか仕様なのか、あと何回やれば先へ進めるのか。作者の頭の中にだけある前提が欠けた状態で、画面と操作だけを手がかりに進むことになります。 この記事では「作者の慣れで上がった難易度は、初見の人にどう映るか」を、自分で確かめるための実験の設計書として組み立てます。結果は書きません。準備、手順、記録の取り方、読み方、起こりやすい誤りを順に示すので、手元の試作で同じ問いに答えを出せます。
この記事の目次
問いを分解する:「難しい」には三種類ある
「難しすぎて離脱した」という言い方は、原因を一つにまとめてしまいます。対策が変わるので、実験の前に三つに分けておきます。
- わからない難しさ:ルールや目的、操作方法が伝わっていない状態です。技術は関係なく、情報が届いていません。
- できない難しさ:やることはわかっているのに、タイミングや精度が要求に追いつかない状態です。練習で埋まる差ですが、練習の入口が急すぎると途中で止まります。
- 報われない難しさ:目的は理解していて操作もできるのに、進んでいる実感がない状態です。失敗の理由が見えない、成功しても変化が小さい、といった場合に起こります。
離脱が起きたとき、この三つのどれかを見分けるのが実験の目的です。「ステージ3が難しいらしい」で終わらせず、「ステージ3の何が、どの種類の難しさとして働いたか」まで分けると、直す場所が一つに絞れます。
もう一つ、実験の前に済ませておくことがあります。作者自身の予測を書き出しておくことです。
初見の人は、どのステージで、何回失敗したところで止まりそうか。最初の操作までに何秒かかりそうか。
予測は紙に書き、観察の後で実際の記録と並べます。予測と実際の差が、作者の慣れの大きさの目安になります。差の大きさだけでなく、差が出た場所も手がかりです。
準備するもの:人・環境・記録の仕組み
人
試作を一度も見たことがない人を3〜5人集めます。ユーザビリティテストの分野では、少人数でも大きな問題の多くが見つかるという考え方が知られています。ただし人数で結果が保証されるわけではないので、あくまで進め方の目安として扱ってください。
選ぶときは、そのジャンルに慣れた人と慣れていない人を混ぜます。慣れた人だけだと「わからない難しさ」が隠れ、慣れていない人だけだと「できない難しさ」の程度が極端に出ることがあります。制作を手伝った人や、開発中の画面を見たことがある人は、初見の条件を満たさないので外します。
環境
- 試作は、ブラウザで開くだけで遊べる状態にします。独立したHTMLファイルなら、そのまま渡せます。ZIPで渡す場合は、直下の index.html から相対パスで素材を読む構成にしておくと、どの端末でも同じように動きます。
- アソバースへの投稿画面は「入力→表示の確認→公開」の3段階で、下書き保存もできます。ただし公開前の試作を特定の人にだけ見せる方法は、確認済みの範囲では案内が見当たりません。この部分は現在の案内で確認してください。
- 画面録画は、必ず本人の同意を得てから使います。録画が難しければ、観察者が手書きで記録します。
記録の仕組み
秒数を目視で測ると、観察に気を取られて抜けが出ます。試作の中に小さなロガーを入れておくと、あとで時刻つきの記録を読み返せます。外部通信は使わず、画面に表示するだけの最小構成です。
<pre id="log" hidden></pre>
<script>
const t0 = performance.now(), rows = [];
let firstInput = null;
function mark(label) {
const s = ((performance.now() - t0) / 1000).toFixed(1);
rows.push(s + "s\t" + label);
document.getElementById("log").textContent = rows.join("\n");
}
addEventListener("pointerdown", () => {
if (firstInput === null) { firstInput = true; mark("first input"); }
});
addEventListener("keydown", e => {
if (firstInput === null) { firstInput = true; mark("first input"); }
if (e.key === "l") {
const el = document.getElementById("log");
el.hidden = !el.hidden;
}
});
// ゲーム側から呼ぶ例:
// mark("stage2 start"); mark("stage2 miss"); mark("stage2 clear");
</script>Lキーでログの表示と非表示を切り替えます。ゲームの要所(ステージ開始、失敗、クリア、一時停止など)で mark("...") を呼ぶようにしておけば、実験後に時刻順の行動記録が手に入ります。ログは画面を開いている間だけ残るので、終わったらすぐ書き写してください。
記録シート
人ごとに、次の項目を記録します。
- 最初の操作までの時間、単位・取り方:画面を開いてから最初の入力まで、秒
- 区間ごとの挑戦回数、単位・取り方:ステージ、面、波ごとに回数
- 区間ごとの所要時間、単位・取り方:開始から成功または失敗までの秒
- 失敗の直前の操作、単位・取り方:「何を押した直後か」を一言で
- 発話、単位・取り方:口に出た言葉をそのまま書く。言い換えない
- 離脱の瞬間、単位・取り方:本人が止めたか、観察者が止めたか。直前30秒の様子
発話は意味づけせず原文のまま書きます。「あれ?」「どこ押すの?」「また?」といった一言が、あとで難しさの種類を見分ける材料になります。
手順:渡して、黙って、見る
- 事前に離脱の定義を決めます。 例として、「本人が自分から止めたとき」と「同じ箇所で何度も失敗して、観察者が『続けますか』と聞いたとき」の二つに分けて記録します。何回で聞くかは試作の長さで変わるので、あらかじめ数字を決めておきます。
- 最初に伝えることを限定します。 「試作を遊んでもらいます。うまくいかなくても、試されているのは遊ぶ人ではなく試作です。途中でやめたくなったら、いつやめても構いません」とだけ伝えます。操作方法やルールは説明しません。
- 画面を渡して、観察者は黙ります。 質問されても答えず、「どうしますか」「どう思いますか」と聞き返す程度にとどめます。助け舟を出したくなる場面こそ、記録すべき場面です。
- 記録シートを埋めます。 手が止まった時間、同じ操作の繰り返し、画面を見回す動きなど、観察者から見えたことをそのまま書きます。
- 終了後に短く聞きます。 「一番止まったのはどこですか」「そのとき何をしようとしていましたか」の二つだけで十分です。長いアンケートにはしません。
- 作者の予測と並べます。 準備で書いた予測を取り出し、実際の挑戦回数や離脱位置と並べて見ます。
人ごとの所要時間は、一人あたり長くても数十分に収まるように試作の範囲を区切っておくと、全員分を同じ条件で揃えられます。
結果の読み方:離脱の「場所」と「直前の様子」を組み合わせる
記録がそろったら、次の順で読みます。
1. 離脱の場所を見る
離脱が同じ箇所に複数人で集まるなら、設計上の問題である可能性が高くなります。一人だけが止まったなら、その人の経験や好みによる差かもしれません。人数が少ないので、一人の結果で断定せず、他の人の記録と見比べて判断します。
2. 離脱の直前30秒で種類を分ける
- 画面の端や説明を探している、同じ質問を口にする、疑う種類:わからない、最初に見直す場所:導入の見せ方、最初の画面の情報量
- 同じ操作を繰り返し、失敗の間隔が短い、疑う種類:できない、最初に見直す場所:難易度の上がり方、最初に求める精度
- 手が止まり画面を眺めている、「何をすれば?」と言う、疑う種類:報われない、最初に見直す場所:目的の表示、成功と失敗のフィードバック
一人の離脱が複数の様子にまたがることもあります。その場合は、最後の10秒に近い様子を優先して見てください。
3. 最初の操作までの時間を見る
画面を開いてから最初の入力までが、予測より大きく離れていれば、「わからない難しさ」が入口で働いている可能性があります。ここは難易度以前の問題で、ステージ調整より先に直す場所です。
4. 予測との差を見る
作者の予測より初見の人の失敗回数が少なく、早く進んだ区間は、作者が心配しすぎていた場所です。逆に、予測より早く離脱した区間は、作者の慣れで見えなくなっていた場所です。差の大きい区間を優先して手を入れます。
直し方の原則
見つけた問題は、一度に全部は直しません。一つだけ変えて、別の初見の人にもう一度渡します。 同じ人に再度遊んでもらうと、前回の記憶が入って条件が変わってしまうからです。変更を一つに絞れば、効果が出たのか出なかったのか、原因をたどれます。
誤りやすい点
- 助言をしてしまう。 「そこは上に行くんですよ」と一言入れた時点で、その場面の記録は初見のものではなくなります。言いたくなったら、その場面に印をつけて我慢します。
- 失敗を本人のせいにする。 「集中していなかった」「ゲームに慣れていない」と片づけると、設計の問題が見えなくなります。まず試作側を疑います。
- 聞き取りで答えを誘導する。 「ここ難しかったですよね?」ではなく、「ここで何を考えていましたか」と聞きます。
- 公開後の数字で代用する。 アソバースのプレイ回数は作品の起動を実測した回数で、同じ端末・同じ作品の30分以内の再起動は重複として除かれます。人数ではなく、どこで離脱したかも読み取れません。ゲーム内スコアの共通ランキングも提供されていません。離脱の位置は、この記事のように自分で観察して確かめる必要があります。
- 画面録画や記録を無断で使う。 録画や発話の記録は、目的を説明して同意を得てからにします。公開する場合は、個人が特定されない形にします。
- 全員の意見を平均してしまう。 3人が止まった場所と1人が止まった場所を同じ重さで扱うと、直す順番を誤ります。件数と離脱の直前の様子を見て、優先順位をつけます。
次の行動
まず今日のうちに、自分の試作について「初見の人はどこで、何回失敗したら止まりそうか」を紙に書いてください。次に、試作を見たことがない人を3人探し、定義した離脱の基準と記録シートを用意して、黙って画面を渡してみましょう。結果が出たら、予測との差が最も大きい区間を一つだけ選び、一箇所だけ直して別の人に渡してください。
参考資料
- Nielsen Norman Group「Why You Only Need to Test with 5 Users」(ユーザビリティテストの人数に関する一般的な考え方)

