はじめに
先日、自身の結婚式を行いました。
その中で、ゲストに写真を投稿してもらい、新郎新婦がそれぞれお気に入りの写真を選んで景品を渡す「フォトコンテスト」を実施しました。
せっかくなら自分たちらしいコンテンツにしたいと思い、写真の投稿、管理、結果発表までできるフォトコンテストアプリを自作しました。
結婚式という一度きりの本番環境で自作アプリを使うために気をつけたこと、やってよかったこと、反省点をまとめたのでご紹介します！
作成物
作ったのは、結婚式用のフォトコンテストWebアプリです。
ゲストには、新郎新婦の写真を撮影してもらい、その写真をアプリからアップロードしてもらいます。
新郎新婦側では投稿された写真を確認し、その中から新郎賞・新婦賞のような形でそれぞれ1枚ずつ写真を選出します。
選ばれた写真は、披露宴中にスライド形式で発表し、撮影してくれたゲストに景品を渡す、という流れにしました。
画面としては、大きく以下の3つを用意しました。
- ゲストが写真を投稿する画面
- 新郎新婦側が投稿写真を確認・選出する管理画面
- 選出した写真を披露宴中に発表する結果発表画面
結果発表画面は、両家の愛犬が発表してくれるスライド形式のものを用意しました。
なぜこのアプリを作ったのか
理由はシンプルで、自分たちの結婚式の写真をたくさん撮ってほしかったからです。
自分も含めてなのですが、私の友人には、普段あまり写真を撮らない方が多いです。
ただ、自分の結婚式くらいは、新郎新婦やゲスト同士の写真をたくさん残してほしいという思いがありました。
そこで、写真を撮ること自体をコンテンツ化できれば、自然と写真を撮ってもらえるのではないかと考えました。
選ばれた方には景品も用意することで、写真を撮ること自体を少し楽しいコンテンツにできると思いました。
結婚式アプリは「普通のWebアプリ」と前提が違う
作ってみて一番感じたのは、結婚式で使うアプリは、普通のWebアプリとは前提がかなり違うということです。
普通のWebアプリであれば、多少の不具合があっても後から直せます。
ユーザーに再アクセスしてもらうこともできます。
しかし、結婚式は基本的に一度きりです。
しかも、当日の新郎新婦にはほとんど余裕がありません。
何かトラブルが起きても、自分がその場で落ち着いて調査して直す、ということは現実的ではありません。
そのため、結婚式で自作アプリを使う場合は、以下のような前提で考える必要がありました。
- 当日、自分は運用にほとんど関われない
- ゲストはアプリを使うために来ているわけではない
- 会場のネットワーク環境は不安定かもしれない
- アプリの使い方を丁寧に説明する時間はあまりない
- 結果発表などの演出で使う場合、失敗すると披露宴の進行に影響する
なので、実装そのものよりも、当日ちゃんと使われる導線とトラブルが起きても止まらない運用設計がかなり重要でした。
技術構成
技術構成は以下のような形です。
- フロントエンド
- Next.js
- ホスティング
- Vercel
- DB
- Supabase Database
- 投稿情報、投稿者名、選出結果の保存に利用
- 画像
- Supabase Storage
- ゲストが投稿した写真の保存に利用
- 投稿者識別
- localStorage
- ログインなしで投稿者をゆるく識別するために利用
基本的には無料でできる範囲内で構成しています。
気をつけたこと
1. ネットワーク環境を事前に確認する
まず気にしたのは、会場のネットワーク環境です。
今回の披露宴会場は地下にありました。
そのため、ゲストのスマホ回線だけに依存すると、写真投稿や結果発表がうまく動かない可能性がありました。
そこで、事前に会場でアプリが動作するか確認しました。
また、式場で利用できるWi-Fiがあったため、事前にゲストへWi-Fi情報をアナウンスしました。
結婚式アプリでは、会場のネットワーク確認はかなり重要だと思います。
特に、写真アップロードのように通信量が多い機能がある場合、ネットワークが不安定だと一気に体験が悪くなります。
また、結果発表画面については、披露宴会場でデータ取得に失敗すると困るため、ネットワーク環境の良い場所で事前にデータを取得し、キャッシュを保持した状態で表示できるようにしました。また、公開しているWebアプリで問題が起きた場合に備えて、ローカル環境でも同じ画面を立ち上げておきました。
リアルタイム性を完全に求めるよりも、披露宴の進行を止めないことを優先しました。
2. 画像アップロードで詰まらないようにする
フォトコンテストアプリなので、メイン機能は写真アップロードです。
ただ、最近のスマホで撮影した写真はサイズが大きくなりがちです。
そのままアップロードすると、通信量が増えたり、アップロードに時間がかかったり、ネットワーク環境によっては失敗しやすくなります。
そのため、アップロード前に画像を圧縮するようにしました。
結婚式当日は、ゲストがアプリの挙動を細かく見てくれるわけではありません。
アップロードに時間がかかったり、失敗したりすると、その時点で離脱される可能性があります。
そのため、写真投稿の体験はできるだけ軽くする必要がありました。
また、ネットワークが不安定な場合も考え、裏側で再送できるような仕組みも用意しました。
このあたりは、リアルイベントで写真アップロード機能を使う場合にかなり大事だと感じました。
3. ログイン機能は作らない
今回のアプリは、結婚式当日の半日程度だけ使うものだったので、ログイン機能は作りませんでした。
参加者にアカウント登録やログインを求めると、それだけで利用ハードルが上がるので、利用者側が手軽に使える設計を意識しました。
画面上では、写真をアップロードする時に、ひらがなフルネームで名前を入力してもらい、誰が投稿した写真かわかるようにしました。
この時、あだ名や変な名前で送って後で認識できないことを防ぎたかったので、ラベルに「あなたの名前（ひらがな フルネーム）」と明記して名前の入力が一意になるようにしました。
裏では、ブラウザのlocalStorageに保存したランダムトークンも一緒に送信するような作りにして、同じブラウザから投稿した写真を確認できるようにしつつ、ログインなしで使えるようにしました。
上記のような結婚式で最低限使えるような認識機能を用意して臨みました。
4. 使い方をできるだけシンプルにする
ゲスト向けの画面は、できるだけシンプルにして、ホーム画面1枚の中に、フォトコンテストのルールと使い方をまとめました。
結婚式当日のゲストは、食事をしたり、写真を撮ったり、他のゲストと話したりしています。
その中で、アプリの説明をじっくり読んでもらうことは期待できません。
そのため、
- 何をするアプリなのか
- どう投稿すればいいのか
がすぐにわかるようにしました。
デザインについては、ChatGPTで何度か画面イメージを生成しながら、自分の中で良いと思えるデザインに近づけていきました。
見た目にこだわりつつも、操作自体はできるだけ迷わないようにすることを意識しました。
5. 当日の導線を事前に決める
結婚式の中で、どのタイミングで案内し、どのタイミングまでに投稿してもらい、写真を選び、どう結果発表画面を出すのかを決めておく必要がありました。
今回は、結婚式の前々日に、参加者全員のLINEにフォトコンテストのURLと説明を送りました。
当日はフォトコンテスト以外にもコンテンツがたくさんあったので、事前に案内を送って認知できるようにしました。
また、当日の流れとしては、中座中に新郎新婦側で写真を選出し、その後の結果発表の時にスクリーンにPCの画面を移して進めるといった流れでした。
中座中、時間が少ない中、私は着替えを自分で行い、かつフォトコンテストの新郎賞・新婦賞の選出をする必要があったのであらかじめPCでWebアプリとローカルでアプリケーションを立ち上げた状態で準備をしており、スムーズに賞を選べるような状態をつくりました。
披露宴の進行をちゃんと把握した上で、どう組み込むかがかなり大事になります。
6. 同時接続やアクセス集中を考える
同時接続数やネットワークが落ちる心配がないかも考えました。
今回の構成はVercelを使っており、過去に会社でQ&Aアプリを同様のネットワーク構成で作成した経験があったため、大きな問題はないと判断しました。
また、アクセス数や同時接続の観点については、生成AIと壁打ちしながら懸念点を洗い出しました。
心配な方は、負荷テストまでできてるといいかもしれません。
反省点
締切前のアナウンスをもっと入れるべきだった
一番の反省は、投稿締切前のアナウンスです。
今回は、中座中に新郎新婦側で写真を選択する必要がありました。
そのため、ある程度早いタイミングまでに写真を投稿してもらう必要がありました。
しかし、締切までに写真をアップロードできていなかった方が半数ほどいました。
当日は、新郎新婦自身に細かくアナウンスする余裕はありません。
そのため、司会者の方に「まもなくフォトコンテストの締切です」と途中で案内してもらうようにしておけば良かったと思いました。
アプリ内に締切を書くだけでは不十分で、リアルな場でのアナウンスも重要でした。
結果発表画面はスクリーンサイズをもっと意識すべきだった
結果発表画面は、当日利用するスクリーンサイズをもっと意識して作れば良かったと思いました。
大きな問題ではありませんでしたが、実際に使ったスクリーンが大きめだったため、少し中央寄りで余白が多いデザインに見えました。
もう少し大きく見えるUIにしておいても良かったです。
開発中はPC画面で確認して満足してしまいがちですが、披露宴で使う場合は、実際のスクリーンに映した時の見え方を想定する必要があります。
今回は少し演出にこだわりすぎた部分もあったので、次に作るなら「会場で見やすいこと」をもっと優先すると思います。
自作したアプリだということを伝える
もう一つの反省点として、このフォトコンテストアプリが自作であることを、もう少しゲストに伝えればよかったと思いました。
エンジニアの感覚だと、結婚式で使うアプリを自分で作るという発想はそこまで不自然ではありません。
しかし、普段アプリ開発に関わっていない人からすると、「結婚式のためにアプリを作った」という発想自体があまり出てこないのだと感じました。
実際、エンジニア以外のゲストの方に聞くと、業者が作ったアプリだと思っていた方が多かったです。
もちろん、自作したことを大げさにアピールしたかったわけではありません。
ただ、「新郎がこの日のために作りました」と一言添えるだけで、ゲストにとっても少し印象に残るコンテンツになったのではないかと思います。
結婚式で自作アプリを使うなら気をつけたいこと
今回の経験を踏まえると、結婚式で自作アプリを使う場合は、以下の点を考えておくと良いと思います。
1. 会場で本当に使えるか確認する
特にネットワーク環境は重要です。
スマホ回線が弱い場所もありますし、地下会場では通信が不安定になることもあります。
写真アップロードや結果発表のように、通信に依存する機能がある場合は、事前に会場で動作確認しておくべきです。
2. ゲストが迷わず使えるUIにする
ゲストはアプリを使うために来ているわけではありません。
そのため、説明を読まなくても何をすればいいかわかるくらい、シンプルにする必要があります。
ログインや複雑な操作は、できるだけ減らした方が良いです。
3. ゲストに行ってほしいタイミングを設計する
アプリを用意しただけでは、期待通りには使われません。
いつ投稿してもらうのか、いつ締め切るのか、誰がアナウンスするのかを決めておく必要があります。
特に、披露宴中に結果発表する場合は、投稿締切のアナウンスがかなり重要です。
4. スクリーン表示を想定して作る
結果発表などでスクリーンに映す場合、PC画面で見やすいだけでは不十分です。
会場のスクリーンサイズ、表示比率、席からの距離を考えて、文字や写真を大きめに作るべきだと感じました。
5. 自作アプリだということを演出に加える
自作アプリを使う場合は、それが自作であることをゲストに伝えるところまで含めて考えると良いと思いました。
自作アプリは単なる便利ツールではなく、新郎新婦らしさを出せる演出の一つにもなります。
そのため、機能を作るだけでなく、どう紹介してもらうかまで考えておくと良いと思いました。
まとめ
結婚式で自作フォトコンテストアプリを作り、実際に披露宴で使ってみました。
作る前は、写真投稿や管理画面の実装を中心に考えていました。
しかし実際には、技術的な実装以上に、当日ちゃんと使ってもらうための導線や、トラブルなく進行するための運用設計が重要でした。
結婚式は一度きりの本番環境です。
だからこそ、自作アプリを使う場合は、作り込みよりも「ちゃんと使われること」「当日止まらないこと」を優先して設計するのが大事だと思いました。
同じように、結婚式やリアルイベントで自作アプリを使おうとしている方の参考になれば幸いです。