🎉
文化祭のIT化に取り組んだ話

2023/06/24に公開
こんにちは、eno1220です。

この記事では、私の所属する学校で行われた文化祭のIT化への取り組みについて紹介します。文化祭実行委員会等でIT系を担当する方などの参考になればと思います。

文章力がないため読みにくい箇所もあるかと思いますが、最後まで読んでいただけると嬉しいです。
記事の内容や記事中で紹介するソフトウェアに関して質問がある場合は、コメント欄や私のTwitterのDMへお願いします。
!本記事の内容は個人の見解であり、所属校及び文化祭実行委員会の公式見解ではありません。

本記事及び記事中で紹介しているソフトウェア等に関して所属校へ直接問い合わせをすることはおやめください。

 1.公式webサイト（2025/5追記）現在は公開を終了しております

 1-1.制作までの流れ
 昨年の文化祭昨年実施された文化祭では新型コロナ感染症対策のため、クラス劇や有志発表を行う体育館への最大入場者数を全校生徒の半分に制限しました。体育館へ入ることのできない生徒に対しては映像を配信することになり、文化祭実行委員会（以下、実行委員会）から私（eno1220）の所属するパソコン部に担当の依頼がやってきました。

色々なことがあった結果、映像配信については私が主担当となり、ビデオカメラで撮影した映像をOBSを使用して、限定公開でYouTube Liveにて配信しました。

このほか、パソコン部では文化祭のさまざまなIT系の仕事を部員で分担して担当していました。
文化祭終了後、パソコン部や実行委員会の先輩方や友人と以下のような課題点があるという話をしていました。
実行委員会としてではなく、パソコン部として行っている活動のため実行委員会から予算が出ない（部活の予算で行っている）[1]
同様に、実行委員会内部と連携がとりずらい/意思決定に関わることができない
これらの課題は、実行委員会内にIT系の業務を担当する部署を設ければ解決できるのではないか、という結論に至り、次年度（今年）の実行委員会幹部の友人たちにこのアイデアを話したところ、概ね好意的な意見をもらうことができたため、実行委員会内の組織として文化祭へ関わっていくことになりました。そんなわけで、今年の実行委員会にIT管理部という名前でIT系の業務を担当する部署を立ち上げることになりました。

私自身はIT管理部の副部署長としてwebサイトや内部システムの開発・運営を主に担当、部署長は同級生のSapphさんにお願いして、動画撮影・編集といった業務や部署の運営等を行ってもらったり、開発にあたって色々なサポートをしてもらったりしました。

IT管理部では中学3年~高校3年まで（私の所属校は中高一貫校のため）の生徒約20名が所属し、本記事で紹介するwebサイト・内部で使用するソフトウェアをはじめ動画撮影・編集や音声編集、掲示物の制作、他部署のIT関連の作業のヘルプ（書類やフォームの制作等）などを担当しました。（文化祭当日は音声や映像のトラブル、誘導などにも対応していました）

 webサイトの制作が認められるまでIT管理部を立ち上げた際の計画の一つとして「文化祭公式webサイトを作る」というものがありました。

2023年の2月下旬（文化祭は同6月上旬）に、webサイト制作の概要についてまとめた企画書を執筆して教員に提出したところ、肯定的な意見が多かったものの、生徒のみによる制作を不安視する意見や文化祭公式webサイトそのものを不必要と捉える意見がありました。[2]

卒業生のみなさんにもアドバイスをいただきつつ、webサイトの安全な開発環境を整えたり、webサイト公開前に教員のチェックをもらう仕組みを作ったり、文化祭公式webサイトを制作するメリットを企画書やスライドにまとめて教員へ提出・プレゼンしたりしました。

その結果、4月中旬になってようやくwebサイトの制作が認められました。

 1-2.概要
 掲載内容主に受験生（小学生）や保護者、地域のみなさんに対し、文化祭への集客や学校PRを目的として制作しました。

掲載した内容は以下の通りです。
模擬店一覧
タイムテーブル（イベント一覧）
校内マップ
来場の際の注意点
来場登録について（後述）
マスコットキャラについて、文化祭について、テーマについて、偉い人たちの挨拶、アクセス etc...

 デザイン実装を始める直前に以下の記事を目にしたので、記事や昨年度の筑波大学学園祭「雙峰祭」のwebサイトを参考にデザインしました。「見て楽しい」「文化祭に行ってみたくなる」ようなサイトを目指した他、サイトの配色については、オレンジをベースとして、全体的にカラフルにしてみました。

https://zenn.dev/inaniwaudon/articles/e4d6d326c4c18b

プロトタイプやラフは制作せず、実装しながら行き当たりばったりで配色や配置などを決めていった結果、カラフルにはなったもののイマイチ統一感のないサイトになってしまいました...しっかり検討を重ねるべきだったなと思っています。

来場の際の注意点や来場登録の実施については、可能な限り多くの方々に周知したい内容だったので、どのデバイスにおいてもトップページを見た瞬間にそれらの情報へのリンクがあるようにした他、サイト内での誘導についても意識してデザインしました。

 1-3.webサイトを支える技術公式webサイトをはじめとして開発したものの多くにおいて以下のような構成で実装しました。

 フロントエンド今回は以下のような技術を採用しました。
