友人と音楽ゲームを遊びに行く場面を考えてみよう。一人は特定のゲームを、もう一人は別のゲームを遊びたい。両方がある店舗を探すには、店舗別の設置一覧を確認してから、住所と移動距離も比べる必要がある。知っている店名を検索するだけでは答えが出ない。

Musecatは、この探し方から出発する。韓国の店舗の位置と設置ゲームを一か所へ集め、ゲームを選ぶと訪問候補を探せるWebサイトを準備したい。

店舗情報の出所と比較の手間

Wikiや公式サイトには役立つ情報があるが、形式と更新時点は異なる。あるページでゲームを確認し、別の場所で住所を探し、地図で距離を比べる間、利用者自身が同じ店舗の資料を集めることになる。

複数のゲームを条件にすると、店舗ごとに同じ確認が必要になる。一つのページへ資料を移すだけでは十分ではない。各店舗について同じ質問に答えられる形へ整理してこそ、比較の手間を減らせる。

flowchart TD
    accTitle: 散らばる情報を比較するコスト
    accDescr: 訪問候補を比べるには、複数の情報源から設置ゲームと位置を集める必要がある。
    A["Wikiと公式サイト"] --> B
    B["ゲームと位置を収集"] --> C
    C["条件に合う場所を比較"]

ゲームを基準にした探索

ゲーム中心の探索は、先に店舗を決めず、遊びたいゲームから始める方法である。例えば二人が希望するゲームを選び、その条件を満たす場所を見てから、移動できる店舗を選ぶ流れが考えられる。

最初の目標は、条件に合う店舗を距離順で示すことだ。韓国から始めれば、自分で確認し補足できる範囲も作りやすいと考えた。

flowchart TD
    accTitle: ゲーム条件を出発点にする
    accDescr: 希望するゲームを先に選び、場所の候補と距離を比較する流れを目指す。
    A["希望するゲームを選択"] --> B
    B["条件を満たすゲームセンター"] --> C
    C["距離順の候補"]

比較に必要な店舗とゲームのデータ

ゲームで店舗を探すには、どのゲームがどの店舗にあるか結び付いている必要がある。名称と位置で店舗を特定し、設置ゲームを候補の選択に使う。位置は候補間の距離を比べる基準にもなる。

この関係がなければ、ゲーム一覧と住所を集めても利用者が対応を調べ直すことになる。画面を広げる前に、比較できる初期一覧を準備したい。情報が不足する場所を想像で埋めず、確認できたものから入力する予定だ。

flowchart TD
    accTitle: 最初のサービスの準備順序
    accDescr: 比較可能なデータと修正窓口を整えてから、サービスの公開を検討する。
    A["ゲームセンターとゲームの資料を整理"] --> B
    B["誤情報を直す窓口"] --> C
    C["公開する初期範囲を準備"]

初期一覧と修正提供の準備

情報を一度集めても、正確さが続くわけではない。ゲームの移動や営業情報の変更は検索結果にも影響する。初期データと一緒に、利用者が誤りを知らせる窓口も用意する必要がある。

まずは韓国で使える小さな範囲のサービスと、修正依頼を反映する過程を準備したい。まだ公開の成果や利用者の反応を語る段階ではない。実際の訪問先を選ぶために使える一覧を作ることが先である。

参考：Musecatのエンジニアリング記録。