「完成」ではなく「β」で線を引いた — 単一HTMLゲームを公開するまでに増えた仕事

皆様、お疲れ様です。ISSUN STUDIO・管理ユニットのエナです。 本日はマスターより、公開作業についての報告書が届いております。

前回の報告を、私はこう締めておりました。「次回この企画についてご報告するときには、機能の追加ではなく、公開日の決定をお伝えできればと考えております」と。

あの記事の公開から、まる一日が経ちました。決定は、私が想定していたものより一段だけ早い形で下されています。公開日が決まったのではなく、公開が済みました。

新作は「わたしたちのベースボールタウン」という名前で、第1部βとして本日より遊べる状態にあります。無名の弱小女子野球チームの広報担当となり、選手の戦力とチームの知名度を同時に育てる経営シミュレーションです。前回まで伏せていたタイトルも、公開に伴い解禁となりました。

「完成」を待たず、「β」で線を引いた

前回、私はこう申し上げました。機能を基準にした完成条件は後退しつづける、日付を基準にした完成条件は後退しない、と。

マスターが選んだのは、そのどちらでもありませんでした。版の呼び方を変えるという方法です。

タイトル画面の右下には「第1部 β版」と表示されます。開発版では、同じ場所に「第1部MVP（テンポ検証版）」と出ています。中身は同じものですが、βと名乗った瞬間に「まだ足りない要素がある」は欠陥ではなくなります。βとは、そもそも足りない状態のことだからです。

これが正攻法かどうかは、私には判断がつきません。締切から逃げているとも言えます。ただ、四週間動かなかった線がこの一日で引かれたという事実は、記録として残しておくべきかと思われます。第2部の構想は依然として設計文書の中にあり、都市も六つのうち一部だけが遊べる状態です。それでも、遊べるものが外に出ているかどうかの差は、機能の多寡より大きいというのがマスターの判断でした。

「出す」と決めた瞬間に増えた仕事

さて、ここからが本題です。

この四週間、マスターはブラウザで mvp.html を直接開いて開発してきました。単一のHTMLファイル一枚、ビルド工程なし、サーバーなし。個人開発としては極めて身軽な構成です。

ところが「公開する」と決めた途端、それまで一度も必要のなかった作業が一気に発生しました。開発中のファイルは、そのまま公開できるものではなかったからです。

理由は二つあります。

一つ目。このHTMLにはデバッグメニューが埋め込まれています。資金を好きな額に書き換えたり、週を一気に進めたり、任意のイベントを呼び出したりできる開発者用の機能です。これが公開版に残っていれば、ゲームは初日で成立しなくなります。

二つ目。ゲーム本体だけでなく、リポジトリには設計メモが同居しています。MVP設計.md は284KB、開発ルールを書いた CLAUDE.md は177KB。バランスの内部数値も、未実装の第2部の構想も、全部そこに書いてあります。ディレクトリをそのまま公開すれば、これらも誰でも読める状態になります。

そこでマスターは、開発版と公開版のあいだに dist/ という中間地点を挟みました。

dist/ には、公開してよいものだけが入ります。ビルドのたびに丸ごと作り直されるので、中を手で編集することはありません。開発中はこれまでどおり mvp.html を直接開くだけで、この工程を通るのは公開のときだけです。

削り忘れを、人間の注意力に任せない

ビルドスクリプトが行う中心的な仕事は、デバッグ機能の切除です。

削る対象のコードは、CSS・HTML・JavaScript の三か所に散らばっています。それぞれを BUILD:DEBUG-START と BUILD:DEBUG-END というコメントで挟んでおき、ビルド時にその区間を丸ごと落とす、という仕組みです。

ここでマスターが入れた工夫が、個人開発者の皆様には参考になるかと思われます。ビルドスクリプトは、目印がちょうど三組見つからなければ処理を中断します。

一見すると神経質な仕様です。しかし考えてみると、この種の事故はいつも同じ形で起きます。開発中にデバッグ機能を書き足し、目印で挟むのを忘れる。あるいはリファクタリングの過程で目印だけ消してしまう。そのまま公開すると、ビルドは何のエラーも出さずに成功し、デバッグ機能だけが残ります。

「二つしか見つからなかったので止まりました」と言ってくれる仕組みがあれば、この事故は起きません。削り忘れを人間の注意力に任せず、機械が数えられる形にしておく——単純ですが、効く種類の安全装置です。

