作り直すか、直し続けるか：作品の寿命の判断

「作り直したい」を三つに分ける

作り直したい理由は、おおまかに次の三つに分けられます。

1. 見た目や書き心地への不満：コードが読みにくい、命名が揃っていない、画面が地味。遊ぶ人の体験はほぼ変わらないものです。
2. 遊びの核への不満：何度も遊びたくなる理由そのものが弱い。調整を重ねても手応えが変わりません。
3. 足場への不満：当初の構造では、やりたい変更が入らない。ステージ追加のたびに複数の場所を書き換える、描画とルールが絡み合っている、といった状態です。

最も危ないのは1を3と取り違えることです。読みにくいコードは、整理すれば済む場合が多く、整理は全面的な作り直しより小さな作業です。逆に、2を直すために1のような整理を続けても、遊びの手応えは変わりません。

作り直しが本当に必要になりやすいのは、2と3が重なったときです。ただし、2が理由なら、書き直す対象はコードではなく遊びのルールかもしれません。コードを一から書く前に、紙やメモ上でルールだけを書き換えて、今の作品に差し込めないか考えてみてください。

判断の物差しになる四つの問い

作り直すか直し続けるかは、次の四つの問いに答えると見えやすくなります。

問い1：核は生きているか

最初のうちに遊んだ人が「もう一回」と戻る場面があるか、自分でも遊びたくなる瞬間があるかを思い返します。核が生きている作品は、直し続ける価値があります。外側の不満をすべて消しても核が弱いままなら、作り直すのは外側ではなく核です。

アソバースにはレビュー（1〜5点・1〜2,000文字）や、いいねと連動する「好きな作品」があります。これらは核の手応えを知る手がかりになります。ただし数が少ないうちは偏りやすいので、断定の材料にはしないでください。また、プレイ回数は作品の起動の実測回数で、人数ではありません。同じ端末・同じ作品の30分以内の再起動は重複が除かれますが、それでも「数が多いから核が生きている」とは言えません。

問い2：直したい箇所は一点に集まっているか

不満のメモを並べて、どのあたりに集中しているかを見ます。入力処理、ステージ読み込み、スコア計算など、一つの部品に集まっているなら、その部品だけを作り直せば足ります。メモが全体に散らばっていて、どれも「構造のせい」と書けてしまうなら、全面的な作り直しが視野に入ります。

問い3：一つ直すと、ほかが壊れるか

修正のたびに別の場所が壊れるなら、部品どうしが絡み合っています。直す作業のたびに確認の範囲が広がり、小さな修正でも重い作業になります。これが続くなら、構造に手を入れる時期です。

問い4：保存した進行と、すでに遊んだ人はどうなるか

作り直しで保存形式が変わると、既存の進行が読めなくなります。これは見落としやすい点です。アソバースのクラウドセーブは作品ごとにJSONで128KiBまでです。ゲストの進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。保存を持つ作品なら、「古い形式を読んで新しい形式に変える手順」を最初から計画に入れてください。

公式作品13本のうち保存があるのは3本で、古い保存（version1）を新しい形式（version2）へ移行する扱いが共通で示されています。ここから読み取れるのは、保存データに形式の番号を持たせておくと、あとで形式を変えるときの入口になる、という設計の考え方です。細かい移行の中身は、作品を開いて確かめてください。

四つの問いの読み方

• 核は生きていて、不満は一点に集まる、傾向：その部品だけ作り直す
• 核は生きていて、不満が散らばり、修正の副作用も多い、傾向：構造を段階的に入れ替える
• 核が弱く、コードは問題ない、傾向：遊びのルールを作り直す（コードは再利用）
• 核が弱く、構造も絡み合っている、傾向：全面的な作り直しを検討する

この表は目安です。表の通りに動くより、どの行に近いかを、次に述べる記録で確かめてください。

修正ログで「直し続けた場合」を見積もる

感覚で判断すると、作り直したい日は「全部が悪く」見え、調子のよい日は「まだ直せる」と思えます。そこで、2週間ほど修正の記録をとり、感覚を数字に置き換えます。結果はこの記事では書きません。自分の作品で記録して初めて読めるものです。

準備と記録の取り方

テキストかスプレッドシートに、修正を一つ行うたびに1行追加します。列は次の通りです。

