ブラウザ間で音声と映像を直接やり取りするWebRTCを土台に、オンライン会議と録画の配信を行うプラットフォームを新規プロダクトとして立ち上げました。既存サービスのデータベースや認証には接続せず、Next.jsのWeb、FastifyのAPI、BullMQを使うWorkerの三つに分け、Turborepoで一つのリポジトリにまとめて管理しています。会議の開始から終了までの状態管理、参加用トークン、ゲストの招待、録画の制御と参加者ごとのマルチトラック処理を実装し、外部のチャットツールから会議を始める連携やモバイル端末からの参加にも対応。節目ごとに動作が確認できている範囲を示す一覧と引き継ぎ文書を整備しました。
- 既存資産にあえてつながない
- 既存サービスのデータベースにも認証にも接続せず独立して立ち上げました。つなげば利用者をそのまま引き込めますが、既存側のリリース手順とスキーマ変更の調整が新規プロダクトの検証速度を縛ります。検証が失敗したときに畳みやすいことも含め、この段階では切り離す側の利点が上回ると判断しました。
- 会議の品質を守る役割分担
- 録画の制御や参加者ごとの音声・映像の処理はWorkerに寄せ、会議の最中にAPIの応答が遅くならないよう負荷を切り離しています。
- 引き継げる状態を保つ進行管理
- 節目ごとに動作が確認できている範囲を一覧化し、引き継ぎ文書を更新し続けました。完成時にまとめて文書を作る進め方では、途中で内製化や体制変更が決まったときに引き継げるものが残りません。新規プロダクトほど方針の変更が起こるため、いつ手を離しても続けられる状態を工程の中に組み込んでいます。
- 型と自動テストで品質を担保
- zodによる入力の検証、Vitestのユニットテスト、PlaywrightのE2Eテストを初期から整え、少人数でも変更を恐れずに開発を進められる体制にしています。
- Web・API・Workerの三分割
- Next.jsのWeb、FastifyのAPI、BullMQのWorkerに分け、Turborepoで一つのリポジトリにまとめました。分けた上で同じリポジトリに置くことで、少人数でも横断的な変更を扱えます。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
リアルタイム通信を扱うプロダクトの検証計画
WebRTCによる音声・映像の品質は、利用者のネットワーク環境や端末に大きく左右され、開発環境で動くことと実際の利用者が満足することの間には距離があります。対応するブラウザや端末の範囲を早い段階で絞り込み、実機での確認を開発計画に組み込むと、公開後の想定外を減らせます。参加者数に応じた配信方式の選択や再接続の扱いは、初期から完璧を目指すよりも、想定する利用場面を限定してから広げる方が、限られた資源で品質を保てます。
録画データの扱いをプロダクトの信頼性に組み込む
録画には参加者の声や姿が残るため、開始できる人、見られる人、共有や削除ができる人の範囲と、どのくらいの期間どこに置くか、暗号化の方針までを最初の仕様に含めます。録画の後処理を非同期のジョブに分け、完了の通知と失敗時の再実行を備えておくと、データ量が増えても会議そのものの品質に影響しません。録画機能は差別化の要素になりやすい反面、信頼を損なう事故の起点にもなるため、機能の魅力とデータの統制を同じ重さで設計することが求められます。
使った技術・扱った領域
- Next.js
- React
- TypeScript
- Fastify
- WebRTC
- PostgreSQL
- Redis
- BullMQ
- Turborepo
- pnpm
- Biome
- zod
- Playwright
- Vitest
- Docker
関連するサービス
関連するインサイト
- シード期のMVPはどこまで作るかシード期の制約のもとで、管理画面・決済・権限・通知・設定をどこまで省けるかを機能ごとに判断します。省いてよいもの、省くと検証が壊れるもの、後で作り直す前提で割り切れるものを線引きします。
- フェーズで変わる技術選定の基準シードは「速く捨てられるか」、シリーズAは「人を増やせるか」、それ以降は「止まらないか」。同じ技術でもフェーズによって正解が変わる理由と、選定を誤ったときの戻し方を発注側の視点で整理します。
- スタートアップのセキュリティと個人情報保護 — 最低限の実務スタートアップが最低限押さえたいセキュリティと個人情報保護の実務を、アカウント管理や秘密情報の扱い、個人情報の取得と削除、CI/CDへの検査組み込み、インシデント初動、生成AI利用の注意まで整理します。
他の開発事例
監修: フィリット・コンサルティング株式会社公開