言語: TypeScript
フレームワーク: Next.js
UIフレームワーク: Chakra UI
状態管理: jotai
これらを採用したのは、私自身が同じ構成で開発した経験があり慣れ親しんでいたから、という理由が一番大きいです。開発にかけられる時間があまりなかったので、今までに経験したことのある技術を採用しようという考えでした。

Chakra UIを導入したところ、バンドルサイズが大きくなってしまったため、こちらの記事を参考にして
必要となるコンポーネントのみを宣言とする
バンドルサイズが肥大化する原因であるframer-motionに依存するコンポーネントを使用しない
というような方針を取りました。

 データベースデータベースにはFirebaseのCloud Firestoreを使用しています。選定した理由は以下の通りです。
安価に運営できること
費用は実行委員会の予算から出すことができるものの、他部署との兼ね合いや機材購入等で多額の予算を使う予定があるのであまりお金をかけたくない。[3]

比較的簡単に習得できること・開発の経験があること
開発期間が短かったため、自分が使用した経験があるか簡単に習得できるものである必要がありました。Firebaseはこれまで何度も運用した経験があるため開発が楽だと考えました。
来年以降の文化祭でもこのシステムを使用することを考えると、開発・運営を引き継いでいく後輩たちが簡単に習得・運営できる技術であるとよりよい。

結果としてはFirestoreの無料枠の範囲内で運用することができました。

FirestoreのCRUDにはNext.jsのApi Routes+Firebase Admin SDKを使用しています。Client SDKを使用して実装を行なった場合、Firestoreから他のDBに移行することになったタイミングで大規模な修正が必要となることが考えられるのでこのような方針を取りました。

 コード管理こちらも同様に普段から使用して慣れているということで、GitとGitHubを使用してコードの管理を行いました。IT管理部のGitHub Organizationを作成し、GitHub Actions（CI用途）やGitHub Pages等も活用しつつ開発を進めました。

 ホスティングフロントエンドでNext.jsを使用しているので、特に深く考えることなくVercelにホスティングすることにしました。（ベンダーロックインみがあるのでどうかという話もある）

GitHub Organizationでコードを管理していたり、文化祭当日は多くのアクセスにより大きな帯域幅を消費することが想定されたりしたため、Vercel Proプランを契約しました

公式webサイトの開発にあたってはdevelopブランチで開発し（開発環境）、適宜公開用のmainブランチへマージする形（本番環境）をとりましたが、Vercelではこれらの環境を簡単に構築・運用することができました。

参考記事

 ドメイン学校が使用しているドメインのサブドメインを使うのはさまざまな事情により難しそう...ということで、keyaki.appというドメインをGoogle Domains[4]で購入しました。今回開発したもの全体を運用するのにかかった費用は上記のVercel Proとドメインで、合計4600円ほどでした。なお、費用については教員へ企画書を提出した上で、実行委員会で使用できる予算枠から支出しています。

私の学校が開校した当初にed.jpでないドメインを取得して運用していたようなのですが（本当になんでこんなことを...）、最近この事実に気付いた際に調査したところ、海外のアダルトサイトがこのドメインを取得していました。学校情報をまとめているサイトにはこのURLが掲載されたままになっているものもあり少し困っています。文化祭においてはドメインを使い捨て感覚で取得したり、引き継ぎできずに失効することも多いかと思いますが、このような事態が発生することもあるので十分注意して運用する必要があると思います。

当初は上記の理由や引き継ぎの観点から複数年契約で購入することを提案していましたが、教員から「ひとまず様子を見て単年で契約し、来年度以降複数年契約で購入してはどうか」という意見が出たため単年契約で購入をしました。

 1-4.工夫した点
 ふりがなを振る

今回のwebサイトは小学生のみなさんも多く閲覧することが予測されたため、一部のページにふりがなを振りました。主に小学5年生以上で習う漢字や熟語に対して手動でふりがなを振っています。

実装としては、Rubyコンポーネントを作成して、ふりがなを振る部分をこのコンポーネントで包み、ふりがな（ひらがな）をコンポーネントに渡すようにしました。また、Rubyコンポーネント内ではふりがなの有無を切り替えられるようにしました。状態管理にはjotaiを採用し、atomWithStorageを使うことで簡単に永続化を実現しました。
Rubyコンポーネントimport type { ReactNode } from 'react'

import { useAtom } from 'jotai'

import { furiganaAtom } from '@/utils/jotai'

const Ruby = ({ children, rt }: { children: ReactNode; rt: string }) => {
  const [furigana] = useAtom(furiganaAtom)

  if (furigana) {
    return (
      <ruby>
        {children}
        <rt>{rt}</rt>
      </ruby>
    )
  }
  return <>{children}</>
}

export default Ruby
jotaiimport { atomWithStorage } from 'jotai/utils'

export const furiganaAtom = atomWithStorage('furigana', false)
実装例また、新型コロナウイルス <Ruby rt='かんせんしょう'>感染症</Ruby>に関して、現状、一般公開を予定しています。 ただし、 <Ruby rt='かんせんじょうきょう'>感染状況</Ruby>が急変した場合は、

 コンテンツ管理システム今回のwebサイト制作に合わせて、コンテンツ管理システム（CMS）を構築しました。模擬店やイベント一覧（タイムテーブル）、お知らせといった情報に関してはCMS上で管理できるようになっています。

