LiGA DiVeRTiDA リニューアル — 技術方針

3. 決済（Stripe）

Stripeひとつで以下の決済手段を全てカバー。別サービスの契約や個別実装は不要。

初期費用・月額固定費なし。決済が発生した分だけ手数料がかかる従量課金。

4. インフラ構成

  ユーザー ──→ Vercel (Next.js) ──→ Cloud Run (NestJS) ──→ Cloud SQL (PostgreSQL)
                   │                       │
                   │                       ├──→ Stripe（決済）
                   │                       ├──→ Resend（メール送信）
                   │                       └──→ Cloudflare R2（画像等）
                   │
                   └──→ Sentry（エラー監視）

なぜこの構成でシンプルに済むのか

AWS自前構築で必要になるインフラ要件の大半が、マネージドサービスに組み込み済み。

④シートではAWS（ECS/Fargate/RDS/ALB/WAF等）前提でインフラ構築に13人日を見積もっている。マネージドサービス採用により、同等以上の信頼性を1人日で実現。

インフラコスト（MVP初期）

ステージング環境

本番とは完全に分離されたステージング環境を開発初期から用意する。

コードは同一で、環境変数のセットだけでステージング/本番を切り替える構成。

なぜ開発初期からステージングが必要か

追加コストは月 ¥2,000 程度（Cloud SQLステージング用インスタンスのみ）。「リリース直前に作る」と手戻りコストの方が遥かに大きい。

5. 開発方針

基本方針

• 速度重視 — モノができることを最優先
• 開発効率の最大化 — コード生成にAIツールを一部活用し、開発速度を向上
• モバイルファースト — ユーザー向けはシングルカラム・モバイルファーストで設計し、PCでも自然に見えるようブレイクポイントで調整。管理画面はデスクトップ前提

進め方

• 設計書・仕様書は作らない — 動くコードとGitHub上のIssue / PRをソースオブトゥルースとする
• やりとりはGitHub Issueで行う — 要望・質問・仕様確認はすべてIssueに起票。議論がそのまま開発タスクになり、経緯もコードと同じ場所に残る
• 会話→実装→確認の短サイクル — Issueで要件を固め、すぐ実装してフィードバックを得る
• 認識合わせは実画面で行う — ステージング環境にデプロイした実画面を見ながら確認。ワイヤーフレームやモックアップのやり取りは最小限にする
• 進捗はGitHub Projectsで共有 — Issueをカンバン（Todo → In Progress → Done）で可視化。クライアントがリアルタイムで進捗を確認でき、進捗報告ミーティングが不要になる（無料）
• PRごとにプレビューURLが自動生成 — Vercelが各PRに対して確認用URLを自動発行。画面確認のたびにデプロイ待ちやミーティングを挟む必要がなく、IssueにURLを貼るだけでフィードバックを受けられる

モノレポ構成

フロント（Next.js）・バック（NestJS）・DB定義・共通型を1つのリポジトリで管理。型やバリデーションの二重実装をなくす。

liga/
├── packages/
│   ├── shared/     ← 型・バリデーションスキーマ・定数（フロント/バック共通）
│   ├── web/        ← Next.js 15（ユーザー向け + 管理画面）
│   ├── api/        ← NestJS（決済・定員管理・スケジュール等のAPI）
│   └── db/         ← Drizzle スキーマ・マイグレーション・seedデータ
├── .github/workflows/  ← CI/CD
└── docker-compose.yml  ← ローカル開発環境

シングルカラムレイアウト

ユーザー向け画面はモバイルファーストのシングルカラムで設計。PCではコンテンツ幅を広げ、余白やカードサイズを調整して自然な見た目にする。

UIトーン: カジュアル × ワクワク × シンプルでかっこいい。直感的に操作できるUI。

スマホを最優先で設計し、PCではブレイクポイント（768px〜）で余白・カード配置等を調整する最小限のレスポンシブ対応。管理画面はデスクトップ前提（shadcn/uiのData Table等をそのまま使用）。

テスト方針

全てにテストを書くのではなく、金銭・安全に直結する箇所に集中する。

6. 開発体制

コード生成にAIツールを一部活用し、定型的な実装（CRUD・テストコード・設定ファイル等）を効率化。人間はレビュー・動作確認・ビジネス判断に集中する。

7. MVP開発スケジュール

前提

• 体制: 4名
• 期間: 約7週間
• リリース目標: 2026/6/14（土）
• 開発開始: 2026/4/28（月）

8. 要件シート未記載だがMVPに組み込み済みの機能

ユースケース検証・現行サイト調査により発見し、全てMVP工数表に計上済み:

PayPay・銀行振込・コンビニ決済はStripe標準機能で対応可能（設定のみ）。