2019ひとつきおくれのアドベントカレンダー18日目です。2019で大いに活躍して受付システムについて書きます。受付システムについて受付は結構大変WordCamp(とくに日本)での大きな問題のひとつに、『受付が混む』というのがあります。これにはいくつかの原因があります。当日、数百人が一斉に押し寄せる。参加リストから該当の参加者を探す必要がある。チェックイン時にパンフやノベルティなどを渡すため1人あたりの時間がかかる。スポンサー・スピーカーの場合は別途案内が必要。チケットを購入したが、購入メールが見つからない。当日チケットを購入してない人が来る。このように作業やイレギュラーが多く、想像以上に受付業務は大変で時間がかかります。増やして、捌ける量をあげる作戦です。これはこれで危険で、参加者をGoogleスプレッドシートで管理して、受付担当複数人でチェックインするとスプレッドシートの更新処理が極端に遅くなってしまい、余計に時間がかかってしまうことがあります。2019で受付システムを作っていただいた速く受付して速く受付から移動してもらう、これが受付での混雑と混乱を避ける方法の1つです。この対策で有効なのがチェックイン自体の速度改善です。パンフやノベルティを渡したり、当日チケット購入してないなでおのイレギュラー対応は速度をあげるのは困難ですが、チェックイン(参加者を探す、チェックする)は速度をあげやすい箇所です。2019にて高橋文樹さんを筆頭としたアプリ開発チームのみなさんが受付システムが作成されました。(くわしくはこちらの記事で)参加者のQRコードにチケット詳細のURLにアクセスでき、そこからチェックインを行います。どんな感じかはこちらの動画を見ていただくとよくわかります。この受付システムの良いところはスマホさえ持っていれば良いという点で、急遽担当者を増やしたりすることも可能ですし、準備するものも個人のスマホのみと、大変手軽です。2019で体験しましたが、確かに以前に比べると爆速です。これは使わない手はない。思い、Tokyoの実行委員会に連絡して快諾いただき、Osakaでも利用することにしました。コミュニティって素敵。システム構成WordPressWordPressに参加者データが蓄積されています。そのデータをダウンロードします。FirestoreDB。ダウンロードしたデータをFirestoreに必要な項目だけ抜き出しインポートします。受付システムはこのFirestoreにアクセスし、検索・チェックインします。データのインポートはJavaScriptで行います。Framework』を利用しています。SlimからFirestoreにアクセスして動的コンテンツの出力とAPI、そして参加者用のQRコード画像の生成を実装してます。Reactフロントエンド。Slimで作られたAPIにアクセスし、データの取得・更新を行って画面に描画します。webpackを利用してコンパイルしています。Lightsailにデプロイしました。1.14.0letsencryptです。Osaka用にカスタマイズするさて、環境としては(予想していたより)早く準備できましたが、そのままでは使えませんでした。Tokyoはチケットが1種類(セッションデイ・懇親会込み、コントリデイはGoogleFormで管理)だったのですが、Osakaはチケットが5種類ありました。コントリデイチケットセッションデイチケット学生チケットマイクロスポンサーチケット懇親会チケットTokyoの場合、チケットが1種類だったので参加者QRコードにはチケットIDが引数として渡されるようになっており、すぐにチケット詳細が表示できました。Osakaの場合、参加者がチケットを複数所持しているのでチケットIDのままだと1参加者で何度もQRコードを読み取らなければいけません。これでは逆に時間がかかってしまいます。そこで、以下のカスタマイズを行いました。STEPQRコードのURLを変えるQRコードのURLをチケットIDを引数としたチケット詳細画面から、メールアドレスを引数としたチケットの検索結果一覧画面に変更しました。STEP引数でチケットを検索できるようにする。元々は検索結果は検索キーワードを元にAPIにアクセスし、結果を利用してReactで再描画してましたが、URLの引数(クエリーストリング)を利用してデフォルトで検索結果一覧を表示するようにし、QRコードからアクセス→検索結果(=参加者のチケット一覧)が表示できるようにしました。STEPメールアドレスをキーにFirestoreにアクセスする。検索機能は、一度Firestoreのデータを全て取得して、名前とメールアドレスで該当のキーワードを含んでいたものを選ぶようになっていました。このままでも利用できたのですがFirestoreは取得した件数に対しての課金です。チケット種類が複数なため、一度に取得する件数が多くすぐに無料上限に達してしまいました。そこで、引数の項目名を変えメールアドレスをキーにFirestoreにアクセスするようにしました。結果、一度に取得する件数が約1,000件から最大4件にまで減りました。STEPチェックインしているかどうかをチケット一覧でわかるようにした。チケット種類が複数なために、どのチケットにチェックインしたか確認する必要がありました。チケットのチェックイン状態が分からなかったので、チケット検索結果一覧にチケットがチェックイン済みかどうかをヒョイウジするように変えました。STEP特別な対応に向けて、詳細画面をカスタマイズ。今回、アレルギーのある方や特別なサポートが必要な方が参加することがすでにわかっている状態でした。そこで、チケット詳細画面にアレルギーと特別なサポートの有無を表示し、受付で把握できるようにしました。渡すノベルティやスピーカーやスポンサー・スポンサー企業がわかるよう、一般参加者以外の特別な対応が必要な方とのやりとりがスムーズにできるようにしました。結果、どうだったか?実は、システム自体はイベント開催2週間くらいに出来上がっていたのですが、もろもろ手配が遅れて受付担当の方へのレクチャーはイベント当日になってしまいました。2019の実行委員の方々をはじめ、いろいろな人に協力していただいた結果です。Osakaでの実績をもとに、今年のWordCampでも使っていただけたらと思っています。微力ながら、カスタマイズやデプロイでご協力できると思いますので、ぜひお声がけください。無事に成功したわけですが、別に一から作ったわけでもないですし、カスタマイズもそんなに大変なものではなかったので記事にするほどのことでもないです。今回のカスタマイズを通してとても良い経験ができたのでお伝えできたらと思い、記事にしました。つまみ食いしていたものがきれいにつながった今回の受付システムで使われている技術、サービスに関しては普段お仕事でメインで使っているものではありません。それぞれを『つまみ食い』していました。Frameworkは使ったことがありませんでした。マイクロフレームワーク(LumenだったりSilexだったり)をつまみ食いしていたので、比較的用意にカスタマイズできました。普段はサーバサイドがメインなのでReactはお仕事で使いませんが、たまたまつまみ食いしてたので、記述のしかたやstateの概念をうっすら理解しており、多少苦労したものの特につまづくことなくカスタマイズできました。stateがうっすらわかっていたので、Firestoreとの連携もそこまで苦労していません。Firestoreもお仕事で使っていませんが、NoSQL(DynamoDBやMongoDB)をつまみ食いしてたので特に問題なく利用できました。ここで『つまみ食い』という表現を使っていますが、それぞれこの業界でいうところの『完全に理解した(チュートリアルは終了した)』までいっていません。Reactは買った本を5章くらいまでしか読んでないですし、マイクロフレームワークはインストールしてさらっと触った程度、NoSQLに至ってはQiitaで記事を読んだレベルです。これらの技術やサービスに対しての知識が全くなかったら、おそらく今回のカスタマイズに手を出していないですし、導入もしなかったでしょう。ほんのちょっと『つまみ食い』していたおかげで、臆することなくカスタマイズすることができました。余裕があるなら、つまみ食いした方が良い自分の領域外の技術やサービス・トレンドよりも領域内を優先した方がよいかもしれません。興味があって余裕があるなら『つまみ食い』しておくと、思わぬところで役立つかもしれません。役立たないこともあるかもしれませんが、決して損にはならないと思っています。記事を読む・ちょっと本を読む・ちょっと触ってみる程度であれば、そんなに時間も負荷もかからないので、僕は今後もつまみ食いし続けていきますし、是非ちょっとだけでも『つまみ食い』してもらえたらなと思います。Sumidaフリーランスデベロッパー。大阪を中心にWeb開発をしています。#3『ひらパーに行ってブログを書く会』開催しました。Unplat検索する。