育てた作品を人に引き継ぐとしたら
遊びを届ける執筆にClaudeを使用しています。

半年かけて育ててきたブラウザゲームを、別の人に預ける場面を考えてみます。引っ越しや仕事の都合で、続きを作る時間が取れなくなったとします。相手はゲームづくりの経験があり、作品の続きを作りたいと言ってくれています。ファイル一式を渡し、「あとはよろしく」と言えば引き継ぎは終わるでしょうか。 おそらく終わりません。コードは読めば何が書いてあるかが分かります。分からないのは、なぜそう書いたのか、何を試してやめたのか、どこが未完成なのかです。ここが口頭の説明に頼っていると、渡した側が忙しくなった途端に誰も答えられなくなります。 この記事の問いは、引き継ぎに最低限どんな記録が要るかです。結論を先に言うと、記録は4種類に分けると抜けが減ります。構成、判断、保存データ、積み残しです。以下、それぞれ何を書くかと、記録が足りているかを自分で確かめる方法を順に見ていきます。
この記事の目次
コードが語らないことを先に数える
渡す側が「当たり前」と思っていることほど、記録から抜けます。たとえばこんな疑問は、コードを眺めても答えが出ません。
- 敵の速度を、なぜこの数字にしたのか
- 使っていない関数が残っているのは、消し忘れか、後で使う予定か
- 保存データのこの項目は、今も使っているのか
- 難しすぎると感じた箇所は、直す途中なのか、意図した難しさなのか
どれも「理由」と「状態」の話です。コードが示すのは現在の姿だけで、そこに至る経緯と今後の見通しは書かれていません。
記録を4種類に分けるのは、この抜けを防ぐためです。
- 構成、答える問い:何がどこにあるか、書く場所の例:ファイル一覧、入口、素材の置き場
- 判断、答える問い:なぜそうしたか、書く場所の例:判断メモ(日付つき)
- 保存データ、答える問い:何を残していて、どう変わってきたか、書く場所の例:形式の説明と変更履歴
- 積み残し、答える問い:何が未完で、次に何をするか、書く場所の例:未着手・保留の一覧
4種類とも、長文である必要はありません。1項目につき数行で足ります。大切なのは、渡す前に一度書き出して、空欄がどこかを知ることです。
構成の記録:入口と置き場所を一枚にする
アソバースにゲームを投稿する場合、構成の前提はある程度決まっています。HTMLまたはZIPをアップロードする形式では、直下のindex.htmlが入口で、素材は相対パスで参照します。サーバー用のコードやサービスワーカー、SharedArrayBufferを使うマルチスレッドは対象外です。サイズにも上限があり、アップロードは20MiB以内、ZIP展開後は合計100MiB・1,000ファイル以内、1ファイル30MiB以内です。
引き継ぎの構成記録には、まずこの前提に照らした現状を書きます。
- 入口のファイルと、そこから読み込んでいるファイルの一覧
- 素材(画像・音)の置き場所と、元データの所在(書き出し前の画像編集ファイルなど)
- 現在のZIPの大きさと、上限までの余裕
- 外部ライブラリを使っているか。使っているなら名前と版
特に見落としやすいのは「元データの所在」です。完成した画像や音だけを渡されても、色を直したいときに元がなければ作り直しになります。元データがどこにあるのかを、一行でも書いておくと引き継ぎ後の作業が変わります。
ライブラリについては、公式作品の一例が参考になります。「灯りのチェス」は判定エンジンとしてchess.jsを同梱している、と案内されています。このように、自作でない部分を何が担っているかが分かる状態が望ましいのです。引き継ぐ側は、そこを自分で書き換えてよいのか、置き換えてよいのかを知りたいはずです。
判断の記録:「しなかったこと」を残す
4種類の中で、最も書かれにくく、最も役に立つのが判断の記録です。ここでは「した判断」より「しなかった判断」を意識して残します。
公式作品の紹介から、設計の読み取り例を一つ挙げます。13作品のうち、保存があるのは「余白の庭」「WAVE / WAVE」「かたちのあいだ」の3作品で、他の10作品の記録や録音は画面を開いている間だけです。設計から読み取れるのは、保存するかしないかは作品ごとに選ばれているということです。庭づくりやリズム制作のように作ったものを後で続けたくなる作品と、一回ごとの遊びで完結する作品とで、扱いを分けているように見えます。なぜその選択になったかの経緯は、作品を開いて確かめるしかありません。
自作に戻して考えてみます。「このゲームはセーブを持たない」という仕様は、コードを見ても「保存処理が無い」としか分かりません。引き継いだ人が善意で保存機能を足し、遊びの緊張感が変わってしまうことも考えられます。そこで判断メモに次のように書きます。
日付:○月○日判断:記録は画面を開いている間だけ保持し、保存しない。理由:一回の挑戦で完結する形にしたかったため。再検討の条件:「続きから遊びたい」という声が複数あれば検討する。
ポイントは「再検討の条件」です。判断を固定するのではなく、どうなったら見直してよいかを書いておくと、引き継ぐ側が動けます。
判断メモに向くのは、次のような項目です。
- 難易度の調整値と、その調整の方針
- ヒントや戻す機能の仕様の境界(たとえば「かたちのあいだ」のヒントは最短手とは限らないと案内されています。こうした境界は仕様として書き残す価値があります)
- 入れなかった機能と、その理由
- 試して外した案
日付をつけておくと、後から読む人は古い判断と新しい判断を見分けられます。
保存データの記録:形は変わるもの
保存を持つ作品では、保存データの記録が引き継ぎの中心になります。遊んだ人の進行が入っているため、読み方を間違えると、その人の記録を壊してしまうからです。
ここでも公式作品の案内が参考になります。13作品共通の案内として、古い保存(version1)は新しい形式(version2)へ移行する、とあります。保存形式には版があり、形式が変わるときに移行の仕組みを用意する、という作り方が読み取れます。この仕組みの中身は、作品を開いて確かめる部分です。
自作でも、保存データには次の項目を記録しておきます。
- 保存している場所(端末内か、クラウドセーブか)
- 項目名と、それぞれの意味・取りうる値
- 形式の版と、版ごとの変更点
- 古い版を読んだときの扱い(捨てるか、変換するか)
- 過去に実際に出した版の一覧
5番目は特に大切です。公開してしまった版の保存データは、遊んだ人の端末に残っています。引き継いだ人が項目名を気軽に変えると、読めなくなる人が出ます。
アソバース側の前提も押さえておきます。アップロードしたゲームにはSDKが自動で追加され、URLで投稿したゲームは作者がSDKを読み込むと、作品専用のプレイヤーIDとクラウドセーブ(作品ごとにJSONで128KiBまで)が使えます。クラウドセーブを使っている作品なら、記録には「JSONの容量がどれくらいか」「上限にどれだけ余裕があるか」も加えておくと、引き継ぐ側が項目を足してよいかを判断できます。
また、ゲームにはFirebaseのUID、認証トークン、メールアドレスを渡さない決まりがあります。引き継ぎの資料の中に、うっかりこうした情報や個人の連絡先が混ざっていないかも、渡す前に確かめておきます。
公開側の記録:作品の所有をどう扱うか
ここまでは作品の中身の話でした。もう一つ、公開している側の事情があります。ここで確認済みの案内から言えることと、言えないことを分けておきます。
アソバースの投稿では、下書き保存、公開内容の更新、非公開化、削除ができます。一方、作品の所有を別のアカウントへ移す機能については、確認済みの案内に記載がありません。そのため、提供されているとは言えず、現在の案内で確認する必要があります。
所有の移し替えができない場合、次のような方法が考えられます。ただし、どれも結果は未確認の前提で読んでください。
- 相手が元のファイルから、自分のアカウントで新しく投稿する
- 元の作品は、状況を見て非公開化する
新しく投稿した場合、プレイ履歴、レビュー、いいねが新しい作品へ引き継がれるのかは、案内で確かめる事項です。別の作品として扱われる可能性を前提に、利用者への告知が要るかも考えておくと安全です。なお、プレイ回数は作品起動の実測回数で、人数ではないため、数字の見せ方も新旧で連続しない可能性があります。
もう一つ、退会の扱いにも注意が要ります。退会すると、アップロードファイル、履歴・セーブを含む個人データ、認証アカウントが削除されます。引き継ぎの前に退会してしまうと、アップロードしたファイルも削除対象になります。元のファイル一式は、手元か相手の側に必ず残してから進めます。
公開側の記録には、次の項目を入れておきます。
- 公開中の作品の名前と、投稿方式(アップロードかURLか)
- 紹介文と遊び方の最新版
- 作者としての約束事(更新の頻度、問い合わせの窓口を公開しているか)
- 公開プロフィールに載せている内容のうち、引き継ぎ後に消すもの
なお、投稿画面の「紹介文と遊び方を作成」は、読み取りから下書きを作る機能で、「この文章を使う」を押したときだけ反映されます。引き継ぎ後に紹介文を作り直すときの出発点として使えますが、内容の確認は人が行います。
引き継ぎ記録が足りているかを確かめる方法
記録を書いたら、足りているかを確かめます。書いた本人は抜けに気づきにくいので、記録だけを頼りにした模擬の引き継ぎを一度行うのが有効です。結果は、各自が自分の作品で得るものです。
準備するもの
- 渡す予定のファイル一式と、4種類の記録
- 作品を知らない人(ゲームづくりの経験がある人が望ましい)。作者本人が「記録を読まない前提」で別の日に読み直す方法でも構いません。
- 記録用のメモ(質問が出た回数と内容を書く)
手順
- 相手に、記録とファイルだけを渡します。口頭の補足はしない約束にします。
- 「ローカルで動かす」「敵の速度を一段階だけ変える」「保存項目を一つ足す」といった小さな課題を、あらかじめ3つほど決めておき、順に頼みます。
- 相手が止まったり、質問したくなったりした箇所を、都度メモします。
- 終わったら、メモを4種類のどれに当てはまるかで分類します。
結果の読み方
- 構成の質問が多いなら、入口や置き場所の説明が足りません。
- 「なぜ」の質問が多いなら、判断メモを増やします。
- 保存の質問が出たなら、項目の意味か版の履歴を厚くします。
- 「次に何をすればよいか」の質問が出たなら、積み残しの一覧を作り直します。
起こりやすい誤りは、課題を簡単にしすぎて、質問が出ないまま「記録は十分」と判断してしまうことです。保存データに触る課題を一つ入れておくと、足りない部分が見えやすくなります。また、質問が出た時点で口頭で答えてしまうと、記録の穴が塞がれずに残ります。答えは必ず記録に書き足します。
次の行動
まず、今育てている作品について、4種類の記録を各5行ずつ書き出し、空欄になった種類を確認してください。次に、作品を知らない人、または数日後の自分に、記録だけを頼りに小さな課題を一つ頼んでみてください。最後に、作品の所有を移す方法や、新規投稿時のレビュー・いいねの扱いは、現在のアソバースの案内で確認してから、引き継ぎの段取りを決めてください。

