作品を非公開にして作り直すと、戻ってくる人はいるのか：停止期間の記録の取り方

「戻ってきた」を分解する

「戻ってきた人」と言っても、確かめたいことは複数あります。大きく3つに分けられます。

• 非公開の前に遊んだ人が、再公開後にもう一度遊んだか
• 再公開後の遊ばれ方が、非公開の前と比べて増えたのか減ったのか
• 以前の遊び手が、反応（いいね、レビュー、フォロー）を残し続けているか

アソバースで確認できる範囲では、プレイ回数は作品起動の実測回数です。同じ端末・同じ作品の30分以内の再起動は重複として除かれますが、人数ではありません。ですから、プレイ回数が増えても「同じ人が何度も起動した」のか「別の人が増えた」のかは、この数字だけでは区別できません。1つ目の問いは、プレイ回数だけでは答えが出ないのです。

2つ目の問いなら、プレイ回数でも扱えます。ただし、起動の増減を見るだけで、人の戻りは見えません。3つ目は、いいねやレビューの数で近づけます。いいねは1アカウント1件で「好きな作品」と連動し、レビューは1アカウント1作品1件です。同じ人が何度も押して増える数字ではないので、人の動きに近い指標です。一方で、押す人は遊んだ人の一部にすぎません。

最初にやることは、どの問いに答えたいのかを1つ選ぶことです。3つ全部を一度に追うと、記録も読み方も散らかります。

非公開にする前に決めること

記録を設計する前に、そもそも非公開が必要なのかを考えます。アソバースの投稿には、公開内容の更新、下書き保存、非公開化、削除があります。公開したまま更新できるなら、非公開は選択肢の1つにすぎません。

次の表で、更新で済むか非公開が要るかを大まかに判断できます。

• 小さな不具合の修正、更新で済む可能性：高い、非公開を考える場面：ほぼ不要
• 難易度やバランスの調整、更新で済む可能性：高い、非公開を考える場面：調整が数週間に及び途中状態を見せたくないとき
• セーブ形式の変更、更新で済む可能性：互換処理を書ければ可、非公開を考える場面：互換処理が間に合わず、旧データが壊れるおそれがあるとき
• 遊びの中心を入れ替える大改修、更新で済む可能性：低い、非公開を考える場面：改修前後で別の作品になるとき

非公開にするなら、停止が始まる日と、再公開の目標日を先に書いておきます。目標日は延びるものですが、書いてあれば「予定より何日延びたか」も記録に残ります。

もう1つ、非公開中に外から何がどう見えるかは、非公開にしてから確認します。作品ページ、検索、ランキング、他の人の「好きな作品」や「あとで遊ぶ」に、非公開の作品がどう表示されるかは、確認済みの案内には書かれていません。思い込みで書かず、非公開化の直後に自分の画面と、できれば別のアカウントで見て、見え方をメモします。ここが分かれば、停止中に誰かが戻りたくても戻れない状態なのか、そもそも見つからないだけなのかを区別できます。

記録の設計：停止前・停止中・再公開後

比較するのは3つの期間です。停止前、停止中、再公開後で、それぞれ4週間を目安にします。曜日の偏りを均すため、期間は7日の倍数にします。週末に遊ばれやすい作品なら、7日単位でないと比較が歪みます。

何を記録するか

表で、指標ごとに分かることと注意点を整理します。

• プレイ回数、分かること：起動の増減、注意点：人数ではありません。30分以内の同一端末の再起動は重複が除かれます
• いいね数、分かること：好意を示した人の累計、注意点：増減は取り消しでも起きます。累計だけでなく日ごとの差を残します
• レビュー件数・平均点、分かること：遊んだ感想の蓄積、注意点：評価順は3件以上から掲載されます。件数が少ない間は平均点に意味を持たせすぎないようにします
• フォロー数、分かること：作者への関心、注意点：作者が数を見られるかどうかは、現在の案内で確認します
• 自分で受け取った声、分かること：戻ってきた実感の根拠、注意点：件数が少なくても、日付と内容を原文に近い形で残します

プレイ回数をどこで確認できるかは、確認済みの案内に書かれていません。作品ページや自分の管理画面に見える数字を確認し、見える場所を最初にメモします。もし停止中に数字が見えなくなるなら、停止の前日に必ず控えておきます。再公開した日に、数字が停止前から連続しているのか、ゼロから始まるのかも確認します。

どう記録するか

記録は、日付、各指標の数字、その日にあった出来事の3列で十分です。毎日同じ時刻に1回転記します。時刻をそろえるのは、日の途中で数えた数字と日の終わりに数えた数字が混ざらないようにするためです。

