仮の名前のまま公開すると、後から何が直せなくなるか：改名コストを測る実験設計

実験の問いと準備

問いは次の二つです。

1. 仮題はあなたの作品の中に何か所あり、直すのに何分かかるか。
2. 公開後には、自分では直せない場所がいくつ生まれうるか。

準備するものは次のとおりです。

• 完成間近、または完成済みの自作ゲーム1本（既存の作品で構いません）
• 仮題として使う文字列を1つ（例：test_final2）
• 時間を測るストップウォッチ
• 後述の記録表を書くメモ

仮題は、ほかの文字列と混ざりにくいものにします。「ゲーム」「パズル」のような一般的な語を仮題にすると、検索で無関係な箇所まで拾ってしまい、数が膨らみます。

手順：三つの工程

工程A：仮題の出現箇所を洗い出す

作品のファイル全体から、仮題を検索します。エディタの全文検索が使えるなら、それが最も確実です。HTML単体で済ませたい場合は、次の最小構成のページが使えます。ソースを貼り付けて仮題を入れると、含まれる行を一覧にします。

<!doctype html>
<meta charset="utf-8">
<title>仮題カウンター</title>
<input id="k" value="test_final2">
<textarea id="s" rows="10" cols="60"></textarea>
<button id="b">数える</button>
<pre id="o"></pre>
<script>
document.getElementById('b').onclick = () => {
  const key = document.getElementById('k').value;
  const hit = [];
  document.getElementById('s').value.split('\n').forEach((line, i) => {
    if (key && line.includes(key)) hit.push((i + 1) + '行目: ' + line.trim());
  });
  document.getElementById('o').textContent =
    '出現行数: ' + hit.length + '\n' + hit.join('\n');
};
</script>

ファイルが複数あるときは、ファイルごとに貼って数えます。ZIPで投稿する作品なら、中のファイル名とフォルダ名も確認します。ソースの中身だけでなく、名前そのものも仮題になりがちだからです。

工程B：改名を実際にやって時間を測る

仮題を新しい名前に差し替える作業を、本番と同じつもりで行います。ストップウォッチを動かし、検索で見つけた箇所を順に直し、動作確認が終わるまでの時間を記録します。このとき、直した箇所の数と、直し忘れが後から見つかった回数も数えます。

次に、名前を一か所にまとめた構成へ作り替え、もう一度改名します。まとめ方の最小例は次のとおりです。

<!doctype html>
<meta charset="utf-8">
<title>仮の名前</title>
<h1 id="t"></h1>
<script>
const GAME = { name: '仮の名前', saveKey: 'game-save', version: 2 };
document.title = GAME.name;
document.getElementById('t').textContent = GAME.name;
const raw = localStorage.getItem(GAME.saveKey);
const data = raw ? JSON.parse(raw) : { version: GAME.version, best: 0 };
localStorage.setItem(GAME.saveKey, JSON.stringify(data));
</script>

ポイントは二つあります。表示用の名前（name）と、保存データを識別するキー（saveKey）を別の項目にしていることです。キーに作品名を使わなければ、改名してもキーは変わりません。保存データにversionを持たせておくと、将来の形式変更にも備えられます。

なお、アップロードした作品内のlocalStorageは一時メモリーとして扱われる互換処理です。恒久的な保存の場所と考えず、ここでは構成の例として読んでください。<title>をスクリプトで入れる書き方では、スクリプトを実行しない読み手には空に見えることがあります。静的に読まれたい場合は、HTMLに直接書く構成のほうが向きます。

改名の時間は、一元化の前後で比べます。同じ作品を同じ手順で2回測るので、2回目は手順に慣れて速くなりやすい点に注意が必要です。この影響を減らすには、工程Bの前後で別の新名称を使い、作業の順序（検索→修正→確認）を固定します。

工程C：公開フローで名前が出る場所を見る

アソバースの投稿画面で、作品名と紹介文を入力し、「表示の確認」の段階まで進みます。ここでは公開せず、下書き保存で止めます。確認する点は次のとおりです。

