オークの国のレストラン予約サイトの設計に関する考察

はじめに

この記事は 一休.com Advent Calendar 2025 の7日目の記事です。

『オルクセン王国史』、おもしろいですよね。
作品の舞台であり、主人公たるオーク王グスタフが統治する「オルクセン王国」は、我々の住む世界とは異なる下記のような特徴を持っています。

• 大柄で食欲が非常に旺盛なオークを中心とした魔種族国家である
• ドワーフやコボルトなど、体格・文化・食習慣の異なる種族も共存している
• 長命種が人口の多くを占める

私の知る限り作中では描かれていませんが、食にこだわりの強いオークの国なのできっとオルクセン王国にもレストラン予約サイトが登場することになるでしょう。
今回は、そんなオルクセンの予約サイトの設計について考察していきたいと思います。

予約の来店人数のモデル

一般的な予約サイトでは、予約の来店人数のモデルはだいたい下記のようになっているはずです。

human_people_count.ts

type PeopleCount = {
    adult: number // 大人の人数
    child: number // 子どもの人数
}

これに対しオルクセンでは、店舗が体格や文化の全く異なる種族の来店に対応したオペレーションを行うために必要な情報として、種族別の人数を構造化する必要があるでしょう。

orc_people_count.ts

type PeopleCount = {
    orc: {
        adult: number
        child: number
    }
    dwarf: {
        adult: number
        child: number
    }
    kobold: {
        adult: number
        child: number
    }
    // ...
}

さらに、同一種族であっても体格や大食い／小食の差異がものすごく大きいということがありそうなので、それを表す構造の導入も考えられます。
ここまでやるとしたら、うまくユーザーに入力させるためのUIの工夫なども別で必要そうですが、そちらは今後の研究に譲ります。

orc_people_count2.ts

type PeopleCount = {
    orc: {
        adult: number[] // 個人差を調整する係数の配列（length=人数）。例: [1, 0.7, 1.5]
        child: number[]
    }
    // ...
}

キャパシティのモデル

一般的な予約サイトでは、単純化すると「キャパシティ = 総席数」と「予約が消費するキャパシティ = 来店人数」の計算によって予約の可否を判定して予約画面に○／×を表示したりすることができます。
これに対し、オルクセンでは前項で述べた種族別の考慮が必要となります。そのためのモデリングとして、「キャパシティ = 面積」、「予約が消費するキャパシティ = 種族面積係数 × 人数」というものが思いつきます。

capacity.ts

// 種族ごとの、1人あたりが占める面積を調整する係数（オーク基準）
const ORC_FACTOR = 1.0
const DWARF_FACTOR = 0.5
const KOBOLD_FACTOR = 0.3

// PeopleCount の定義は orc_people_count.ts のものとする
const consumingCapacity = (p: PeopleCount): number =>
    ORC_FACTOR * p.orc.adult
    + DWARF_FACTOR * p.dwarf.adult
    + KOBOLD_FACTOR * p.kobold.adult
    // + ... 

しかし、これでは不十分です。まず、最終的に座る席は離散的なものだから連続値では扱えないだろうというツッコミどころがあります。また、それをなんとか克服したとしても、たとえば次のようなセッティングの店舗に対応できないという問題が残ります。

• カウンター席は、どの種族であっても1席に1人座れる
• ソファ席は、設備の耐久性的にコボルト以下の体格の者しか座れない

こうしたことを考えると、オルクセンのレストランのキャパシティは単純な数として表すことはできず、個別具体的な席ごとの制約の積み重ねとして表すしかなさそうです。
予約1件ごとにちょっとした最適化問題を解く必要があるということになるかもしれません。

サービスのカバー範囲

ここまでを総合すると、オルクセンではレストラン店舗オーナーは予約サイトのセットアップ時に微に入り細を穿った設定をする必要があります。それを考えると、オルクセンのレストラン予約サイトは、ただ予約ができるだけではなくレストランの業務全体を包括的にカバーするサービスとして発展する傾向が強いでしょう。
店舗オーナー側はいちいち複数のサービスで細かい設定をするのは面倒なので1つのサービスに集約したいと思うはずですし、サービス提供者側も予約受付設定のために収集した店舗の業務知識を抜け目なく利用してプロダクト開発を行い、アップセルを狙うに違いありません。
まだ触れていない観点では、長命種が多いことからリピーターの獲得が売上に与える影響など経営上のファクターとして相当大きいものになるため、CRMもサービスに組み込まれるでしょう。統合されたCRM機能の支援のもとで、我々の世界で言う「Googleマップのクチコミに全レス」みたいなことをするのがオルクセンでは常識ということになっているかもしれません。

まとめ

レストラン予約サイトの設計なんて決まりきっていると思っていましたが、それは人間世界という強力な前提に基づくものであって、当たり前ではないということに気づかされました。

参考