4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ChompyAdvent Calendar 2023

Day 21

座席統合・移動機能について

Last updated at Posted at 2023-12-22

Advent Calendar 2023 Template.png

この記事は、Chompy アドベントカレンダー 21日目の記事です。

はじめに

はじめまして。エンジニアのKazukiです。
Chompyには、約3年ほど前にGoを勉強し始めて間もない頃にインターンとしてジョインしました。今はバックエンドに限らず、Webやモバイルのフロントエンドも含め開発に携わっています。

Chompyでは、飲食店に関わる様々なシステムを開発しており、その1つとして、飲食店に特化したレジ × ハンディ × CRMツールであるChompy Studio(以降Studio)を提供しています。

概要

今回は、そのStudioの機能として開発した座席の統合・移動機能について書いていきたいと思います。
恐らくみなさん馴染みがあるように、飲食店では、4名の来店客用に2名席をくっつけたり、途中から人数が増えたので大きい席に移動したりというオペレーションが発生します。今回の座席統合・移動機能はそれを店舗のデジタルツール上で管理できるようにするためのものです。Studio上で統合されている卓が分かることで、商品の提供タイミングをコントロールしたり、各スタッフが移動後の空席状態の把握等に役立ちます。

座席統合・移動は飲食店のオペレーションとしては馴染みがありますが、
それをシステム上実現するには考慮する点が多く、既に注文が入っている卓同士は統合してしまって良いのか、統合ミスのリスクをどのようにカバーするか、移動・統合が複数回行われたときに問題が起きないか、など様々な懸念がありました。ここからはどういう仕様・実装方針でこの機能を開発したのかについて書きます。

仕様について

つらつらテキストで書くより実際の機能を見せた方が仕様のイメージがつきそうなので、簡単に機能をお見せします。

1つの画面で統合・移動のどちらもすることができ、元々選択していた座席以外が選択されれば移動、元々の座席も含めて他の座席が選択されていれば統合になります。

Screenshot 2023-12-22 at 15.11.39.png
※画像は統合のパターン

実装について

イメージ感がざっくり掴めたところで、実装について書きたいと思います。

今回行った実装について話す前提として、注文と座席がどう管理されていたのかについて軽く触れます。Chompyでは、注文のエンティティ(Order)と座席のエンティティ(Table)があり、
Orderが紐づいているTableの情報を持つことで、座席と注文を1対1の関係性で紐付けて管理していました。

ここまで座席の統合・移動と一括りに呼んできましたが、実際には統合と移動で難易度がだいぶ異なります。

移動
座席の移動は比較的簡単で、移動元のOrderの紐づく座席を変更し、もし移動先に既に注文があれば、移動先の注文も吸収する。移動は、OrderとTableの関係性が1対1で変わらないため、既存の実装の延長で比較的容易に実装できました。対して考慮する点が多かったのは統合の方で、統合側の実装に関して話したいと思います。

統合
統合に関しては大きく2つの実装方針がありました。1つは、Orderが統合されたTableの情報も保持し、1対多の関係(親Tableと統合された子Table)で管理する。もう1つは、OrderとTableの1対1の関係性を残したまま、統合状態は別のコレクションを作って管理する。という方針の2つです。
最初は前者の方針で実装を進めていたのですが、1つ詰まりポイントになったのがQRコードを読み込んでのWebオーダーへの対応です。Chompyの提供サービスとして、卓上のQRコードを読み込むと卓番号が指定された状態で注文が行えるWebオーダーがあります。
基本的にQRコードは卓ごとに配置されてあることから、A,B,Cの3卓が仮に統合されていたとしても、どの卓のQRコードから注文が入るのかはわからないので、OrderとTableは1対1の関係性を保った方が楽にその点クリアできるのではないかということで、後者の方法で実装を検討し直しました。が、実装を進めていくと注文した商品の履歴や会計処理など、1つのOrderに対する操作を前提として作られている画面を複数のOrderにも対応させるのが非常に困難なことが分かり、統合時にOrderを1つにまとめる前者の方針に落ち着きました。問題であったQRコードを読み込んでの注文への対応は、統合されている卓のQRが読み込まれた場合には、選択している座席をバックエンド側で親の卓にセットする形で、親のOrderに注文が追加されていく形にしました。

(文章に起こしてみると、そんなに悩む点でもなかったかなwと思ってしまうのですが、こういう判断がもっと早く正確にできるようになっていきたいですw)

終わりに

この機能は統合も移動もログが残るようになっているんですが、ログを見ると日常的に使われていて、顧客が必要なものを作れている感があり嬉しいです。ただ、現時点で100%完成しているとは言えない機能で、個人的には近い将来、統合や移動をミスってしまった時に復元を簡単にする分割機能が作れたらいいな〜と思っています。割に長文になってしまいましたが、ここまで読んでいただきありがとうございました。

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?