#DevReljp DevRel/Japan CONFERENCE 2024【スタッフメモ】

## 本稿の留意事項
- 本稿はこれからカンファレンススタッフをやってみようと考えているエンジニアのための記事であり、本稿を通じて別イベントスタッフとして活躍していただいた方を通して技術を身に付けたい方の発展を期するものである事をご留意願います
- 本稿自体はDevRel Japan Conference 2024のセミナーセッションについては触れません
  - ありがたいことにスタッフをしながらセミナーの内容は聞けたものの、内容を腹落ち・考察など自身に落とし込める心理的余裕がなかったため、学びとして定着しておらず途中で諦めました

## 本日のセミナーイベント
https://devrel.tokyo/japan-2024

繰り返しになりますが、今回は一般参加ではなくスタッフ参加のため、セミナーの内容というよりは運営側目線[^運営スタッフ]でのアレコレです
今プチバズっているスタッフエンジニアではないですが、エンジニアがイベントスタッフしてみた話なので、そういう意味ではスタッフ（エンジニア）と言い張っておきます。
きちんとしたスタッフエンジニアについては、Qiita内だけでも多くの投稿が見つかりますのでそちらを参照されると良いでしょう。

https://qiita.com/search?q=%E3%82%B9%E3%82%BF%E3%83%83%E3%83%95%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2

[^運営スタッフ]: 【運営側目線】一般参加者目線でメモ。実はスタッフも大別して２パターンで、一般に問題解決能力がある存在を指しますが、全てのユーザーのペルソナを立てる事が外部スタッフ（≒当日スタッフ）の教育コスト面や現実的な課題設定として難しいため、スタッフは「わかる人を呼んでくる役」と割り切ると良いです。そして、スタッフへの要望は自分のわがままになっていないか見直し・振り返りましょう。なお自己反省中

## 本稿のターゲット
- いつも一般参加で知らずのうちにお世話になっている人（私）
- エンジニアイベントには参加しているが、スタッフは未経験の方（今日までの私）
- エンジニア界隈以外のイベントスタッフ主催・経験者（私）
- コミュニティに何かしら貢献したい人（私）

という、私のための備忘録です

## 本稿の目的・目標
:::note
次は（できたらいっしょに）スタッフやろうぜ！
:::

スタッフになって気付く、知れる話は多いです
（逆に言うと、スタッフをやると一般参加以上に情報が集まります）

### イベントに参加する目的から考える、スタッフをやるべき人
- イベントの界隈や業界については知らない・分からない
  - セッションを聴いたりブースで話してみるのも方法としては良いですが、コアメンバーとの交流の時間が最も手っ取り早く情報・知識が得られます
    - コアメンバーはコミュニティにも詳しく、かつ業界にも詳しい人が多い上に別イベント（でorも）主催やってる人がいます
  - 当たり前ですが、知らない事は全部教えてくれ、というスタンスでは「こいつナメてんのか？」と思われても仕方ないのは当然です。節度はお忘れ無く！
    - とはいえ、知らない・詳しくないからこそ新しい風を吹かせるという役割を期待されている事は多いです
- 自分もセミナーに興味がある
- 裏技として
  - 声を大にして言うことではないのですが、来場者として参加要件を満たしていなくてもスタッフとしての参加要件を満たしていればイベントに参加する事ができます

### いきなりスタッフ参加はハードル高くない？
実は私もこの辺りは気持ちとしてありました。
というのも、IT界隈ではいないと認識されがちですが、IT界隈以外の催し事を含めると大体スタッフルームまたはイベント中の盗難騒ぎが起こるため（起こった現場に居合わせた経験があるため）身元不明のスタッフを採用しませんし、身分証ではないですが緊急連絡先などをはじめスタッフの個人情報は持つようにしています。
私の場合は当該イベント終了後は使う事がない上に、活用できない個人情報は持っているだけでリスクでしかないため即時破棄しますが、個人情報を取られても良いという信頼関係が成立していない関係値の人間をスタッフとして扱うことをリスクだと考えているからです。

これを説明すると納得はされますが、今のところそういった問題になっていないのは本当に良い界隈だなと思いました。

### スタッフって報酬あるの？
ある場合もあるでしょうし、ない場合もあるんじゃないでしょうか？
基本的にスタッフとは「コミュニティやイベントに貢献したい」という気持ちでやるものだと思っているので、報酬の多寡は気にしていませんし、求めたこともありません。また、求められた事もありません。
とはいえ、主催目線では「どうしてもこの人にお願いしたい」というケースはあるので、その場合は交渉になるでしょう（ケースバイケース）

