最初のレビューが届いたら、何を直し何を直さないか：1件の声を判断に変える基準

1件のレビューが教えてくれることと、教えてくれないこと

アソバースのレビューは、1〜5点の評価と1〜2,000文字の本文で書かれます。1つのアカウントが1つの作品に書けるのは1件で、本人が編集も削除もできます。つまり、1件目は「ある一人が、ある時点で感じたこと」です。後で書き直されることもあります。

数字の扱いにも注意が必要です。プレイ回数は作品を起動した実測回数で、人数ではありません。同じ端末と作品の組み合わせでは、30分以内の再起動は重複として除かれます。レビューが1件でプレイ回数が数十回あるなら、書いた人以外の多くは何も言わずに去ったか、満足したかのどちらかです。どちらなのかは、数字からは分かりません。

評価順のランキングは、レビューが3件以上ある作品から掲載されます。仕組みの上でも、1件は「傾向」として扱われない量です。1件目の点数は気にしすぎず、情報として読むのが現実的です。

1件のレビューには、次の使い方が向いています。

• 具体的に書かれた事実（「ボタンを押しても反応しなかった」など）は、確認する手がかりになります。
• 感想（「長い」「難しい」）は、仮説として手元に置きます。
• 点数そのものは、この段階では判断の材料にしません。

レビューを3種類に仕分ける

レビューの文は、混ざった状態で届きます。直す前に、1文ずつ次の3つに分けます。

• 事実の報告、例（架空）：「スマホで右ボタンが押せませんでした」、扱い：再現できるか確かめます
• 体験の感想、例（架空）：「最初が長い」「分かりにくい」、扱い：原因を推測し、仮説として保留します
• 好みの提案、例（架空）：「ここにタイマーがほしい」、扱い：作品の核に合うかで判断します

冒頭の例なら、「最初のステージが長い」は体験の感想です。「操作が分かりにくい」も感想ですが、どの操作がどう分かりにくいのかが書かれていません。そのため、この時点では原因が特定できません。

ここで大事なのは、感想を事実のように扱わないことです。「長い」と感じた理由は少なくとも3通り考えられます。実際に所要時間が長い場合、時間は普通でも目的が見えずに長く感じた場合、途中で操作に迷って時間を使った場合です。3つで直し方がまったく違います。1つ目はステージの設計を変える話で、2つ目は冒頭の見せ方、3つ目は操作の説明の話です。

「直す」「保留」「直さない」の基準

仕分けたあとは、次の順に問います。

1. 再現できる不具合は、すぐ直す

動かない、押せない、進めなくなるといった不具合は、好みの問題ではありません。自分の環境で再現できれば、優先して直します。再現できなくても、画面の狭さや端末の違いが原因の可能性があるので、ブラウザの幅を変えて試す価値はあります。

2. 伝わっていないだけなら、作品ではなく説明を直す

「分かりにくい」の多くは、ゲーム本体を変えなくても改善できます。アソバースでは公開した作品の内容を更新できるので、紹介文や遊び方の書き方を直すだけで済むことがあります。投稿画面には、公開済みURLや本人の検証済みアップロードを読み取って紹介文と遊び方の下書きを作る機能があります。使うかどうかは自分で決められます。「この文章を使う」を押したときだけ反映され、生成しただけで公開されることはありません。

3. 1件だけの難易度の話は、保留する

「長い」「難しい」「簡単すぎる」は、遊ぶ人によって逆の意見が出やすい項目です。1件の段階では、直さずに記録だけ残します。2件目、3件目で同じ点が出たときに、はじめて直す候補にします。

4. 作品の核に反する提案は、直さない

ここで、自分の作品の核を一文で書いておくことが役に立ちます。たとえば「短い時間で、一手ずつ考えるパズル」と決めてあれば、「リアルタイムの制限時間をつけてほしい」という提案は核とずれます。提案が悪いわけではありません。その提案を入れると、別の作品になるということです。

