ID:81725さん

## 0. はじめに こちらのプロジェクトは個人開発で発足したプロダクトとなっております。 まずは元々この業界で10年以上見てきた私が業界分析を行い課題を洗い出す段階にあります。 現在はこの業界名義で活動するAritstのブランティングサポートするための開発を第一フェーズとして進めています。 このプロジェクトのモチベーションとしては、即座にリリース自体は目指していません。 業界分析を進めつつ、この業界における本当の課題は何かということを解き明かし解消していくことが目的であり、その課題解決の手段としてプロダクトが構築されていくからです。 プロダクトを作ることがゴールではなく、課題を見つけて開発者自身なりに業界へ寄与するための足掛かりとして発足しており、最終的リリース、検証、業界への寄与することを目指しております。 ## 1. プロジェクト概要 ### ビジョン BeatSinkCentralは日本のビートボックスコミュニティの健全化と持続可能な発展を目指す総合プラットフォームです。プレイヤー、イベント主催者、観客を繋ぐ中心的なハブとして機能し、透明性・安全性・成長を促進します。 ### 現在のステータス MVP段階（フェーズ1）- プレイヤー紹介システムの構築に注力 --- ## 2. 背景・課題認識 ### なぜこのプロジェクトを始めたか #### 業界の現状と課題 同世代のBeatboxer兼オーガナイザーとの対話を通じて、以下の課題が明確になりました： | カテゴリ | 課題 | |---------|------| | **情報の分散** | イベント日程が重複し、観客・参加者が分散。情報が統一されておらず貴重な機会を逃すケースが発生 | | **安全性の欠如** | イベントでの不適切行為（性的被害等）が発生。業界の内輪のみで形成されている狭い世界のため、健全な業界・イベントとして保つことが困難 | | **風評被害への脆弱性** | ネット告発が発生した際、証明が難しく対応が困難。悪魔の証明的な形で立場が弱くなるリスク | | **機会の不平等** | 一部人脈のあるプレイヤーのみが優遇される傾向 | | **収益構造の未整備** | プレイヤー・オーガナイザー双方に持続可能な収益基盤がない | #### オーガナイザーへのヒアリングで判明した課題 **イベント運営の困りごと：** - チケット販売のオーディエンスに対する販売管理が煩雑 - エントリー方法がスマホで完結できない（キャンセル管理、自動メール返信、チケット発行、オンライン決済） - 電子決済のみで行いたいが手数料がネック - スポンサーを募ってお金を出してもらう仕組みがない - 違反者の管理ができていない **プレイヤーブッキングの課題：** - 収益性があるのかわからず博打になってしまう - 珍しいから呼ぶ → ミスマッチが発生 - プレイヤーが受け身な状態（声がかかるのを待つ） --- ## 3. 解決アプローチ ### 表向きの顔：ポータルサイト - イベントの情報集約 - プレイヤー情報の掲載 - 認定制度によるブランド化 ### 裏側の機能：管理・安全基盤 - プレイヤー・オーガナイザーの一元管理 - 行動履歴・評価システム - 違反者管理（ブラックリスト） --- ## 4. ビジネスモデル・収益構造 ### フェーズ別収益化計画 | フェーズ | 内容 | 収益源 | |---------|------|--------| | **Phase 1** (現在) | MVP - プレイヤー紹介 | - | | **Phase 1+** | 基本的なエンゲージメント機能 | - | | **Phase 2** | 収益基盤 | チケット販売手数料、プレミアムメンバーシップ | | **Phase 3** | サービス拡張 | マーケットプレイス手数料、プロモーション | | **Phase 4** | ビジネス展開 | 企業マッチング、スポンサーシップ | ### 収益モデル詳細 #### 1. メンバーシップ収益 | 種別 | 内容 | |------|------| | 基本会員（無料） | 基本的なプロフィール登録のみ | | プロ会員（有料） | 詳細プロフィール、優先エントリー権、プロモーション機会、スポンサーマッチング機会 | | 認定料 | 初回認定・更新料 | #### 2. イベント関連収益 | 種別 | 内容 | |------|------| | 掲載料 | 基本掲載（無料）、プレミアム掲載（有料：優先表示等） | | チケット販売 | 販売手数料（5-10%）、決済システム連携 | #### 3. 広告収益 - バナー広告（トップページ、イベントページ） - スポンサードコンテンツ - 楽器メーカー・音響機器・アパレル等からの広告 #### 4. マーケットプレイス - オリジナルグッズ、練習用教材、機材販売 - 販売手数料（10-15%） #### 5. プロモーションサービス - プレイヤー向け：プロフィール制作支援、PR動画制作、メディア露出機会 - イベント向け：告知物制作、SNS運用支援、集客支援 #### 6. データ活用 - イベント分析レポート（集客傾向、参加者属性、マーケティングインサイト） - 業界トレンドレポート #### 7. 企業向けサービス - タレントマッチング（イベント出演、CM・広告出演、企業イベント出演） - 企業スポンサーシッププログラム --- ## 5. 期待される効果 ### 短期的効果 - イベントの安全性向上 - トラブル対応の標準化 - 情報の透明性確保 ### 中期的効果 - プレイヤーの権利保護強化 - イベントの質的向上 - コミュニティの健全化 ### 長期的効果 - 業界の信頼性向上 - 新規参入の促進 - 市場の拡大 - 企業スポンサーの参入促進 --- ## 6. 出したバリュー・できること ### 0→1 プロダクト構築力 #### 課題発見からソリューション設計まで | やったこと | 詳細 | |-----------|------| | **ドメインエキスパートへのヒアリング** | 同世代のBeatboxer兼オーガナイザーと対話し、業界の課題を構造化 | | **課題の言語化** | 情報の分散、安全性の欠如、収益構造の未整備など、抽象的な課題を具体的な要件に落とし込み | | **ペルソナ定義** | パブリック・プレイヤー・オーガナイザーの3ドメインでターゲットユーザーを明確化 | | **段階的ロードマップ策定** | MVP → 収益基盤 → サービス拡張 → ビジネス展開の4フェーズで開発計画を設計 | #### ビジネス観点での設計 | やったこと | 詳細 | |-----------|------| | **収益モデル設計** | メンバーシップ、チケット販売手数料、広告、マーケットプレイス、企業マッチングの5つの収益源を設計 | | **ステークホルダー分析** | プレイヤー・オーガナイザー・観客・スポンサー企業それぞれの価値提供を整理 | | **競合分析・差別化** | 既存のイベント管理ツールとの違い（業界特化・安全性・認定制度）を明確化 | --- ### 技術選定・アーキテクチャ設計 #### 技術選定の意思決定 | 選定 | 理由・意図 | |------|-----------| | **Monorepo構成（Turborepo）** | UI・API・データベースを横断した開発効率化、パッケージ間の依存管理を一元化 | | **Next.js App Router + Hono統合** | フロントエンドとBFFを同一リポジトリで管理し、開発速度とデプロイ効率を向上 | | **Atomic Design + shadcn/ui** | デザインシステムの一貫性確保、コンポーネント再利用性の最大化 | | **Drizzle ORM + Supabase** | 型安全なDB操作、マイグレーション管理の容易さ、スケーラビリティ | | **Storybook + Chromatic** | コンポーネント駆動開発、ビジュアルリグレッション検知の自動化 | | **Zod** | フロント・バックエンド間のバリデーション統一、型安全性の担保 | #### アーキテクチャ設計の特徴 | 設計方針 | 詳細 | |---------|------| | **UI/アプリケーション分離** | UIコンポーネントはPropsを受け取り表示のみに徹する設計。状態管理・ビジネスロジックとの依存を排除 | | **フレームワーク非依存** | Next.js固有の機能に依存せず、Reactベースで実装。将来の環境移行に対応可能 | | **ドメイン分割** | パブリック・プレイヤー・オーガナイザーの3ドメインで機能を整理 | | **REST API + クライアント自動生成** | API仕様からクライアントコードを自動生成し、型安全な通信を実現 | --- ### UX起点の設計思考 #### ユーザー体験設計 | 設計観点 | 詳細 | |---------|------| | **「知る→理解する→応援する」の導線** | 受動的ユーザーから能動的サポーターへ変化を促す体験設計 | | **デバイス特性に合わせたレスポンシブ設計** | モバイルファーストを意識したUI設計 | | **ペルソナ別の情報設計** | 観客・プレイヤー・オーガナイザーそれぞれに最適化された情報構造 | #### 本業で培ったUX設計の応用 - デザイナーとの協働経験を活かし、エンジニア視点からのUX提案を実践 - 技術的制約とユーザー体験のバランスを取った意思決定 --- ### 開発基盤・品質担保 #### 開発環境の構築 | 構築内容 | 詳細 | |---------|------| | **CI/CD パイプライン** | GitHub Actions + Vercelで、PR作成→プレビュー環境、mainマージ→本番環境の自動デプロイ | | **コード品質管理** | ESLint + Prettier + Code Rabbit AIによる自動レビュー | | **ビジュアルリグレッションテスト** | Storybook × Chromaticで意図しないUI変更を自動検知 | | **環境分離** | 開発 / プレビュー / 本番の3環境を整備 | #### 本業での学びの応用 - VRT導入の背景：「UI変更を人の目で検知するのは困難」という課題を、自動化で解決 - コード規約策定の経験を活かし、個人開発でも一貫したコーディングスタイルを維持 --- ### できること（本プロジェクトで証明されたスキル） | カテゴリ | できること | |---------|-----------| | **プロダクト構築** | 課題発見 → ヒアリング → 要件定義 → 設計 → 実装 → 運用までの0→1全工程 | | **ビジネス設計** | 収益モデル設計、ステークホルダー分析、段階的ロードマップ策定 | | **技術選定** | プロダクト特性を踏まえた技術スタックの選定と意思決定の言語化 | | **アーキテクチャ設計** | Monorepo構成、UI/アプリ分離、ドメイン分割、拡張性を考慮した設計 | | **UX設計** | ペルソナ定義、ユーザージャーニー設計、デバイス特性を考慮したUI設計 | | **品質担保** | CI/CD構築、VRT導入、コード品質管理の仕組み化 | | **ドメイン知識の習得** | 業界特有の課題をヒアリングし、技術で解決するソリューションに落とし込む力 | --- ### 本業との相乗効果 | 本業で培ったスキル | 個人開発での応用 | |-------------------|-----------------| | フロントエンド実装基盤の確立 | Atomic Design + shadcn/uiでの一貫したコンポーネント設計 | | テスト戦略（VRT、コンポーネントテスト） | Storybook × Chromaticの導入 | | デザイナーとの協働経験 | UX起点の設計思考、技術制約を踏まえた体験設計 | | バックエンド領域への拡張 | API設計、DB設計、型安全なバリデーション | | チーム開発での意思決定経験 | 技術選定・設計の「なぜ」を言語化する習慣 | --- ## 7. 技術スタック ### フロントエンド | カテゴリ | 技術 | |---------|------| | フレームワーク | React, Next.js, TypeScript | | スタイリング | Tailwind CSS, Tailwind Variants | | UIコンポーネント | shadcn/ui | | ライブラリ | Lucide React, React Aria Components, Recharts | | ビルド | Turborepo (monorepo構成) | | テスト | Storybook, Chromatic (ビジュアルリグレッションテスト) | ### バックエンド | カテゴリ | 技術 | |---------|------| | フレームワーク | Hono.js, TypeScript | | API設計 | REST API + クライアント自動生成 | | バリデーション | Zod | ### データベース | カテゴリ | 技術 | |---------|------| | DB | PostgreSQL (Supabase) | | ORM | Drizzle ORM | | マイグレーション | Drizzle Kit | ### インフラ・デプロイ | カテゴリ | 技術 | |---------|------| | CI/CD | GitHub Actions | | ホスティング | Vercel | | 環境 | 開発 / プレビュー / 本番 | --- ## 8. ドメイン設計 | ドメイン | 対象ユーザー | 主要機能 | |---------|-------------|---------| | パブリック | 一般観客 | イベント情報閲覧、プレイヤー情報閲覧、基本情報・ガイド | | プレイヤー | メンバー | アカウント管理、イベントエントリー、プロフィール管理、実績管理 | | オーガナイザー | イベント主催者 | イベント管理、プレイヤー評価、運営管理、安全管理 | ### UX設計方針 > 「知る」→「理解する」→「応援する」 - 受動的ユーザーから能動的サポーターへの変化を促す体験設計 - デバイス特性に合わせたレスポンシブなインターフェース --- ## 9. リポジトリ構成 ``` / ├── apps/ │ ├── beatfolio/ # フロントエンドアプリケーション │ └── api-server/ # APIサーバー (BFF) │ └── packages/ ├── ui/ # UIコンポーネントライブラリ ├── data/ # データモデルとモックデータ └── database/ # データベース関連 ``` --- ## 10. 開発ワークフロー ### コード品質 - ESLint / Prettier - GitHub Pull Requests - Code Rabbit AI によるコードレビュー ### デプロイパイプライン ``` PR作成 → プレビュー環境へ自動デプロイ ↓ mainマージ → 本番環境へ自動デプロイ ``` --- ## 11. 実装の特徴 - React + Next.js によるモダンなWebアプリケーション - APIルーティングに Hono を採用（Next.js App Routerと統合） - Tailwind CSS による再利用可能なコンポーネント設計 - Atomic Design ベースのコンポーネント構造 - TypeScript + Zod によるエンドツーエンドの型安全性 --- ## 12. 次のアクション ### 検証活動 - ドメイン関連の人たちにヒアリング継続 - 東京のイベントオーガナイザーとの連携・検証 ### 開発 - プレイヤー情報の一元化をターゲットに体験部分を設計 - UX視点からの見直し（主観を排除）