ゲームを選ぶと近くの店舗が見つかるようにするには、まず店舗ごとのゲームと位置をそろえる必要がある。検索画面を作っても、比較に使える資料がなければ候補を表示できない。2月から準備したMusecatは、約45店舗の位置、営業時間、ゲーム一覧と修正窓口を用意し、6月17日に韓国でAlphaを公開した。

2023-06-17のAlpha原本コードを合成サンプルデータで再現。公開当時の画面構成でゲーム条件と近くの店舗を確認できる。 韓国語の原画面。当時のAlphaは韓国語のみ対応。

初期データと管理者の入力

Wikiや公式サイトの情報は、同じ形式で並んでいるわけではない。名称と位置、営業時間、設置ゲームを確認し、サービスが読める形へ移す作業が必要だった。

3月には利用者が短い文章で修正を送り、管理者がFirebaseを直接更新していた。内容の解釈とデータ形式の統一を管理者が担う。二人で管理する状況では、同じ内容を同じJSON形式にできる道具も必要になった。

flowchart TD
    accTitle: Alphaのデータ準備
    accDescr: 散在する資料を確認し、サービスで比較できる初期一覧を整える。
    A["Wikiと公開情報の確認"] --> B
    B["位置・営業時間・ゲーム一覧の入力"] --> C
    C["初期店舗一覧"]

管理者用のJSON入力フォーム

JSONは項目名と値を組み合わせてデータを表す形式である。例えば営業時間では、構造から毎回書くより、決まった欄へ値を入れる方が形式をそろえやすい。4月には入力からJSONを作る管理者ページを用意した。

最初のフォームはFirebaseへ直接書かず、JSON生成までとした。直接書き込みの権限に伴うリスクを抑えるためだ。公開準備では内容を確認してFirebaseへ送る機能も設けた。反映する情報は管理者が判断する。

Alphaの管理者用入力フォーム。定義済みの項目から反映用JSONを生成する。 韓国語の原画面。当時のAlphaは韓国語のみ対応。

flowchart TD
    accTitle: 初期管理者JSONフォームの自動化範囲
    accDescr: 4月の初期フォームは入力からJSONを生成し、実際の反映は管理者が担った。
    A["管理者の入力"] --> B
    B["入力構造の確認とJSON生成"] --> C
    C["管理者がFirebaseへ反映"]

修正提供と新規店舗の入力

5月から提供内容に店舗IDを結び付けた。詳細画面からそのIDを持つ提供ページを開く。変更内容は自由文で受け付けるため、どのゲームや筐体についての修正かは説明に書く必要がある。

送信時には店舗ID、文章、送信者の匿名認証UID、受付時刻を保存する。UIDは匿名認証の利用者を識別する値で、対象店舗とともに提供内容へ付ける。受付後の確認と更新は管理者が担当する。

新規店舗の依頼には、ゲームを選び、料金や台数、追加情報を入れるフォームも用意した。訂正と違い、まだ一覧にない場所の資料を集めるためだ。初期情報は公開資料から手入力し、コミュニティでの告知とGoogle Sheetsでも追加提供を受けた。

同じAlphaコードの入力画面。架空の店舗と例文を使用し、再現サーバーでは認証と送信を無効にしている。 韓国語の原画面。当時のAlphaは韓国語のみ対応。

2023年6月17日のAlphaソースにある新規店舗入力画面。ローカルの入力例であり、送信は無効。 韓国語の原画面。当時のAlphaは韓国語のみ対応。

flowchart TD
    accTitle: 対象を指定した情報提供
    accDescr: 情報提供の経路にある店舗IDへ自由記述と送信情報を結び付け、管理者が確認する。
    A["店舗ページのID"] --> B
    B["自由記述で変更内容を説明"] --> C
    C["対象を指定した情報提供"] --> D
    D["管理者による確認と反映"]

Alphaの公開と情報更新

公開した一覧では、希望するゲームがある店舗と距離を調べられる。誤りを見つけた利用者はその店舗へ提供でき、管理者はフォームで保存形式をそろえられる。約45店舗の初期情報と修正経路を一緒に用意した。

ゲームや筐体の細部は、依頼文を読んで確認する必要がある。提供数が増えれば、この作業が反映を待たせる可能性もある。公開後の情報需要や繰り返される誤りを見ながら、次の管理方法を検討する。

2023-06-17のコードによる店舗詳細。サンプルの価格と台数を当時のコンポーネントで表示している。 韓国語の原画面。当時のAlphaは韓国語のみ対応。

参考：Musecatの開発記録。