ドレスショップ・衣装店の試着予約とドレスの在庫・予約の管理。同じドレスの重複予約を防ぎ、提携式場と挙式日の変更をつなぐ設計

この記事の結論：ドレスショップ・衣装店の試着予約と在庫・予約の管理は、ドレスを「デザイン」ではなく「1着ごと」の記録で持ち、本番の貸し出しは挙式日の前後に準備と手入れの日数を足した期間で押さえます。同じ1着の期間が重ならないことはデータベースの制約で保証し、迷っているお客様のキープには期限を付けて自動で外します。試着の予約は、部屋とスタッフの枠と、試着したいドレスが店にあるかの二つを確かめて受けます。提携式場とは、挙式日の変更やキャンセルを受け取る経路と、個人情報を渡す根拠を先に決めておきます。

読み手は、ドレスショップや衣装店で予約と在庫の帳簿を任されている方と、仕組みを組み立てる技術者を想定しています。個別のお店や式場の話ではなく、作る側が先に決めておく設計の考え方を並べました。

ドレスショップの在庫と予約は「1着ごと×期間」で管理する

ドレスの在庫は、デザインごとの数ではなく、1着ずつの記録として持ち、予約はその1着に対する「期間」として登録します。同じデザインでもサイズやお直しの跡が違い、どの1着がいつ店にあり、いつ外に出ているかが分からないと、重複予約は防げないからです。

小物（ベール、グローブ、アクセサリー）は、1点ずつ管理するほど高価でない物もあります。数量で持つ物と1点ずつ持つ物を、品目ごとに分けて決めておくと、台帳が細かくなりすぎません。

同じドレスの重複予約は、3つの場面で起きやすい

重複予約は、店頭・電話・Webなど受付の窓口が分かれているとき、手入れの期間を数え忘れたとき、キープの期限があいまいなときに起きやすくなります。どの場面でも、人が台帳を見て判断している限り、同時に二つの受付が通る余地が残ります。

紙の予約表や共有の表計算でも、一人が一つの窓口を見ている間はうまく回ります。窓口が増えたり、店舗が複数になったりした時点で、登録の瞬間に重なりを確かめる仕組みが要るようになります。

試着予約は、部屋・スタッフの枠とドレスの所在の二つで受ける

試着の予約は、試着室とスタッフの空きと、試着したいドレスがその日に店にあるかの二つを確かめてから受け付けます。部屋が空いていても、目当ての1着が貸し出し中やお直し中なら、来店しても着られないからです。

1. 部屋とスタッフの空きを見る。 試着室ごと、時間帯ごとに枠を持ち、着付けのできるスタッフのシフトと合わせる
2. 試着したいドレスを選んでもらう。 Webで受ける場合は、デザインを選んでもらい、店に戻っている1着があるかを確かめる
3. 所在が合わない1着は外して見せる。 貸し出し中・お直し中・クリーニング中の1着は、その日の試着の候補に出さない
4. 予約が入ったら、その1着に試着の印を付ける。 本番の押さえとは別の記録にして、同じ日に別店舗へ移さないようにする

試着の予約は来店の約束であって、ドレスを決めたわけではありません。そのため、試着の予約だけでは本番の期間を押さえず、決めた時点で次の節の押さえに進みます。

本番の貸し出しは、挙式日の前後に準備と手入れの日数を足して押さえる

本番の貸し出しの押さえは、挙式日の一日だけでなく、準備・配送・返却・クリーニング・検品の日数を前後に足した期間で登録します。挙式日だけを見て重複を確かめると、返却直後で手入れの終わっていない1着に、次の予約が入ってしまうからです。

前後の日数は、ドレスの素材や、クリーニングを外に出すかどうかで変わるので、品目ごとに決められる作りにします。データベースにPostgreSQLを使うなら、1着ごとに期間が重ならない制約をかけられます。

