レビューは更新になるのか？ 仮定の三例で読む、届く感想の書き方と拾い方

更新の材料になるレビューの条件

まず、アソバースで確認できているレビューの仕組みを整理します。

• 点数は1〜5点で、本文は1〜2,000文字です。
• 1アカウントが1作品に書けるのは1件で、本人が編集・削除できます。
• 自作への評価はできません。
• レビューの投稿にはメール確認が必要です。
• 評価順のランキングには、レビューが3件以上ある作品だけが載ります。

ここから読み取れる点が二つあります。一つ目は、1作品1件で編集できるので、更新後に「直っていました」と書き換えられることです。二つ目は、レビューが数件の段階では、1件の点数で平均が大きく動くことです。点数だけを更新の根拠にすると、判断を誤りやすくなります。

作者にとって使いやすいのは、点数よりも本文に書かれた「どの場面で何が起きたか」です。2,000文字は長い感想を書くには十分ですが、必要なのは長さではなく、場面と結果が分かることです。

なお、レビューへの作者からの返信機能については、確認できている範囲に含まれていません。使えるかどうかは、現在の案内で確認してください。作者の公開プロフィールにSNSや問い合わせページのHTTPS URLがある場合は、そこが別の連絡手段になります。ただし公開は本人が選んだときだけなので、載っていない作者もいます。

仮定の三例

以下の作品はすべて、説明のために置いた仮定です。実在する投稿作品でも、公式作品でもありません。

例1：記憶ゲームの「いきなり終了」

3回間違えると終わる光の順番記憶ゲーム（仮）を考えます。次のようなレビューが届いたとします。

気づいたら終わっていました。どこで何回間違えたのか分からず、納得できませんでした。

このレビューには、場面（途中で終了）、困りごと（間違いの回数が見えない）、感情（納得できない）が入っています。作者が読み取れるのは、ルールの問題ではなく表示の問題だということです。3回で終了という設計は変えず、残りの許容回数を画面に出す更新で解決できるかもしれません。

ここで「もっと簡単にしてほしい」とだけ書かれていた場合を比べてみます。難易度を下げるのか、説明を足すのか、作者は判断できません。同じ不満でも、場面が書いてあるかどうかで、更新につながる度合いが変わります。

例2：スライドパズルの「ボタンが小さい」

数字をそろえるスライドパズル（仮）で、次のレビューが届いたとします。

スマホだとタイルが小さくて、隣のタイルを押してしまいます。

作者が確認すべきなのは、どの画面幅で起きるのかです。レビューに機種名や画面の向きが書かれていれば、再現しやすくなります。書かれていなければ、作者は自分で画面幅を変えて確かめます。ブラウザの開発者ツールには画面サイズを切り替える機能が付いているのが一般的なので、そこで見るのが手軽な方法です。

直し方も一つではありません。タイルの最小サイズを決める、盤面の余白を減らす、拡大表示に対応する、などが考えられます。どれを選ぶかは、元のレビューの文面だけでは決まりません。

例3：「次に開いたら最初からだった」

保存について、次のようなレビューが届いたとします。

昨日の続きから遊ぼうとしたら、最初に戻っていました。

保存の要望は、アソバースの仕組みと照らして確かめる必要があります。アップロード作品の中のlocalStorageとsessionStorageは、一時メモリーとして動く互換処理です。これを当てにした保存は、続きから遊べない原因になりえます。

確認済みの手段として、アップロードしたゲームにはSDKが自動で追加されます。URL投稿のゲームは、作者がSDKを読み込むと使えます。SDKを使うと、作品専用のプレイヤーIDと、作品ごとにJSONで128KiBまでのクラウドセーブが使えます。クラウドセーブはログイン中のプレイヤーが対象です。ゲストの進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。

つまりこのレビューは、更新で解決できる要望です。同時に、更新後の説明も必要です。「ログインすると続きから遊べます」という一文が遊び方にあれば、ゲストで遊んだ人の期待とのずれを減らせます。ゲームにはFirebaseのUID、認証トークン、メールアドレスを渡してはいけない点も忘れないでください。

作者の仕分け：直す・説明する・見送る

三つの例から、レビューへの対応は三種類に分けられます。

