この記事は TUT (powered by LinuxClub) Advent Calendar 2025 14 日目の記事です。 なんとか間に合った。
挨拶
前回の TUT Advent Calendar 2021 を主催した 
id:KashEight (X: @KashEight) です。
いつの間にか 4 年経ってて怖いですね。
話すこと
在籍してたときに残した club-portal というプロダクトについてのお話です。 いわゆるサークル管理システムなんですが、結局未完成のまま卒業してアレになってしまったのでその振り返りに近い話です。
- https://github.com/lc-tut/club-portal
- バックエンド実装
- https://github.com/lc-tut/club-portal-frontend
- フロントエンド実装
時系列
起点
元々 2020 年あたりでコロナウイルス周りの騒ぎでオフラインで色々不都合があったことから始まった話です。 一応当時でも、サークルを掲載する場所は大学 HP 上*1にあったんですが、色々不都合が大きく一旦別にして作ろうという感じでが持ち上がりました*2。
実行主体としては自分が当時部長をしてたサークルでやる感じです。まあ、察しがつくように、LinuxClub というところなんですが…。
結局、自分と、当時会計をしてた友人の二人でやっていました。
初期構成
時期が時期なので、話が来てから作成までの猶予はまずありません。
なので、初期構成は WordPress 上に nginx + oauth2-proxy を通した構成にしました。 oauth2-proxy は大学のメールアドレスのみ通すようにしています*3。
ホストサーバに関しては、元々サークル内で VPS を借りていてそこにホストもできたんですが、DNS などの基幹システムとかもそこに乗っかっていたほかスペック周りも心配だったので、新しく VPS を追加した経緯があります*4。今思えば中々いい判断ですね。
ちなみに、当時いじった WordPress 用の PHP コードとかはまだ GitHub のプライベートリポジトリの中に眠っています。色々と見たくないものがたくさんあったりしますが…。
作り直し
さて、WordPress で立てたのはいいですが、正直 WordPress のメンテナンスコストは高いのでどうにかしたいです。アレな PHP コードだったり本体やプラグイン等のアップデートだったりそういう保守は確実に無理なのはわかっていたので、早々に脱出したい機運は最初からありました。
脱出するとしてもやり方は色々ありますが、当時は最低限以下の要素が必要というのがありました:
- 人にちゃんと見せれるような UI
- サービスとして提供するので
- アクセス制限の実装
- 大学に関係ない人は編集できなかったり閲覧できなかったりするようにしたい
- 中長期運用できるようにメンテナンスコストは低くしたい
- 永続データの保管とフロントエンド上での表示
- サークル情報など
このほかにも色々考えたことは多かったのですが、基本的には上記を必須要件として考えました。 その結果、バックエンドは Go + gin、フロントエンドは TypeScript + React という選択になりました。
主に以下の理由で決定しました:
- Python (w/ Django, Flask) で書きたくなかった
- 文脈として、弊学では Python をメインとして授業が行われる
- その経緯から当然、選定候補になるんですが動的型付けかつランタイム実行で容易に壊れるので、メンテナンスコストが高くなりそうなのが予見できた
- 今みたいなコーディング AI も当然ない
- 小さく、堅牢にバックエンドを書きたいし早く実行したい
- 一つ前の時点で TypeScript で書いて Node.js ランタイム上での実行することも考えたんですが、
node_modules/がでかすぎるし、そこが壊れたら壊れる - かつ、Docker を使った開発は規程路線ではあったので、Node.js + Docker の取り回しでうーんとなりがちだった
- 一つ前の時点で TypeScript で書いて Node.js ランタイム上での実行することも考えたんですが、
- Node.js ランタイムでできる気がしなかった
- Node.js を選ばなかった一番の理由
- まだ Go でやる方がいいかなって…、Node.js ランタイムでのライブラリ選定含めて苦しいなこれとはすでになっていた
- UI 周りを見通しの良い実装にしたい
- WordPress で突貫工事した経験上、バックエンドからのテンプレート表示は確実に崩壊すると思ったので
技術周りの知識はあったので、フロントエンドとバックエンドの基本実装は自分が中心に開発してました。 一方で、UI デザイン周りは手をつけられる自信がなかったので友人がメインにやっていた感じです*5。
さて、技術そのものはいいんですが設計、特にバックエンドの設計に関しては自分はほぼ素人です*6。 技術系のバイトもしたこともなければそういう知識ある人が周辺にいたわけでもなかったので、独学で進めることとなります。
なので、バックエンドは traP が作成している traQ というアプリケーションのアーキテクチャに強い影響を受けています。
いわゆるクリーンアーキテクチャの設計なんですが、見よう見まねではありますがこれをもとに実装を進めました。 結果として、けっこういい感じに実装ができたのではないかと思っています。
フロントエンドは気合いでなんとかしました。
最初のリリースは友人宅で徹夜開発した末のリリースだったのでけっこう思い出があります。 朝 4 時か 5 時ぐらいに見えるバグを直して動いたときは大声で喜んでました。
結局、できたあとは完全に停滞してしまいましたが。
停滞とその原因
マンパワー不足
これが一番大きいです。正直あるあるの話だしいつものではありますが…。
リポジトリの Contribution 見れば一目瞭然ですが、バックエンドは自分で、フロントエンドも当時の友人と自分がメインの開発者という状態です。 インフラ周りも自分がやっていたので全ての面倒を自分が見ていた状態でした。
常に自分が介在している状態なので、マンパワーが当然足りません。
不十分な引き継ぎ
これはすみませんと謝罪するしかないし言い訳しかできない話なんですが、コロナ禍のサークル運営やこれの運用、大学関連の諸々で本当にしんどい状態で引き継ぎが全くできませんでした。
完成したあとはやる気の低下だったり、研究だったりなんなりで文字通り忙殺されたのと、色々と精神的に参っていた時期も重なっていたのでどうしても優先度が低くなりドキュメントもまともに残せなかったです。
振り返りとか
やりたかったこと
機能面で言えば以下があります:
- イベント等のおしらせ
- ユーザに対するメール通知
- アカウント連携周り
コード面で言えば以下があります:
- テストコードの整備
- ドキュメント周りの整備
- CI/CD 周り
まだまだあるんですが、当時のことを振り返るとここらへんがメインだとは思います。 特に機能面周りは一番最初に提示した構想ではあるので、やれなかったことに対していろんな気持ちが湧いてきます。
もし今作り直すとしたら
これに関しては解はないんでしょうが、正直作り直そうと思っても同じような技術選定で同じようなアーキテクチャで作り直すんじゃないかなーとは思います。
なんなら今の実装やデザインをそのまま使う可能性が非常に高い気がします。 それぐらいにはわざわざ新しく作り直そうというメリットもないぐらいには作ったとは思っています。
せいぜいフロントエンドの Chakra UI はやめるとか、このライブラリを使うのをやめるとかそういう細かい話がメインかなと思います。 ただ、もう完全に離れちゃった側なので自分から口出しする権利はないんですが…。
おわりに
ということで、自分が大学時代に遺したプロダクトについて話しました。
色々言ってはいるけど、これを作っていなかったら今の自分はなかったと思いますし、作らなければよかったというような強い後悔はないです。