データベースにはFirestoreを採用していて、Next.jsのSSG（Static Site Generation）を用いてwebサイトに情報を反映しています。


イベントを頑張って入力し終えたの図

「お知らせ」の本文に関してはマークダウン記法を使用できるようにしました。マークダウンからの変換についてはReactMarkdownを使用しています。リンクや箇条書き等が表現することができるので、分かりやすく情報を伝えることができたのではないかと思っています。

 タイムテーブル

もう少しデザインを頑張りたかった...

イベント一覧については、cssのgridを用いてタイムテーブルを作成しました。こちらについてもCMS上で入力した情報を元にSSGで生成されています。

overflow-x: scrollを指定することで、スマートフォン等で閲覧した場合には横にスクロールできるようにしています。

 校内マップ文化祭に来場される皆さんは卒業生を除いて、学校内に入るのが初めてor入った経験が少ない方々です。そのような人たちにもわかりやすく校内の案内をしたい！ということで校内マップを実装しました。

SVGを使って実装しており、右下のボタンをクリックすることで拡大・縮小できるほか、マウスのドラッグやタップで動かせるようになっています。

各模擬店は<rect>要素を使用して表示しています。模擬店の情報は以下のように一つ一つ座標やサイズ・色・階層などをハードコーティングしています。[5]
模擬店の情報の例 '258': {
   x: 1270,
   y: 120,
   width: 270,
   height: 190,
   color: 'blue',
   floor: 2,
   roomName: 'パソコン室',
   orgName: 'パソコン部',
   boothName: 'Hello, KSS PC Club',
 },
線についても同様に<polyline>要素を使用しています。各階ごとに座標を指定していきました。
線の例  4: [
    '145 1020 145 800 360 800 360 715 560 715 560 800 440 800 560 800 560 715 775 715 775 800 1515 800 1515 715 1900 715 1900 800 1935 800 1935 1015 145 1020',
    '460 757 560 757',
    '1785 715 1785 800',
    '1840 715 1840 780',
    '1785 780 1840 780',
  ],


一番力をいれて実装したのが、経路探索機能です。各模擬店（教室）間に限られてはしまいますが最短経路をマップ上に表示することができます。

各模擬店（教室）に経路探索用の座標と隣接する頂点（模擬店）の情報を持たせて重みつきグラフ（重みは各隣接頂点間のユークリッド距離）を構築します。今回はおおよそ、頂点数100、辺数250のグラフになりました。経路探索にはダイクストラ法を用いており、通過する頂点を求めた上でpolylineの座標を算出してマップ上に描画しています。

ダイクストラ法についてはNode Dijkstraというライブラリを使用し、フロントエンド側で十分高速な経路探索を実現しています。
各模擬店の座標と隣接頂点を持たせた様子'258':{
    vertex: {
        x: 1310,
        y: 100,
    },
    edge: ['257'],
}
文化祭当日は、webサイトとは別にミライタッチと呼ばれるタッチして操作できる電子黒板にマップを表示して校内に設置した結果、たくさんの方々に活用いただきました。

実装についてはこちらの記事を参考にさせていただきました。

https://qiita.com/chururi/items/93ab81aad98fd8456e15

 1-5.振り返り

教員に依頼をし、文化祭公式webサイトへのリンクを学校HPへ掲載していただいた他、保護者の皆さんに対してはURLを学校の運営するチャットサービスを通じて共有していただきました。また、実行委員会の生徒を中心に家族・友人・知人や卒業生の皆さんに対して周知を行っていただいた結果、上記画像のように約3週間で5000名を超える方にアクセスいただき、閲覧回数は3万回を超えました。



興味深いのは、モバイル端末からのアクセスが9割を超えたことです。ここまでモバイルからのアクセスが多いとは想定していませんでした。最近はモバイルからの閲覧のみ想定して作られたwebサイトも多数見かけますが、この結果を見るとそのような動きが生まれるのも理解できます。（デスクトップのレイアウト考案にかなりの時間をかけたのでちょっと悲しい）

また、モバイル端末からのアクセスの中でも特にiOSユーザの多さが目立ちます。閲覧したユーザ数はAndroid OS:iOS=1:3ほどの比率ですが、日本におけるスマートフォンののOSのシェアはAndroid OS:iOS=1:2ほどの比率であることを考えると、このwebサイトを閲覧した層はiOSユーザが日本の平均に比べてちょっと多いようです。若い世代の閲覧が多かったためでしょうか...?
公開後や文化祭当日には、保護者の皆さんや卒業生のみなさん、友人たちからお褒めの言葉を多数いただきとても嬉しかったです。一方で、実行委員会内での情報共有をサボってしまったため、関係部署と急遽調整を行ったり深夜に連絡を取るなど色々な方面にご迷惑をおかけしてしまった他、コンテンツの不十分さを感じる部分があるなど反省点が数多くあります。来年以降も引き続き運営していくことになると思うので、私も関わることのできる範囲で改善を進めていければと考えています。

 2.来場登録システム
 2-1.概要文化祭の一般公開にあたって来場者数の把握と入場の円滑化を目的として開発されたシステムです。

 2-2.開発までの経緯私の所属校の文化祭は、新型コロナウイルスの影響により2020年以降、中止や開催形態の変更・関係者のみでの実施などが続いていましたが、今年は来場制限なしの一般公開となり、4年ぶりに外部の方を受け入れることとなりました。しかしながら、外部の方を受け入れるのにあたりいくつかの課題点がありました。