• 直す、例：残り回数が見えない、タイルが押しにくい、対応：画面や操作を更新する
• 説明する、例：ログインで保存できることが伝わっていない、対応：紹介文や遊び方を更新する
• 見送る、例：「もっと派手に」のように方向が合わない、対応：記録して、同じ指摘が増えるか待つ

見送ることは、無視とは違います。作品の狙いと合わない要望を、理由をつけて保留にする判断です。たとえば、難しさが魅力の作品で「簡単にしてほしい」という声が1件だけなら、難易度そのものは変えず、練習用の入口を足せるかを考える手があります。

レビュー台帳のつくり方

自分の作品を公開している人は、レビューを台帳にすると、見送りも含めて判断を残せます。表計算ソフトやメモ帳で次の列を作ります。

1. 日付
2. 作品のバージョン（更新の都度、自分で番号を振ります）
3. レビューの該当部分の引用（本人のレビューなので、台帳で使う分には問題になりにくいですが、外に出す場合は書いた人への配慮が要ります）
4. 種類（直す／説明する／見送る）
5. 対応した日と内容

同じ種類の指摘が複数のレビューに出てきたら、優先度を上げる、という運用が基本です。1件だけの指摘は、まず再現できるかを自分で確かめます。再現できれば、1件でも直す価値があります。

更新の効果をどう読むか

更新後に確かめたくなるのは、「良くなったのか」です。ここで使える数字には限りがあります。

• プレイ回数は、作品の起動を実測した回数です。人数ではありません。同じ端末・同じ作品の30分以内の再起動は重複として除かれます。更新後に回数が増えても、人数が増えたとは言えません。
• レビュー平均は、件数が少ないうちは1件で大きく動きます。評価順に載るのは3件以上からなので、3件前後の平均差は、更新の効果かどうか判断できません。
• ゲーム内スコアの共通ランキングは未提供です。更新の前後でスコアを比べる仕組みは、アソバース側にはありません。

数字より確かな手がかりは、更新後に同じ場面についてのレビューが変わったかどうかです。例1なら、「終了の理由が分からない」という指摘が出なくなったかを見ます。出なくなったからといって効果の証明にはなりませんが、台帳に「指摘が止まった」と記録しておけば、次の判断の材料になります。

誤りやすい点も挙げておきます。

• 更新直後に、数日分のプレイ回数の増減だけで結論を出すこと。
• 好意的なレビューだけを拾い、不満の中の共通点を見落とすこと。
• 更新内容を紹介文に書かず、レビューした人が気づけないままになること。

更新は、公開内容の更新として行えます。非公開化や削除もできるので、直した結果がかえって悪くなった場合は、非公開にして直し直すこともできます。

読者が書くときの型

レビューを書く側にとっての「更新につながりやすい型」を、五つの要素にまとめます。全部を満たす必要はなく、二つか三つ入れるだけで、作者の判断が速くなります。

1. 場面：どの画面、どの操作のときか。
2. 結果：何が起きたか、起きなかったか。
3. 環境：スマホかパソコンか、画面の向き、ブラウザの種類（分かる範囲で）。
4. 期待：本来どうなってほしかったか。
5. 良かった点：残してほしい部分。更新で変わってほしくない点を知らせるのも大事です。

たとえば「つまらない」より「3回目の失敗で終わった理由が分からず、そこで閉じました。残り回数が見えると続けられたと思います」のほうが、作者は動けます。

ほかに気をつけたい点もあります。批判するときは、作品への指摘と作者への評価を分けて書きます。自作へのレビューはできないので、友人の作品を持ち上げる目的でも書けません。更新後は、レビューの編集で「直っていました」と書き換えれば、次に読む人の参考になります。

次の行動

遊ぶ人は、最近遊んだ作品を一つ選び、上の五つの要素のうち場面と結果の二つだけを入れてレビューを書いてみてください。作る人は、手元の作品のレビューや感想を、直す・説明する・見送るの三種類に分けた台帳を作ってみてください。まだレビューがない場合は、例1〜3のような仮定の指摘を自作に当てはめて、直せるかを点検するところから始められます。

保護者や学習者の方は、レビューは作品を通じた文章の練習にも使えます。投稿やレビューの利用条件は現在の案内で確認し、メール確認が必要な点も合わせて見ておいてください。