昔経験したバグの話
1. はじめに
筆者は、バグの事象を調べることが好きである。例えば、動画サイトなどでゲームのバグ動画を調べ、「なんでこんな事が起こるのだろう?」などと考える。
バグの大半は、些細なミスが原因であるが、外部事象を確認すると非常に不可解に見える。今回は、筆者のライフワークであるバグを題材として、筆者が経験したECサイトのバグの話をまとめたいと思う。
2. ECサイトとは
2.1 ECサイトの概要
ECサイトとは、Webサイト上から商品を購入できるサービスである。ECサイトを使用すると、ユーザは店舗に行くことなくいつでもどこでも商品を購入することができる。
かつて、商品を購入する時は実店舗に足を運び、その中から商品を購入する必要があった。店舗に行くには時間がかかるし、目当ての商品がない場合は、商品を購入できず無駄足となることもあった。
ECサイトの最大手が、「Amazon」「楽天」だろう。これらのサービスを使用すれば、サイト上にある商品であれば、いつでもどこでも商品を購入することができる。今現在は、小規模事業者でもECサイトを持っており、日本中のユーザからの注文に対応することができる。
2.2 ECサイトの動作フロー
一般的なECサイトの購入フローは以下のようになっている。
(1) 欲しい商品を商品をカートに入れる
(2) カートに入れた商品を購入方法を決定する
例:配送先、決済方法(クレジットor代引き)
(3) 購入を確定する
ユーザが欲しい商品をサイトから見つけ、カートに入れる。カートに入れた商品の個数を決定し、購入ボタンを押下する。その後、配送先や決済方法を決めると、決済完了である。その後、自宅に商品が届く。
3. バグの事象
いよいよバグの話である。
過去のバグの事象を下記にまとめる。
3.1 事象
今回のバグの事象は、「在庫無限状態の商品を購入する場合、マイナスの在庫数となった在庫減少メールを運用側に送信する」である。また、在庫無限の商品の在庫を運用側から修正することができない。
例:
メールの文面:
「商品○○の在庫が-10となりました。」
3.2 回避策
商品データベースにアクセスし、該当する在庫を別の値に変更する。
3.3 当事象発生時の損害
ユーザと運営者ともに金銭・セキュリティ的な損害はなし。ただし、在庫減少メール送信時にマイナスの在庫を送信するため、運用担当者が混乱する。
3.4 前提知識
本事象を知るうえで必要な前提知識をまとめる。
3.4.1 在庫無限商品とは何か?
今回の事象は、在庫無限の商品のみで発生する。「在庫無限」とは何かというと、在庫が事実上存在しない商品である。例えば、商品の包装する紙などに該当する。このような商品は、厳密には在庫がある。しかし、在庫が無限の商品として考え、在庫無限状態で運用する。
在庫無限商品であっても、データベース上は普通の商品と変わらない。違うのは、在庫無限フラグが付いているかどうかである。
3.4.2 在庫減少メール
在庫減少メールとは、ユーザが購入時に在庫数が一定数以下となる場合は、在庫状況を運用側に知らせるメールである。運用担当者は、このメールを確認し、商品の仕入れに役立てる。
3.4.3 通常商品と在庫無限商品の在庫減少
通常、商品を購入すると、自動的にデータベースからその商品の在庫を減らす。例えば、在庫10の商品を2個購入すると、在庫が8となる。在庫が0の商品はそもそもサイト上に現れない仕様となっており、在庫切れの商品はそもそも購入することはできない。
一方、在庫無限商品では、在庫は無限であるため、何回でも商品を購入することができる。
3.4.4 在庫数の修正
通常商品の場合、運用側は在庫数を運用者の画面から修正可能である。在庫数の修正などの運用に必要な処理は、運用側の画面から修正できる。例えば、「在庫数10の商品を0に変更する」などは運用側の画面から自由に変更できる。
3.5 何が問題か?
3.4の事前知識をもとに何が問題かまとめる。
3.5.1 在庫数がマイナスになる
在庫無限商品では、在庫は無限であるが、在庫数は減り続ける(図1)。
図1は、在庫無限商品の購入フローである。例えば、在庫数が0の在庫無限商品を1個購入すると、-1となる。この際、在庫減少メールの閾値に入ってしまい、マイナスの在庫を送信してしまう。
また、通常商品では在庫が0の商品は購入できないが、在庫無限商品は在庫に関わらず購入することができる。
3.5.2 運用側から在庫数を修正できない
もう一点は、運用側から在庫数を修正することができない。これは、入力フォームに制限がかかっており、在庫数を修正することができない。結果として、データベース上から在庫数を修正しなければならない。
4. どうすればいいのか
修正方法はいろいろあるのだろうが、恐らく以下のように修正すると良いと思われる。
4.1 修正方法
・在庫無限の商品の場合は、在庫を減少しない
在庫無限の商品に関わらず、在庫が減少していたため問題となっていた。修正案としては、「在庫無限の商品の場合は、在庫数を減少しない」とする必要があるだろう。
4.2 運用でカバー
運用でカバーすることもできる。在庫無限商品の在庫数を1000などに設定しておくことである。これによって、当事象に関係なく対応できる。
5. 終わりに
今回は、昔経験したバグの事象をまとめた。ピンポイントで役に立つ話ではないけれど、自分の記憶の整理をすることができた。また機会があればまとめようと思う。
この記事が気に入ったらサポートをしてみませんか?