資格勉強を一人で続けるのは、思った以上に難しい。
そんな課題を解決するために、社内エンジニアのJohn Smithさんは、学習マッチングサービス「StudyBuddy」の開発に挑みました。
前回（#03） では全画面の実装とSupabase連携の基本を紹介しました。
今回（#04） はDB設計・RLSポリシー・Realtimeチャットの実装の詳細記録です。
🗄️ データベース設計（Supabaseスキーマ）
4テーブルのシンプル構成（ユーザー情報、マッチング管理、学習記録、チャットメッセージ）にし、新規ユーザー自動登録トリガーを整理。
🔐 RLS（Row Level Security）設計
テーブルごとの「誰が誰のデータを見てよいか」を機能要件から設計し直し、マッチング候補の実績が取得できなかった穴を修正。
🤝 マッチング機能の実装
マッチングは「申請 → 承認」の2ステップ。資格・学習時間帯・報告頻度が一致するほど上位に表示される。
👤 プロフィールページの追加
初回・2回目以降の両方に対応するシンプルな実装にまとめた。
📊 進捗トラッキングの実装
`fmtH` 関数により、1分だけ学習記録があっても、`0.0h` ではなく `1m` と正確に表示される。
💬 Realtimeチャットの実装
⚠️二重接続のエラーが起きた⚠️
Supabaseはチャンネルを名前でキャッシュするため、1回目の接続が残ったまま2回目の接続を試みると「その番号はもう通話中」とエラーになった。
👉ランダムサフィックス ＋ cancelledフラグでチャンネル名を毎回ユニークにしてキャッシュを回避
✅リアルタイムでメッセージを受信できるように
📲 PWA設定
ブラウザのアドレスバーを非表示にし、ネイティブアプリに近い体験を提供。
今回のセッションでは、StudyBuddyの主要機能について振り返りました。生成AIとの対話を活用しながら、要件整理から実装、デバッグまで進めた開発の試行錯誤が伝わってきます。
続いて、プロジェクトを開発したJohn Smithさんのコメントを紹介します。
今回は、前回実装した各画面のコードを深掘りしました。次回はプッシュ通知、学習目標の設定、パートナーへの「いいね」スタンプ機能等の、ユーザー体験を高める機能拡張に取り組みます。
社長の目
DB設計からRLSポリシー、Realtimeチャットのエラー解決に至るまで、知見が詰まった読み応えのある記事でした。「動くものを作る」にとどまらず、保守性やユーザーの使い勝手を意識した丁寧なコード設計がなされており、妥協せずに品質を高めようとするエンジニアとしての真摯な姿勢が伺えます。次回予定されている機能拡張も期待しています。
今回の開発における試行錯誤や詳細なプロセスは、John Smithさん本人のブログでご覧いただけます。
