人手不足の大学祭で効率化を頑張っている話

公開日

こんにちは。富山大学医学薬学祭実行委員会 委員長の島﨑(@TakahSim)と申します。本記事では大学祭の運営を効率化するためにシステムを構築した話をお届けします。

医学薬学祭実行委員会の現状について

2024年の医学薬学祭の模様

私たち医学薬学祭実行委員会は富山大学に3つあるキャンパスのうち、医学部と薬学部がある「杉谷キャンパス」で大学祭を開催している団体です。杉谷キャンパスは学部が2つしかないため学生数が少なく、その学生もみんな実習やら実験やらであまり時間が確保できません。また、コロナ禍で大学祭が3年間中止になったことにより新入生を集めるノウハウが消えてしまい、新入生を集めるのにも苦戦しています。それだけでなく、数年前から富山大学の1年生の授業はすべて別キャンパス(五福キャンパス。富山駅に近くてとても便利)で行われており、1年生はそもそも杉谷キャンパスに足を運ぶことがありません。

富山大学のキャンパス所在地 (出典：富山大学のWebサイト)

このような理由のため、私たちはほかの大学祭では考えられないほどの少人数で大学祭を運営しています。大学祭当日は他キャンパスの大学祭や出展団体から人を派遣していただいてなんとか運営できていますが、事前準備の事務作業の多くは2〜3人で回す必要がありました。

私たちはこの状況で大学祭を開催するため、時間のかかる作業をへらすべく電子システム化を進めることにしました。

これまでの試みと問題点

2023年度は出展団体からの各種申請手段としてGoogleフォームを使用し、告知手段としてLINEのグループを使用していたのですが、以下のような問題点がありました。

未回答団体の把握が難しい

Googleフォームでは毎回団体名を入力してもらうようにしましたが、団体名の入力には表記揺れがあり、機械的に集計することができません。そのため、どの団体がまだ回答していないのかを確認するために委員が手動でリストから消していくなどの対応が必要で時間がとられていました。

回答の重複が起こる

Googleフォームの機能として回答を1回に制限することはできますが、これはGoogleアカウントに対して1回のみに制限するという設定です。団体の中で複数人が回答することがあるため、この設定はそこまでの意味をなしませんでした。また、この設定を行うと複数の団体に所属している人が1つの団体の分しか回答できなくなるという弊害もあります。

お知らせが読まれたかどうかがわからない

LINEグループではだれが読んでだれが読んでないかの把握ができません。そのため、連絡事項が伝わったかどうかの確認ができず、連絡に支障を来すことがあります。

出展団体の世代交代に弱い

出展団体(サークル)では途中で世代交代がありますが、その際に適切な引き継ぎが行われないことがあります。特にLINEグループでは参加する前のメッセージは見ることができないため、過去のお知らせが伝わっていないことが多々ありました。

効率化の方針

2023年度の反省を生かし、GoogleフォームとLINEグループ以外の方法で各種申請手段を用意したいと考えました。

私たちのような少人数の大学祭が電子システム化をするにあたって考慮すべき点は以下のようなものがあります。

  • 大学祭直前の一番忙しい時期に手間・時間を節約できること
  • 委員長としての仕事の片手間に開発できること
  • 今後の世代でもメンテナンスを続けていけること
  • 壊れないこと(一番重要)

それぞれの項目について、個別に検討しました。

大学祭直前の一番忙しい時期に手間・時間を節約できること

10月に開催する医学薬学祭で一番忙しい時期は9月下旬以降となります。また、準備は4月下旬から始めるので、開発は11月から3月までの5ヶ月間で終わらせる必要があります。

その時点では次年度の大学祭の詳細は決まっていないため、コードを編集せずに設定画面から柔軟にいろいろなことができるようにする必要があります。

委員長としての仕事の片手間に開発できること

大学生は学業が最優先ですので、開発期間中も授業をしっかりと受ける必要があります。午前中は毎日授業が詰まっており、午後も17〜18時頃まで実習があるため、開発に使える時間帯は夜だけでした。また、11月から3月にも委員会の仕事が全くないわけではなく、報告書の作成や会計業務など委員長としてやるべきことはあり、開発にかけることができる時間はかなり少ないです。

