【第1回】から読む

言葉にできなかった想いは、全部このシステムに込めました

全14回の連載、最終回です。

3ヶ月間で170コミット。93本のDBマイグレーション。52人のゲスト。379枚の写真。156通のメッセージ。2,628件のトランザクション。

この連載は「結婚式のITシステムを作った技術記事」として始まりました。でも最終回は、技術の話ではなく、なぜ作ったのかを話させてください。

🎯 この記事で得られること

✅ 3ヶ月のフルスタック開発を振り返った正直な評価（KPT形式）

✅ 技術選定の事後評価と「やり直すならどうするか」

✅ 1回限りのイベントシステムを作るエンジニアへの実践的アドバイス

✅ コードでしか伝えられなかった、エンジニアの想い

✅ うまくいったこと

設計面

1. 写真報酬がチップ経済のエンジンになった

チップ発行量の過半数（481,500 / 全体の約55%）が写真関連。「撮るだけで報酬がもらえる」シンプルな設計が、52人のゲストから379枚の写真を引き出した。

2. NFC席次カードが「テクノロジーを意識させない導入」を実現した

「席次カードをスマホにかざしてください」── ゲストは「登録作業」を意識することなく、個別メッセージの感動とともにシステムに参加した。

3. 大予想のlocked演出が会場の一体感を生んだ

「もう予想できない、でも結果はまだわからない」── この数十秒間の緊張感が、全員を同じ方向に向かせた。プロポーズ再現度の試合では389,250チップが動き、10.66倍の大穴が的中して歓声が上がった。

4. スタンプラリーが新郎側・新婦側の壁を壊した

15人がスタンプラリーを達成。「スタンプが欲しいから話しかける」という口実が、初対面のゲスト同士の会話を自然に生み出した。

技術面

1. Next.js + Supabase の選定は正解だった

App RouterのServer Actions + Supabase RPC で「フロント→バックエンド→DB」を1関数に集約できた。フルスタック1人開発では、この生産性が不可欠だった。

2. system_config による当日の即時調整

バーのクールダウンを5分→10分に変更、報酬額の微調整── リデプロイなしで設定変更できる仕組みが、本番中に3回以上活躍した。

3. source_ref による冪等性保証

2,628件のトランザクションで二重付与は0件。40人が同時に操作する環境でも、DBレベルのユニーク制約が完璧に機能した。

運用面

1. 予備チップ8枚（SPARE-001〜008）の事前準備

NFCが読めないゲストが数名発生。予備チップ + 手動紐付けRPC + QRフォールバックの三重保険で全員を救済できた。

2. cancel_coliseum_matchが本番で活躍

大予想の1問目が判定不能になり、190,550チップを全額返金。「もしも」のために実装した機能が本番で使われた。

❌ うまくいかなかったこと

設計面

1. 親族のデジタルデバイド

所属別の平均チップで、親族グループは3,778チップ── 他のグループの3分の1以下。スマホ操作に不慣れな世代には、代理参加の仕組み（受付係による写真アップロード等）を用意すべきだった。

2. P2P送金の利用率25%

チップ送金を使ったのは13人（52人中25%）。NFCチップタッチで送金する体験は技術的には面白いが、2時間半では「対戦文化」が浸透しきらなかった。

3. バー利用率35%

バーNFCにタッチした人は18人。チップ獲得手段として十分に認知されていなかった。設置場所の目立たなさか、ルール説明の不足が原因。

技術面

1. 大予想ポップアップのスクロール不可バグ

5択の問題でモーダルが画面からはみ出し、ベットボタンに辿り着けない── 2択のテストしかしていなかった致命的な見落とし。当日ホットフィックスで対応。

2. スライドショーの写真表示偏り

新しい写真がアップロードされるたびにインデックスがリセットされ、同じ写真ばかり表示された。順番表示→ランダム加重選択への当日修正。

3. メッセージ返信が1件しかできない制限

新婦が返信しようとして初めて発覚。翌日にDBテーブルを新設して対応。

🔄 やり直すなら何を変えるか

1. 親族向けの参加パスを用意する

スマホ操作が苦手な人でも参加できる仕組み。例えば「受付係が代理で写真をアップする」「テーブル単位で1台のタブレットを共有する」など。

