目的のゲームがあると知って訪れたのに、ボタンの故障で遊べなかったとしよう。設置一覧は正しくても、訪問に必要な情報は不足している。Deltaでは筐体の問題や現地情報を文章で受け、解決まで店舗ページ上部へ表示するようにした。投稿者以外の利用者も正常化を確認して解決を知らせられる。

2025-07-01のDelta運用画面。レガシーGamma-Webの原本コードをサンプル報告で再現。未解決の内容を店舗ページ上部で先に確認できる。

設置一覧と訪問時の状態

ゲーム一覧の台数は、設置されている筐体を表す。例えば一台の画面が故障したからと台数を減らすと、設置情報そのものが誤ってしまう。一時的な問題を伝えつつ、本来の保有情報を残す方法が必要だった。

従来のその他情報入力は、定まった項目に入らない内容を運営へ送る窓口だった。運営者は確認して反映できるが、次の訪問者への案内という役割は明確ではなかった。投稿内容を店舗画面に出し、解決状態も一緒に扱うことにした。

flowchart TD
    accTitle: 故障報告と対象の接続
    accDescr: 店舗を指定した状態で問題を文章入力し、別のチケットに残す。
    A["店舗ページ"] --> B
    B["筐体の問題を説明"] --> C
    C["対象店舗の報告チケット"]

文章による故障の受付

入口を故障報告とユーザー報告へ変え、筐体の問題やほかの利用者へ共有する現地情報を書くよう案内した。どのゲームの何番台かを文章で説明する。現段階では写真添付や、故障箇所を定めた入力フォームは提供しない。

同じバージョンの報告詳細。場所・作成者・文章で残した問題を接続する。合成サンプルデータ。 日本語ルートで撮影。当時のチケット画面のラベルは韓国語のままである。

報告は店舗に結び付いたチケットuserTicketとして保存する。ゲームや料金を上書きせず、問題を別に残す資料だ。店舗画面から送るため、運営者が文章だけで対象を探し直す負担も減る。

flowchart TD
    accTitle: 未解決報告の公開
    accDescr: 未解決のメッセージと作成時点を店舗上部に表示する。
    A["未解決報告を取得"] --> B
    B["メッセージと作成時点"] --> C
    C["店舗ページ上部に表示"]

未解決表示と解決ボタン

詳細画面はその店舗の未解決その他チケットを読む。サーバー上では種別ETC、状態pendingの資料である。作成時刻とメッセージをカードに載せて上部に置き、ゲーム一覧の奥や運営の待機列を探さずに確認できるようにした。

解決済み報告の状態表示。2025-07-01のコードにサンプルデータを接続した。 日本語ルートで撮影。当時のチケット状態のラベルは韓国語のままである。

カードの解決ボタンを押すと確認後に状態をsolvedへ変える。成功後は画面も更新して未解決一覧から外す。作成者だけに制限せず、現地で正常化を確かめた別の利用者もすぐ知らせられる。

flowchart TD
    accTitle: 解決を知らせる流れ
    accDescr: 利用者が解決を確認してから状態と画面を更新する。
    A["解決済みを選択"] --> B
    B["解決したか確認"] --> C
    C["チケット状態を更新"] --> D
    D["未解決一覧を更新"]

現地案内の効果と確認課題

設置情報と現地の報告を一緒に確認できるようになった。故障を知らせるために保有ゲームを消す必要がなく、解決後は未解決案内から下がる。投稿した文章が訪問者への注意となり、その後の解決までつながる流れを作れた。

ただし筐体名や位置は正確に書く必要がある。解決ボタンも人の確認に依存し、誤判断で報告が下がったり古い内容が残ったりし得る。文章だけでは筐体や故障箇所を一定の形式で分けにくい。運用を通じ、対象と解決判断に必要な情報をさらに確認していく必要がある。

参考：故障報告を導入した変更。