チケット予約サイトの仕組について

Question

私がよく利用するチケット予約サイトでは、予約を確定する直前のタイミングで整理番号が表示され、恐らくその時点で私のチケットの整理番号が確定します。
（そう考えるのは、私が利用した限りにおいて画面の表示された整理番号と実際の発券時で整理番号が変わったことが無いため）
この整理番号順で当日入場する順番が決まるので、整理番号はユニークかつ早く予約した人ほど若い番号になる仕様であることが要件となります。

一方で予約したものの、予約した人の決済忘れなど何らかの理由でキャンセルになる可能性があります。
しかし、一度使った整理番号がキャンセルによって空いたと言っても、その整理番号を使い回すのは明らかに不平等な結果を招きます。

すると、このような事象への対応としては、
・在席管理（満席管理）は、予約レコード件数なりで判断できるので整理番号は不要
・整理番号は順序性があれば欠番があっても影響は無い（１・３が居て２が居なくても問題はない）
ということから、全員の整理番号を見られるわけではないので事実は分かりませんが、
キャンセル等は欠番扱いにして、整理番号の欠番を許容しているのかなと推測されます。

一方で整理番号の欠番というのは生理的に若干の気持ち悪さを感じますし、
悪意のある人間が予約⇒キャンセルを連発すると、座席キャパが２００なのに整理番号が３００という明らかに違和感を覚える整理番号が発行されることになりかねません。

おおよそ開発者向けのサイトで聞くようなことではないかも知れませんが、
細かい実装はさておき、どのようなアイデアでこのような問題を解消することはできるようになりますでしょうか？

Answer 1

おおよそ開発者向けのサイトで聞くようなことではないかも知れませんが、
細かい実装はさておき、どのようなアイデアでこのような問題を解消することはできるようになりますでしょうか？

一方で整理番号の欠番というのは生理的に若干の気持ち悪さを感じますし、

「生理的な若干の気持ち悪さ」は具体的な悪影響（例えば販売率の低下）を招くものでは無いのでそもそも問題として扱わない

悪意のある人間が予約⇒キャンセルを連発すると、座席キャパが２００なのに整理番号が３００という明らかに違和感を覚える整理番号が発行されることになりかねません。

違和感についても同様

と言うのが一般的な実装になるかと思います。
工夫を凝らして違和感を排除したところで保守コストと潜在的なバグのリスクが大きくなるだけなので、よほどの理由が無い限りは欠番を許容すると言う仕様にするのが合理的です。

---

仮に解決策を模索するとして、生理的な気持ち悪さや違和感と言うのは万人が望む解決というのは非常に難しいです。

例えば、

• 連番の後に必要十分と思われる桁を付与しておく

例)席が200席ある場合、
100,200,300,400～20000 としておいて、2番目の整理番号にキャンセルがあったら201

とか

• そもそも連番にせずにランダムでユニークなIDにしておく

など出来るかと思いますが、これで違和感が排除できるかは人によります

---

こういった問題を解決しようとすると

1. 目的を具体化する
2. 目的をクリアしたとする計測方法とその閾値を決める
3. 現状と改善後を2の計測方法で計測して改善を進める

というステップを踏んで実装していく必要があります。
例えば

1. 目的を具体化する

購入者のうち大多数の人間が購入意欲の妨げになる違和感を感じない事を目的とする
2. 目的をクリアしたとする計測方法とその閾値を決める
購入者にアンケートを取って、得られた回答の2/3の人が違和感を感じなければOKとする
3. アイディア実装前後でそれぞれアンケートを取ってみる
クリアしなかったら次のアイディアを実装する

と言う感じになるので、トライアンドエラーを繰り返すしかなくなります。
（目的を例のように設定した場合は、おそらく初期状態でクリア出来ると想像しますが）

Comments

[Radec]

ご回答ありがとうございます。理想的には、例えばよく知られたライブラリの機能ないしはDBの機能としてこのような制約を解消する方法があれば知りたいというものではありましたが、
そのようなものは無く、個人の主観を排除し一般論で論じかつコストパフォーマンスも考慮すると、「欠番を許容とする仕様とすることが合理的である」というのは納得できるの回答と感じます（これも主観ですが）

ご提案の内容も解決はできるものの違和感を覚えるか？という問いとしてみると確かに個人の感覚によるなあと感じた次第です。

[maisumakun]

> 例えばよく知られたライブラリの機能ないしはDBの機能としてこのような制約を解消する方法があれば知りたい

根本的に「そのようなキーの順序に意味をもたせる」こと自体が、ほとんどの場合に適切ではありません。「SQLアンチパターン」という本でも取り上げられています。

https://qiita.com/fatomy/items/42f33246b23d40859f46

宝くじのバラ/連番とか、限定生産の製品のシリアルナンバーとか、「番号そのものに価値がある」状況であれば別として、便宜上振られる番号にそこまでの工数をかける意味は、ほぼありません。

[maisumakun]

今回の場合、「初期値を15894のように、じゅうぶん大きくしてから始める」でも違和感は軽減できる気がします。

[tanat]

> Radecさん

フィードバックありがとうございます。

> 例えばよく知られたライブラリの機能ないしはDBの機能としてこのような制約を解消する方法があれば知りたいというものではありましたが、

番号再利用以外の最終的な解決方法が明確で無く、番号の再利用は避けるべき実装である以上、汎用的なライブラリやDBの機能として実装されるのは難しい様に思います。
（「整理券発行システム」の様な具体的なアプリケーションの機能の一つとして実装されているケースはあるかもしれませんが、あくまでアプリケーションでの実装の範囲を出ないと思います）

[tanat]

> maisumakunさん

補足ありがとうございます。
私も「根本的に「そのようなキーの順序に意味をもたせる」こと自体が、ほとんどの場合に適切ではありません。」が全てかなと思います。
初期値を十分に大きくするというのは色々なところで見かけますね。