ハンディターミナルを用いたデジタルチケットシステム開発【DeNA TechCon 2023】

youtube：https://youtu.be/mwQMWaq1vAE

概要：
本発表では我々が開発したデジタルチケットシステムについて紹介します。横浜DeNAベイスターズはこれまで紙チケットによる入場管理を行ってきましたが、現在二次元コードを用いたデジタルチケットの導入が検討されています。

通常のモバイルアプリケーションとは異なり、業務用ハンディターミナルであるためハードウェアに依存した問題が発生しえます。また、チケットシステムのため、随時サーバーとの接続が必要で、屋外での利用も見越した通信環境問題などにも対応する必要があります。このようなデジタルチケットシステム開発を通じて得られた通常のモバイルアプリケーションとは異なる要件への対応、業務用ハンディターミナルを用いた開発の難しさ、Android の USB 周辺機器の対応などについて紹介します。

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2023 公式サイト
https://techcon2023.dena.dev/

Transcript

1. ハンディターミナルを用いた デジタルチケットシステム開発
2. Table of Contents • プロジェクトについて • システム構成 ◦ サーバ ◦ 端末 ◦ もぎりアプリ • 端末選定 • 評価 • Androidの USB機器の対応 • まとめ 2
3. プロジェクト概要 • 横浜DeNAベイスターズでは従来全て紙チケットによる入場管理が行われていたが、2023年 よりデジタルチケットシステムを導入する • 目的 ◦ チケットレスで入場することによるユーザー体験の向上 ◦ もぎりや集計、分析などのチケット関連業務の負担・コスト軽減 • スケジュール ◦ 開発開始 2022年 7月 ◦ 端末選定 2022年9月末 ◦ ファンフェスティバルでの試験 2022年 11月末 ◦ 本格運用 2023年 2月初旬 3
4. システム要件 • 二次元コードをデジタルチケット認証機にかざし入場できるかどうかを判定する ◦ スマートフォン ◦ コンビニ発券のチケット ◦ 印刷した紙 • 副券・アドオン券を扱える ◦ 入場券と併売されるグッズや飲食の引換券のこと • オフラインでももぎりを行える ◦ システム障害, 通信障害があった場合でももぎりが行える • 同行者に簡便に分配することができる 4
5. デジタルチケットシステム • 来場者が自身のスマートフォンに表示した二次元コードを専用端末にか ざし、入場を行う • 正しいチケットであれば入場を許可し、そうでなければその旨を来場者 に知らせる 5
6. 紙チケット • コンビニエンスストアで発行可能な紙チケット • 従来の紙チケットに二次元コードが追加されたもの • スマートフォンに表示するよりもかなり小さい 6
7. オフライン対応 • ハンディ端末は原則オンラインで動作するが、システム障害やネットワーク障害を考慮し オフラインでも動作するように設計を行った • Firestore native mode ◦ 特にコードを追加することなく、オフラインでも同様に動く ◦ オフラインで変更されたデータは、再度オンラインになった場合ローカルデータとク ラウド上のデータが同期される 7
8. システム構成 8
9. サーバ構成 • 機能 ◦ 電子チケット情報管理 • 構成 ◦ Google App Engine ◦ Go ◦ Firestore 9
10. もぎりアプリ • 機能 ◦ 二次元コードを読み取り、妥当なチケットか確認 ◦ 成否判定を表示する • 実装 ◦ UI、二次元コード検証(Firestore) ▪ Flutter ◦ 二次元コードリーダ制御、USB機器制御、カメラ認証 ▪ Flutter native plugin in Kotlin 10
11. Flutter native pluginの構成 • 機能 ◦ 各種ベンダーのライブラリを抽象化し, 共通 APIを提供 ▪ アプリ側でベンダーを意識する必要をなくす ◦ カメラによる 二次元コード認識の実装 ▪ fallback用 ◦ USB機器の対応 ▪ シグナルタワー 11
12. Flutter native pluginの構成 12
13. ハンディターミナルの選定基準 • 二次元コードの認識が早く、精度が良い ◦ 紙チケットの場合、しわがあったり濡れていたりすることが考えられる • 屋外で問題なく使える • 耐久性 ◦ 防水性、落下耐久性など • 長時間バッテリー駆動 ◦ 横浜スタジアムのゲートでは電源を引っ張れない箇所もあるためバッテリーで駆動 させる必要がある ◦ 通常の試合では約 8時間入場を受け付けるため、その時間バッテリーが持つ • SIMカード通信可能 ◦ 屋外での利用が必須であるため、 4G回線などの移動通信システムで通信を行う必 要がある ◦ ネットワーク冗長性を考慮し、デュアルSIMが好ましい • コスト ◦ 端末価格、ランニングコスト • 納期 ◦ 2023年シーズン開始に間に合うか 13
14. ハンディターミナルの選定 • 選定対象 ◦ Android スマートフォン型 5社 ◦ 据え置き端末型 3社 ▪ コンビニの交通系 ICカード決済端末のような形状 • 対象機をすべてチケットもぎりアプリに対応させ評価を行った 14
15. ハンディターミナル対応 • 実装にあたっての苦労 ◦ 各ベンダーのライブラリのインタフェースに類似性がない ▪ 共通インタフェースを作成するのが大変だった ▪ あまり Android的に使いやすい APIではない ◦ 据え置き端末は USB HID(キーボード)として扱うため扱いが難しい ▪ 1文字ずつ処理が必要 • アプリで文字列を連結させデータを構築する必要 ▪ 状態管理 • 読み取ったデータの連結、どこからどこまでが一つのデータかの管理 ▪ 求める読み取り速度を満たしていない • デバイスからの転送速度が遅めに設定されている ◦ 1つの二次元コード読み取りに 1秒程度かかる ▪ 仕様が公開されておらず、キーボード以外としてうまく扱えなかった ◦ ドキュメント・サンプルが乏しく、公開されている利用例が少ない ◦ 時間がなかった 15
16. 現場でのテスト • 2022年10月に実際に横浜スタジアムでテスト • 現場で試して気づいたこと ◦ 端末の音が聞こえづらい ▪ 専用端末は一般的なスマートフォンよりは大音量であるためテスト 時は気にならなかったが、屋外かつ人が多い場所だとそれでも端末 からの発せられる音が聞こえづらかった ◦ 画面が見づらい ▪ 場所によっては太陽光を受けることになり見づらい ▪ モニタの輝度が消費電力に大きく影響するため、輝度を下げたいが、 輝度を下げると画面が見づらくなるというジレンマ 16
17. USBシグナルタワー • 視覚的, 聴覚的な認識の補助に利用 ◦ 任意の色のライトを自由に点灯できる ◦ 複数パターンの音を鳴らせる • 選定理由 ◦ 比較的入手しやすく、USB対応機種がある ◦ Windows向けのライブラリしか提供されていないが、USB制御の仕様は公開され ている • 実装方法などは後述 17
18. ファンフェスティバルでの試験実施 • 11月26日 横浜DeNAベイスターズファンフェスティバルで試験実施 ◦ 初めて一般の方に使ってもらう ◦ 対象は約 200名分 • 想定しない事態が数件発生 ◦ もぎりのレスポンスが遅くなるケースが頻繁に見られる(後述) ◦ 意図せぬ複数回読み取り ▪ 二次元コードを使った認証にまだまだ慣れていない人が多く、かざ し続ける人も多く見られた ◦ ハンディー端末がフリーズする • システム以外にも課題が見つかった ◦ 案内、導線、配置 18
19. ハードウェア依存問題 • ファンフェスティバルでチケット読み取りに 5-10秒程度かかる事態が頻発 ◦ お客さんやゲート担当の方が少し混乱する事態に • 原因調査 ◦ 特定のタイミングで二次元コードを読み込むと端末の全体の動作が重くなる ◦ 問題の切り分け ▪ 本アプリだけで発生するのか ? ▪ ベンダ提供のサンプルで再現するか ? ▪ 最低限の構成のアプリで再現する ? ◦ ベンダーに適宜状況を報告しつつ調査を行った ◦ ハードウェアに起因する問題ではないかという結論を出し、再現手順の確立、 再現アプ リの作成などを行いハードウェアベンダーに報告 • 結論 ◦ ファームウェアに起因する問題 ◦ 緊急度の高い問題として扱っていただき早期に解消してもらうことができた 19
20. Androidの USB機器の対応 • Android 3.1から USB機器のサポート ◦ 一部 APIは API Level 26以降 • 基礎知識 ◦ USBの転送方式 ▪ Bulk転送、Interrupt転送、Control転送、Isochronous転送 ◦ 各種用語 ▪ Interface、Endpoint、vendor ID、product ID etc ◦ ターゲットとなる機器の仕様 • AndroidManifest.xmlに必要な設定を追加 20
21. Androidの USB機器の対応 実装 • 単純なデバイスの場合 1. UsbManager.ACTION_USB_DEVICE_ATTACHEDイベントをアプリで受け取る 2. UsbDeviceインスタンスから目的の USB endpointを取得する 3. USB endpointからデータを読み書きする • USBシグナルタワーに関しては Kotlin100行程度で対応することができた 21
22. 教訓 • サンプル・デモアプリを徹底的に調べ、同じ機能を実現できるかを確認する ◦ 今回利用した端末にはドキュメントに記載されていない APIがデモアプリで使われており、 そのことを知るまでにだいぶ時間がかかってしまった ◦ デモアプリがシステムアプリとして実装されており、ベンダー以外が同様に実装すること が難しいケースがあった ▪ システムアプリとは • @SystemApi のメソッドが呼び出せる特別なアプリ • アプリをROMを署名した鍵で署名する必要がある ◦ 確認方法 ▪ 提供されたSDKだけで同じ機能を実現できるか ▪ ある機能を実行した時のログが一致するか ◦ 実現できない場合、疑問がある場合は速やかに問い合わせる 22
23. 教訓 • ハードウェアの問題の取り組み ◦ ベンダーとの協力が不可欠 ◦ 高い温度感を持って取り組んでもらう ▪ 再現手法の確立 • 問題を再現させる最低限のアプリの作成 ▪ 再現動画の用意 ◦ 本案件ではベンダーも深刻な不具合と認識してくれて約1か月で解決することができた • 実際の利用者を想定した QAの必要性 ◦ 今回は開発者・QA担当者が操作に慣れすぎてしまい、テストを繰り返しても二次元コード の読み取りが同じようなタイミングになってしまっていた ◦ 読み取りのタイミング、かざす位置など実際の利用を想定する必要があった ◦ 実際のお客さんと同じシステムを知らない人にテストしてもらうのが良い • Androidの USB対応 ◦ 実装が容易 23
24. まとめ • 実際に使う場所、利用する人に使ってもらいフィードバックを得ることが重要 • 専用ハードウェアでは自分たちではどうにもできない問題にぶつかることもある ◦ 問題がハードウェアにある可能性も考慮する ◦ 問題の切り分け、再現の確立、ベンダーとの協力が重要 • 3月 4日から横浜スタジアムで本格運用予定 24
25. ご清聴ありがとうございました 25