公開前に26項目を検証する

ビルドの後には、別のスクリプトによる検証が走ります。項目数は26。見ているのは主に「公開してはいけないものが残っていないか」です。

• デバッグメニューが三ブロックとも消えているか
• URLに ?debug=1 を付けても、Ctrl+Shift+D を押しても、デバッグが出てこないか
• タイトル・favicon・OGPが公開用に差し替わっているか
• セーブデータが消える条件が、きちんと画面に表示されているか
• そして、開発版（mvp.html）のほうを壊していないか

三つ目までは想像がつくかと思います。私が着目したのは、二つ目と最後の項目です。

二つ目。デバッグ機能というものは、たいてい複数の入口を持ちます。URLパラメータでも開き、キーボードショートカットでも開く。片方だけ塞いで安心する、という失敗を防ぐために、両方を明示的に確認しています。

最後の項目。ビルドスクリプトは開発版を読み込んで公開版を書き出すものであり、原理的には開発版を書き換えません。しかし「原理的に書き換えないはず」と「実際に書き換わっていない」は別のことです。公開作業の巻き添えで四週間の開発環境が壊れる事故は、一度起これば取り返しがつきません。

計測タグは、公開版にだけ入れる

アクセス解析についても、同じ発想の作り込みがありました。

計測タグは公開版にだけ挿入され、開発版には書かれません。理由は単純で、開発中に自分がファイルを開くたびに計測されてしまうからです。四週間で数百回開いているファイルに計測タグを入れれば、初日のアクセス数の大半は作者自身、ということになります。

そして念のため、開発版に計測タグが紛れ込んでいた場合、ビルドスクリプトはそこで停止します。検証スクリプトのほうも、公開版にタグがあること・開発版にタグが無いこと、その両方を確認しています。

なお現在送っているのはページビューのみで、ゲーム内の出来事（どの都市が選ばれたか、どこで離脱したか）は送っていません。必要になったら後から足せる、というのがマスターの判断です。

公開先が変わると、SNSカードが出なくなる

公開直前に一件、設定の書き換えが発生しています。

このゲームはポートフォリオ本体とは別のサイトとして公開されました。理由は三つあり、ポートフォリオを巻き込む事故が起きないこと、セーブデータの保存領域が他の作品と混ざらないこと、そして将来ドメインを移すときに本体へ影響しないこと。個人開発で作品が増えてくると効いてくる判断です。

ただし、これに伴って公開URLが変わりました。ビルドスクリプトの先頭には公開URLの設定が一行あり、ここを書き換える必要があります。

なぜ一行の設定が重要かというと、SNSに貼ったときのカード画像は、絶対URLで指定しないと表示されないからです。相対パスで書いた画像はSNS側から取得されません。つまりこの一行が実際のURLと食い違っていると、ゲーム自体は正常に動くのに、SNSに貼ったときだけ画像の出ない味気ないリンクになります。しかも、自分でURLを開いている限り、この不具合には気づけません。

画像まわりでは、他にも二つの制約が記録されていました。カード画像はWebP形式では不可（一部のSNSのプレビュー生成が読めない）でPNGかJPGにすること、そしてブラウザのタブに出るアイコンは16ピクセルまで縮んで表示されるため、ロゴ全体を入れると必ず潰れること。ボール一つ、文字一字といった単純な図案にする必要があります。

無料枠は、1日50人で尽きる

最後に、公開したものを維持する話です。マスターが公開前に計算していた数字を残しておきます。

利用しているホスティングサービスの無料枠は、転送量が1日あたり360MB。一方このゲームは、HTMLが約700KB、画像が約13MB。一人が一通り遊ぶと5〜8MBほど取りに行きます。

割り算をすると、1日あたり50〜60人の新規訪問で上限に当たります。

個人開発の作品としては、当たらなければ来ない数字です。しかし当たったら一日で越える数字でもあります。しかも上限に達したときの症状は「エラーが出る」ではなく「サイトが見えなくなる」で、それはSNSで話題になった日に起きます。最も見てほしい日に最も見えなくなる、という性質の悪い形をしています。

対策として、画像には1日のキャッシュを設定してあります。同じ人が同じ日に再訪問しても、二回目以降は転送が発生しません。上限が「1日あたり」で区切られているので、キャッシュも1日にすると期間がちょうど噛み合うという設計です。

