はじめに
2026年3月ごろから、個人主催のイベントにおいて、参加者の管理や受付を行えるWebサービスを開発しており、7月にリリースしました。既に50人規模の配布企画や、140人規模の打ち上げで使っていただきました。本当にありがたい限りです。
実際に開発して分かったのは、「システムを作ること」と「現場の課題を解決すること」は、まったく別の難しさを持っているということでした。
本記事では、Webサービスを個人開発し、140人規模のイベントで実運用するまでに経験した、技術選定・失敗・現場での気づきを振り返ります。
個人開発に興味がある方に届いてくれたら嬉しいです。
プロフィールなど
私は2025年に異業種から転職し、Webアプリのシステムエンジニアとして、都内の会社に勤務しています。
学生時代に趣味でJavaをやっていたくらいで、実際にシステムを開発する知識は今の会社に入るまでほとんどありませんでした。
実務経験は約1年半で、主にSpring Boot、Thymeleaf、MySQL、Nuxt（少しだけ）を使用しているシステムの開発を担当しています。
個人開発をしようと思ったきっかけ
きっかけは、とあるライブ後の打ち上げに参加したときでした。
受付で、1人のスタッフの方が紙の名簿から参加者の名前を探して、誰が来たのか記録していました。
後から聞いた話では、参加者が60人前後いて、受付だけで1時間近くかかったそうです。
集金は後からだったので、純粋に参加者の本人確認だけで1時間です。
その光景を見た時です。
この業務をもっと効率的にできないだろうか。自分の持つ知識を使って助けることはできないだろうか。
そう強く思ったのを覚えています。
実際に作ったもの
開発したのは、イベント参加者が事前に申し込み、当日はQRコードを提示して受付できるWebサービスです。スタッフ側では、承認・支払い・受付状況などをリアルタイムに確認できます。
以前は約60人の本人確認のみの受付に1人で約1時間かかっていました。
今回の実運用では、集金や年齢確認を含みながら、ピーク帯の118人を受付スタッフ5人で並列化し、約45分で処理できました。
要件整理と技術選定
ざっくりと基本的な機能を決める
今回作成したWebサービスで、絶対に実装したい機能や要件は以下の通りでした。
- 参加者の状況をリアルタイムに把握できること
- 承認や集金の有無などを集計できること
- QRコードによる参加者の本人確認ができること
- SNSによるソーシャルログインに対応すること
- 直感的に理解できるUIを提供すること
- イベントの参加者とスタッフでセキュリティ境界を明確にすること
ひとまずこのあたりを最初に決めました。その上で技術選定を行いました。
技術選定
今回選定した技術は以下の通りです。
-
フロントエンド
- Thymeleaf ... SSRしたかったから
- Alpine.js ... 使いたかった！！本当に初心者
- Bulma ... レスポンシブデザインを作りやすいと聞いたので
-
バックエンド
- Spring Boot ... 最も使い慣れたJavaのフレームワークだから
- Spring Session ... 外部DBにセッション情報を保存したかったから
- Spring Security ... セキュリティ境界を強固にするため
- MyBatis ... SQLを直接記述してDBを操作したかったから
- scribejava ... X OAuth 1.0aの認証用
- PostgreSQL ... こだわりなし、無料だから
-
デプロイ先やDBなど
- Cloud Run ... 無料枠が強力だったから
- Supabase ... 無料でRDBMSが使えるから
- Cloudflare ... 無料でDDoS対策などができるから
本当はモダンな技術が使いたかったので、 Spring BootでREST API + Nuxt とかにもしてみたかったです。
けれど、 自分の今の知識で、安定して安全に動くものを作れるのか と考えた時、私はNuxtの知識が非常に乏しかったので、自分にとって経験や知識のあるSpring Boot + Thymeleafを主に使用することにしました。
開発中の話
現場の声を聞きながら機能を増やした
ひとまず、イベント運営に最低限必要な情報として、次のようなものを考えました。
- 参加者のプロフィール（名前、アイコンなど）
- 参加者のステータス（承認済みか、お金は払っているのか、キャンセルしたのか）
- 誰がどのイベントに参加していて、権限はどのレベルなのか
など、言い出すとキリがないので、思いついたものから次々に追加していくスタイルで実装していました。素早く形にできる反面、後から振り返ると、これが技術的負債を増やす一因にもなりました。
ありがたいことに、イベント主催経験者の方々から現場の課題を教えてもらい、プロトタイプを触ってもらいながら打ち合わせができました。現場で実際に使用する人の声が聞けるのは本当に助かりました。
15人規模の受け入れテストで約40件の課題が見つかった
リリースの1ヶ月前くらいに、「このままイベントに出しても受付業務などはいけるな！」と思った時点で、主催経験者の方にお願いして人を集めてもらい、テストをやりました。
結果はかなりシビアなもので、課題がめちゃくちゃ出てきて、大小含めて40箇所くらいの修正をするハメになりました。
これは本当にやっておいて良かったと思います。結局のところ、実際に使ってもらわないと出てこない問題は山ほどあることを、身にしみて感じました。
リリース直前に大規模改修をした
当初、このシステムはXによるソーシャルログインを前提に開発しており、新規にアカウントを発行したりする手間をなくそうとしていました。とある晩、見事にXがサービスダウンしてしまい、急遽Discordによるソーシャルログインもできるように対応しました。
この時、Xの認証情報とDiscordの認証情報を紐づけ、各SNSのアカウントを連携してマルチログインできるようにしました。つまり、
「Xがダウンしていても、Discordでログインすることで、Xのプロフィール情報を使うことができる」
という状態を作りたかったのです。
これがめちゃくちゃ大変！！！
連携後のユーザーIDをどうするのか、片方の連携を解除したら紐づくSNSの情報はどうするのか、既に参加登録したユーザーの情報はどうやって書き換えるのか、など。
このあたりから、ソースコード全体がどんどん汚くなってきて、保守や調査にCopilotやCodexを多用するようになりました。
リリース後の話
本番環境ゆえの問題が多発
Googleの検索インデックスにうまく登録されない、CDNがキャッシュしてくれない、古いデータがGCPに残って無駄に課金されるなど、本番環境でなければ浮き彫りにならない問題が大量に出てきて、安定して運用できるまでに1ヶ月くらいかかりました。
その間にも、打ち上げ当日までにほしい機能を追加したり、アプリ側のバグを修正したりと、やることはたくさんでした。
モチベーションが切れた、それでも作り続けたいと思った
リリース後、急にモチベーションが無くなってしまった時期がありました。
本業をやりつつの趣味の個人開発には、知識の限界や心理的負担が少なからずあると思います。
特に今回は実際に使われる日が決まっていたため、「間に合わせなければならない」「本番で失敗できない」という心理的な負担もありました。
本番で事故ったらどうしよう。
1回きりで使われなくなったらどうしよう。
使った結果、むしろ運営が大変になったらどうしよう。
そんなことを考えている時期もありました。
それでも、作り続けました。
リリースしてしまった以上、半端な形では終わらせたくなかったというのもありますが、根本にあった原動力は、
「自分の持つ知識を使って、誰かを助けたい」
ということを強く思い続けたからだと思います。
だからこそ「使ってもらう予定の打ち上げでは絶対に事故らせないぞ！」と、強く思いながら改良を続けました。
140人規模のイベントで実運用した
元々、9月のライブの打ち上げで使ってもらう前提で開発がスタートしたこともあり、実際に現場で技術スタッフとして参加してきました。
謎のHTTP 404/409 が大量に発生
スマホでCloud Runのログを監視している時に、謎の警告が大量に流れてきて？？？となっていました。業務自体は一応できているので一旦放置していましたが、ちょっと気持ち悪かったです。
原因は現在も調査中ですが、「エラーや警告が出ているけど業務は動いている」という状態を現場で判断する難しさを感じました。
綺麗だと思ったUIと、現場で使えるUIは違った
テストしていたときは、実際に人を動かすわけではないので心理的に落ち着いて操作することができます。
しかし、特に人が集中した時間帯には1分間に10人ほどが受付へ来ることもあり、「QRコードの読み取り→年齢確認→集金→受付完了」を複数のスタッフで同時に捌く必要がありました。落ち着いている場面では問題なくても、現場のスピードにUIデザインが追いつけず、何度もQRコードを読み直したり、ページのリロードが必要になってしまいました。
ページ遷移する余裕すらない
全体の状況はダッシュボード、受付はQRスキャナー、参加者の属性情報は案内履歴からチェック、といった感じで、ページごとに必要な情報をまとめているデザインになっていました。しかし、
実際の現場ではまじでページ遷移する余裕が無い！！！
ページ遷移自体は数秒でできましたが、必要な情報が一瞬で取れないという小さな時間の積み重ねは、かなりストレスになりました。
開発を一区切り終えて感じたこと
やりたい技術と使える技術は違う
結局のところ大切なのは、「現場で安定して動かせるかどうか」です。当初、Nuxtを使いたかったですが、結果的に使わなくて良かったと思います。ただ、途中で緊急度の高い改修などがいくつか発生してしまったため、後半の実装はAIによるコード生成に頼る場面が増えました。
生成されたコードを十分に整理しきれないまま改修を進めた結果、メソッド名が曖昧になったり、JavaScriptの処理が乱雑になったりして、保守が難しくなっています。
まずは既存の構成を維持しながら乱雑になったJavaScriptを整理し、必要な箇所からVueへ移行する予定です。Nuxtの採用については、知識と要件が揃った段階で改めて検討したいと思います。
作りたい機能と求められる機能は違う
開発者自身が「これがあれば役に立ちそう！」と思っていても、実際に現場で使ってみて全く使い物にならない機能がたくさんありました。だからこそ、「現場を知ること」「現場の求めているものを知ること」「現場の人が考えていることを知ること」の大切さを身にしみて感じました。
有識者がいることのありがたさ
知り合いの打ち上げ主催経験者の方に現場の運用について意見をもらえたおかげで、本当に必要な機能を考えることができました。
知り合いのエンジニアの方にセキュリティや通信周りについてチェックや指導をもらえたおかげで、セキュリティ境界やDB周りの品質を向上させることができました。
1人の力では限界があります。だからこそ、経験や知識のある方がいることは、本当に心強かったです。
AIにはまだ限界がある
AIはとても優秀です。実際にこのプロジェクトの開発でも、さまざまなコーディングエージェントを活用しました。漠然とした内容でも、ある程度形にした答えをくれる。本当にすごいと思います。
けれど、AIは実際の現場を知りません。
そして、人間は矛盾の塊です。
現場で生じる焦りや判断の迷いまで、AIだけで予測することはできませんでした。
だからこそ、AIの提案を採用するには現場を客観的に観察し、最終的にどうするのかを判断する力が人間に必要だと感じました。
実装力だけでなく、現場を理解し、矛盾する要望の中から利用者が本当に必要としているものを読み解く力が、エンジニアとして成長するうえで最も大切だと感じました。
まとめ
一瞬の思いつきがきっかけになった個人開発で、結果的にかなり大きなプロジェクトになってしまいましたが、やってみて本当に良かったと思います。
特に、インフラやセキュリティの知識、上流工程への理解、AIに関する知識など、始める前にはまったく無かった知識をたくさん習得することができました。
そして、コードを書くこと以上に、現場を知り、試し、失敗から改善することの大切さを学びました。
もし身近に解決したい課題があるなら、まずは実際に困っている人の話を聞き、小さく作って使ってもらうところから始めてみてはいかがでしょうか。
最後まで読んでいただきありがとうございました。