来場者数が見通せない

私の学校は比較的新しい学校で文化祭の開催実績が少ない上に、文化祭の一般公開を最後に実施したのが上記の通り2019年と4年前であるため、過去の実績をあまり参考にすることができませんでした。また、2019年以降に地域の受験に対する状況が変化したこと、周辺の学校と同じ日に文化祭を実施するなど様々な要素が原因となり、来場者数の想定が難しくなりました。
入場の際に時間がかかる

火災や地震といった災害や食中毒の発生時に備え、来場者の方にグループ全員の名前と緊急時連絡先を入場時に記入していただく必要がある旨を教員から聞いていました。そのため、ひとグループあたりが入場に要する時間が長くなり、入場待ちの混雑が激しくなることが予想されました。
以上を踏まえ、事前の来場登録を実施すれば良いのではないか、と考えはじめるようになりました。これ以前にZennで以下のような記事を見ていたこともあって、IT管理部で来場登録システムを構築してみたいと思うようになりました。
https://zenn.dev/su8ru/articles/cappuccino-system

https://zenn.dev/newt_st21/articles/gateway-stay-status-record-system
上記記事を参考にプロトタイプを作成し、教員にプレゼンしたところ興味を持っていただき、来場登録システムを導入することが決定しました。

来場登録システムの開発・運営にあたっては文化祭で滞在状況記録システムを運用しましたの筆者であるnewtさんに技術面や運営面で様々なアドバイスをいただきました。いただいたアドバイスなしに円滑な運営をすることはできなかったと思います。本当にありがとうございました🙇‍♂️

 2-3.システム全体の流れ
 予約段階予約手順を含めた一連の流れや注意点を文化祭公式webサイト上に掲載しました。また保護者のみなさんに対しては学校側から来場登録を行なっている旨をチャットサービスにて周知していただきました。[6]

なお、来場登録は必須ではなく、入場した際に紙へ氏名や緊急時連絡先等を記入することでも入場できるようになっていました。

 概要来場者がGoogleフォームに必要事項（氏名・メールアドレス・緊急時連絡先・グループ人数）を入力し送信する
Googleフォームの送信をトリガーにGASが起動する
フォームへの入力内容をもとに予約IDを生成する
予約IDは万が一を想定し、人の目でも解読できるようにRABBBBXXXという形式にしました。

R: 予約種別（3:一般、9:テスト用）

A: グループ人数

B: 入力順で連番（0001-9999)

X: 乱数

3桁の乱数を用いることでお気持ち程度ですが他人の予約IDを入手できないようにしました。何人か入手を試みた人はいたようですが...

予約IDのみをFirestoreへ投げる

こちらのライブラリを使用して、予約IDのみをFirestoreに書き込みます。

電子チケットのURLが書かれたメールをGoogleフォームに入力されたメールアドレス宛に送信する
来場者は届いたメールから電子チケットを開き、予約情報を確認する

 詳細予約システムを一から自作することも考えましたが、生徒が来場者の個人情報を触るのは避けたい+教員からも生徒が個人情報を触れないような運営をして欲しいと依頼されたため、GoogleフォームとGAS（Google App Script）を用いて構築した予約システムを教員に渡して（教員のGoogleアカウントでGASを動かす）、それ以降は生徒が来場者の個人情報に触れないようにしました。

生徒が触れることのできるデータはFirestoreに書き込まれた予約IDのみです。予約IDの仕様により各グループの人数がわかるため、随時それぞれのグループの人数を足し合わせていき、予約した人数を把握していました。（非効率的すぎる）

私の学校ではGoogle Workspace for Educationに加入しており、生徒・教職員に一人一つGoogleアカウントが渡されており、Google WorkspaceのアカウントであればGASから1500通/24時間 までメールを送信することができます。1500件/24時間 を超えるような予約があるとは想定されなかったため、SendGridなどのサービスを利用するのではなくGASで直接メールを送信する形をとりました。（無料で取得できるGoogleアカウントであれば100通/24時間 までですので注意してください）

 注意点GASからそのままメールを送信すると、当該GASのオーナーのメールアドレスがメールの送信元メールアドレスとして設定されてしまいます。学校側から生徒・教職員に渡されるGoogleアカウントのメールアドレスには個人名が含まれる（{姓}.{名}@ドメイン名）ため、以下のようにすることで送信元メールアドレスを送信専用アカウントとし、個人名が露出しないようにしました。
const mailOption = {
  noReply: true
}
// mailAddress: メアド mailTitle: タイトル mailText: 本文
GmailApp.sendEmail(mailAddress, mailTitle, mailText,　mailOption);
https://zenn.dev/newt_st21/articles/using-gas-on-submit-google-form#4.-いっぱいおくる