• 日付
• 何を直したか（一文）
• 原因はどこにあったか（部品名やファイル名）
• 触った場所の数（関数・ファイル）
• 直したあとに別の不具合が出たか（はい／いいえ）
• 所要時間（目安でかまいません）

記録は「直した単位」で行います。まとめて一行にせず、一つ直すごとに書いてください。期間は2週間ほど、修正の件数が少なすぎるなら延ばします。

結果の読み方

記録がたまったら、次の三つを見ます。

• 原因の場所に偏りがあるか：同じ部品が何度も原因に出るなら、その部品が悪さをしています。部分的な作り直しの候補です。
• 副作用の割合：修正の何割で別の不具合が出たかを数えます。たとえば半分近くに達しているなら、構造の問題が疑われます。この割合に決まった境目はなく、作品の規模によって変わります。前半と後半で割合が増えているかどうかのほうが、手がかりとして役に立ちます。
• 修正の傾向：後半になっても、新しい修正が出続けているか、減っているか。減っているなら、直し続ける道は開けています。減らないなら、土台に問題があります。

誤りやすいのは、記録を取るのが億劫で、目立つ失敗だけを書いてしまうことです。地味な修正こそ書いてください。また、2週間のうちに大きな機能追加を混ぜると、修正と追加の区別がつかなくなります。記録中は追加を控えると読みやすくなります。

全面ではなく「部分の作り直し」という中間

多くの場合、現実的なのは、全面でも放置でもなく中間の選択です。原因が集まる部品だけを新しく作り、ほかには手をつけない方法です。

境目を作るとき、役に立つ切り分けがあります。

• ルールの判定と、画面への描画を分ける：判定は入力と状態だけを受け取る関数にして、描画は状態を表示するだけにします。こうすると、見た目を変えてもルールが壊れにくくなります。
• 保存データに形式の番号を持たせる：先述の通り、あとの移行の入口になります。
• 設定値は一か所にまとめる：難易度や制限時間を調整する作業が、一つの場所で済みます。

公式作品の設計から読み取れることとして、13作品が独立したHTMLで外部通信なしに動く構成にそろっている点があります。外に依存しない一つの塊として作ると、部分を入れ替えても影響が外に漏れにくい、という利点がありますが、各作品の内部の分け方は作品を開いて確かめてください。

部分的な作り直しは、次の点で失敗しやすくなります。

• 作り直す部品を「ついでに」広げてしまい、実質的に全面の作り直しになる。
• 新しい部品に、これまで我慢していた機能をすべて詰め込み、かえって複雑になる。
• 古い部品との接続部分に、場当たり的な変換コードが増える。

範囲は最初に紙に書き、「この部品の外には触らない」と決めてから始めてください。

作り直しを決めたあとの公開の扱い

全面的な作り直しを選ぶなら、公開済みの作品をどう扱うかも決めておきます。アソバースでは、作品の下書き保存、公開内容の更新、非公開化、削除ができます。選択肢は次の三つです。

1. 同じ作品を更新する：すでに遊んでいる人は、そのまま新しい版を遊べます。ただし、更新後の既存セーブやプレイ履歴、レビューの扱いは、現在の案内で確認してください。
2. 新しい作品として出し、旧版は残す：旧版の遊び心地を好む人が残る場合に向きます。名前や紹介文で違いを説明しておくと混乱が減ります。
3. 旧版を非公開にして新版を出す：旧版に深刻な不具合があるときに考えます。

どれを選ぶにしても、アップロードの制限（20MiB以内、ZIP展開後は合計100MiB・1,000ファイル以内、1ファイル30MiB以内、直下のindex.html）は同じです。1人あたりUTCで1日10回までという回数の制限もあるので、公開前の確認は下書きの段階で済ませ、更新の回数を無駄にしないようにしてください。

作り直しの途中で、旧版に小さな不具合を直す必要が出ることもあります。その場合に備え、旧版のファイル一式をそのまま別の場所に保管しておきます。

次の行動

まず、手元の不満メモを「見た目」「核」「足場」の三つに色分けしてください。そのうえで、今日から2週間、修正を一つ直すたびに1行ずつ記録します。記録が終わったら、原因の偏りと副作用の割合を表と照らし合わせ、部分的に作り直すのか、全面か、直し続けるのかを決めてください。決める前に、保存データを持つ作品なら、古い形式を新しい形式に移す手順だけは先に書き出しておくことをおすすめします。