あえて言えば「一般参加では得られない機会（時間・体験）と情報量・人脈が報酬です。
なお「ください」と言ってもらえるものではないため、自ら報酬を作りましょう。

## やったこと（スタッフ業務）
項目は時系列順にしてますが、流動的に変わってます

### 会場前・設営
- ワンパターンで手を動かせば良いもの
  - ネックストラップ組み立て
  - トートバックへのチラシ・フライヤー詰め
  - 内職を効率的にやるスキルも重要。マクドナルドとかはこの辺り鍛えられるのでおすすめ
    - ただし、マクドナルドの場合は標準規格として効率的な方法は研究され尽くしているので、自分流にアレンジしたい場合は自分最適であると認識した上でやり方を他者に強要しないようにする
- ゴミの管理・ゴミ箱設置（場合により組み立て）
- ゴミの分別
  - 大ゴミ
    - 配送に使った段ボール
    - 資料など配布後に手元からなくなったため必要性が消えた梱包材類
  - 小ゴミ（可燃・不燃・ペットボトル・）
    - 来場者が持ち込んだもの（スタッフを含む）
    - 会場提供者が常設しているゴミ箱の使用を制限する取り組み
  - ガムテープや養生テープを使って机にゴミ袋をぶら下げて貼り付けたりもしてますが、

会場提供側宛の配送物や、参加スポンサーの配送物が混じる事があるので、梱包物の取り出し時には宛名が確実に正しいことを確認してから取り出します。

### 受付・会場案内
- 案内漏れについては、最初の会場セッション・あいさつで全体向けに案内するので多少漏れたり間違っていてもそちらで吸収できます
  - 特に会場のことはこの時に初めて知る（気付く）事があるかも
- 受付業務の作業
  - 名前を聞いて名簿（紙なりスプレッドシートなり）から検索する
  - 専用アプリからQRコードを読み込む
    - 今回はこちら
  - おそらく名簿管理している事がほとんどのはずなので、名前検索時は以下に注意
    - 漢字の読みが一致しない
    - 登録名と名前が一致しない
    - システム上、読みを登録していない
- スピーカー・スポンサー対応
  - 予約をしていないケースがある（多い）
- 景品交換所とルールの案内
  - スタッフ・あるかどうかも事前に確認しておくべき
  - 主催・対応フローを認識・周知する

### 現地運営
- 補充
  - ケータリング（ご飯とか食べ物系）の準備、展開
  - リフレッシュメント（ドリンク、お菓子系）
- タイムキーパー
  - シフト決め（聞きたいセッションがあれば調整）
  - タイムキーバーのフォロー[^timer]

特に補充関係はなくなった時にどうするかも決めておいても良かったかも
どうしてもなくなりやすいもの（人気）とそうでないものの差があり、数が読みにくいのも実情ですが、売れない商品を押し出す工夫を意識できると売れ残り（を集めて宅配コストかけたり）を防げるかなと
↑この辺りはコンビニ経営者レベルの意見が聞きたい

[^timer]: 【タイムキーバーのフォロー】本カンファレンスに限らず、タイムキーパーがその時間中の全責任を負うというプレッシャーがきついので、タイムキーパーは一人代表で立てますが、時間管理自体はタイムキーパー・登壇者・ヘルパーで3重管理すべきだと思ってます。

## 懇親会の準備
:::note warn
イベントレポートは即時投稿しないと二度と見ないし忘れる、という自己の戒めがありますので、懇親会については覚えていたら追記しています
:::

最終セッションが終わった後に書いていくコーナー、のつもりですが、このタイミングから忙しくなるので、本稿はそこまでに書いた内容ということですね。
この先は執筆時点ではまだ未来の話なので書けないのです…。

## 参考：イベント前のスタッフミーティングなど
当日スタッフのためか、１回のみ
当日の流れの確認と、集合場所・時間だけ決めた印象。資料は後から追記されるので前日または当日にもう一度確認しておくぐらい

## 当日の所感
おそらく多くの方が初見になると思うので、ちょっとだけ「所感」という項目について言及しておきます。

:::note
「お気持ち」は大事だと思ってます。
:::

:::note alert
「お気持ち」を押し付けるのはダメだと思ってます。
:::

所感のコーナーはイベントの内容とは関係ない話とか「お気持ち」を書いてますが、押し付けるものではないし、なんなら部分最適の可能性が高いため、他のイベントまたは同じ系列のイベントでも最適解が異なる可能性があります。