こちらの記事にあるように、GASの実装次第ではGoogleフォームに同時にたくさんの入力があった場合にGASが期待する動作をしないことがありますので注意が必要です。

実際私もこの記事を見るまではまったく気づいていませんでした。重ねてですが、こちらの記事を執筆されたnewtさんには深く感謝しています。

 電子チケットメールにバーコードの画像を添付することも考えたのですが、キャリアメールだとどうやら画像が表示されないことがあるようだったので、web上で表示することにしました。先述のように来場者にはメールに電子チケットのURLを添付して送信し、電子チケットを開いてもらう形をとりました。


電子チケットのスクリーンショット
スマートフォンをお持ちでない方もいらっしゃるだろうなと思ったので（私が小学生の時は家族含めてスマホを誰も持っていなかったというのもあって）電子チケットを印刷しやすいように、html2canvasを使用して電子チケットのコンポーネントをpng画像に変換し、ダウンロードする機能を搭載しました。

 受付来場者に対して電子チケットを開くよう呼びかける
電子チケット上や公式webサイト上であらかじめ周知していました。

来場者のスマホに表示されるバーコードをバーコードリーダで読み取る
読み取った予約IDが入場可能かを検証する
存在する予約IDか、すでに入場済みのIDではないか、などをチェックしていました。

入場可能であれば、グループの人数を確認し、入場を記録する
予約した際に入力したグループの人数を超えている場合は入場できないようになっていました。（別途緊急時連絡先等を紙へ記入していただきました）

パンフレットの配布や注意事項の説明等を行う
受付は実行委員会の誘導担当の部署の方と連携して行いました。事前に担当する生徒や先生方を集めてもらい、私から受付の対応の仕方（言葉遣い）やバーコード読み取り方、トラブルが発生した場合の対応について簡単なレクチャーを行いました。また、詳細な手順を記したマニュアルを作成し配布しました。

 工夫した点私自身このような大規模なシステムを構築したのは初めてだったのでかなりの不安がありました。来場登録システムが動かなくなった場合、文化祭運営に支障をきたすことは目に見えています。そこで、最悪な状況に備えて予約IDを人力でパースできるような仕様をとったほか、受付の端末がインターネットに接続できなくなった場合などに備え、PWA化+オフライン対応を行いました。

PWA化は、next-pwaを用いて行いました。めちゃくちゃ手軽にPWA化やオフライン対応ができるのでいいですね。オフライン対応としては、バーコードリーダで読み取った予約IDをDexie.jsを用いてIndexedDBに蓄積しておき、CSV形式でダウンロードできるような形をとりました。ダウンロードしたCSVは指定のGoogle Driveにアップロードするようにしました。
ところで、なんでQRコードではなくてバーコードを用いているのかというと、諸事情によりパソコン部にバーコードリーダーが20台ほど保管されていたためです。ログを見返してみた限り、一度も使われることなく4年くらい眠っていたみたいで...使う機会があってよかった。

 2-4.振り返り
 よかった点来場登録を行ったことによって、文化祭への来場者数の把握ができるようになりました。結果的に来場登録を行った人数は実行委員会内で想定していた人数を1000名近く上回ることになりました。あまりにも想定外だったため、この情報を実行委員会内で共有し、混雑対策について検討を行ったほかパンフレットの増刷、準備物の量の調整等を行いました。

しかしながら来場登録を行って実際に入場した人数は来場登録した人数の75%にとどまりました。これは多くの方が文化祭直前になって再度入場登録をしたからだとみています。[7]
受付については概ねスムーズに来場者を流すことができ、受付開始から20分ほどで数百名が並んでいた行列は解消され、それ以降は待ち時間ほぼ0で入場することができたようです。担当した皆さんがとても優秀でした。すごい！

 反省点Firestoreに書き込まれている予約IDの連番になっている部分（RABBBBXXXのBBBBの部分）を見ていると、ところどころ飛んでいる番号があることに気づきました。文化祭終了後に調査したところ、おおよそ3%の割合でFirestoreに記録されていない番号があったようです。どうやら予約の際に動かしたGASでエラーが多発していたようです。（前述の通り、生徒は来場者の個人情報に触れないようにするため運用中含めGASの管理画面にアクセスしないようにしていました）

エラーの詳細について、（私が確認をサボっているので）現時点で把握していませんが、どうやらGASでは不定期にエラーが発生することがあるようです。今回運用にあたっては、エラーが頻発することはまずないだろうと考えたため、予約の際にフォームを送信後メールが届かなかった場合は
システムの不具合によりメールが送信できなかったと考えられます。 大変申し訳ございませんが、文化祭当日の入場の際に緊急時連絡先を指定の用紙へ記入してください。
と公式webサイト上に掲載し特に対応を行っていませんでしたが、即時リトライや定期的に処理漏れに対処するコードを実行するなどの対応を取るべきだったと反省しています。
受付については、実際に受付を行う場所でのシミュレーションを行わなかったがために、想定していなかった事象が多数発生し文化祭当日に運用方法を変更したり、マニュアルを一部変更して対応したりしていました。また、入場方法や動線についての掲示物が不十分だったため、天候が悪かったことも相まって来場者の方を混乱させてしまいました。結局、全力で大声で呼びかけるというパワープレイで乗り切るなどしていました。

