育て終わる：これ以上更新しないと決める日の、宣言の仕方

「やめる」と「閉じる」はどこが違うか

更新を止めること自体は、誰にでもできます。閉じるとは、止めたうえで、次の三つを言葉にすることです。

1. 何が入っているか（この作品で遊べること）
2. 何を入れないか（意図して入れなかったこと）
3. これから何が起きるか（修正はするのか、しないのか）

放置との違いは、三つ目にいちばん表れます。「不具合の報告があれば、動かなくなるような問題だけ直す」と書いてあれば、読む人は自分の期待を適切な大きさに調整できます。何も書かれていなければ、期待は人によって大きくも小さくもなり、そのずれが後からレビューの不満という形で現れます。

もう一つ大切なのは、宣言が作品の「未完成さ」への言い訳ではない点です。短く遊べる作品、一つの仕掛けだけを試した作品でも、「これで一つの形」と言い切れば完成です。完成の大きさは、規模ではなく輪郭の明確さで決まります。

完成の定義は、更新の途中ではなく最初近くに書く

終わりの日に慌てて基準を作ると、「もう疲れたから終わり」という気分と、「ここまで作ったから完成」という判断が混ざってしまいます。そこで、育てる途中の早い段階で、完成の条件を一度文章にしておくことを勧めます。たとえば次のような形です。

• 最初から最後まで、説明なしで一周遊べる
• 失敗したときに、何が悪かったか分かる
• 画面を閉じて再び開いても、進行の扱いが分かる（残るのか、残らないのか）
• スマートフォンとパソコンの両方で、入口の操作ができる

条件は作品ごとに違ってかまいません。数は多くても五つ程度にとどめます。多すぎると、条件そのものが「終わらない理由」になります。

残りのリストを三つに仕分ける

終わりを決める日には、手元に「やりたいことのリスト」が残っているはずです。これを一項目ずつ、次の三つに振り分けます。

• 直す、判断の基準：完成の条件を満たすために必要、または遊んで壊れる、例：特定の操作で進行できなくなる
• 足さない、判断の基準：作品の輪郭を広げる追加で、今の形でも成り立つ、例：新しいステージ、別モード
• 次作へ回す、判断の基準：面白いが、この作品の問いとは別の問い、例：別の操作方法で試したいアイデア

ここで重要なのは「足さない」の項目を捨てずに、宣言文の「入れなかったこと」として言葉にしておくことです。入れなかったことを書いてあると、作品は「抜けがある」のではなく「選んだ形」に見えます。

宣言文の書き方：三文で足ります

宣言は長くなくてかまいません。三要素を一文ずつ書くと、次のようになります（作品名は仮のものです）。

「小さな灯台」はこのバージョンで完成としています。全8面を最後まで遊べます。新しい面や別モードは入れない方針です。動かなくなる不具合の報告があった場合に限り、修正を検討します。

この文には、次の働きがあります。

• 「全8面」のように、数えられる範囲を示している
• 「入れない方針」と、意図を明示している
• 「検討します」と、約束しすぎない言い方にしている

避けたほうがよいのは、「そのうち更新するかもしれません」「気が向いたら直します」のような、期待を残す書き方です。完成の宣言としては、閉じたことにならなくなります。逆に「一切直しません」と言い切ると、重大な不具合まで放置する約束になってしまうため、範囲を決めて書くほうが無理がありません。

アソバースでは、公開済みの作品の内容を更新できるので、紹介文の末尾に宣言文を入れておくのは現実的な方法です。投稿画面には「紹介文と遊び方を作成」という下書き機能もありますが、これは読み取った内容から文章案を作るもので、「この文章を使う」を押したときだけ反映されます。宣言の三文は作品の判断そのものなので、案をもらうにしても、最終的には自分の言葉で書き直しておくと、意図とずれません。

最後の更新で確かめておきたいこと

宣言した日が、実質的に最後のコード変更の日になります。この更新で見ておく点を三つに絞ります。

1. 既存の進行データを壊さない

セーブを持つ作品の場合、最後の更新でデータ形式を変えると、すでに遊んだ人の進行が読めなくなる恐れがあります。アソバースのクラウドセーブは作品ごとにJSONで128KiBまでなので、形式を変えるなら、バージョン番号を持たせて古い形式を読み替えるのが基本です。短い例を示します。

const CURRENT_VERSION = 2;

function fresh() {
  return { version: CURRENT_VERSION, best: 0, cleared: [] };
}

function migrate(save) {
  if (!save || typeof save !== "object") return fresh();
  let data = { ...save };
  if (!data.version) data.version = 1;
  if (data.version === 1) {
    // 旧形式: stages 配列 → 新形式: cleared 配列
    data = { version: 2, best: data.best ?? 0, cleared: data.stages ?? [] };
  }
  return data.version === CURRENT_VERSION ? data : fresh();
}

