🐦‍🔥 RACK HOUSE

Google Cloud Go

概要

RACK HOUSEは、高強度筋力トレーニングおよびパワーリフティングに特化した、パワーラック（ハーフラック）専用構成のトレーニング施設である。 有酸素運動設備や筋トレマシンを導入せず、純度とミニマルさを徹底した空間的ソリューションを提案する。

コンセプト

OCCUPY. LIFT. LEAVE.

  • 占有 → 鍛錬 → 退出 という動線に基づいた空間設計により、滞留と惰性を排除

LOUD ALLOWED

  • 気合・発声・床衝撃等の出力行為を制限しない方針により、競技強度のパフォーマンスを支援

主な構造・運用機構

1. 限定設備構成

  • 常設設備はパワーラックのみ
    • 各ラックはダンベル・ストレージ・セーフティバー等完備。
  • 床引き専用エリア
    • デッドリフト・オリンピックリフティング（スナッチ・クリーン＆ジャーク）等、床反力系種目に特化した専用ゾーンを設置。
    • 各ゾーンにはリフティングプラットフォームを導入し、高重量バーベルのドロップを明示的に許容する構造とする。
  • 有酸素・マシン類設備は完全撤廃

2. 占有管理システム（時間制パワーラック管理）

  • 最大占有時間：90分（延長・予約不可）
  • ラック横のUI（物理ボタン＋デジタルタイマー）による占有開始操作
  • 残時間はラック横ディスプレイに常時表示
  • 終了時は視覚アラート・環境光等で明示
  • 公平性・回転効率・心理的安全性の三立を図る設計。

3. 営業および安全管理体制

  • 営業時間：早朝〜22:00（深夜営業なし）
  • スタッフ常駐制（営業時間内全時間帯）
    • 緊急対応、衛生維持を担う。
  • 録画・センサーによるリスク監視および抑止体制を整備予定。

対象ユーザー像

  • 高重量／高強度トレーニングを恒常的に行うトレーニー
  • 集中志向の短時間完遂型ユーザー
  • ライトユーザー層については訴求対象外だが、排除はしない
    • WELCOME BUT NOT MARKETED

営業ポリシー

項目内容
占有時間制限最大90分／ラック（延長・予約不可）
利用方式現地受付・先着順（アプリ化検討中）
設備構成パワーラックのみ。その他機材は一切非設置
トレーニング形式自由鍛錬（ラック内にてコンパウンド・補助種目可）
発声全面的許容（掛け声・床衝撃・爆発的動作等）
安全体制常時スタッフによる監視／サポート／環境整備
ドロップ明示的に許容。　　　　　　　　　　　　

🧾 プライシング構造（ユーザー視点）

区分価格コメント
ドロップイン¥600 / 回月10回以下の利用のライト層に最適。
月額会員¥6,980 / 月週3回以上ペースの利用を想定。払いやすい価格帯。

運用・設計上の課題

[1] 近隣との防音・床衝撃問題への対応

  • 建屋選定時に重量床対応物件・テナント最下層限定とする必要あり
  • 防音防振設計は初期投資において300〜500万円程度の上乗せ前提

[2] 常駐スタッフの質と確保

  • トレーニングフォーム支援、重量補助、事故対応など専門スキルが必要
  • 人材採用難易度は高め。教育コスト・評価制度設計が必要

[3] 回転効率 vs 待機者のストレス最適化

  • ラック数と同時利用上限に対し、ピーク帯混雑への対応策が不可欠
    • 待機エリアの整備（フォーム練習用スペース）
    • モニタリングAIによる混雑予測
    • アプリ通知などによる時間帯分散誘導

拡張構想および中期計画骨子

  • 会員管理＋占有管理統合型ソフトウェア／UI開発
  • リアルタイム混雑可視化＋AI推定

外部連携：自社開発ゲームアプリとのクロスオーバー

  • ゲーム内に登場する「アイテム」を現実空間での「リワード（例：プロテイン、諸景品）」へ変換
    • アプリ内QRコード or 会員コードと連動し、無人配布機から自動排出される設計
    • 達成者がスタッフに報告する形式は避け、非対面かつ即時性のあるUXによる心理的安全性を確保
  • フィットネスとエンタメの融合による会員エンゲージメント向上

Google Cloud ベース社内ネットワーク運用方針

1. 基盤インフラ

  • クラウドプラットフォーム
    Google Cloud を唯一のインフラ基盤とし、オンプレミス設備は一切採用しない。

  • コンピューティング

    • アプリケーションは Cloud Run（コンテナベースのサーバーレス実行基盤）を原則とし、Cloud Run functions でイベント駆動処理を実行する。
    • VMは特別要件を除き利用せず、必要時もコンテナベースのリソースで代替する。

  • データベース

    • 基幹リレーショナル DB には Cloud SQL（PostgreSQL） を採用。
    • 将来的な高スケール用途（例：ゲーム運営）には Cloud Spanner の導入検討を明記。

  • オブジェクトストレージ

    • バックアップおよびアーカイブはすべて Cloud Storage に保存。
    • 定期バックアップや DR（災害復旧）演習を実施し、復旧手順を文書化する。

2. 業務サポート環境

  • アイデンティティ & 認証管理

    • Google Workspace を ID 基盤とし、SSO による統合認証と最小権限ポリシーの適用を全社で実施。

  • ファイル共有およびコラボレーション

    • Google Drive を標準のファイルサーバと認定し、フォルダ権限を厳格に運用。
    • 文書はすべて Google Workspace 上で作成・管理し、Microsoft Office 製品の導入はしない。

  • 通信手段

    • 社外とのメールは Gmail を統一使用し、DLP／暗号化ポリシーを適用。
    • 社内コミュニケーションはメールを使わず Google Chat を活用。

3. セキュリティ／運用監視

  • モニタリング

    • Cloud Monitoring によりシステム稼働・パフォーマンスを常時監視し、閾値超過時は自動アラートを発動。
    • Cloud Logging によってログを一元管理し、異常検知・トラブルシューティングを迅速化。

  • バックアップ管理

    • Cloud SQL の自動バックアップ設定を全インスタンスで全常に有効化。
    • 重要データは Cloud Storage へ定期エクスポートし、世代管理および復元可能性を保証。

  • アクセス制御

    • Google Workspace の IAM 機能を活用し、リソース権限を最小権限原則に従って適切に付与・解除。
    • 権限変更のプロセスを明文化し、変更履歴を監査可能にする。

4. インフラ構成管理

  • Infrastructure as Code（IaC）

    • Terraform を基盤ツールとして採用し、Google Cloud リソースをコード管理する。
    • CI/CD パイプラインと連携し、構成変更はリビジョン管理・自動テスト・レビューを経てデプロイ。

  • 運用自動化

    • Cloud Scheduler と Cloud Run functions を組み合わせて定期バッチ処理を自動化し、手動業務を排除。

5. 今後の拡張検討事項

  • 大規模トランザクション対応

    • Cloud Spanner の導入を性能ベンチマークに基づき評価し、用途適合性を判断。

  • ネットワークセキュリティ強化

    • VPC Service Controls および Firewall ルールの詳細設計と運用検証を実施。

  • エンドユーザー保護強化

    • MDM（モバイル端末管理）および MFA（多要素認証）の全社員展開により、アクセスセキュリティを強化。