出来事の列には、告知、SNSでの紹介、仕様変更、自分のテストプレイを書きます。再公開の日に告知を出すと、その日と翌日に起動が集中して山ができます。何が山を作ったのかを、あとから切り分けるための列です。

自分のテストプレイは特に重要です。作者自身が再公開後に動作確認で何度も起動すれば、実測の起動回数に混ざる可能性があります。混ざるかどうかは案内で確認し、混ざるなら、確認のために起動した日と回数を記録して、あとで差し引く目安にします。30分以内の再起動が重複除外になる点も、自分の確認作業には効きます。続けて試すと数えられず、間隔を空けると数えられる、という差が出るかもしれません。

結果の読み方を先に決める

結果を見てから解釈を考えると、期待に合わせて読んでしまいがちです。そこで、記録を始める前に、次の読み方を書いておきます。

1. 停止前4週の1日あたりの平均プレイ回数と、再公開後4週の1日あたりの平均を並べます。
2. 再公開後の平均が停止前を下回る、同程度、上回るのどれかを判断します。どのくらいの差を「同程度」とみなすかは、見る前に自分で決めておきます。
3. 再公開直後の山の日を除いた平均も出します。除くかどうかで結論が変わるなら、結論を急がないことにします。

たとえば仮の数字として、停止前の平均が1日10回、再公開後の平均が1日6回だったとします。これは説明のための例で、実際の結果ではありません。この場合、「戻りが弱い」と決めるのはまだ早いです。作り直しで作品が別物になり、新しい遊び手が少しずつ増える途中かもしれません。そこで、再公開後の4週をさらに前半と後半に分け、後半が前半より上向いているかも見ます。

プレイ回数が人数ではない点を忘れないでください。同じ人が毎日起動して平均を押し上げることもあれば、多数の人が1回ずつ試して去ることもあります。平均が同じでも、遊ばれ方は別物です。この限界を、記録の最後に1行書いておきます。

さらに、数字の外側にある手がかりを並べます。いいねやレビューの日付が、再公開の後に集中していれば、反応が新しい作品に向いている可能性があります。停止前に反応した人が、再公開後に何か書いたかどうかは、アカウントの表示名が見えるかぎりで確かめられます。ただし、同じ人かどうかを数字から断定することはできません。断定できない部分は、断定できないと書き残すのが誠実です。

戻ってきた人に出会える作りにする

数字で戻りを推定するだけでなく、作品の側に「おかえりなさい」を迎える仕組みを置く手もあります。

アップロードした作品にはSDKが自動で追加され、URL投稿でも作者がSDKを読み込めば、作品専用のプレイヤーIDと、作品ごとにJSONで128KiBまでのクラウドセーブが使えます。ログインしている遊び手なら、前回のセーブがクラウドに残っています。作品が起動したときにそのセーブを読み、前回の最終プレイ日や到達点を見つければ、戻ってきた人を作品自身が認識できます。

具体的な読み書きの手順は、SDKの案内に従ってください。ここでは設計の考え方だけ述べます。

• セーブに形式のバージョン番号を入れておき、作り直し後も旧形式を読めるようにします。旧セーブが読めないと、戻ってきた人の進行が消えます。
• 旧形式のデータから新形式へ移す処理を、再公開の前に旧データで試します。
• 再公開後の初回起動で、旧セーブがあれば短い案内を出し、進行をどう扱ったかを伝えます。
• 128KiBの上限があるので、作り直しで増えたデータが収まるかを確かめます。

端末のセーブにも注意が必要です。未同期の端末セーブは、クラウドの古いデータより優先して再送されます。非公開の間に端末へ残った旧形式のデータが、再公開後にそのまま送られてくる場面は十分あり得ます。旧形式を新形式が読めなければ、戻ってきた人が最初に出会うのが壊れた進行になってしまいます。

また、アップロード作品内のlocalStorageやsessionStorageは一時メモリーの互換処理です。戻りの判定を長期に残す場所としては使えません。ゲストの履歴と進行は端末内に保存され、ログイン後のアカウントに自動では混ざらないので、ゲストとして遊んだ人の戻りは、この仕組みでは捉えられません。ここも限界として記録に書いておきます。

作者側がクラウドセーブの内容を集計して見られるかどうかは、確認済みの案内にありません。現在の案内で確認してください。見られないなら、この仕組みは作者の分析用ではなく、遊び手への迎え方として使うものと割り切れます。

次の行動

作り直しを始める前に、停止予定日と再公開の目標日、答えたい問いを1つ、そして「同程度」とみなす幅を紙に書きます。次に、停止前の4週分の数字を毎日同じ時刻に転記しはじめます。非公開にした直後には、作品が外からどう見えるかを確認してメモします。再公開前には、旧セーブを新しい形式で読み込めるかを必ず試してください。