2. ルール説明を動画にする

口頭でのルール説明に時間がかかりすぎた。30秒のルール説明動画をスクリーンに流すだけで、全員の理解度が揃うはず。

3. テストの選択肢パターンを網羅する

大予想のスクロール不可バグは、5択のテストケースがあれば防げた。「最大選択肢数での表示テスト」をチェックリストに入れるべきだった。

4. バーNFCの設置場所を目立たせる

光るPOPスタンドや、バーカウンターの目線の高さに設置するなど、視認性の工夫。

🔧 技術選定の振り返り

技術	期待	実際	やり直すなら
Next.js 15 (App Router)	Server Actions + RSC でフルスタック完結	期待通り。1人開発に最適	そのまま採用
Supabase	PostgreSQL + Auth + Realtime + Storage が一括	RPC + RLS の組み合わせが強力	そのまま採用
Supabase Realtime	リアルタイム同期	不安定な場面あり。ポーリング併用が必須	変えない（ハイブリッド前提で設計）
AWS Rekognition	顔認識 + 画像モデレーション	精度十分。ブロック1枚のみ（過剰検出なし）	そのまま採用
Vercel	デプロイの手軽さ	当日ホットフィックスも即デプロイできた	そのまま採用
NFC (NTAG215)	物理とデジタルの接点	読み取り失敗あり。QRフォールバック必須	NFC + QR 併用を最初から設計

結論：技術選定は全て正解だった。 問題があったのは技術ではなく、テストの網羅性と運用設計。

💬 同じことをやりたいエンジニアへ

始める前に

3ヶ月は必要。1ヶ月で完成させようとすると、本番でバグだらけになる。フルスタック1人開発で必要な機能を全て実装するには、最低3ヶ月
「1回限り」だから妥協していい部分と、絶対に妥協してはいけない部分がある。 妥協してはいけないのは「データの整合性」と「フォールバック手段」。妥協していいのは「UIの完成度」
本番当日はコードを触ることになる。 「コードフリーズ」は理想。現実には、本番で初めて露呈するバグがある。ホットフィックスを即デプロイできる体制を整えておくこと

最も大切なこと

テクノロジーは黒子でいい。

結婚式の主役は新郎新婦とゲスト。テクノロジーが前に出すぎると、「なんか面倒なアプリを使わされた」で終わる。

席次カードをかざしたらメッセージが出てくる。チップを渡すだけでカジノに入れる。写真を撮るだけでチップがもらえる──ゲストが「テクノロジーを使っている」と意識しない設計が、最終的にシステムの価値を決める。

🙏 おわりに

この連載を書き始めたとき、「技術記事として面白いものを」と思っていました。

でも14回書き続ける中で、気づいたことがあります。

このシステムは、技術の練習でも、ポートフォリオでもなかった。

エンジニアとして10年、コードを書いてきました。でも、コードで人を直接幸せにしたことは、実はあまりなかった。

仕事で書くコードは、ユーザーに届くまでに何段階ものレイヤーを挟む。自分のコードが誰かの顔を笑顔にする瞬間を、この目で見ることはほとんどない。

結婚式のシステムは違いました。

席次カードをかざした瞬間に「すごい！」と言ってくれるゲストの顔を見た。大予想の結果発表で歓声が上がる会場を見た。サンキューページを開いて「こんな称号もらえたの！」と笑う友人を見た。

自分のコードが、目の前にいる人の表情を変える。 この体験は、エンジニア人生で初めてのことでした。

🎬 フィナーレ

披露宴の最後に、スクリーンに映したメッセージがあります。

連載の記事タイトルが1つずつ表示され、それぞれに新婦への言葉がタイプライターエフェクトで綴られる演出です。

最後に、この連載を読んでくれたあなたにも、同じメッセージを贈ります。

Dear ──

今日に向けて準備する中で 書き残した全13章のブログがあります

今はタイトルと、そこに込めた想いだけ伝えます

#1 なぜ結婚式に「IT」で貢献しようと思ったのか

── きみに最高の1日をプレゼントしたかった。それが全ての始まりだった

