リテール導入で発生した問題、改善するためにシステムの強化へ
今回登壇したのは、出前館のプロダクト本部 マーチャント部 マーチャント連携開発グループに所属する三木一馬氏。出前館と加盟店間のAPI連携機能の開発や運用、AWSのインフラ構築などを担当している。
出前館のサイトやアプリにおけるリテール対応と聞くと、ユーザー向けのtoC部分がイメージされるが、実は加盟店ドメインなどBtoBの領域も多い。実際に出前館で注文した後、ユーザーに配達するまでの流れを表したのが、以下の図である。そこには大きく分けて3つのドメインが存在する。
主にユーザーとのやり取りを行う出前館の「サイト・アプリ」、飲食店などの加盟店とのやり取りを行う「加盟店」、商品を届ける配達員とのやり取りを行う「デリバリー」ドメインである。
現在、出前館ではフード加盟店に加えて、リテール加盟店の導入も進んでいる。リテール加盟店とは、食料品や日用品を扱うコンビニエンスストアやスーパーマーケット、医薬品を扱うドラッグストアなどである。三木氏いわく、「従来のフード加盟店とは異なる部分が多く、さまざまな課題が発生していた」という。
当初のリテール店舗における運用フローは、出前館ユーザーが商品を注文すると、出前館で注文の受付処理が行われ、その後小売り店舗にあるタブレットアプリに注文情報が連携される。店舗のスタッフがその商品をピックし、配達員が店舗でピックされた商品を受け取り、ユーザーのもとへ届ける流れであった。
商品の欠品があった場合は、店舗スタッフが出前館のタブレットアプリに該当商品の品切れを設定する。出前館サイト上では品切れ表示となり、その商品を含む注文はできなくなる。
だが、リテール店舗では取り扱う商品数も多く、品切れや解除の設定を一つひとつ手動で行うのは店舗スタッフの業務負荷が高くなる。さらには、品切れ対応の遅れや漏れは、カスタマーセンターの対応コストやUXにも悪い影響を及ぼす。
そこで三木氏ら開発チームは、加盟店側にある在庫データをもとに出前館の品切れを設定できるAPIを作成し、システム化を行った。品切れ設定や参照用のAPIを新たに開発し、加盟店側の在庫データをもとに、定期的に品切れ設定APIを呼び出す仕組みである。システム化によって品切れ設定業務が自動化され、業務負荷を軽減することができた。
だが、品切れの設定を反映する在庫連携バッチは数分間に1回起動する仕様だったため、その間にユーザーが注文することができてしまい、注文後に実は欠品だったという事象も発生してしまう。そのため、在庫が少なくなってきた段階で、出前館上で品切れ設定にする必要があった。そこで、店舗で在庫をゼロまで売り切ることができないという課題が出てきたのである。
この課題に対しては、注文時に在庫の存在をAPIで問い合わせる機能を追加することで、欠品商品の注文を防ぎ、加盟店としては在庫が最後まで確実に売り切れるように対策した。
まず、決済画面遷移時に店舗側システムに対して、APIでリクエストを行い、販売可否APIが加盟店側の在庫が存在していることを担保する。注文確定時に店舗がシステムに対して再度APIリクエストを行い、在庫引当APIで加盟店側の在庫数を担保した上で、在庫販売した分だけマイナスさせる仕組みだ。
さらに、ユーザーが参照するUI上の品切れ設定の反映ラグと決済エラーを繰り返す状況にも改善を加え、ユーザーの決済時販売可否APIのレスポンスが在庫なしの場合、その商品を即座に品切れの状態にするような処理を追加した。このようにさまざまな課題を解消して、最終的に完成した処理の流れが以下の図である。