今回発生したトラブルの原因は大きく分けて「シミュレーション不足」と「周知不足」だったと考えています。要するに準備不足ですね...さまざまな事態を想定して準備はしたほうがいいです。

突然のマニュアルの変更があったり、私の指示が二転三転する中で、効率的な作業を考え臨機応変に対応してくださった、受付担当の生徒のみなさんには深く感謝しています。ありがとうございました。

 3.情報提供モニター
 3-1.概要文化祭に関わるさまざまな情報を来場者へ提供することを目的として制作されたwebアプリです。主に以下のような機能を備えています。
各模擬店において入力された混雑状況（待ち時間）を表示する
管理画面であらかじめ設定しておいた、今後開催されるイベントを表示する
同じく管理画面で入力された、実行委員会から来場者に対するお知らせを表示する
情報提供モニターによって、特定の模擬店への来場者の集中の緩和が期待できるほか、実行委員会としても混雑箇所の把握や、より効率的な来場者の誘導等を行うことができます。また、各種イベントへの集客や情報の周知にも役立てることができます。


学校HPより引用
機能的には以下の3点から構成されています。これ以降、ここに挙げる名称で説明を行います。
管理画面
アカウント・模擬店情報・イベント情報等の作成・更新・削除を行う。
管理者権限のあるアカウントのみ操作可能。

各模擬店情報入力画面
各模擬店が運営状況や混雑状況を入力する。

情報提供モニター
上記画像の通り来場者に対して情報を提供する。


 3-2.技術的な構成情報提供モニターは、Asaさんを中心としたパソコン部OBが2019年度〜2022年度にかけて開発・運営したkss-pc-club/Fes-Monitorを参考に、フルスクラッチで書き直し+管理画面といった機能を大幅に追加したものです。

 フロントエンドkss-pc-club/Fes-Monitorは、ReactやjQueryを用いて実装されていましたが、公式webサイトなどと同様に、Next.js+TypeScript+Chakra UIを用いて実装をし直しました。

 認証認証には、Firebase Authenticationを使用しました。認証プロバイダにはメール/パスワード認証を使用していて、後述するように各模擬店と実行委員会の幹部生徒に対してアカウントを作成しました。Context APIを用いてログインしているユーザ情報の取得やページへのアクセス制限を行っています。
これまで同様に、データベースはFirestoreを、コードはGitHubで管理してVercelでホスティングしています。

 3-3.運用の流れ
 アカウント作成先ほども述べたように、認証にはFirebase Authenticationのメール/パスワード認証を使用しています。情報提供モニターの管理画面からメールアドレスとパスワードを入力して、Firebase Admin SDKを通じてアカウントを作成するようになっています。メールアドレスのドメイン名には取得したkeyaki.appを使用しています。

import { auth } from '@/libs/firebaseAdmin' // 初期化処理等を行う

const { email, password } = req.body
await auth.createUser({email, password})
アカウント作成にあたっては、卒業生であるRyoga.exeさんが昨年の文化祭にあたって作成したパスワード生成用のコードを使用させていただきました。ABCDEFGHJKLMNPQRSTUVWXYZ23456789の中からランダムで6文字を選んで繋げるようになっています。Iと1やOと0のような紛らわしい文字を使用しないように配慮しているそうです。（任天堂の運営するNintendo Switch Onlineのシリアルコードに倣っているらしい）

 事前準備（文化祭前日〜当日朝）あらかじめ各模擬店の情報（名称・実施団体・場所）とイベント情報（名称・開催場所・開催時間）をアカウント同様、情報提供モニターの管理画面から設定しておきます。



また、文化祭一般公開の前日に、各模擬店の代表者に対し情報入力用のChromeBookと操作マニュアル、ログイン情報（メールアドレス・パスワード）を配布しました。ChromeBookについては学校で予備用として保管されているものを教員の監督の下、IT管理部で配布した端末の管理等を行い、文化祭中に端末が充電切れを起こすなどした際には交換できるような体制を整えました。

情報表示用のモニターは、大型の電子黒板（ミライタッチ）を借用し、ChromeBookからミラーリングする形で運用を行いました。

 文化祭当日各模擬店にはあらかじめ配布したChromeBookから管理画面を通じて、随時模擬店の運営状況（開店、閉店、準備中、中断中）と混雑状況（待ち時間）を入力してもらいました。また、実行委員会では、来場者へのお知らせを随時更新するなどしていました。



この他、ChromeBookの交換対応（結局なかったけど）や情報提供モニターの定期的な動作確認等をIT管理部や実行委員会幹部などで分担して実施しました。

情報提供モニターに運営にご協力いただいたみなさん、ありがとうございました🙇‍♂️

 3-4.振り返り
 良かった点昨年の文化祭で旧情報提供モニターを運営した際、準備や周知の不足が原因で混雑状況を入力しなかった模擬店が多数発生してしまいました。今年はその反省を生かし、できるだけ多くの模擬店に混雑状況を入力してもらえるよう周知の徹底や操作マニュアルの配布などを行いました。

