はじめに

はじめまして！Qiita記事初投稿となります、hinata（@hinanata72）です。

現在、完全未経験からWebエンジニアを目指して、オンラインスクール
RUNTEQ にて Ruby on Rails を中心に学習しています。

この度、スクール内の制作課題の成果物として、音楽フェス準備を楽しく・スマートにするWebアプリ「FES READY（フェスレディ）」を本リリースいたしましたので、その紹介をさせていただきます。

🔗 FES READY

アプリURL：https://fesready.com

GitHub：https://github.com/hinata7777/fes_ready

目次

作成経緯
Webアプリの紹介
こだわりポイント
技術スタック
技術選定理由
反省点
感想

1. 作成経緯

突然ですが、私の趣味は音楽ライブに行くことです。🎸

音楽ライブの中でも「音楽フェス」と呼ばれるものに参加することは特に好きです。

音楽フェスでは、1日の中で様々なアーティストを観ることができます。
好きなアーティストをたくさん観られるのはもちろん、知らないアーティストのライブをきっかけにファンになることもあり、自分の音楽の幅が広がる、とても大好きな空間です。

しかし、音楽フェスに行くたび、

フェス情報の閲覧：フェス公式サイト・アプリ
楽曲予習：Spotify・YouTube
当日の持ち物リスト：Web検索・メモ帳アプリ
当日の天気：気象アプリ

…と、複数のサービスを4〜5個も行き来するのが当たり前 でした。

結果、

当日のタイムスケジュールが組みにくい
知らないアーティストのどの曲を聴いて予習すればよいのか分からない
初参加のフェスほど迷いやすい
必要な持ち物の漏れが起きる

という フェス準備の負担 がどうしても発生していました。

今となっては慣れもあり、当たり前に準備ができている自分ですが、
初めてフェスに行ったときには、必要なものの買い忘れや、予習して聴いていた曲を全くライブで歌わないなど、様々な面で失敗してきました（それも良き思い出ではあるのですが笑）

課題のアプリ開発をするにあたってふと思ったのが、

「フェスの準備を全部ひとつのアプリで完結できればいいのでは？」

というものです。その課題感から

「予習・準備・当日動線をトータルでサポートするアプリを作ろう」

と思い立ち、「FES READY」の開発をスタートしました。

🧭 まとめ
音楽フェス準備で感じていた「複数サービスを行き来する不便さ」から、
“予習・準備・当日動線をひとつにまとめたい” という課題意識が
FES READY 開発の原点です。

2. Webアプリの紹介

ここからは、「FES READY」の機能について簡単に紹介します。

🔍 フェス・アーティスト情報の閲覧・検索

開催予定のフェス情報や、アーティスト情報をまとめています。

フェス情報に関しては、

基本情報（公式サイト、開催地等）
出演アーティスト情報
タイムテーブル
「屋内/野外」等のタグによる環境情報
日程ごとの予習リスト

まで一括で確認することができます。

🎧 過去セットリスト × Spotify 埋め込みで楽曲予習

各アーティストには予習用ページがあり、

過去の出演フェスにおけるセットリスト
曲ごとのSpotify試聴（Spotifyに音源がある曲のみ）
フェスにおける頻出曲ランキング

初めて観るアーティストでも、「まず何を聴けばいい？」問題 が一瞬で解決します。
現在はデータがまだ少ないですが、今後もセットリストデータを追加予定です。

🕒 マイタイムテーブル作成

参加予定のフェスを選んで、観たいアーティストの出演枠を選ぶことで、
フェス当日のマイタイムテーブル を作成できます。

これにより、当日のタイムスケジュールをアプリ内で一括管理することができます。

🎒 持ち物チェックリスト

自分専用の持ち物リストを作成することができ、作成した持ち物リストはチェックリストとして利用することができます。

さらに、参加予定のフェス日程を設定すると、
当日のフェス会場の天気予報 が表示されるため、当日の天気や気温によって最適な持ち物リストを作成することができます。

🔍 まとめ
FES READY では、
フェス情報・楽曲予習・タイムテーブル・持ち物管理・天気確認 を
ひとつのアプリで完結できるようにしています。

3. こだわりポイント

ここからは、開発でこだわって作成したポイントについて簡単に紹介します。

📚 使い方説明不要！直感的に操作できる導線

自分自身が新しいアプリやサービスを利用する際に、「使用方法」を読むのが正直めんどうだと感じるタイプです。
そのため、「なんとなく触っても迷わず使える」画面設計を目指して開発しました。

例えば、作成した「マイタイムテーブル」を確認したい場合、

「タイムテーブル（フッター）」→「マイタイムテーブル一覧」
「マイページ」→「マイタイムテーブル一覧」

というように、2つの導線からアクセスできるようにしています。

「マイタイムテーブルを見たい」と思ったときに、
ユーザーが直感的に向かいそうなのは「タイムテーブル」か「マイページ」だと考え、
その両方に導線を用意しました。

毎日のようにフェス準備をする人は多くないと思うので、
たまに触っても迷わず使えることを大切にしています。

👀 ひと目でわかる「聴くべき曲」

フェスに参加するとなると、観たことのないアーティストの予習をしようと考える方も多いと思います。
しかし実際には、

Spotifyのトップソングが、必ずしもライブ定番曲とは限らない
フェス公式プレイリストには、実際のセットリストとズレた曲が含まれていることがある
個人作成のプレイリストには、その人の好みが強く反映されがち

といったことも多く、
「予習していたのに、ライブでは全然やらなかった…」という経験を何度もしてきました。