そのため、私たちはまず他大学の大学祭で用いられている電子システムでソースコードが公開されているものをカスタマイズして使えないか検討しました。筑波大学の大学祭である「雙峰祭」の実行委員会様がApache-2.0ライセンスでソースコードを公開されていたのを見つけましたが、バックエンドがRustで書かれており、私のRust力では最後まで自力でカスタマイズしきれるか不安があったためこの案は断念しました。

次に、ノーコード・ローコードツールを使用できないか検討しました。医学薬学祭実行委員会ではメール環境としてサイボウズのメールワイズを使用しており、同じサイボウズ社のkintoneを使用できないか調べたところ、こちらは単独では外部にフォームを公開できないようで、私たちの必要とする要件を満たせないようでした。追加で調べたところ、サードパーティー製サービスと組み合わせることでできるようになるようですが、予算面から断念しました。他社のノーコード・ローコードツールについても調査しましたが、予算面と機能面の両方で利用可能なものが見つからない結果となりました。

こうなると自分でWebアプリケーションを開発するしかありません。まず、以下の基準から使用する技術を選定しました。

  • 一般に広く普及していること
  • 型などIDEのサポートが受けやすいこと
  • ドキュメントが充実していること
  • できるだけ既存のライブラリを組み合わせて作れること

これらの観点から、サーバサイドのプログラミング言語はPHP、フロント側のAltJSとしてはTypeScriptを使うことにしました。

PHPのWebアプリケーションフレームワークとしてはメジャーなものでLaravelがありますが、Laravelはモデルで動的プロパティを多用するのであまりIDEの補完に優しくありません。また、データベースのマイグレーションも自分でデータベースに対する変更を書くような思想なので正直好みではないです。私は、開発者がModel(Entity)のあるべき状態を定義したら、機械がそれに合わせてマイグレーションを自動で書いてくれるのがあるべき姿だと思っています。RDBMSという機械にはフレームワークという「機械」が対話すべきです。

SymfonyだとデフォルトでORMとしてDoctrineを使用するのですが、Doctrineはこのような思想に近く、マイグレーションを自動で生成してくれます。また、SymfonyはPHPのAttributeという構文を使ってルーティングやアクセス権など様々な設定を行うのですが、こちらも美しくて好きです。そのため、サーバサイドのフレームワークとしてはSymfonyを使うことに決めました。

(補足)この記事を書いているときに知ったのですが、一応LaravelでもDoctrineは使えるらしいです。

次はフロントエンドです。残念ながら私にはデザインのセンスは一切ないので、Bootstrapやその他ツールキットを使うことは前提でした。あとはそれをSymfonyから直接HTMLとして出力するか、フロントエンドを別個にReact等で作ってWeb API経由で連携させるかを考える必要があります。

SymfonyからHTMLとして出力する利点としては、いちいちAPI仕様を定めずに柔軟に画面構成を変更できること、SymfonyのForm機能を利用してフォームのバリデーションやエラー表示をフレームワークに任せられることなどがあります。

一方、フロントエンドを別個に作る利点としては、よりリッチな装飾ができてUXを高めやすいこと、将来的に開発者が増えた場合に分業がしやすいこと、サーバサイドに詳しい人とフロントエンドに詳しい人のそれぞれの能力を最大限に引き出せることがあります。

今回は人員・期限ともに余裕がなく、とりあえず動くものを完成させることが重要だったためSymfonyからHTMLとして出力することにしましたが、将来的にはフロントエンドを分離したいと考えています。医学薬学祭のWebサイトはReact(Next.js)で作っているため、それに乗せることも検討しています。

医学薬学祭のWebサイト(2024年度のもの)

今後の世代でもメンテナンスを続けていけること

医学薬学祭実行委員会は学生で構成されているので、代替わりのことも考える必要があります。世代が変わってもメンテナンスを続けることができるようにするためには運用難易度を下げた上でマニュアルを残しておくことが有効ですが、具体的に運用の難易度を下げる方法として以下の対応をしました。

