ヒアリングを進めると、単なるホームページ制作ではこのサロンが抱える本当の課題は解決できないと気づきました。
課題の本質を深掘り
この美容サロンは、ヘア、ネイル、エステ、マツエク、マシンピラティスといった複合サービスを提供していました。しかし、多くのお客様はこのサロンが複合施設であることに気付いていなかったのです。
さらに、以下のような課題も判明しました:
- HotPepperBeautyで「ヘア」と「その他」の予約媒体が分かれており、顧客が混乱する
- SNS(X、Instagram、LINE)の投稿管理が煩雑で、情報の整理ができていない
- 顧客もどの媒体を見れば良いのか分からず、情報が届きにくい
提案した本当に役立つ仕組み
提案内容
- スタッフ別の指名予約リンク・メニューを一元管理
- カタログ・ブログ投稿機能(メニュー紹介、実績掲載)
- 投稿と同時にX、LINE公式など複数SNSに自動通知
- アクセス数・予約数を計測・分析できるダッシュボード
- 顧客がブログやカタログからそのまま予約ページにアクセス可能
システムを支える技術構成
フロントエンド
ReactとNext.js(Page Router)を採用し、UIはSassで独自実装。状態管理はuseState/useContextでシンプルに実装し、Reduxなどは不要と判断しました。
インフラ構成
- フロントエンド:Vercel(SSR+ISRで最適化)
- データベース:Firebase Firestore(スキーマレスで更新頻度の高いデータに最適)
- 認証:Firebase Authentication
- 画像管理:Firebase Storage
バックエンド処理
画像の自動圧縮・WebP変換、SNSへの自動投稿、Firestoreドキュメントの更新処理はFirebase Cloud Functionsで実装し、Cloud Runで処理を実行。デプロイはGitHubとCloud BuildのCI/CDで自動化しました。
API設計
基本的にFirestore SDKで直接操作し、Next.jsのISR再生成用にAPI(/api/revalidate)を用意しました。Zodで型定義とバリデーションを管理し、スキーマがそのままAPI仕様書の役割を果たすようにしています。
ソースコード管理
モノレポ(Nx)構成で、サロン管理画面と顧客画面を分けて開発。コンポーネント・型定義・ロジックを共通管理し、効率的な開発体制を実現しました。
開発プロセスと運用設計
投稿・ビルド・表示の流れを以下のように設計:
- 管理画面から投稿(Firestoreにstatus=imagingで保存)
- Cloud Functionsが画像を最適化・WebP変換
- Firestoreのstatusをbuildingに更新
- ISRの再生成APIをトリガー
- ページ再生成後にstatus=publicに更新
これにより、最新情報を即時反映しつつ、高速な表示体験も実現しました。
ISR採用の背景
当初はSSRを検討していましたが、ページ読み込みが重くなり、サロン側からのフィードバックを受けてISR(手動再生成)に切り替えました。これにより、最新情報を維持しつつ、パフォーマンスも向上しました。



