こんにちは、先月結婚式を挙げて一息ついた AI・機械学習チームの苅野(@hkford3)です。 このブログはAI・機械学習チームブログリレー 3日目の記事です。前日は@inakam00が結婚式をLINE BotとAIでエンジニアリングしてみた話でした。今日の記事も結婚式の話です。結婚式はなんぼあってもいいですからね。
結婚式の受付では新郎新婦の知り合いが担当する受付で名前を名乗り参列登録することが多いです。名前を聞き返したり漢字を聞いて名簿と照会したりと意外と受付はやることが多くて大変そうでした。そこで受付の負担を減らそうと思い QR コードで受付登録ができるアプリを作ったところ、期待とは逆に苦戦してしまった話をします。
作ったアプリ
Next.js のアプリを作って PC でローカルで動かすようにしました。どこかのクラウドにアプリをホストすればそれっぽかったんですが、会場でWi-Fiが使えるか分からなかったので（まあ当日フタを開けてみれば、回線品質どうこう以前の問題だったんですが…）。
処理の流れ
アプリには大きく分けて 3 つの機能があります。
- 受付登録: QR コードをかざすことでその人の参列登録が完了する
- ご祝儀受領: 受付の人間が参列者の画面からボタンを押すとその人からご祝儀をいただいたことになる
- 登録確認: 参列予定の人全員の参列登録を一覧で表示する
細かい話ですが受付登録は HTML フォームを使って行うのでクライアント側で実行する必要があるため Client Components として、登録確認は json ファイルを読み込むのに fs モジュールが必要なため Server Components として実装する必要がありました。この処理ってどこで行うんだっけというのを意識しながら実装しないといけませんでした。
データストア
かっちり作るならローカルで DB コンテナを動かしてバックエンドの API を作ってやるでしょうが今回は json ファイルを読み書きすることにしました。クライアントは PC 一台で同時にアクセスすることはないですし、最悪エディタでJSONを直接編集すればいいと考えるとこの方が楽でした。Server Actionsで参列登録する方の id をキーにして json ファイルを更新することにしました。
QR コード
事前に参列者に配布する QR コードは Rust のqrcode crate を使って参列者の名前を元にハッシュ化して QR コード png で生成しました。受付に使う入場券的なもののテンプレートは妻が Canva で作ってくれたので人力でテンプレートに QR コード画像を貼り付けて完成です。
私が Amazon で買った QR コードリーダーは QR コードをかざすとデコードしてデコードした文字列を標準入力で渡してくれます。購入したQRコードリーダーをPCに繋ぎ、HTMLフォームにカーソルを合わせておけば、QRコードをかざした時にデコードされた文字列が自動で入力され、アプリ側でよしなにハンドリングできるよう設定しました。
ポストモーテム
全員分の QR コードで動作確認して正常系では動くことを確認した後で式本番を迎えました。新郎新婦が写真撮影やら親族挨拶やらをしている最中受付はどうなっていたかを聞いたところなかなかカオスな状態になっていたようでした。
「QR コード？ 受け取ってませんけど」
凝り性の妻が本物の航空券のように入場券を作り込んだところ、入場券を LINE で受け取った人の中から「私たちは新幹線で行くので航空券は不要ですよ」と言う人が出てきました。受付の余興で使う QR コードのつもりの新郎新婦と、お車代の代わりに航空券を取ってくれたんだと思う参列者のすれ違いが生んだ悲劇で、受付は混乱し列が伸びていきました。
思わぬ伏兵: ご祝儀
結婚式の受付では、参列登録だけでなく、人によってはご祝儀の受け取りも発生します。催促するのも良くないと思い参列者からご祝儀をいただいた場合に限りアプリでその参列者からご祝儀を受け取ったと登録するフローにしてました。式当日はアプリが動いている PC が一台しかないので列が渋滞し、QR コードで登録した方はすぐに横にどいてご祝儀を出してくれます。
AさんがQRコードをかざして登録完了、と同時に隣でご祝儀を手渡す。その瞬間に次のBさんがQRコードをかざし、アプリの画面はBさんに切り替わる。Aさんからご祝儀をいただいたことを登録しようにも画面はBさんの画面になっていて途方に暮れる、という事態が頻発しました。さらに悪いことに、アプリには一度ご祝儀の受領処理を行うと取り消せないという致命的なバグが混入していました。先ほどの例で言えば、誤ってBさんのご祝儀登録処理を行ってしまうともう元には戻せない状態でした。
紙と json どちらを信じるか
当日アプリがトラブったらデータの管理は json なので最悪 json を直接編集すればいいですよと受付には伝えていました。途切れない参列者の列とご祝儀の束を前に json をエディタで編集する余裕があるはずもなく、結局会場が用意した紙の参列者管理表が single source of truth になり後日受付をしてくれた先輩からは「json ファイルは確実に間違っているので紙の情報を信じるように」と言われました。こうして新郎の自己満足アプリは現場に混乱だけをもたらしてその役目を終えました。
振り返り
そもそも『紙』で良かったのでは…という身も蓋もないツッコミは置いておいて、ご祝儀の管理をアプリでやらなければ良かったかもしれません。そうすれば参列者は QR コードをかざすだけで受付が完了し、横のトレーに渡す人はご祝儀を渡してそのまま待合室に行くことができました。ただそうするとご祝儀の管理に紙が必要でアプリを作っても受付が楽にならないので、やっぱりそもそも紙管理で良かったです。現場のことを考えずにツールを作ってもなかなかうまくいかないことがわかりました。
アプリは受付を掻き回しただけだったわけですが、参列者の登録がうまくいったのは受付をしてくれた新郎新婦の先輩と友人四人のおかげです。まるで学園祭の出店のように、臨機応変に受付をさばいてくれました。二次会で話したときは大変だったけどなんとかなったよと言ってくれてホッとしました(目は笑ってなかった気がしますがきっと気のせい)。
We are hiring!
エムスリーAI・機械学習チームでは、現場が使いやすく価値を生むような開発をしていく意欲のあるエンジニアを募集しています。 新卒・中途それぞれの採用だけでなく、カジュアル面談やインターンも常時募集しています。
