ブラウザ間で音声と映像を直接やり取りする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による音声・映像の品質は、利用者のネットワーク環境や端末に大きく左右され、開発環境で動くことと実際の利用者が満足することの間には距離があります。対応するブラウザや端末の範囲を早い段階で絞り込み、実機での確認を開発計画に組み込むと、公開後の想定外を減らせます。参加者数に応じた配信方式の選択や再接続の扱いは、初期から完璧を目指すよりも、想定する利用場面を限定してから広げる方が、限られた資源で品質を保てます。
録画データの扱いをプロダクトの信頼性に組み込む
録画には参加者の声や姿が残るため、開始できる人、見られる人、共有や削除ができる人の範囲と、どのくらいの期間どこに置くか、暗号化の方針までを最初の仕様に含めます。録画の後処理を非同期のジョブに分け、完了の通知と失敗時の再実行を備えておくと、データ量が増えても会議そのものの品質に影響しません。録画機能は差別化の要素になりやすい反面、信頼を損なう事故の起点にもなるため、機能の魅力とデータの統制を同じ重さで設計することが求められます。
関連するサービス
関連するインサイト
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP（実用最小限の製品）の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- 少人数開発チームの体制設計 — 役割・採用・外部パートナーの使い分け小さなチームでプロダクトを作り続けるために必要な役割と兼務の考え方、採用と外部パートナーの使い分け、CI/CDや生成AIで人手を補う仕組みを、事業フェーズの変化とあわせて整理します。
- スタートアップのセキュリティと個人情報保護 — 最低限の実務スタートアップが最低限押さえたいセキュリティと個人情報保護の実務を、アカウント管理や秘密情報の扱い、個人情報の取得と削除、CI/CDへの検査組み込み、インシデント初動、生成AI利用の注意まで整理します。
他の開発事例
監修: フィリット・コンサルティング株式会社公開