スキースクールレッスン管理システム

2025年2月3日 2025年3月5日 yousan

はじめに

ある地方にあるスキースクール用の管理システムを開発しました。　　　…といっても実際の実務用のプログラムではなく、仮想的に問題点を想定し、それを改善するシステムを作成しました。

まだ改良段階のものもあるのですが、途中経過を含めて完成した体で書かせてもらっています。

そもそもなぜこういった開発を行っているかと言うと、SupabaseとRefineの組み合わせが非常に強力で、エンジニアとして使っていて気持ちがいい、気分がいい、もっと開発をしたい！という思いがあるからです。いわゆる開発体験（DX）が良いです。

加えて今回のプロジェクトでは Cursor の Composerをできる限り使っていて、Cursorを使うとこんなにもコードを書いてくれるんだとか、知識がなくて困っていたコードをスラスラと書いてくれたり、繰り返し作業が面倒だなぁと思ったところを書いてくれたりしてそれに感動しているところもあります。

ともあれある程度形になったのでここに公開します。ソースコードも公開しておきます。

ソースコード

デモサイト

システム概要

まずはそのスキースクールの状況や問題点についてです。

地方にあるスキー場とは別経営のスキースクール
地域密着型のスクールとして活動
現在はレッスンの管理をエクセルで管理を行っているが、複数人での同時管理が困難。
担当者が休んだ場合や、電話でのレッスン申し込みが相次いだ場合にエクセルを同時編集できず困っている。
予約情報の確認や過去の履歴を確認することがエクセルの検索機能のみで時間がかかったり、上手くヒットさせることができないことがある。

そういった問題を解決するため、ウェブシステムでのレッスン管理システムのデモ版を作成しました。

デモサイト

ソースコード

要件の洗い出し

まずは要件の洗い出しを行いました。改善したいことをベースに書き出ししていきます。

また今回はエクセルでの管理からシステム化されるため、将来的な拡張機能についても考慮事項として記載しておきました。

将来的な拡張としては下記のようなものがありました。

レッスン自体のリマインドメール（明日はレッスンの日です、という案内）
レッスン終了後のレッスン内容の案内メール
次のレッスンをリコメンドするメール
レッスン中に撮影された動画の管理と案内
インストラクターによる一般的なハウツー動画の配布

詳細設計とシステム構成図

次に要件定義から詳細設計を行いました。

バックエンドにはIaaSのSupabaseを用いているので、認証やDBについてはSupabaseで実装されます。

2.1 認証フロー

sequenceDiagram
    Actor User
    participant Frontend
    participant Supabase
    participant DB
    
    User->>Frontend: ログイン要求
    Frontend->>Supabase: 認証リクエスト
    Supabase->>DB: ユーザー検証
    DB-->>Supabase: 検証結果
    Supabase-->>Frontend: JWT発行
    Frontend-->>User: ログイン完了

今回はユーザーを複数種類作成するため、権限設計も行っておきます。

2.2 権限設計

機能	管理者	インストラクター	受講者
レッスン管理	○	△（閲覧のみ）	△（閲覧のみ）
予約管理	○	△（担当分）	△（自身の予約）
ユーザー管理	○	×	×
スケジュール管理	○	△（自身の予定）	×

3.1.2レッスン予約フロー

sequenceDiagram
    Actor Admin
    participant Frontend
    participant Supabase
    participant DB
    
    Admin->>Frontend: スケジュール登録
    Frontend->>Supabase: バリデーション
    Supabase->>DB: スケジュール保存
    DB-->>Supabase: 保存完了
    Supabase->>Frontend: 完了通知
    Frontend->>Admin: 登録完了表示

基本的な設計を行う際、各種識別のIDとしてはUUIDを利用していました。レッスン予約の識別IDもUUIDです。ですが実務上、UUIDでレッスン予約を管理すると、電話やメールでの対応の際に長くて複雑なため、利用者が混乱するだろうというと思われました。

そのため予約についてはUUID意外に識別コードを割り当てるようにしました。予約作成の年月をベースに通し番号を振っているため、予約番号を見ればだいたいいつ頃の予約であるかがわかるようになっています。これにより利用者がスムーズに伝えられると思います。そういった定義も行っておきました。

予約の業務フロー図です。

stateDiagram-v2
    [*] --> 申し込み
    申し込み --> 申し込み承認: インストラクターが承認
    申し込み --> キャンセル: ユーザーがキャンセル
    申し込み承認 --> 受講済: レッスン完了
    申し込み承認 --> キャンセル: ユーザーがキャンセル
    キャンセル --> [*]
    受講済 --> [*]