-- 1着ごとに、キープと確定を合わせて期間が重ならないようにする例
CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE dress_hold (
  id        BIGSERIAL PRIMARY KEY,
  dress_id  BIGINT NOT NULL,          -- 1着（個体）の管理番号
  customer_id BIGINT NOT NULL,
  period    DATERANGE NOT NULL,       -- 前の準備〜後の手入れまでを含めた期間
  status    TEXT NOT NULL,            -- keep（キープ）/ fixed（確定）/ released（解除）
  keep_until TIMESTAMPTZ,             -- キープの期限
  EXCLUDE USING gist (dress_id WITH =, period WITH &&)
    WHERE (status IN ('keep', 'fixed'))
);

空きを画面で見てから書き込む作りだけでは、二人のスタッフが同時に同じ1着を押さえたとき、両方の登録が通ってしまいます。最後の砦をデータベースに置いておけば、受付の窓口がいくつ増えても、同じ1着の期間が二重に入ることはありません。

キープ（仮押さえ）には期限を付け、期限が来たら自動で外す

お客様が迷っている間のキープは、期限を決めて登録し、期限を過ぎたら自動で外して、担当スタッフに知らせます。期限のないキープが残ると、そのドレスを着たい別のお客様を断ることになり、店にとっても機会を逃すことになるからです。

期限が切れて押さえが外れたことを、スタッフが知らないままお客様に「キープしてあります」と案内してしまう行き違いは、何より防ぎたいところです。解除の処理と知らせは、一続きの処理として作ります。

ドレスの状態は一つの項目で追い、所在を見失わない

1着ごとの状態は、「店にある」「貸し出し中」「手入れ中」のように一つの項目で持ち、変わるたびに履歴を残します。状態が分かれた複数のチェック欄で表すと、「貸し出し中なのにクリーニング中」のような矛盾が生まれ、所在が分からなくなります。

複数の店舗でドレスを融通し合うなら、状態とは別に「どの店舗にあるか」も持ちます。移動中の1着は試着の候補に出さないようにしておくと、来店したのにドレスがない、という事態を防げます。

提携式場との連携は、挙式日の変更を受け取る経路と、情報を渡す根拠を先に決める

提携式場と連携するときは、挙式日の変更やキャンセルを店がどう受け取るかと、お客様の情報をどんな根拠で渡し合うかを、仕組みを作る前に決めます。挙式日が動いたのに店の押さえが古い日のままだと、新しい日には別のお客様の予約が入っている、ということが起きるからです。

式場の仕組みとデータを直接つなぐ場合は、送られてくる挙式日の変更を自動で反映させず、店のスタッフが確かめてから押さえを動かす作りが安全です。変更後の期間に別の押さえが重なっていたら、その場で知らせが出るようにします。

既製の予約システムで足りるか、作るかを見分ける

既製の予約システムで足りるかどうかは、1着ごとの期間の押さえと、前後の手入れ日数、キープの期限を、その製品が扱えるかどうかで見極めます。来店予約だけを扱う製品では、試着の枠は取れても、ドレスの貸し出し期間の重なりまでは管理できないことが多いからです。

株式会社bundlyzeでは形の違う予約を業種ごとに扱える管理システムを企画し、運用の段階まで自社で開発しています。ドレスのように「1点ものを期間で貸す」予約も、同じ考え方の上に組み立てられます。帳簿の単位や押さえの持ち方から話し合いたいなら、予約や在庫の仕組みづくりの窓口（bundlyze）に相談の始め方を載せています。

出典

下の2件は2026年10月3日に読んだ内容です。改正で記述が変わることもあるので、設計を確定させる時点でもう一度目を通してください。

• 個人情報保護法の通則編の指針（個人情報保護委員会）：3-6-1 第三者提供の制限の原則、3-6-3 委託・共同利用など第三者に当たらない場合
• 同委員会が公開しているQ&A：共同利用する者の範囲の示し方