予約 データ整理の観点

予約の仕組みを考えるときは、いきなりテーブル定義に入るより、まず「何を区別して持つ必要があるか」を整理するほうが進めやすいです。

まず分けて考えたい情報

まとまり	役割
リソース定義	何を押さえる対象とするか（席・部屋・担当者）
枠・カレンダー	いつ受け付け可能か、営業時間・定休
予約（申込〜確定）	誰が・いつ・何を押さえたか
状態・履歴	変更・キャンセル・ノーショー・消化の記録

flowchart TD
    A["リソース定義\n席・部屋・担当者・設備"] --> B["枠・カレンダー\nいつ受け付けるか"]
    B --> C["予約\n誰が・いつ・何を押さえたか"]
    C --> D["状態・履歴\n変更・取消・消化"]

なぜ分けるのか

この4つを分けて考えると、次のような問いに答えやすくなります。

• 特定の日だけ枠を閉じたいのか
• 特定のリソースを撤去・追加したいのか
• 個別の予約を変更・取消したいのか
• 実績を後から確認したいのか

逆に、これらが混ざると、臨時休業や設備入替、問い合わせ対応のときに切り分けしにくくなります。

リソース単位で持ちたい情報

• 種別（席／部屋／担当者／設備）
• 属性（定員・面積・対応スキルなど）
• 前後バッファ
• 有効・無効の期間（撤去・休止）
• 所属するリソースグループ

枠・カレンダー単位で持ちたい情報

• 対象リソース
• 営業時間・刻み
• 定休日・臨時休業
• 受付開始・締切
• 枠ごとの上限（定員・人数）

予約単位で持ちたい情報

公開向けの観点としては、少なくとも次のような情報を持つかどうかを整理しておくと十分です。

• 誰の予約か（会員／ゲスト）
• 対象リソースと日時
• サービス内容と所要時間
• 申込チャネル（アプリ／電話／来店）
• 現在の状態（受付／確定／変更／取消／消化）
• 決済状況（事前決済の場合）

履歴をどこまで残すか

施策によって、必要な履歴の粒度は変わります。

• 変更履歴（いつ誰が何を変えたか）
• キャンセル理由
• ノーショー判定の記録
• 通知送信の記録
• 繰上げ（キャンセル待ち）の処理履歴

問い合わせ対応やペナルティ運用を重視するほど、履歴は細かく残す必要があります。一方で、保持しすぎると個人情報の取扱い負荷が増えるため、どこまで残し、いつ匿名化・削除するか を合わせて決めておく必要があります。

他機能との関係

予約は他の機能と連携することが多い領域です。

• 会員・認証（本人確認、ブラックリスト）
• 決済（事前決済、返金）
• 通知（リマインダー、繰上げ案内）
• 特典（予約完了時のクーポン配布、参加券の発券）
• 集計・分析（稼働率、キャンセル率、リピート率）

このため、予約単体のデータモデルだけでなく、どこから参照され、どこに連携するかを整理しておくと、後工程がスムーズになります。

実案件で詰めること

最終的には、次のような条件で持ち方が変わります。

• 複数リソースの同時押さえの有無
• 繰り返し予約の有無
• キャンセル待ちの有無
• 店舗代行入力の粒度
• 外部カレンダー連携の有無

そのため、このページは実装用のデータモデルではなく、要件定義の前段で認識をそろえるための整理に留めています。