console.log(migrate({ version: 1, best: 120, stages: [1, 2] }));
console.log(migrate(null));

一つ目の呼び出しでは、旧形式の stages が新形式の cleared に移ります。二つ目では、空のデータから初期状態が作られます。ブラウザのコンソールに貼り付けて、出力を自分の目で確認してみてください。「読めないデータは初期状態に戻す」という最後の保険を入れておくと、想定外の形式でも画面が固まりません。

2. 「残らないもの」を明記する

作品によっては、記録がその画面を開いている間しか残らないものもあります。それ自体は問題ではありませんが、遊ぶ人が「残ると思っていた」と感じるのは避けたいところです。宣言文か遊び方に、「記録はこの画面を開いている間だけ」のように一行添えておきます。

3. 外部に頼っている部分を減らす

完成した作品は、作者が手を入れなくても動き続けることが望まれます。外部のサーバーや読み込み先に頼る部分があると、作者の知らないところで動かなくなります。素材は相対パスでまとめ、入口を直下のindex.htmlにそろえておくと、作品が自分だけで閉じた形になります。サーバー用コードやサービスワーカーはアソバースへのアップロード対象外でもあるので、その意味でも、単独で完結する構成は完成と相性がよいといえます。

数字は「完成の証拠」にならない

宣言の前後で、プレイ回数やレビューが気になる場面もあると思います。ここで注意したいのは、数字の読み方です。

アソバースのプレイ回数は作品の起動の実測回数で、同じ端末・同じ作品の30分以内の再起動は重複として数えません。人数ではないので、「何人が遊んだか」の答えにはなりません。レビューは1〜5点で、評価順のランキングはレビューが3件以上になってから載ります。つまり、数字が少ないことは、作品が未完成であることの証拠ではありません。

完成かどうかは、数字ではなく、最初に書いた完成の条件で判断します。数字は、宣言の後に作品がどう受け取られたかを知る材料として、別に扱うほうが気持ちが楽になります。

宣言のあと、作品には三つの道がある

宣言をした後の作品は、次のいずれかを選べます。

• そのまま公開し続ける：最も多い選択です。宣言文があれば、更新がないこと自体は不安材料になりません。
• 修正だけ受け付ける：宣言文に書いた範囲の不具合だけ直します。「何を直し、何を直さないか」は、先に書いた基準で判断できます。
• 非公開にする、または削除する：アソバースでは、公開内容の更新のほかに、非公開化と削除ができます。公開し続ける意味が薄れた場合や、作品を作り直したい場合の選択肢です。なお、退会するとアップロードしたファイルや履歴・セーブを含む個人データが削除される点は、頭に置いておいてください。

不具合の報告が来たときの判断基準は、三つの問いで足ります。

1. 完成の条件が崩れていますか。
2. 修正によって、既存の進行データを壊しませんか。
3. 宣言文に書いた範囲に入っていますか。

三つとも「はい」であれば直し、そうでなければ宣言のとおりに見送ります。宣言があることで、一件ごとに迷う負担が減ります。

自分で行える、宣言の予行演習

実際に宣言する前に、次の手順を試してみてください。結果は作品ごとに異なります。

1. 完成の条件を書き出す：三〜五項目、一項目一文で書きます。
2. 残りのリストを仕分ける：「直す」「足さない」「次作へ」の三つに振り分けます。
3. 宣言文を三文で書く：何が入っているか、何を入れないか、これから何が起きるか、の順です。
4. 一週間置いて読み返す：書いた直後は気持ちが乗っているので、時間を置いて、約束しすぎていないか確かめます。
5. 友人に三分遊んでもらう：遊んだ後に宣言文を読んでもらい、「書かれていることと遊んだ感触が合っているか」だけを聞きます。感想の細部ではなく、輪郭が合っているかを見ます。
6. セーブ読み込みを試す：旧形式のデータを用意して、新しいコードで開けるかを確かめます。

五番目で「合っていない」と言われたなら、作品を変えるより先に、宣言文のほうを直せないか考えてみてください。ずれの原因が作品の側にあるときは、完成の条件を満たしていないことになります。そのときは、条件に戻って直す箇所を決め直します。

次の行動

まず、育てている作品について、完成の条件を三つだけ書き出してみてください。次に、残りのリストを「直す」「足さない」「次作へ」に仕分け、「足さない」ものを宣言文の一文にします。最後に、データ形式の変更があるなら、バージョン番号を持たせる処理を入れてから、公開内容を更新してください。