公開後に遊びの中心を変えると、遊んでいた人はどう感じるか：更新の許容範囲を測る実験設計

準備：変更の大きさと「核の一文」を決める

変更を3段階に分ける

「大きく作り変えた」には幅があります。比べるために、変更を次の3段階に分けます。

• A 調整、変える内容：数値、見た目、操作感の手直し、例：制限時間の変更、色の変更、ボタン位置の変更
• B 追加・削除、変える内容：ルールや要素の出し入れ、例：新しい敵の追加、ヒント機能の削除
• C 置換、変える内容：遊びの中心そのものの入れ替え、例：考えるパズルを反射神経のゲームに変える

一つの更新に複数の段階が混ざると、どの変更への反応なのか分からなくなります。実験では、1回の更新につき1段階だけを動かします。

更新前の「核の一文」を書く

次に、更新前のゲームを「プレイヤーは〜して、〜を味わう」という一文で書きます。たとえば「行き止まりを避けながら、少ない手数で道を見つけることを味わう」のような一文です。

これが変えてよい範囲を測る物差しになります。核の一文に出てくる要素を変えると、Cに近づきます。出てこない要素は、A・Bで動かしやすい候補です。

ただし、作者が書いた一文は仮説にすぎません。遊んだ人が本当に好きだった点とずれていることがよくあります。そのずれを、手順の中で確かめます。

用意するもの

• 更新前のゲーム一式。手元に必ずコピーを保存します。 アソバースでは公開内容の更新ができますが、更新前の版が残るかどうかは、確認済みの案内にありません。現在の案内で確認し、残る前提にはしません。
• 更新後のゲーム一式。更新前と同じ入口の形（直下のindex.html）で作ります。
• 遊んでくれる人。更新前のゲームを一度以上遊んだ人を、できれば条件ごとに3人以上集めます。人数が少なくても、傾向をつかむ目的なら使えます。ただし結論としては弱くなります。
• 記録用の質問票。紙でも表計算でも構いません。

公開済みの作品で試すことに抵抗があるときは、手元のHTMLを友人に直接渡して遊んでもらう方法もあります。公開内容を書き換える前に、反応の傾向だけ確かめられます。

手順：更新前に聞き、更新後に同じことを聞く

実験は、更新前の聞き取り、更新、更新後の聞き取りの3つに分かれます。

1. 更新前の聞き取り（ベースライン）

更新前のゲームを遊んでもらい、その直後に次の3つを聞きます。

1. このゲームの好きな点を、一文で書いてください。
2. このゲームを友達に説明するなら、何と言いますか。
3. 一つだけ変えてよいとしたら、何を変えますか。

1と2の答えと、自分で書いた核の一文を並べます。一致していれば、核の把握が正確です。ずれていれば、ずれた部分が「作者が見えていなかった価値」の候補です。

2. 更新を一つの段階に絞って作る

A・B・Cのうち一つを選んで更新版を作ります。複数の段階を比べたいときは、別の人に別の段階を割り当てます。同じ人にA、B、Cと続けて見せると、前の更新の印象が次に混ざるためです。

3. 更新後の聞き取り

更新後は、同じ人に二度遊んでもらい、それぞれの直後に聞きます。初回と数日後の2回に分けるのは、最初の違和感が慣れで薄れるのかを見るためです。

聞く内容は次のとおりです。

• 更新前に答えた「好きな点」は、今も残っていると感じますか（残っている／変わった／消えた）。
• 「同じゲームだ」という感覚は5段階でいくつですか（1＝別のゲーム、5＝同じゲーム）。
• 戻してほしい点はありますか。あれば具体的に書いてください。
• 更新後に新しく好きになった点はありますか。

更新内容は、遊ぶ前に紹介文のような短い文章で伝えるグループと、何も伝えないグループに分けてもかまいません。この場合、違いを見たいのは「事前説明の有無」だけにします。同時に他の条件を動かさないでください。

記録の取り方：何を、どの単位で残すか

記録は1人1行の表にして、次の列を作ります。