もちろん、曲を知らなくてもライブは楽しめますが、
2曲くらいでも知っている曲がセットリストに入っていることが、そのステージを観続けるきっかけになる
と個人的には感じています。

そこで、
過去のフェスセットリストをもとに楽曲データを集計し、
フェスで“実際によく演奏されている曲”がひと目でわかる仕組み
を作りました。

✔ まとめ
「説明を読まなくても使える導線」と
「何を聴けばいいかがすぐ分かる予習体験」にこだわり、
直感的に使えるUI/UX を目指しました。

4. 技術スタック

Rails 8 + Hotwire（Turbo / Stimulus） + Tailwind CSS
PostgreSQL（Neon）
Docker、Fly.io
認証: Devise + Google OAuth
外部連携: Spotify API, Open-Meteo API

5. 技術選定理由

ここからは、使用技術の選定理由について簡単に紹介します。

💎 Rails 8 + Hotwire（Turbo / Stimulus）

本アプリは、私が学習しているメイン言語"Ruby"のフレームワークである Ruby on Rails を用いて開発しました。
RUNTEQがRails中心のカリキュラムであることも大きな理由のひとつですが、

フェス情報の一覧・検索・詳細表示といった CRUD中心の機能が多い
初学者でも素早く機能追加・改善を回せる 開発生産性の高さ
Hotwire によって SPAに近い操作感を、少ない実装コストで実現できる

といった点が、「FES READY」のような個人開発のWebアプリに非常にマッチしていると感じました。

📝 検討した構成メモ

Rails + Hotwire：◎ 実装コストが低く、学習内容をそのまま活かせる

Rails API + React：△ フロント・バック分離で学習コストが高い

Next.js + BaaS：△ 当時の自分には設計・運用が難しそう

→ 今回は「まず価値を届ける」ことを優先して Rails + Hotwire を選択

API + SPA 構成（Rails API + React / Next.js など）も検討しましたが、
初期実装や運用コストを考えると、
まずは少ない工数で価値提供できる Rails + Hotwire が最適だと判断しました。

🗃 Neon（Serverless Postgres）

DB には Serverless Postgres である Neon を採用しました。

Free プランで手軽に本番 DB を用意でき、初期コストを抑えられる
PostgreSQL をそのまま利用でき、Rails との親和性が高い
Fly.io との組み合わせ事例が多く、構成イメージがしやすい

個人開発としてまずは 「小さく始めて、必要に応じてスケールできる」 点を重視し、
Neon を選定しました。

☁ Fly.io

インフラには Fly.io を採用しました。

Docker ベースで Rails アプリをそのままデプロイできる
東京リージョンがあり、日本からのアクセスで低遅延が期待できる
個人開発でも扱いやすく、ドキュメントや事例が豊富

また、過去に別プロダクト「MeloLog」で Spotify API の技術検証を行った際、
Renderのシンガポールリージョンでデプロイしていた環境では、
日本語表記の楽曲名データがうまく取得できずに苦戦した経験がありました。
（結果的にはリージョンそのものが直接の原因ではなかった可能性もありますが）

この経験から、
日本向けのサービスである以上、まずは東京リージョンで動かす構成にしておきたい
と考え、Fly.io を選定しました。

🎧 Spotify API / Open-Meteo

外部 API については、アプリの体験価値を高めることを重視して選定しました。

Spotify API：アーティストの楽曲試聴やビジュアル情報を取得し、直感的で楽しい予習体験を実現
Open-Meteo API：会場周辺の天気予報を取得し、当日の持ち物準備に役立つ情報を提供

「フェス準備をトータルでサポートする」というコンセプトに合う API として、
これらを採用しました。

Spotify API

Open-Meteo

6. 反省点

アプリ開発中の反省点は山のようにありますが、特に大きかったのは以下の点です。

New Relic 等によるパフォーマンス監視がまだ十分にできていないこと
通知やシェア機能など、ユーザー体験を高める機能が最小限に留まっていること
ER 図・DB 設計の甘さにより、後から何度もカラム追加のマイグレーションを行ってしまったこと

特に DB 設計については、当初の ER 図に
UUID などのセキュリティ面を考慮したカラム設計が不足しており、
開発途中で何度もスキーマを見直すことになってしまいました。

その結果、マイグレーションの管理やデータ整合性に気を遣う場面が増え、
「最初の設計フェーズの重要性」 を強く実感しました。

これらの反省を踏まえ、今後は「設計段階でのレビューや検討時間」をより多く取り、
パフォーマンス監視やユーザー体験の改善も含めて、
継続的にブラッシュアップしていきたいと考えています。

🎓 この開発で得た学び

設計フェーズに時間をかけることで、後工程の手戻りを大きく減らせる

「動く」だけでなく「運用し続けられる」構成を意識することが大切

小さく作って改善する個人開発では、割り切りも重要

7. 感想

今回、
「予習・準備・当日動線」を一元化するとユーザー体験がどう変わるのかをテーマに、
実際にひとつのサービスとして形にできたことは、自分にとって大きな経験になりました。

要件整理から設計、実装、デプロイ、そして運用までを一通り経験する中で、
「動くものを作る」だけでなく、

ユーザーにとって本当に使いやすいものは何かを考え続けることの大切さ

を学びました。

まだまだ改善の余地はありますが、
フェス当日までを“迷わず楽しめる”Webアプリとして成長させていけるよう、
これからも少しずつアップデートを続けていきたいと思います。

最後まで読んでいただき、ありがとうございました！