作品に手紙を書く：一年後の自分への更新メモ
遊びを届ける執筆にClaudeを使用しています。
公開したブラウザゲームに、感想が一件届いたとします。「この面だけ、どうしても進めません」という内容です。ところが、そのゲームを最後に開いたのは一年前です。フォルダを開くと、ファイル名はmain2_final_new.js、変数名はtmp3。なぜこの作りにしたのか、どこを直すと何が壊れるのか、手がかりはほとんど残っていません。 一年前の自分は、ほとんど他人です。当時は頭の中にあった前提や、あとで直そうと思っていた箇所の記憶は、時間とともに消えます。コードには「何をしているか」は残りますが、「なぜそうしたか」と「どこを触ると危ないか」は残りません。そこでこの記事では、作品の公開時に一年後の自分へ宛てた手紙、つまり更新メモを書くことを考えます。何を書けば、未来の自分が最短で作業に戻れるのかを、具体的に絞っていきます。
一年後の自分が最初に困ること
更新作業の最初の三十分で、人は主に三つのことで止まります。
- どこから手をつけるか分からない：入口のファイルも、全体の構造も思い出せません。
- どこまで触ってよいか分からない：動いている部分を壊すのが怖くなり、手が止まります。
- 何を直したかったのか分からない：公開時に「次はこうしたい」と思っていたはずの内容が消えています。
つまり更新メモの役目は、作品の説明書を書くことではありません。再開の最初の三十分を軽くすることです。完成した作品を紹介する文章とは目的が違います。紹介文は遊ぶ人に向けて書き、更新メモは未来の作り手に向けて書きます。両方を混ぜると、どちらも中途半端になります。
読み手を一年後の自分に絞ると、書く内容の優先順位も決まります。自分が当たり前に知っていること、たとえばゲームのルールは短く済ませます。逆に、あとから思い出せなくなるもの、つまり判断の理由、危険な場所、約束事を厚く書きます。
手紙に書く五つのこと
更新メモは、次の五項目で足ります。ファイルを一つ作って、公開のたびに書き足します。
- 1. この作品で決めたこと、決めなかったこと：たとえば「難易度は三段階にした。ステージ追加は見送った」のように書きます。見送った理由まで一行添えると、あとで同じ検討をやり直さずに済みます。
- 2. 入口と構造の地図：どのファイルから読み始めればよいか、画面遷移はどこで管理しているかを数行で書きます。コード全体の解説は不要で、地図だけで十分です。
- 3. 触ると壊れやすい場所：判定の計算、乱数の扱い、保存データの読み書きなどです。「ここは直さず、呼び出し側で調整する」といった暗黙の約束も、この項目に残します。
- 4. 保存データの形式：保存するキー名、中身の構造、形式の版番号を書きます。次の節で詳しく扱います。
- 5. 次にやりたい一手：大きな計画ではなく、最初に着手する小さな一歩を一つだけ書きます。「操作説明の文言を直す」程度で構いません。再開の最初の一歩が決まっているだけで、作業に戻る心理的な負担は大きく下がります。
書くときの注意は、日付を入れることです。「現在は」「最近」と書くと、一年後には意味が分かりません。「公開時点では」と書くか、年月を添えます。また、外部の素材やツールを使った場合は、名前と入手元を書き残します。再利用の条件を確かめ直すときに、出発点になります。
場面で考える：保存形式の変更
保存データの形式は、更新で最も事故が起きやすい場所です。次のような場面を考えてみます。
あるパズルゲームが、プレイヤーの進行を「クリアしたステージ番号の配列」で保存していたとします。一年後、ステージごとの最少手数も記録したくなり、保存の構造を変えることにしました。何も考えずに形式を変えると、以前の形式で保存したプレイヤーのデータが、新しいコードでは読めなくなります。進行が消えたように見えれば、遊んでくれた人の信頼を損ないます。
これを防ぐ定番の方法は、保存データに版番号を持たせることです。
- 保存データにversionという項目を入れ、初版は1とします。
- 形式を変えるときは版を上げ、読み込み時に「古い版を見つけたら新しい形式に変換する」処理を一か所にまとめます。
- 変換の内容を更新メモに残します。「版1は配列、版2は項目ごとの辞書。版1の配列は、各要素を『クリア済み、最少手数なし』として変換」のような書き方です。
メモに書くのは、版ごとの違いと、変換で何を補ったか（補えなかったか）です。これがないと、一年後の自分は、古い形式のデータが世の中に残っていることすら忘れます。
アソバースで作品を公開するなら、もう一点注意があります。アップロードした作品の中でのlocalStorageとsessionStorageは、一時メモリー的な互換処理として扱われます。長く残したい進行は、SDKが提供するクラウドセーブ（作品ごとにJSON形式で128KiBまで）に頼る設計になります。URL投稿の作品では、作者がSDKを読み込んだときに使えます。メモには「どの保存先に何を置いているか」と「データの大きさの見込み」を書いておくと、上限に近づいたときの判断が速くなります。また、Firebaseのユーザー識別子や認証トークン、メールアドレスは、ゲームに渡してはいけません。作品側で独自に個人情報を扱う設計にしないことも、メモの「触ってはいけない場所」に入れておく価値があります。
公式作品の保存から読み取れること
アソバースの公式作品の確認済み事項からは、保存形式が後から変わりうるものとして扱われていることが読み取れます。
13本の公式作品のうち、保存があるのは「余白の庭」「WAVE / WAVE」「かたちのあいだ」の3作品です。他の10作品の記録や録音は、画面を開いている間だけ残ります。そして、古い保存（version1）は新しい形式（version2）へ移行する、と案内されています。
ここから言えるのは、設計から読み取れる範囲では、保存には版があり、版が上がっても以前のデータを引き継ぐ経路が用意されている、ということです。なぜその形式にしたのか、何が変わったのかといった内部の経緯は、確認済み事項にはありません。移行の細かい挙動や、保存の中身がどうなっているかは、作品を開いて実際に確かめる部分です。
学べることは、「保存する作品」と「保存しない作品」を最初に分けて決めることです。13作品のうち10作品は、あえて画面を開いている間だけの記録に絞っています。保存しなければ、形式の移行という負担そのものが発生しません。更新メモの項目4に「この作品は保存しない」と書くことも、立派な設計判断の記録になります。
アソバースでの更新に結びつける
手紙を書くタイミングは、公開の直前がおすすめです。アソバースの投稿は、入力、表示の確認、公開の3段階で進みます。表示の確認で動作を見たあと、公開ボタンを押す前に、メモを書き終える流れにしておきます。下書き保存もできるので、公開を急がずに、メモとセットで仕上げられます。
公開後に内容を直すときは、公開内容の更新ができます。更新前に、メモの項目3と項目4を読み返します。壊れやすい場所を触るのか、保存形式を変えるのか。どちらでもなければ、そのまま進めます。どちらかに当たるなら、変更前に影響範囲を一度書き出してからにします。
作品を一時的に直したいときは、非公開にする選択肢もあります。アップロードの上限（1ファイル30MiB、ZIP展開後は合計100MiB・1,000ファイル、アップロード全体で20MiB以内など）に近い作品は、素材を差し替えるとき、サイズの記録がメモにあるかどうかで判断の速さが変わります。サーバー用コードやサービスワーカーが対象外であることも、メモの「やらないこと」に入れておくと、更新時に余計な検討をせずに済みます。
メモが役に立つかどうかを確かめる簡単な方法があります。手紙だけを手元に置き、作品のフォルダを開いて、時間を区切って作業を再開してみるのです。たとえば次の手順です。
- 公開から数週間たった日に、メモ以外を見ずに作品のフォルダを開きます。
- 15分の間に、項目5の「次の一手」に着手できるかを試します。
- 迷った箇所、メモになくて困った情報を、そのまま更新メモの末尾に追記します。
結果は、人によって、作品によって変わります。この確認で出た「困った」の一覧が、そのままメモの改善点になります。一回で完璧な手紙は書けないので、更新のたびに育てる前提で構いません。
次の行動
今ある作品を一つ選び、五項目のうち「保存データの形式」と「次にやりたい一手」だけを、今日のうちに書いてみます。ほかの項目は、更新のたびに足せば十分です。書き終えたら、数週間後の日付をカレンダーに入れ、手紙だけを頼りに作品を開き直してみます。
