受付システムを改造した話

2020 1/18
受付システムを改造した話

WordCamp Osaka 2019ひとつきおくれのアドベントカレンダー18日目です。2回目の投稿です。今回はWordCamp Osaka 2019で大いに活躍して受付システムについて書きます。

目次

受付システムについて

受付は結構大変

WordCamp(とくに日本)での大きな問題のひとつに、『受付が混む』というのがあります。これにはいくつかの原因があります。

  • 当日、数百人が一斉に押し寄せる。
  • 参加リストから該当の参加者を探す必要がある。
  • チェックイン時にパンフやノベルティなどを渡すため1人あたりの時間がかかる。
  • スポンサー・スピーカーの場合は別途案内が必要。
  • チケットを購入したが、購入メールが見つからない。
  • 当日チケットを購入してない人が来る。

このように作業やイレギュラーが多く、想像以上に受付業務は大変で時間がかかります。この問題の解決策としてよく取られていたのが『人海戦術』。受付担当を増やして、捌ける量をあげる作戦です。ただ、これはこれで危険で、参加者をGoogleスプレッドシートで管理して、受付担当複数人でチェックインするとスプレッドシートの更新処理が極端に遅くなってしまい、余計に時間がかかってしまうことがあります。

WordCamp Tokyo 2019で受付システムを作っていただいた

速く受付して速く受付から移動してもらう、これが受付での混雑と混乱を避ける方法の1つです。この対策で有効なのがチェックイン自体の速度改善です。パンフやノベルティを渡したり、当日チケット購入してないなでおのイレギュラー対応は速度をあげるのは困難ですが、チェックイン(参加者を探す、チェックする)は速度をあげやすい箇所です。この速度改善を目的として、WordCamp Tokyo 2019にて高橋文樹さんを筆頭としたアプリ開発チームのみなさんが受付システムが作成されました。(くわしくはこちらの記事で)

参加者のQRコードにチケット詳細のURLにアクセスでき、そこからチェックインを行います。どんな感じかはこちらの動画を見ていただくとよくわかります。この受付システムの良いところはスマホさえ持っていれば良いという点で、急遽担当者を増やしたりすることも可能ですし、準備するものも個人のスマホのみと、大変手軽です。

実際にWordCamp Tokyo 2019で体験しましたが、確かに以前に比べると爆速です。しかもOSS。これは使わない手はない。そう思い、Tokyoの実行委員会に連絡して快諾いただき、Osakaでも利用することにしました。コミュニティって素敵。

システム構成

画像
WordPress

WordPressに参加者データが蓄積されています。そのデータをダウンロードします。

Firestore

DB。ダウンロードしたデータをFirestoreに必要な項目だけ抜き出しインポートします。受付システムはこのFirestoreにアクセスし、検索・チェックインします。データのインポートはJavaScriptで行います。

Slim Framework

サーバサイドの実装にPHPのマイクロフレームワーク『Slim Framework』を利用しています。SlimからFirestoreにアクセスして動的コンテンツの出力とAPI、そして参加者用のQRコード画像の生成を実装してます。

React

フロントエンド。Slimで作られたAPIにアクセスし、データの取得・更新を行って画面に描画します。gulp, webpackを利用してコンパイルしています。(ついでにscssも)

この構成のシステムを今回はたまたま持ってた個人のaws Lightsailにデプロイしました。ざっくりサーバ環境は

  • Ubuntu 18.04
  • PHP 7.3
  • Nginx 1.14.0
  • letsencrypt

です。

Osaka用にカスタマイズする

さて、環境としては(予想していたより)早く準備できましたが、そのままでは使えませんでした。Tokyoはチケットが1種類(セッションデイ・懇親会込み、コントリデイはGoogleFormで管理)だったのですが、Osakaはチケットが5種類ありました。

  • コントリデイチケット
  • セッションデイチケット
  • 学生チケット
  • マイクロスポンサーチケット
  • 懇親会チケット

Tokyoの場合、チケットが1種類だったので参加者QRコードにはチケットIDが引数として渡されるようになっており、すぐにチケット詳細が表示できました。Osakaの場合、参加者がチケットを複数所持しているのでチケットIDのままだと1参加者で何度もQRコードを読み取らなければいけません。これでは逆に時間がかかってしまいます。そこで、以下のカスタマイズを行いました。

STEP
QRコードのURLを変える

QRコードのURLをチケットIDを引数としたチケット詳細画面から、メールアドレスを引数としたチケットの検索結果一覧画面に変更しました。

STEP
引数でチケットを検索できるようにする。

元々は検索結果は検索キーワードを元にAPIにアクセスし、結果を利用してReactで再描画してましたが、URLの引数(クエリーストリング)を利用してデフォルトで検索結果一覧を表示するようにし、QRコードからアクセス→検索結果(=参加者のチケット一覧)が表示できるようにしました。