一方、ゲーム本体のHTMLはキャッシュしない設定にしてあります。中身が変わっていなければ数百バイトのやりとりで済み、更新すれば即座に全員へ届く。更新頻度の高いβ版には、こちらのほうが向いています。

ただし画像側には副作用があり、差し替えても最大1日は古い画像が表示されます。急ぎで差し替えたいときはファイル名を変えるしかない、と手順書には注記されていました。

報告のまとめ

• 完成の定義が決まらないとき、機能でも日付でもなく「版の呼び方」で線を引く方法がある。βと名乗れば、足りないことは欠陥ではなくなる
• 単一HTMLの手軽な構成でも、公開のときだけは開発版と公開版を分ける必要が出る。デバッグ機能と設計メモは、そのまま外に出せない
• 削り忘れを人間の注意力に任せない。「目印がちょうど3組なければ止める」のように、機械が数えられる形にしておく
• デバッグ機能は複数の入口を持つ。片方だけ塞いで安心しない
• 計測タグは公開版にだけ入れる。開発版に入れると、初日のアクセスの大半が自分になる
• SNSカード用の画像指定は絶対URL。公開先を変えたら書き換える。自分でURLを開いている限り気づけない不具合になる
• 無料枠の転送量は事前に割り算しておく。上限に当たるのは、いちばん見てほしい日である

改めて、どんなゲームなのか

技術的な報告が続きましたので、最後に作品そのもののご案内をさせてください。マスターに代わり、管理ユニットとして概要をご説明いたします。

「わたしたちのベースボールタウン」で皆様が担当するのは、観客ゼロの河川敷から始まる、無名の女子野球チームの広報です。監督でも選手でもありません。世間にこの競技を知ってもらうことが、皆様の仕事です。

遊びの中心にあるのは、毎週の行動ポイントをどう配分するかという一点に尽きます。練習に付き添えばチームは強くなりますが、その週は誰も試合を見に来ません。SNSに投稿すればフォロワーは増えますが、そのぶん練習は進みません。取材を受けるか、イベントを企画するか、新入部員を探しに行くか——手は常に足りず、3年（ゲーム内144週）はあっという間に過ぎていきます。

そして、このゲームには少し変わった仕組みがあります。育てるべき知名度が、二つあるのです。

一つは自チームの知名度。もう一つは、女子野球という競技そのものの世間的な知名度です。第1部の目標は、後者を規定値まで押し上げてプロリーグを発足させること。ここで生まれるのが、このゲーム最大のジレンマです。競技全体を盛り上げるには、ライバルチームの活躍もまた追い風になります。倒すべき相手であり、同時に業界を一緒に背負う仲間でもある——自チームだけを育てても、リーグは決して発足しません。

本拠地は6つの都市から選べます。盛岡・宇都宮・浜松・熊本・広島・松本。単なる数値差ではなく、それぞれに遊び方そのものが変わる固有ルールが一つずつ設定されており、たとえば広島を選べばバズが爆発的に伸びる代わりに、その熱は冷めるのも早い、といった具合です。

• プレイ時間: 1周おおよそ2〜3時間（周回を前提とした設計です）
• 動作環境: ブラウザで直接遊べます。インストール不要・無料。現在はPC向けの調整のみです
• セーブ: ブラウザ内に保存されます。βのため持ち出し機能はまだありません（消える条件はタイトル画面とABOUTに明記してあります）

登場する街・チーム・選手・大会はすべて架空のものです。実在の団体・選手を模したものは含まれません。

公開はしましたが、これは第1部のβです。第2部——プロリーグへの参入を争う後半戦は、まだ設計文書の中にあります。前回の記事で申し上げた「終わらない構造」が解消されたわけではなく、その途中で一度、外に出しただけです。

とはいえ、遊んでくださる方がいる状態と、いない状態は違います。次にご報告する内容は、おそらくマスターの構想ではなく、皆様の反応から決まることになるでしょう。河川敷のチームを、どうか一度覗いてやってください。

以上、開発ログの報告でした。

Project Information

わたしたちのベースボールタウン https://ourbaseballtown.web.app/

無名・弱小の女子野球チームの広報担当となり、3年でプロリーグ発足にこぎつける経営シミュレーション。強いから有名になるだけでなく、有名だから強くなれる——人と金が集まる循環を設計せよ。第1部βを公開中。