パチスロホール向け データ管理SaaS
パチスロ業界には、データが豊富にある。業界最大級のデータポータルには、全国のホールの台別データが毎日蓄積されている。
問題は、そのデータが経営者にも、ファンにも、スタッフにも、うまく届いていないことだった。
スタッフは毎朝、そのサイトを手動で確認してエクセルに転記する。3時間かかる。1日3時間 × 300日 = 900時間。誰かの大切な時間が、毎日、定型作業で消えていた。ファンは情報を求めてSNSや専門サイトを巡回するが、情報は断片的で信頼性にばらつきがある。ホール経営者は競合の状況をリアルタイムで把握できない。
データはあった。つながっていなかっただけだ。
創業15年のホール経営企業の創業者が、ある日これを言語化してきた。
最初は「スクレイピングしてデータを表示するツール」に見えた。でも、話を聞いていくと全然違う問題だとわかってきた。スタッフ、ファン、ホール経営者という3つのユーザー像が、それぞれ全く異なる情報を、全く異なる使い方をしている。この3者を一つのシステムで繋ぐには、設計から考え直す必要があった。
リノエッジがプロジェクトに入ったのは、途中からだった。
別の会社がすでに開発を進めていた。でも商用展開に耐えられる設計ではなかった——そのことは、コードを読み始めた最初の数時間でわかった。その後、前の開発会社はプロジェクトから離れた。
引き継ぎではなく、作り直しだった。
プロジェクト期間4ヶ月。「データ表示ツール」ではなく「ホールエコシステム全体に価値を届けるSaaS」として設計した。軸に置いたのは3つのアカウント区分だ——ホール店舗・クリエイター・ユーザー。この区分に基づいて、機能も画面も、それぞれ独立して設計した。
ただ、プロジェクトで一番難しかったのは設計ではなく、移行だった。初期プロトタイプはReplitで開発されていたが、商用展開に耐える設計ではなかった。Laravelベースのバックエンドに全面移行する過程で、200件を超えるバグが顕在化した。正直、想定以上の数だった。でも1件ずつ潰した。「このフェーズをきちんとやり切るかどうかで、3年後のメンテナンスコストが変わる」という判断だった。
3,200件超のデータを毎日自動取得する基盤を構築した。取得失敗時のリトライ・異常検知・差分更新を組み込み、手動作業ゼロを実現した。1万件規模の同時データ処理を前提に負荷テストを実施済みで、複数ホールへの展開にも耐えられる設計になっている。
複数ホールが同じシステムを使う場合、データの混在と処理の競合が起きる。Docker Composeによるコンテナ分離アーキテクチャを採用し、ホールごとに独立した環境を保ちながら運用コストを最小化した。
基本機能は無料で提供し、AI分析機能のみポイント制で有料化するモデルを選んだ。「まずデータと向き合う習慣をつけてほしい。その先に、AIが何を示すかを体験してほしい」という創業者の意向を受けた設計だ。決済はGMOとStripeを用途別に使い分け、延滞アカウントの管理機能も実装している。
台別のスランプグラフをリアルタイムで確認できる。スケジュール管理UIでホールのイベント情報も把握できる。「どの台が今どういう状態か」が、サイトを開くだけでわかる。
スランプグラフをそのまま保存・投稿画像に変換できる機能を実装した。X（旧Twitter）やInstagram向けの投稿テンプレートも用意し、「データを見た → 発信する」までのフローが1つのツールで完結する。クリエイターが発信するたびに、ホールの認知が広がる仕組みになっている。
競合ホールのデータ比較ダッシュボードを実装した。「あの店の出玉率は？」「今週の稼働状況は？」が数字で確認できる。ファンからの問い合わせを一元管理するインクワイアリーシステムも稼働しており、対応漏れをなくした。
| Before | After | ||
|---|---|---|---|
| スタッフの毎朝 | 手動転記 3時間 | → | 自動取得 0分 |
| ファンの情報収集 | SNS巡回、信頼性不明 | → | リアルタイムグラフ |
| 経営者の競合把握 | 感覚と経験 | → | 数字と比較ダッシュボード |
| 移行バグ | 200件超が潜在 | → | 全件解消 |
| 同時処理能力 | 未確認 | → | 1万件テストクリア |