Kubernetes管理ツールを導入する

Kubernetesはコマンドラインからkubectlを叩いて操作することが多いですが、私を含め一般人にはちょっとそれは難しいです。どこで何が起きているのかを網羅的に把握できるツールとしてRancherを導入しました。

さくらインターネット様にはさくらのクラウドをご提供いただいておりますので、そちらの仮想マシン上でRancherを動かし、そのKubernetesクラスタで今回開発したシステムやWebサイトを動かしています。

医学薬学祭のインフラ構成図

自動デプロイを設定する

また、RancherにはFleetというCI/CDシステムが付属しているので、それとGitHub Actionsを組み合わせて、GitHubにPushしたら自動でデプロイされるように設定しています。

ここでKubernetesで動かすイメージはさくらのクラウドのコンテナレジストリに保存しています。ストレージ系は管理が面倒なので、ここをマネージドでやってくれるのは大変ありがたいです。

壊れないこと

何度も繰り返していますが、私たちには人手が足りていないため、システムが壊れたときの影響がかなり大きくなってしまいます。そのため、システムの構成要素は冗長化するよう心がけています。

まず、Rancher・Kubernetesのレベルではすべてロードバランサを用いたHA構成で構築しており、そのロードバランサアプライアンスや上流のVPCルータアプライアンスも冗長構成にしてあります。

Kubernetesノードを動かすVMでは作成時に@groupタグを指定し、収容ホストが分散されるように工夫し、収容ホスト障害の対策を行いました。

さくらのクラウドのマップ画面。VMに@groupタグが設定されている

ストレージについては運用難易度が高いため、LabプロダクトのエンハンスドデータベースでTiDBを用いて動かしています。TiDBはMySQLとの互換性が高いため、ローカル開発環境ではMySQLを使うが本番環境ではTiDBを使うといったことも可能です。

ちなみに、MySQLのInnoDBではPrimary KeyとしてUUIDを用いるとパフォーマンスが低下する問題がありますが、TiDBではむしろPrimary KeyとしてUUIDを使用することが推奨されているようです。分散型データベースの特徴を感じますね。

アップロードファイル等のBLOBはオブジェクトストレージに保存し、消えて困るデータは絶対にノードのローカルストレージに保存しないようにしています。

それでもどこかが壊れたらどうするのかという話にはなりますが、これらの構成はすべてTerraformで書いてあるので、壊れたら一度すべて消して再度terraform applyを実行することで作り直すことができます。データは前述のとおりエンハンスドデータベースやオブジェクトストレージに保存されているので一切の影響を受けません。

このように技術選定を進めた結果、医学薬学祭の電子システムは昔からある技術と最近っぽい技術が入り交じる実に興味深い技術スタックで構成されるようになりました。

将来に向けての構想

2024年度の医学薬学祭の電子システムは上記のような構成でRancher・Kubernetes上に構築したのですが、残念なことにKubernetes周りをわかる人はアプリケーションレイヤーをわかる人と比較して少ないです。富山大学杉谷キャンパスにはもともと情報系の人は少ないので、将来的に引き継ぎのハードルを下げるためにも、自分たちでKubernetesクラスタを運用するのではなく何らかのPaaSを使用することも検討すべきかもしれません。

ちょうど今年(2025年)の2月4日にさくらインターネットからAppRunというPaaSサービスのβ版が提供されましたので、2025年度の電子システムの一部をこれに載せられないかと考えています。

また、私たちと同じように、事務作業の電子化に課題を感じているが人手不足によって改善が難しいという状況にある大学祭が全国に複数存在しているなら、そのような大学祭が共同でシステムを開発・運用できないかと考えています。もし興味のある方がいらっしゃいましたらぜひお声がけください。

富山大学医学薬学祭実行委員会
〒930-0194　富山県富山市杉谷2630　富山大学杉谷キャンパス
Webサイト：https://www.iyakusai.com/
メールアドレス：info@iyakusai.com