• 参加者ID、内容：名前ではなく番号
• 変更段階、内容：A／B／C
• 事前説明、内容：あり／なし
• 更新前の好きな点、内容：原文のまま
• 初回の「同じゲーム」評価、内容：1〜5
• 数日後の評価、内容：1〜5
• 好きな点の状態、内容：残っている／変わった／消えた
• 戻したい点、内容：原文のまま

意見は要約せず、原文のまま残します。要約すると、作者の解釈が混ざります。

アソバース上の数字は、補助情報としても扱いに注意してください。

• プレイ回数は作品起動の実測回数で、人数ではありません。同じ端末・作品の30分以内の再起動は重複が除かれます。更新後に回数が増えても減っても、遊んだ人の感情は読み取れません。
• レビューは1アカウント1作品に1件で、本人が後から編集できます。更新前に書かれたレビューは、更新後の内容と食い違っていても、そのまま残ることがあります。レビューを根拠にするときは、いつ書かれたかを念頭に置きます。
• いいねは1アカウント1件で、「好きな作品」と連動します。「好き」の理由までは分かりません。

こうした数字は、聞き取りの代わりにはなりません。聞き取りで見えた傾向を、あとから照らし合わせる位置づけで使います。

結果の読み方：どの結果ならどう判断するか

聞き取りがそろったら、変更段階ごとに「同じゲーム」の評価と、好きな点の状態を並べます。ここで見るのは平均値より、回答が割れているかどうかです。

• 評価が高く、好きな点も「残っている」、解釈：変更が核に触れていない、次の判断：その段階の更新は進めやすい
• 評価が低く、「好きな点」が「消えた」、解釈：変更が核に触れている、次の判断：核の一文を見直す。更新を別作品として切り出す案も検討する
• 初回は低く、数日後に上がる、解釈：慣れの問題、次の判断：更新の見せ方（説明の追加など）で対処できる可能性がある
• 初回も数日後も低く、戻したい点が一致する、解釈：特定の要素への反発、次の判断：その要素だけを戻す、または選べるようにする
• 評価が人によって大きく割れる、解釈：遊ぶ動機が人ごとに違う、次の判断：好きな点の原文を見て、グループ分けを試みる

更新前の聞き取りで、作者の核の一文と参加者の「好きな点」がずれていた場合は、特に注意してください。作者がAだと思って変えた部分が、参加者にとっては核だった可能性があります。

変えてよい範囲は、こうして見つかった「参加者の誰も好きな点に挙げなかった要素」と考えられます。ただし、少人数の聞き取りから出る線は暫定です。断定せず、次の更新で確かめ直す前提で扱います。

誤りやすい点：結果を歪めやすい落とし穴

• 知人だけで集める： 気を遣って肯定的に答えがちです。質問は「どこが良かったか」だけでなく、「戻してほしい点」も必ず聞きます。否定意見を出しやすい形にします。
• 段階を混ぜる： BとCを一度に更新すると、どちらへの反応か分かれません。1回の更新で動かすのは1段階にします。
• 更新前の好きな点を聞かない： 更新後だけ聞くと、比べる基準がありません。ベースラインは必須です。
• セーブの扱いを見落とす： 進行が消えたことへの不満は、遊びの変更への不満と混ざります。アソバースではログイン中にクラウドセーブ（作品ごとにJSONで128KiBまで）が使えますが、ゲストの進行は端末内に保存されます。更新で保存形式を変えるなら、保存データにバージョン番号を持たせ、古い形式を読み込める移行処理を用意します。公式作品でも、古い保存（version1）を新しい形式（version2）へ移行する考え方が採られています。実験の参加者の進行が更新で消えないことも、あらかじめ確認します。
• 更新内容を伝えないまま反応を読む： 紹介文に何が変わったかを書いていないと、遊んだ人は「壊れた」と受け取る場合があります。事前説明あり・なしの比較は、この点を確かめる目的でも使えます。
• 結果を一般化する： 自分のゲームと自分の参加者から得た線は、他の作品にはそのまま当てはまりません。

次の行動

まず、自作の公開済みゲームについて「核の一文」を書き、更新前の版を手元に保存してください。次に、一度遊んだことのある人を数名選び、更新前の好きな点を聞くところから始めてみます。更新は、A・B・Cのうち最も小さいものを一つだけ動かして、同じ質問をもう一度投げるところまで進めます。