核に合わない提案でも、背景にある不満は拾えます。「時間制限がほしい」の裏には「緊張感が足りない」があるかもしれません。それなら、核を保ったまま別の方法（手数の記録を見せるなど）で応えられる可能性があります。

自分で行える仕分けの手順

ここからは、レビューが届いたときに手元で行う手順です。結果は作品によって違うので、記録の形だけを示します。

1. レビュー本文をコピーし、1文ずつ改行します。
2. 各文に「事実」「感想」「提案」のどれかを付けます。
3. 「事実」は、自分の環境で再現できるかを試して、「再現した／しなかった／条件付き」を書きます。条件付きなら、ブラウザの幅、端末、操作方法を書き添えます。
4. 「感想」は、考えられる原因を3つまで書き出します。たとえば「長い」なら、所要時間、目的の見えにくさ、操作の迷いです。
5. 「提案」は、作品の核の一文と照らし、合うか合わないかを書きます。
6. 最後に、各項目へ「直す／保留／直さない」を付け、理由を一行で書きます。

「感想」の原因を絞り込むために、自分以外の誰かに最初の数分を遊んでもらい、止まった場所と迷った場所を観察する方法があります。やり方は次のとおりです。

• 1人につき、冒頭から最初のクリアまたは離脱までを見ます。
• 説明や助言はせず、止まった場所と時間だけを書き留めます。
• 3人以上で行い、同じ場所で止まる人が複数いるかを見ます。

同じ場所で複数人が止まるなら、その場所は直す候補です。人によってばらばらなら、原因は好みや経験の差にある可能性が高く、保留が妥当です。まだ誰にも遊んでもらっていない段階では、これらの結果は何も分かりません。結果を想像で埋めず、実際に観察してから判断してください。

直したあとに確かめること

更新は、直した場所だけでなく、直していない場所にも影響します。更新前に次の点を確認します。

• 直した不具合が直ったか。 再現手順を、もう一度同じ条件でたどります。
• 前に動いていた部分が壊れていないか。 最初のステージから最後まで通して遊びます。
• セーブ形式を変えていないか。 ここは見落としやすい点です。

セーブ形式は、軽く考えると危険です。ステージ構成を変えたとき、保存している値の意味まで変わってしまうことがあります。

アソバースの公式作品では、古い保存（version1）を新しい形式（version2）へ移行するようになっています。ここから読み取れるのは、保存データに版番号を持たせ、読み込むときに古い版を新しい形へ変換するという考え方が有効だということです。実際の移行処理の中身は、各作品を開いて確かめてください。

自作でも、同じ考え方を小さく取り入れられます。次は、単独で動く最小の例です。

// 保存データを読み込むときに、版を見て新しい形へそろえる
function migrate(save) {
  const fresh = { version: 2, stage: 1, best: null };
  if (!save || typeof save !== "object") return fresh;
  if (save.version === 2) return save;
  // version 1 は level という数値だけを持っていた、という想定の例
  return {
    version: 2,
    stage: Number(save.level) || 1,
    best: save.best ?? null
  };
}

console.log(migrate({ level: 4, best: 38 }));
console.log(migrate(null));
console.log(migrate({ version: 2, stage: 3, best: 20 }));

3つの呼び出しは、古い形式、空のデータ、新しい形式の順に確認するものです。更新の前に、自分の作品の古いデータで同じ確認をしておくと、「更新したら進行が消えた」という事故を避けられます。クラウドセーブは作品ごとにJSONで128KiBまで使えます。形式を変えるときも、この容量の範囲に収まるかを見ておきます。

最後に、更新の記録を残します。「何のレビュー文を受けて、何を直し、何を直さなかったか。直さなかった理由は何か」を3行で書いておけば、2件目、3件目が届いたときに、前回の判断を見返せます。

次の行動

最初のレビューが届いたら、直す前に本文を1文ずつ「事実・感想・提案」に分け、作品の核を一文で書いてください。まだレビューが届いていなくても、核の一文と、保留にした項目を書く記録欄は先に用意できます。届いた声は、直す理由と直さない理由の両方を残してから動かすと、次の更新の判断が楽になります。