実行委員会としても、混雑状況を参考にして校内の見回り（混雑が激しかったため、安全確保等ができているか確認を行っていました）を行うなど、円滑な運営に繋げることができたのではないかと思います。

 反省点各模擬店にChromeBookを配布し、随時入力するという形を取ったのですが、校内で一部wifiの繋がりにくい箇所があり（主に屋外）一部模擬店の情報が反映できませんでした。今回の文化祭において、生徒のスマートフォンの利用は制限されていたためスマホから情報を入力するということもできませんでした。あらかじめwifiの強度を確認したり、情報を入力できない場合の対処法を考えたりしておくべきでした。

また、実行委員会からのお知らせを流す機能については、「当日空いてる時間に更新をかければいいかな〜」と考えていたのですが、想像以上に文化祭当日は忙しく、更新をしているタイミングがほとんどありませんでした。これを受けて後述する公開版ではお知らせを指定した時間帯に流すことができる機能を追加しました。

 3-5.公開版について今回制作した情報提供モニターと管理画面について、機能の追加や修正を加えたものをFestival-MonitorとしてGitHubにて公開しました。なお、文化祭当日に運用したものから大幅なデザインの変更や実装・仕様の変更などがあり、こちらの記事で紹介している内容と一部異なるものになっています。

各学校の文化祭で使用していただければ嬉しいです！！



https://github.com/keyaki-fes/Festival-Monitor
実装が適当だったり、機能が不十分だったりするので、Issueにて修正提案やバグ報告などしていただけると助かります。また、運用についてはドキュメントを参考にしてください。

 利用にあたって利用にあたっては、利用される方が各自で Firebase の設定を行い、任意のホスティングサービスへデプロイする必要があります。（Next.jsのmiddlewareやAPI Routesが使用できる環境である必要があります）費用がかかることもあるのでご注意ください。
利用にあたっては各学校の文化祭運営状況に合わせてカスタマイズを加えていただければと思います。追加で実装した機能、修正した点などがある場合はよろしければ本リポジトリまでPRいただけると嬉しいです。
このほか利用報告はeno1220のDM等でお待ちしております。本ソフトウェアの各学校の文化祭における運営方法などを教えていただけるとeno1220が喜びます。[8]
不具合報告や機能リクエストについてもTwitterやGitHubのIssueより受け付けています。

 4.そのほか
 4-1.一人一台端末GIGAスクール構想により、私の所属する学校では2019年度後半に国の予算で校内にそれなりに高性能なアクセスポイントが設置されました。各アクセスポイントに対して20-30台程度の接続であればそれなりに快適にインターネットを使用することができます。

体育館や校庭を除くほぼ全校でwifiが使うことができるようになり、中学生にはChromeBookが一人一台配布されていたり、高校生は各自で端末を持ち込めるように（BYOD）なったりしました。

文化祭の実施に当たっても、ChromeBookを各模擬店に一台配布した他、ミライタッチと呼ばれるwifiに接続可能な電子黒板を使用しました。

また、書類の作成や情報の共有など、文化祭に関わる多くの活動をパソコンやタブレット等の端末で行うようになり、紙媒体でのやりとりがかなり少なくなったのではないかと感じています。

今となっては学校でwifiが使えないという時代があったことが信じられません...

 4-2.Google Workspaceの活用県教育委員会全体で Google Workspace for Education に加入していて、生徒・教職員一人一人にGoogleアカウントが配布されています。

実行委員会内では配布した書類やマニュアルの制作をGoogleドキュメントで、名簿や予算の管理をGoogleスプレッドシートで、アンケートや希望調査をGoogleフォームで、書類や動画、音声、イラスト等の制作物の共有をGoogleドライブで行うなど、さまざまな場面で活用されていたように感じます。[9]Google Workspaceでは「組織内」にファイルの共有相手を制限することができるので便利です。

Googleドライブの運用にあたっては共有ドライブ機能を積極的に使用するよう実行委員会内で周知していました。ファイルの共有がしやすいというのもあるのですが、単にファイルを共有する場合だとオーナーの生徒が卒業しGoogleアカウントが無効化されてしまった場合にファイルの閲覧ができなくなってしまいます。ですが共有ドライブを使うことでこれを回避することが可能で、次年度以降もファイルを使い回したり、後輩へ引き継ぎを容易に行うことができるようになります。

話を聞いているとGoogleスプレッドシートやGoogleフォームを活用して模擬店のレジシステムや販売数管理システムを自作して運用を行っていたクラスもあるようです。（すごい！）

 4-3.引き継ぎTwitterやDiscordのコミュニティなどで、「文化祭の技術部門で活動をしてきたものの、これらを引き継ぐ生徒がいない」と嘆く声を幾つか目にしました。私の所属校は普通の(?)中高一貫校ですが、プログラミングに気持ちがある生徒が多く在籍[10]していて、人材の確保には困らない状況でした。実際にIT管理部には約20人の生徒が所属しています。やるべきは、文化祭で使用する技術（Next.js等）を後輩たちへ伝授することです。

IT管理部を設立した時点では後輩の育成を主題においた活動を計画していましたが、文化祭に近づくにつれてだんだんと育成を担当する立場である私の余裕がなくなってしまい、後輩たちを放置する状態になってしまいました。無計画に思いつきで育成プログラムを実施していたこともあり、後輩たちにはせっかく部署に入ってもらったのに当初伝えていたようなこともできず、不快な思いをさせてしまったと反省しています。[11]

