Diary of a Perpetual Student

Perpetual Student: A person who remains at university far beyond the normal period

学園祭のWeb開発を語る: 抽象編 自分たちの責務をどう絞り、どう委嘱するか

遠い昔に学園祭の Web 開発をしていた話をするシリーズもの最終回

  1. 具象編1: 講習会と砂場遊びで支える組織
  2. 具象編2: 開発体験・保守性を投げ捨てる
  3. 抽象編: 学園祭の開発部署という組織や、学園祭Webサイトというプロダクトの性質から語る ←イマココ

ここからは、これまでの昔話ではなく、現代の Web 事情を踏まえたり、自分が昔いた組織特有ではない一般の話に寄せたりして書いていく。

もし、自分がまた大学生になってどこかの学園祭の Web サイトを作るとしたら、どういう選択をするだろうか。そんな思考実験をしてみる。

静的なサイトを作ろう

ここ4、5年でフロントエンド界隈は凄まじい進化を遂げたと思っている。TypeScript により保守性と開発体験が向上したし、React や Vue.js など、再利用可能で影響範囲のスコープを絞れる component ベースで物を作れるフレームワークも一般に浸透した。

個人的に一番偉大だと思っているのが、Next.js や Nuxt.js などに実装されている Static Generation(静的サイト生成)である。

サーバ上で HTML を動的に組み立てるのは、パフォーマンスやセキュリティ面での懸念がある。もちろん、プロには知識があるから、キャッシュを活用したり、フレームワークを適切に使って XSS や SQLi を回避したりする。しかし、それを学生に求められるかは難しいところがある。このシリーズエントリの中で講習会をやっていた話をしたが、フロントエンドとサーバサイド両方の話をガッツリやっていたらあっという間に1年が過ぎてしまう。

自分がかつて作っていた学園祭のサイトは、同じアプリケーションでお客さんに見せる部分も、学生に見せる部分(電子申請フォーム)も作っていた。お客さんに見せるところでも、ヘッダメニューなどをテンプレートで作るためにサーバサイドのフレームワークで HTML を組み立てていたのである。しかし、現代でそれを行うのはリッチなフロントエンドフレームワークを使って簡単にできる。電子申請の部分は別のアプリケーションとして分けてあげればよい。

一般的な学園祭サイトの運営において、ある程度技術を身につけて自分たちで作るのであれば、フロントエンド寄りに軸足を置いた方が良い。この状況はこの先しばらくは変わらないんじゃないか、と思っている。

もちろん、SG でサイトを作ればセキュリティ面の心配は全くない、と言っているわけではない。でも、考慮範囲が小さくなるだけで十分儲けものである。

従量課金のクラウドサービスは選択しにくい

アプリケーションの次はそれを載せるインフラの話をしよう。

今の自分が選ぶとしたら、有名なレンタルサーバを月定額で借りて、そこに静的な Web サイトをデプロイする。マネージドなクラウドサービスに載せるのも cool で個人的にはやりたいものの、それを組織が選ぶべき選択肢として提示することはないかもしれない。

一番の問題は料金面である。たかだか学園祭のサイトにマネージドサービスにするほどのトラフィックはない。システムのスケーリングを手動で行うこともないので、それをマネージドサービスが勝手にやってもらっても恩恵が薄い。

特に、従量課金体系の場合は要注意である。ケチって WAF を入れないでいたら DDoS 攻撃喰らってクラウド破産、みたいなことが起こらないように運用しなければならない。そういうところにちゃんと興味があって学園祭のサイトを運用しようとしている人は本当に少ないのではないだろうか。

自分が学生の頃を思えば、監視という業務を本当に疎かにしていたと思う。Availability の目標値どころか Observability も 0 であった。

これは Twitter などで公になっていることなので書くが、自分がいた学園祭実行委員会の Web 担当部署が昨年、所有しているドメインを失効させオークションにかけられてしまう、という事故を起こした。Webサイトは閲覧不可能になり、独自ドメインのメールで学内外の人と連絡していたのもできなくなっただろう。そして、ドメインを再度手元に戻すために多くの負担を強いられた

こういった変化するものを、人とシステムの力で観測できる状態にするという取り組みに手が割けないのであれば、従量課金のサービスなんてとても使っていられないと思う。これは仕方ない面もあって、企業は週5日働いてくれる社員を雇って運用するのだけれど、学生の本分は遊び勉強なので、それほど恒常的に時間を割けない。

料金のトラッキングができないのであれば、定額でサービスを提供できる方が学園祭のサイトとしては嬉しいと思う。これは、サービスの可用性と料金の予測可能性とどちらが大事ですか?というトレードオフの関係になっている。

もちろん、サーバを持つこと自体もセキュリティ面での懸念が大きいだろう。(そのため、権限が大きくないレンタルサーバを候補に上げた。)クラウドサービスを使うことの否定はしていなくて、無料枠で確実に収まり勝手に料金が増えなければ良いと思う。

まとめ

プロダクトそのものの価値にどれぐらい commit したかも大事だが、その裏側でどんな根拠を持ってこういう意思決定をした、と自信を持って言えることも重要だ。自分が新卒採用の面接担当だったらそういう話を学生から聞きたいと思う。

zenn.dev

上のエントリを読んで「めちゃくちゃ良いな」と思って始めたこのシリーズ投稿もこれでおしまいにする。学園祭 Web 界隈の益々の発展を祈っている。