STEP
メールアドレスをキーにFirestoreにアクセスする。

検索機能は、一度Firestoreのデータを全て取得して、名前とメールアドレスで該当のキーワードを含んでいたものを選ぶようになっていました。このままでも利用できたのですがFirestoreは取得した件数に対しての課金です。チケット種類が複数なため、一度に取得する件数が多くすぐに無料上限に達してしまいました。そこで、引数の項目名を変えメールアドレスをキーにFirestoreにアクセスするようにしました。結果、一度に取得する件数が約1,000件から最大4件にまで減りました。

STEP
チェックインしているかどうかをチケット一覧でわかるようにした。

チケット種類が複数なために、どのチケットにチェックインしたか確認する必要がありました。もともとはチケットのチェックイン状態が分からなかったので、チケット検索結果一覧にチケットがチェックイン済みかどうかをヒョイウジするように変えました。

STEP
特別な対応に向けて、詳細画面をカスタマイズ。

今回、アレルギーのある方や特別なサポートが必要な方が参加することがすでにわかっている状態でした。そこで、チケット詳細画面にアレルギーと特別なサポートの有無を表示し、受付で把握できるようにしました。また、渡すノベルティやスピーカーやスポンサー・スポンサー企業がわかるよう、一般参加者以外の特別な対応が必要な方とのやりとりがスムーズにできるようにしました。

結果、どうだったか?

実は、システム自体はイベント開催2週間くらいに出来上がっていたのですが、もろもろ手配が遅れて受付担当の方へのレクチャーはイベント当日になってしまいました。受付の配置箇所的にもかなりの混雑が予想され、なおかつ受付開始前に実行委員・当日スタッフを利用した受付リハーサルでは相当混雑してしまったのですが、リハーサルの効果と受付担当の方の尽力により、当日はほぼ混むことなくスムーズに受付を行うことができました!今回受付がスムーズだったこともあり、アンケート結果における受付に関する満足度は、

画像

このように、約90%の方に、『よかった』と感じていただけました!

WordCamp Tokyo 2019の実行委員の方々をはじめ、いろいろな人に協力していただいた結果です。ありがとうございました!この受付システムは、今回のWordCamp Tokyo, Osakaでの実績をもとに、今年のWordCampでも使っていただけたらと思っています。微力ながら、カスタマイズやデプロイでご協力できると思いますので、ぜひお声がけください。

ここから本題

無事に成功したわけですが、別に一から作ったわけでもないですし、カスタマイズもそんなに大変なものではなかったので記事にするほどのことでもないです。ただ、今回のカスタマイズを通してとても良い経験ができたのでお伝えできたらと思い、記事にしました。

つまみ食いしていたものがきれいにつながった

今回の受付システムで使われている技術、サービスに関しては普段お仕事でメインで使っているものではありません。しかし、たまたまそれぞれを『つまみ食い』していました。

お仕事はPHPをメインとしたプログラム開発ですが、普段はSymfonyを使っているため、Slim Frameworkは使ったことがありませんでした。ただ、たまたまマイクロフレームワーク(LumenだったりSilexだったり)をつまみ食いしていたので、比較的用意にカスタマイズできました。普段はサーバサイドがメインなのでReactはお仕事で使いませんが、たまたまつまみ食いしてたので、記述のしかたやstateの概念をうっすら理解しており、多少苦労したものの特につまづくことなくカスタマイズできました。stateがうっすらわかっていたので、Firestoreとの連携もそこまで苦労していません。Firestoreもお仕事で使っていませんが、NoSQL(DynamoDBやMongoDB)をつまみ食いしてたので特に問題なく利用できました。

ここで『つまみ食い』という表現を使っていますが、それぞれこの業界でいうところの『完全に理解した(チュートリアルは終了した)』までいっていません。Reactは買った本を5章くらいまでしか読んでないですし、マイクロフレームワークはインストールしてさらっと触った程度、NoSQLに至ってはQiitaで記事を読んだレベルです。もしこれらの技術やサービスに対しての知識が全くなかったら、おそらく今回のカスタマイズに手を出していないですし、導入もしなかったでしょう。でも、ほんのちょっと『つまみ食い』していたおかげで、臆することなくカスタマイズすることができました。

余裕があるなら、つまみ食いした方が良い

自分の領域外の技術やサービス・トレンドよりも領域内を優先した方がよいかもしれません。が、少しでも興味があって余裕があるなら『つまみ食い』しておくと、思わぬところで役立つかもしれません。役立たないこともあるかもしれませんが、決して損にはならないと思っています。ちょっと記事を読む・ちょっと本を読む・ちょっと触ってみる程度であれば、そんなに時間も負荷もかからないので、僕は今後もつまみ食いし続けていきますし、是非ちょっとだけでも『つまみ食い』してもらえたらなと思います。

関連記事

目次