Swift Punk メンバーとして登場し、try! Swift Tokyo 2024 の司会を務めさせていただきました、Organizer のあっきーです。SNS などでは AkkeyLab というニックネームで活動しています。

Organizer という形でカンファレンスに携わるのは今回が初めてだったので、今後に活かすための振り返りとして執筆しました。イベントの主催として活躍されている方はもちろん、参加者としてイベントを最大限楽しむ秘訣を知ることもできるように工夫していますので、最後まで読んでいただけますと幸いです。

try! Swift Tokyo

プログラミング言語「Swift」をテーマにした国際カンファレンスです。スピーカー、参加者ともに日本国外からの参加者も多いという特徴があります。
過去のトークは YouTube でも公開されていますので、まだ参加したことのない方はこの記事と合わせて見てみてください！

ウェブサイトの管理

try! Swift Tokyo 2024 のウェブサイトは STUDIO で作成・管理されており、各要素の作成と更新を担当しました。

STUDIO を使うのは初めてでしたが、直感的な操作感によって、ウェブ制作に詳しくない私でも早いうちにある程度使いこなせるようになりました。しかし、以下のような特徴によって予想以上に工数が膨らむ作業があったのも事実です。

1. 日本語と英語のページが別で存在する

2. 繰り返し要素が多い

3. 事前確認が必要な要素がある

1. 日本語と英語のページが別で存在する

try! Swift Tokyo の特徴の一つとして「日本国外からの参加者も多い」というものがあります。ですから、ウェブサイトにも日本語だけでなく英語のページが存在します。
ウェブサイトの多言語対応の方法はいくつかあると思いますが、STUDIO で実現できる方法をベースに手動翻訳を採用しています。よって、STUDIO 内には日本語版と英語版のリソースが存在し、要素を追加・編集・削除する場合には日本語版と英語版の両方を同じように操作する必要が出てきます。

2. 繰り返し要素が多い

スピーカー一覧、タイムテーブル、スポンサー一覧、オーガナイザー一覧と、同じレイアウトの要素を特定の規則に則って表示する箇所が多く存在します。STUDIO のプランを変更することで解決できる課題ではありますが、これらの繰り返し要素を全てコピペで実現していました。
単純作業の割に多くの作業時間を必要とする点は想定外でした。

3. 事前確認が必要な要素がある

try! Swift Tokyo をご支援いただいているスポンサー様のロゴは、担当者様に事前確認をしていただいてから公開していました。STUDIO では下書き状態と公開状態という2つの状態があり、事前確認では下書き状態を共有していました。一見そこまで支障が出るようには感じないのですが、次のような場合に意識することが一気に増えます。
例えば、A社とB社にロゴ確認を依頼し、並行してスピーカー一覧の作成が進行していたとします。ここで、A社から掲載OKの返信を頂いた場合、B社のロゴと作成途中のスピーカー一覧を一時的に非表示にしてから公開します。その後、先程一時的に非表示にしたものを戻します。

皆さんは、カンファレンスのウェブサイトをいつ見ていますか？おそらく、開催前日から当日という方が最も多いのではないでしょうか。今回紹介したように、開催の数ヶ月前から定期的に更新されることが多いので、チケットの購入前や購入後も定期的に確認してみることをおすすめします！

Organizer としては、工数をもう少し精度高く見積もれるようにすることが次回への try point になります。また、ウェブサイトの管理手法を見直すことも重要かもしれません。

Swift Punk

Apple Vision Pro を装着した姿が Daft Punk のように見えることから生まれたアイデアでした。

私は当日の登場だけでなく、Swift Punk の衣装準備を担当していました。実はこの衣装、本番の1週間前から急ピッチで準備したもので、できる限り本家に近づくように買い揃えました。皆さん楽しんでいただけましたか？

このパフォーマンスは、try! Swift Tokyo 初日の午前10時過ぎから一度だけ行いました。私もそうですが、朝が苦手な方にとっては難易度の高い時間帯かもしれませんが、カンファレンスは朝からの参加をお勧めします！

司会進行

今回、日本語の司会を務めさせていただきました。この規模のイベントの司会は人生初で凄い緊張しましたが、これを通じてまた一つ成長できたような気がします。

try! Swift Tokyo に参加された方であればご存知かと思いますが、スピーカーによるトークはリアルタイムでの通訳が行われます。しかし、司会は通訳さんにお願いせず、日本語担当と英語担当の2人で行っています。
これは、会場を暖める雰囲気づくりをしたり、緊張しているスピーカーにエールを送るなど、言葉で伝える以上のことが求められるからです。

私にとって司会は、大きなチャレンジだったこともあり、今回の try! Swift Tokyo の中で最も反省ポイントが多かったです。ただ、この反省ポイントは1日目終了の段階でも明確になっているものが多かったため、2日目から改善できたことも多かったです。次の3つに分けて司会として行ったことを少しご紹介します。

1. 事前アンケートからスピーカー紹介を準備

2. 共通アナウンスを含めて、タイムライン形式で台本化

3. Discord での連絡を元に臨時のアナウンスを準備

1. 事前アンケートからスピーカー紹介を準備

スピーカーの皆さんには、いくつかのエピソードを事前アンケートという形で伺っていました。例えば「Will AI take away programmers' jobs?」や「Give some advice to Swift beginners」といった設問を自由回答形式で準備していました。
これを元にトーク前のスピーカー紹介を準備するのですが、「わお！こんな活動もされているんだ！」「このエピソード面白いなぁ！」と気づいたら夢中になっていて、予想以上に時間がかかってしまった準備の一つでした。大変だけどすごく楽しい、まさにこのことですね！

2. 共通アナウンスを含めて、タイムライン形式で台本化

初日の反省を活かして2日目で大きく改善を施したのがこの台本です。スピーカーによるトークに比べれば遥かに話すことの少ない司会ですが、セッション毎に繰り返す内容や、それらの日本語と英語を準備するとかなりの分量になります。
なので、初日の段階では、話す内容を単純に列挙しただけの台本になっていて、どこを読んでいたか見失うだけでなく、全体像が分かりにくい状態となっていました。

そこで、2日目にはセッションや項目毎にトグルでグループ化することにより、見やすさを格段に改善させました。Notion を使うなど、次回に活かせる改善策は山のようにありますが、初日の問題点を翌日で改善できたのは個人的に頑張れたポイントでした。

3. Discord での連絡を元に臨時のアナウンスを準備

トーク中も基本的にはメインホールに居ることになりますが、Discord のチェックや今後のアナウンス確認など、集中してトークを聞く余裕はありません。理想としては、トークを聞いてその感想をスピーカーさんにお伝えしたいので、事前の台本確認やシミュレーションを手厚くすることが次回への try point になります。

皆さんは、カンファレンスにトークを応募したことはありますか？魅力的なトークを披露してくださるスピーカーの数々を見てきたからこそ、「私なんて…」と高いハードルを感じてしまっている方も多いかもしれません。
そんな皆さんには、日頃熱意を持って取り組んでいるエンジニアリングに自信を持っていただきたいなと思います！なぜなら、スピーカーの皆さんからは強い熱意を感じたからです。

ここまで様々な舞台裏をご紹介しましたが、決して私だけの成果ではなく、try! Swift Tokyo 運営メンバー全員の助けがあってやっと実現したものです。本当にありがとうございました！

カンファレンスに参加してくださった皆さん、ありがとうございました！熱心にコミュニケーションを取っている姿や、たっぷりの笑顔で盛り上がっている会場を見るたびに「Organizer として携われて良かった！」と嬉しい思いに包まれていました。

また皆さんにお会いできるのを楽しみにしています！
Hope to see you again!