当初の育成計画では、オンラインで各自自主的に学習し（教材はある程度指定するがレベルに合わせて選択する方式）、わからない点に関してはチャットで質問をする、という形式をとっていましたが、うまくいきませんでした。定期的にリアルで集まって交流をし、学習する機会を持つということがモチベーションや学習の維持管理の上では重要なのかなと考えています。また、このような育成は実行委員会が主だって活動をする3〜4ヶ月の短い期間でできることではないため、半年〜数年かけて育成するという計画を立てて行くべきでした。

今後、簡単ではありますがReactやNext.js、Firebase等の今回使用した技術の講習を実施したいと考えています。

 5.さいごに記事中にも書いてきましたが、文化祭IT化を進めるにあたっては教員や実行委員会などと協議や調整を重ねたり、学校内で十分な周知を行ったりする必要がありました。（来場登録システムの受付部分など、これらが不十分だった部分もありました。）実際、開発にかけた時間と同じくらい、これらに時間を割いたと思います。IT化を進めるということは、単に何か作ればいいのということではなく、作ったものを実際に使えるように・使ってもらえるようにするための努力を十分にしなければならないことを強く感じました。[12]
各章にも書きましたが、約1年という長い期間をかけて準備してきたプロジェクトが実際に運用されている様子をみて非常に感動しました。また、保護者の方や来場された方々、尊敬する卒業生のみなさんや教職員、友人たちからお褒めの言葉を頂いた時はとても嬉しい気持ちになりました。

なんだかんだ色々ありましたが、経験した中で一番楽しくて充実感がありました。また文化祭やりたいですね。（高3なのでもうないんですが）大学でも学園祭等で情報系の部署に参加したいなと思っていますし、引き継ぎをうまくできなかったので当然ですが、今後も可能な限りIT管理部の後輩たちのサポートをしていこうと思います。
最後になりますが、
これまでの文化祭のIT部門を支え、今回技術的なアドバイスや実装をしてくださったRyoga.exeさんやAsaさんをはじめとする卒業生のみなさん
予約システム構築にあたりアドバイスをいただいたnewtさん
わがままを聞いていただき1年間を通してさまざまな協力をしてくださった実行委員会のみなさん
システムの運営を担当してくださった生徒のみなさん
運営の許可をいただき暖かく見守っていただいた先生方
IT管理部のみなさん
本当にありがとうございました！
また、本記事をレビューしていただいた

Ryoga.exeさん

Asaさん

Sapphさん

はなむさん
をはじめとするみなさんに感謝申し上げます。
記事の冒頭にも書いた通り、記事の内容や記事中で紹介するソフトウェアに関して質問がある場合は、コメント欄や私のTwitterのDMにいただければ可能な範囲で回答します。今回の文化祭で得た知見をできるだけ共有していこうと思いますのでお気軽にお声がけください。
最後までご覧いただきありがとうございました。

脚注
厳密には、一部経費に関しては実行委員会の予算から出してもらっていました。 ↩︎
中でも多かったのは「学校のHPに制作したコンテンツを載せるだけじゃダメなの?」という意見でした。そこで、学校のHPではなく文化祭のwebサイトを制作するメリットについてプレゼンを行ったり、学校のHP上では実現できないようなコンテンツのプロトタイプを制作し、教員にデモを行ったりしました。 ↩︎
文化祭全体の予算が少ないというのもありますが... ↩︎
この記事の執筆をしている際に、Google Domainsの提供終了・事業売却が告知されました。移行や後輩への引き継ぎをどうしようか悩みますね。 ↩︎
GitHub Copilotが補完してくれたのでかなり楽でした。学生はGitHub Student Developer Packで無料で使うことができます。 ↩︎
聞いたところによれば、生徒の皆さんも積極的に来場登録についてご家族、ご友人や卒業生のみなさんに拡散してくださったそうです。ありがとうございました。 ↩︎
生徒は来場者の個人情報に触れることができないため、あくまでGoogle Analyticsなどの情報を勘案した上での考察です。 ↩︎
この記事の執筆をしている際に、TwitterのDMの仕様変更が告知されました。 ↩︎
以前はWordやExcelのファイルをLINEやDiscordで添付して共有していたようです。Officeソフトを持っていない生徒も多いことが、WordやExcelではなくGoogleドキュメントやスプレッドシートを使っている一因でもあります。（Officeは高いし） ↩︎
パソコン部はありますが、パソコン部員でなくてもプログラミングに気持ちのある生徒が生徒数の割に多く存在しているような気がします。また実行委員会IT管理部含めてIT系のコミュニティがいくつか存在しています。 ↩︎
友人からは私が「全て自分でやろう」という思考をしていたのがよくないと指摘を受けました。なんでもかんでも一人でやろうとする悪い癖が出てしましました。仕事を他の人にお願いしたり、アドバイザーとして参加していただいた卒業生などに積極的に頼っていくべきだったと反省しています。 ↩︎
かっこいいことを言いたかったものの語彙力がなくこんな文になってしまいました。 ↩︎