#2 「1回限り」のシステムを設計する

── たった1日のために3ヶ月。でも、きみのためならそれでいい

#3 写真をAI顔認識で自動タグ付けする仕組み

── きみの笑顔も、大好きな人たちとの瞬間も、1枚も見逃したくなかった

#4 写真が動き出すスライドショーを作った話

── みんなの写真が会場に流れる瞬間を、きみに見せたかった

#5 勝者・敗者に分かれないゲーム設計

── 誰も損しない。全員が笑える。そんなゲームにしたかった

#6 みんなが本気で盛り上がるリアルタイム対戦を作った話

── 友達が本気で盛り上がる姿を、きみと一緒に見たかった

#7 会場全体がひとつになるベッティング演出

── 会場全体が一つになる演出が、どうしても欲しかった

#8 全員が得をするゲームの仕掛け

── 何度も設計を直した。きみのために、妥協したくなかった

#9 ゲームを壊さないための多層防御設計

── 当日、何が起きても大丈夫なように。きみを不安にさせたくなかった

#10 「祭りのあと」を設計する

── 終わった後も思い出せるように。大切な人たちとの写真やメッセージが残るように

#11 結婚式当日レポート

── この日のことは、一生忘れない

#12 データで振り返る結婚式の数字たち

── 数字にも、きみへの想いが詰まっている

#13 やり直すなら何を変えるか

── 答えは一つ。きみと出会えた人生を、もう一度選ぶ

きみと出会えたことが、僕の人生で一番の幸運でした

隣で笑ってくれるだけで、どんな日も楽しい一日になった

きみのために何かを作る時間が、僕にとって一番幸せな時間だった

結婚してくれてありがとう

プロポーズの言葉は物足りなかったかもしれないけど

言葉にできなかった想いは、全部このシステムに込めました

50年後、またこの動画を一緒に見て こんなこともあったねって 笑いながら話せたらいいなと思います

これからもよろしくね

fin

「1回限り」のイベントシステム開発チェックリスト

3ヶ月・170コミットの経験から、イベントシステム開発のチェックリストをまとめます。

開発フェーズ

✅ 最低3ヶ月の開発期間を確保する
✅ system_config テーブルで本番中に設定変更可能にする
✅ source_ref 等の冪等性キーで二重処理を防止する
✅ 物理デバイス（NFC等）にはQRフォールバックを必ず用意する
✅ 予備デバイスと手動紐付け機能を準備する
✅ 全選択肢パターンでUIテストを行う（2択だけでなく5択も）

本番当日

✅ ホットフィックスの即時デプロイ体制を整える
✅ 管理画面からの設定変更手順をリハーサルする
✅ キャンセル・返金のRPCを事前に用意しておく
✅ デジタルデバイドに配慮した代替参加手段を用意する

本番後

✅ トランザクションログから全データを分析する
✅ game_type 別の集計で設計の成否を評価する
✅ 参加率の低い機能を特定し、原因を分析する

📖 連載全記事一覧

回	タイトル
第1回	なぜ結婚式に「IT」で貢献しようと思ったのか
第2回	「1回限り」のシステムを設計する
第3回	AI顔認識で自動タグ付けする仕組み
第4回	Ken Burns Effectのスライドショー
第5回	ゼロサムにしないチップ経済圏
第6回	物理NFCチップと対戦システムの実装
第7回	席次カードにNFCを仕込んだら、受付が感動体験になった
第8回	40人が一斉参加する「みんなで大予想」の設計と実装
第9回	全員が得をするゲームの仕掛け
第10回	ゲームを壊さないための多層防御設計
第11回	「祭りのあと」を設計する
第12回	2026年4月5日、すべてが動いた日
第13回	2,628件のトランザクションが語る結婚式の物語
第14回	言葉にできなかった想いは、全部このシステムに込めました（本記事）

全14回の連載を読んでいただき、ありがとうございました。

この記事が面白いと思ったら、ぜひシェアをお願いします！

あなたのシェアが、同じような「面白いことやりたいエンジニア」に届くかもしれません。

エンジニアが新婦のために結婚式にITで全力で貢献しようとした話【最終回】言葉にできなかった想いは、全部このシステムに込めました