• 作品名の欄に入力した文字は、確認画面のどこに現れるか
• 作品を開いたとき、作品自身の画面（見出しやタブ）に仮題が見えていないか
• 「紹介文と遊び方を作成」を使った場合、下書きに仮題が混じっていないか。反映されるのは「この文章を使う」を押したときだけなので、押す前に読み直します。

最後に、公開後に作品名を変えられるか、変えたとき履歴やいいねの紐づきがどうなるかを、現在の案内で確認します。確認済みの範囲では、公開内容の更新、非公開化、削除ができます。ただし名前の変更がどこまで反映されるかは、ここでは断定できません。

記録の取り方

洗い出した箇所は、次の表に1行ずつ書きます。数えるのは「場所」の単位です。同じファイルに5回出ていても、役割が同じなら1行にまとめ、回数を備考に書きます。

• 画面の見出し、種類：自分で直せる、直す手間（分）：、直したか：
• ブラウザのタブ名、種類：自分で直せる、直す手間（分）：、直したか：
• 保存データのキー、種類：直すと進行に影響、直す手間（分）：、直したか：
• ZIP／ファイル名、種類：自分で直せる、直す手間（分）：、直したか：
• 友達に送った文面、種類：他人の手元に残る、直す手間（分）：、直したか：
• 共有済みのURL、種類：他人の手元に残る、直す手間（分）：、直したか：
• 作品名（公開後）、種類：現在の案内で確認、直す手間（分）：、直したか：

種類は次の4つに分けます。

• 自分で直せる：自分のファイルや入力欄にあり、修正すれば済むもの
• 直すと進行に影響：保存データなど、書き換えると遊ぶ人の記録が読めなくなる可能性があるもの
• 他人の手元に残る：公開後に、あなたの手の届かない場所へ複製される文字列
• 現在の案内で確認：プラットフォームの仕様に依存し、この記事では断定できないもの

測定は、工程Bの2回を最低限とします。時間は「分」単位で十分です。細かい秒数よりも、どの行に時間がかかったかが分かることが目的です。

結果の読み方と起こりやすい誤り

表が埋まったら、種類ごとに行数を数えます。読み方の目安は次のとおりです。

• 「自分で直せる」だけで大半が占められ、一元化後の改名が速い：仮題での公開はやり直しやすい状態です。ただし、公開前に名前を決める手間のほうが小さいかもしれません。
• 「直すと進行に影響」が1行でもある：名前に依存したキーは、公開前に切り離しておく価値があります。
• 「他人の手元に残る」が多い：共有を始める前に名前を決めるほうが安全です。レビューの本文やSNSの投稿は、作者が書き換えられない場所に旧名を残しえます。レビューは本人が編集・削除する仕組みなので、作者の側では直せません。
• 「現在の案内で確認」の行が残っている：確認が済むまで、仮題での公開は避けるのが無難です。

この実験で起こりやすい誤りは三つあります。

一つ目は、見た目だけを直して終わることです。タブ名と見出しを新名称にしても、保存キーに旧名が残っていると、気づかないまま内部に仮題が残ります。逆に、キーまで変えてしまうと、すでに遊んだ人の記録が読めなくなります。キーを変えるなら、旧キーを読んで新キーへ移す処理を書き、移行後は旧キーを消すかどうかを決めておきます。公式作品にも、古い保存（version1）を新しい形式（version2）へ移す仕組みがあります。保存形式に版を持たせておく考え方は、改名にも使えます。

二つ目は、検索語が弱すぎて取りこぼすことです。「game」のような語を仮題にすると、ほかの語に埋もれます。大文字小文字の違いや、全角・半角の違いも見落としの原因です。検索は表記ゆれを分けて、2〜3通り試します。

三つ目は、一元化の効果を時間だけで判断することです。2回目が速かったのは、構成のおかげか、慣れのおかげかを分けられません。時間とあわせて、直し忘れの回数も比べてください。時間が同じでも、直し忘れが減っていれば、一元化には意味があります。

次の行動

まず、手元の作品で仮題を検索し、場所の一覧を作ってみてください。次に、保存キーと表示名を分ける構成に直し、改名を2回測ります。最後に、投稿画面で下書きを保存し、名前が現れる場所と公開後の変更範囲を現在の案内で確かめてから、公開するかどうかを決めましょう。