多分本稿のメインコンテンツです。

### スタッフもセッション聞きたい！
→聞けました。他のセミナーでもスタッフ間でうまいこと連携をとってもらえば聞きたいセッションに集中できるんじゃないかと思います
アーカイブ視聴ができるとのことで、当日のスタッフ業務・イベント運営に集中していました。知識は会場でなくても得られるので、体験を得ることをメインにしました

### 会場環境良すぎ
- 実は先週段階に別イベントで来場してました
- Wifiがある、しかも強い
- 電源もある（が、使ってない…）
  - 一般参加者目線だと「使わせてくれよ！」と思うのですが（今回、一般参加だったら間違いなく思ってる）、スタッフ目線だと転倒リスクが上がって危ないので使って欲しくない
    - 最大の参加人数に合わせて席数を用意するので、机を確保できない
    - 電源を安全に利用するために机が必須。その場合、席数を減らす必要がある
- スタッフの登壇者率高すぎ
  - そういうもんなのかな…？他のイベントでも私が知らない（気にしていない）だけで、イベントスタッフだけど登壇者！というケースは多いのかもしれない

### コアスタッフの練度の高さ
ちょっと用語説明が必要なので、先に解説を入れます。
まずスタッフの種類がコアスタッフ（コミュニティ運営メンバー）と当日スタッフ（都度募集・有志）に分かれます。
幸いにも、別コミュニティでコアスタッフ（という名称こそ使わなかったのですが、似たようなロール）をやっていたので、このあたりについては違和感なく入っていけました。
が、それにしてはコアスタッフの熟練度がすごい。１〜２年かそこらの

- 当日、ベテランスタッフの方にめっちゃご指導いただきました！感謝
  - 奇しくも、個人的にも勉強会などで一方的に知ってるだけの方でしたので「お前誰やねん」的な受け入れ障壁もなかった気がします
  - いうて私もイベント運営の主催経験があるので、なんか役割を見つけてバリューを出そう、というので色々と試行錯誤やってました
- スタッフミーティング等で、特に運営側から指示やアナウンスもなかったのですがほぼ全員がSlackに常駐してました
  - 午前中は会場に意識を全力で向けていたので気づかなかったんですが、午後からはSlackにも張り付いて全体運営フォローに回りました
  - 特に次のプログラムがなんだ、いつから始まるんだ、登壇者との打ち合わせがしたいので誰か知りたいなどの要望が多く発生していた印象です

### 各スタッフの経歴もやばい
- 一般参加目線だとスタッフの存在を軽視してしまいがちなのは、同人誌即売会（コミケ）でもあるある
  - 即売会のスタッフも別イベントの主催なり代表が別イベントのスタッフやってます、とかザラにある
- そもそもイベントスタッフをやりたがる人なんてヤバい人（私目線。なんちゃってエンジニア）しかいない（戒め）
  - こう書くとブーメランが刺さるのですが、自分の事は棚に上げます

小話にもならないネタなんですが、コミケをタイポして「小池」になってしまったのに後で気づいたので都知事の力は強いと思いました。

### わかってないなりにやろうとして混乱させてしまった（かも？）
ちょっと反省だなーと思っているところでもあるんですが、大体の場合現地対応するスタッフ、特に主催寄りは忙しいです。
タイムマネジメントは結構きつい上に面倒臭いので、主催側が手の回りにくい細々とした軽作業を持つようにしました。
その一つが、この後のタイムテーブルを全体に流す、という作業なのですが

- 手元に来場者用のスケジュール
- 別ファイルで運営用スケジュール

を持っていたために、うっかりやらかしてしまいました。
２つのスケジュールを同じ日に受け取ったのがウッカリの原因かもしれません。
同じタイミングで２種類のタイムスケジュールを運用する場合は、日付をずらして展開・周知すると良かったかもしれません

### Slack：ちゃんとリアクションしよう
現地対応をしているため、見たのか見ていないのかが確認できません。
少なくとも見たよ！という場合は見たよスタンプを決めておきましょう
また、質問や相談をした場合は解決したのかどうかスレッドを辿らないとわからない事があるので、解決済みならきちんとクローズしましょう。
私の場合、以下を使う事が多いです。

- 見たよ：👍 or 👀
- 解決済み：✅
- **相談後時間が経っており、未解決**：もう一回全体に向けてメンション飛ばす。緊急性により時間を調整

## 謝辞
本イベントではZennさんも登壇されていたので、他の記事はやらないようにしていますが、本稿だけマルチポストさせてもらってます。

### 注釈