NOT A HOTEL予約の自動移動

こんにちは！
NOT A HOTELでSoftware Engineerをしております、@hokutsです。

この記事では、ホテル予約のアプリなどで、特定の部屋について「この日付は予約できるのか？」を判定するロジックの話を緩く書きます。

部屋タイプ

ある程度の規模のホテルだと、同じタイプのお部屋がたくさんあり、ユーザーは部屋番号ではなく部屋の「仕様」を指定して予約することが多いと思います。「シングル・禁煙」のような形ですね。

部屋在庫

こういった部屋の空き状況を管理する最も簡単な方法は、下記のような形で「各部屋タイプの残り空室」（=在庫）を日毎に管理するやり方です。

日付は宿泊日（夜を過ごす日）基準で、チェックアウト日は考慮しません。これを元に例えば「11/2にシングル禁煙の部屋は予約できるか？」を判断し、予約が入ったら、そこの在庫を減らしていきます。

しかし本当にこんな単純なやり方で判定は可能なのでしょうか？
同じタイプの部屋が3つある例で、下記のようなパターンを考えてみましょう。青がすでに入っている予約です。

12/2、12/3、12/4の在庫数が1になっています。この辺の日付に1泊の予約を入れられることはすぐにわかりますね。空いてるところに予約を入れればいいだけです。
では、「12/2から同じ部屋に3泊の予約」は入れられるでしょうか？

前提として、既存の予約をしたユーザーは部屋番号を指定しているわけではないので、同じタイプの部屋同士であれば、運営側の都合で未来日の予約を自由に移動させることができるとします。
この3泊の予約を入れるには、既存の予約を並べ替えて同じ部屋が3日連続で空いている状態を作る必要があります。この表に書き切れていない12/11以降にも各部屋にどんな予約が入っているかわからないとして、並び替えれば必ずうまくいくのかどうか、が問題です。

下記のように考えることができます。

802号室が3日連続で空くようにしてみます。
まず、803号室の12/3の空室を、802号室に移動させたいですよね。

これは実は簡単で、802号室と803号室で、12/3以降のすべての予約を入れ換えてしまえばよいです。

一つ一つの予約をパズルのようにどう移動するかを考える必要はなく、12/11以降にどれだけ予約が入っていようとも、それらをすべて、丸ごと入れ換えてしまえばよいです。
この状態から、同じように12/4以降で801号室と802号室の予約をすべて入れ換えてしまえば、下図のように802号室を3日連続空室にできます。

このように考えると、特定の未来日に予約できるかどうかは、残り在庫さえ見れば判定できそうです。
つまり、アプリなどでの予約時点では、実際に部屋を割り当てる必要も、既存予約の並び替えを実行する必要もないことになります。

在庫数のみでは対処できないパターン

ただし、この方法は下図のようなパターンには対応できません。

801号室の12/9に、移動できない「工事」が入っていて、ほかの部屋の予約をここに移動することができません。
在庫管理によってこのような問題に現実的に対応するには、在庫数を少なめに設定しておき、手動で管理するなどの方法が必要になります。
実際の大型ホテルでは、予約を管理する担当者が経験則から当日キャンセルなども考慮して受け入れ可能数をコントロールするといった運用もされているようです。これは当日にも一定の空室が出ることを許容した、大型ホテルならではのやり方だと思います。

NOT A HOTEL

NOT A HOTELの場合、そもそも「同じタイプの部屋」がない物件も多いのですが、間取りや利用ルール（ペット可かどうか）が同じというところも存在します。
通常のホテルと違うのは下記のような点です。

• 同じタイプの物件が2つのみなど、少なめ

• オーナーの予約は所有されている物件に固定する必要がある
  ※契約にもよる

• 1つの物件の予約を受けられなかった場合の損失が大きい

NOT A HOTELのオーナーはその物件を購入されており、物件によっては専用のロッカーなどもあるため、間取りなどが同じだからといって運営の都合で予約を動かすことはできないケース（契約）が多いです。

一方でオーナー以外の予約については基本的に動かすことが可能です。（例外もわりとあるのですが長くなるので省きます。）しかし新規予約が受け付けられるかを在庫数で判定することは難しいです。部屋数が少ないことや、一物件あたりのコストが高いこともあり、空き部屋が出ることを覚悟の上での運用もビジネスとして現実的ではありません。
動かせる予約と動かせない予約が混在しているため、NOT A HOTELでは下記のような方針をとっています。

• すべての予約について、予約時点で物件を割り当てる

  • オーナーの場合は確定（移動不可）

  • オーナー以外の場合は基本的に仮状態（移動可）

• 新規予約時、既存予約の並べ替えを試み、予約可能かどうかを判定する

実際の画面

オーナー以外が宿泊する例として、相互利用（オーナーが所有物件の宿泊権を消費して他の物件に宿泊する方式）というのがありますが、下図はその場合の予約を受け付けるカレンダーUIです。

同じタイプの物件が2つあるところを予約しようとしているとします。
カレンダーUIで、チェックイン可能な日付を取得するのは比較的簡単です。2つの物件のうち、どちらかが空いている日付を取得すればよいです。上の画面はそれを表示したものです。
そして、チェックイン日を選んだ状態が次の画面です。

チェックイン日を選ぶと、チェックアウト可能な日付を表示する必要がありますが、これが少し大変です。連泊可能かどうかを判定するために、「既存予約の並び替えによって空室になるか？」を各日で判定する必要があるからです。
愚直にやると計算量が膨大になってしまうため、再帰処理で深さをコントロールしたり、二分探索を駆使するなどして工夫しています。
このあたりは、要件となるパターンも年々増えているところなので、処理の効率化を含めて議論が進んでいる部分でもあります。

カレンダーの時点では実際には並び替えは行いませんが、予約を入れる時点で既存予約を並べ替え、空いた物件と日程に新規予約を割り当てることになります。

まとめてみる

NOT A HOTELはビジネス設計が複雑なので、カレンダーUIを表示するだけでもかなり複雑なロジックが動いてたりするのですが、その中でもよりドメイン依存が少なくシンプルな話題として、予約の並び替えについて書いてみました。読み物として楽しんでいただけていたら嬉しいです。