Fuda

アプリの概要

音楽イベントの主催者が「チケット販売・当日の受付・当日の物販決済・売上分配の計算」までを 1 サービスで完結できる B2B プラットフォーム。観客（スマホ）・主催者（PC）・当日スタッフ（iPhone） という性質の異なる 3 つの利用シーンを、それぞれに最適化したデザインで設計しました。当日の対面決済は、iPhone をそのまま決済端末にするiPhoneのタッチ決済対応の専用 iOS アプリが担い、Web プラットフォームと 1つのアカウントで連携します。

背景と課題定義：個別実装の限界と、買う側として感じた入場UXの不満

Fudaの着想は、2024年から運営に携わっている音楽団体「Global Sound」の現場でした。プロジェクトの始まりは、知り合いのアカペラ団体から「イベント用のホームページを作ってほしい」と依頼されたことでした。最初のイベントでは専用の問い合わせやチケットフォームを個別に実装して無事に運用を終えましたが、2つ目のイベントで同じシステムを構築対する際に大きな壁に直面しました。ホームページ自体が別物であるため、全く同じフォーム実装をゼロから繰り返さなければならず、非常に骨が折れる作業でした。

さらに3つ目のイベントの構想が立ち上がった時、「イベントごとに都度新しくフォームを作り続けるのは運用として限界を感じ、共通の基盤（プラットフォーム）を作るべきだ」と確信しました。ちょうど、界隈で広く使われていた安価な外部チケットサービスが終了するタイミングとも重なり、開発へ踏み切る絶好の動機となりました。

共通プラットフォームを設計するにあたり、既存の大手サービス（LivePocketやPassMarketなど）に対して、自分が一人の「観客（買う側）」としてイベントに通う中で、感じていた入場時のUXの不満を徹底的に解消することを目指しました。

① チケット購入時の「アカウントログイン」の壁

友達から送られてきたリンクを踏んでチケットを買おうとした瞬間、新規登録やログインを求められるステップは、購入体験において少しイラッと瞬間でした。Fudaではこれを排除し、スマートフォンからの購入を前提とした簡素なインターフェースを設計し、「メールアドレス・名前・決済手段（クレジットカードやPayPay）」を入力するだけで、ログインを行わずに5分以内に購入が完了する動線へと最短化しました。

② 会場の電波不良による「QRコードが開かない」問題

地下のライブハウスや人が密集する会場では、電波が悪いため主催側・観客に関わらずスマホで受付のQRコードを開けず、入場口で混雑する光景も見てきました。この現場の課題を解決するため、Fudaは主催者・当日スタッフ側のフロントエンドとしてiOSネイティブアプリを構築しました。電波が入る場所で事前にアプリを開いておけば、すべての来場者データがローカルデータベースにキャッシュとして蓄積される構造です。画面上には「何時何分時点の最新状態」であるかが明記され、数百人規模のイベントであれば、完全にオフラインの状態でも遅延なくQRコードの読み取りとチェックインを回せる仕様に仕上げました。

③ 例外発生時における受付オペレーションの硬直化

観客がスマートフォンのバッテリー切れなどでQRコード自体を提示できない場合、従来のシステムでは購入証明の確認に手間がかかっていました。Fudaの受付アプリ内には、購入者の顧客一覧が常時展開されているため、QRコードがない場合でもその場で名前やアドレスを聞いて検索するだけで、「支払済み/未払い」のステータスを確認して即座に入場処理を完了できる柔軟性を担保しました。

戦略的トレードオフ：コア体験の選定と、機能の段階的割り切り

3ヶ月という短いタイムラインで本番環境へ投入するために、実現すべきコア体験（Webでのスムーズなチケット販売、オフライン対応のチェックイン、会場でのTap to Pay決済）は妥協せず実装する一方、汎用的なチケットサイトが持つ周辺機能は明確にスコープから除外する割り切りを行いました。

具体的には、ポータル機能（イベント一覧ページ）は作成していません。各イベントが独立した固有のURLを持ち、主催者が自身のSNS（音楽団体のXなど）に直接リンクを貼って集客する運用を前提としました。また、観客向けの専用アプリ開発や、小規模イベントでは実装コストが跳ね上がる座席指定機能も対象外としました。サービスのトップページ（LP）についても、機能や手数料の記載といった最小限に留め、グラフィックのブラッシュアップは後回しにしています。

代わりにリソースを投資したのが、会場での「iPhoneのタッチ決済」の実装です。イベント当日には必ず飛び入り参加の観客がいますが、小規模な音楽界隈では「当日券は現金のみ」という慣習が一般化していました。この決済手段をデジタル化し導入障壁を下げるため、タッチ決済をMVPの段階から組み込み、実際の現場で検証する選択をしました。

サービスデザイン：売上情報とスタッフ権限のセキュリティ分離

当初、このプロダクトは「観客」と「主催者」の2つの役割だけで設計を進めていました。しかし、自分自身で主催者向けの管理画面を作り込み、現在の売上や入金金額、過去の購入者情報が画面に並んだ瞬間、ある明確な違和感に直面しました。

スタッフ用の別権限が存在しない場合、当日の受付や会場物販を手伝ってくれる友人やメンバーに、主催者アカウントのログイン情報をそのまま共有することになります。しかし運営側の心理として、手伝ってくれるスタッフに対して現在の総売上額や全体の顧客データを公開することは、セキュリティおよびプライバシーの観点から避けるべきであると判断しました。

さらに、将来的にこのプロダクトを外部のイベント主催者へ展開していくフェーズを考慮した際、アルバイトや外部スタッフが受付を回すケースにおいて、機密情報へのアクセスを遮断する仕組みはプラットフォームの信頼性として不可欠な要件となります。「全体のダッシュボードや個人情報は非表示にし、QRコード受付とTap to Pay決済の2つのアクションに限定する」。お金と権限を分離する「スタッフロール」の設計は、この実務上の懸念から定義されました。

• 権限の最小化：売上ダッシュボードや顧客の個人情報は最小限の表示とし、プライバシーを保護。
• 機能の絞り込み：「QRコードによる入場受付」と「タッチ決済による会場決済」の2つのアクションのみに特化。
• 現場最優先のUI：片手が塞がることが多い受付環境を想定し、片手で確実に操作できるレイアウト、色による識別、オフライン耐性を重視。

プロダクトデザイン

出演者ごとの個人ノルマ集計 — 専用購入リンクの自動発行

既存のチケットサービスではカバーされていなかったものの、学生や社会人のインディーズ音楽イベントにおいて必須となる特有の運用がありました。出演者ごとの個人ノルマ（誰の紹介でチケットが売れたか）の集計管理です。従来の汎用プラットフォームでは、購入画面の自由記述備考欄に「〇〇の紹介」と手入力してもらうしかなく、イベント後に主催者がテキストデータを目視で手作業集計する大きな負担が発生していました。

Fudaでは、イベント全体の組織構造を活かし、出演者ごとに固有のパラメータが付与された「専用購入リンク」をワンクリックで自動発行するシステムを基本機能として実装しました。

出演メンバーは、自分の専用リンクをLINEやSNSでファンに共有するだけで、誰から何枚売れたのかが主催者側のダッシュボードにリアルタイムで自動集計されます。購入者側にも出演者を選択させる余計なステップを踏ませず、今時のコミュニケーション動線に最適化されたスマートな集計システムを実現しました。これにより、チケット販売は単なる「決済手続き」を超えて、コミュニティの運営負荷を劇的に下げる体験へと昇華しています。

チケットを「体験の入口」にする ― QR ウォレット

意図的な体験設計：機能の先にある感情への投資

静的なQRコードを表示するだけでも、入場という機能要件は100%成立します。しかしこの改修では、単なる機能の担保に留まらず、プロダクトの定着率を高めるための「意図的な体験設計」としてインタラクションの実装を行いました。

「静的UIで十分」と切り捨てられがちな部分に対し、デザイナーとして明確な仮説を持ってリソースを投資した実例です。

1. 体験の仮説と意図

チケットを購入した瞬間に「自分の財布に本物のチケットが入った」という確かな所有感と、イベント当日への高揚感を提供することを目指しました。入場手続きをただの義務的なタスクにするのではなく、イベント体験の心地よい入口に変えることが狙いです。

2. 実装における意思決定

motion/react の共有レイアウト（Shared Layout）を活用し、チケットが開く・閉じるアニメーションを単一のキーフレームの正逆再生で制御しました。動きの法則に一貫性を持たせることで、ユーザーに操作の安心感を与えます。 複数枚のチケットがある場合は、ウォレットの枠幅にクリップされないフルサイズの横スワイプカルーセルでめくる挙動にし、閉じるとカードが無造作に重なる「財布の中にしまってある」状態を視覚的に表現しました。

3. 抑制とトレードオフ

演出を足すことによるシステムの脆弱化を防ぐため、あらかじめ厳格な境界線を設計しました。

• ロジックの隔離: スキャンや入場に関するコアロジックには一切手を加えず、見た目のレイアウト層だけでインタラクションを完結させています。
• アクセシビリティ: OSの prefers-reduced-motion（視覚効果を減らす設定）が有効な場合は動きだけを完全に止め、カードの形状や情報設計が変わらないように配慮しました。
• 認知負荷の軽減: 派手な登場アニメーションは初回購入時のみ（Cookie制御）に限定して操作のヒントを与え、2回目以降の表示ではアニメーションをスキップさせて実用性を最優先しています。

重要なのは単に見栄えの派手さを追うことではなく、システムの堅牢性を一切壊さずに、いかに感情的な心地よさを上乗せできるかという「適切な境界線を設計すること」だと考えています。

デザインエンジニアリング：音声AIと構造指示による「AIとの壁なき議論」

3ヶ月でWeb・iOSネイティブアプリ・決済基盤までを一人で構築するにあたり、実装はAI（Claude）への自然言語ディレクションを主軸とし、UIはshadcn/uiを採用して実装速度を担保しました。私自身はコードを直接記述せず、「他画面との配置の一貫性」「primaryアクションの機能」をデザイナーの視点でレビュー・ディレクションすることに専念し、品質と速度を両立させています。

振り返りとこれからの展望：実証検証の完了と、次世代ワークフローへの布石

3ヶ月の開発を経て、実際のチームによる実証イベント運用を無事に完了しました。イベント当日、多数の決済が行われる中で決済エラー：0件という安定性をMVPの段階で実証できたことは、プロダクトの信頼性を担保する大きな成果となりました。この本番運用を経て、デザイナーとしての視点から次の改善ポイントと技術的境界線を特定しています。

① タッチ決済におけるAndroidユーザーの取りこぼし（Stripeの仕様）

Fudaの最大のコア機能として組み込んだ「iPhoneのタッチ決済」ですが、当日の現金決済を完全に無くすアプローチにおいて、日本国内におけるStripeのTap to Pay SDKが現状Android端末をサポートしていないという技術的境界線に突き当たりました。日本のiPhoneシェアが高いとはいえ、Android端末を持つ主催者やユーザーに対してデジタル決済を提供できない制約は、プロダクトの今後の拡張における明確な課題であり、QRコード決済の拡張などの代替案を検討しています。

② 運用フィードバックに基づくUI/UXの改修（現在進行中）

実証イベントを終えた現在、得られたフィードバックを基に、以下の改修とブラッシュアップを今まさに進めています。

• 振込タイミングの見直し：イベント終了後、主催者へ売上が入金されるタイミングや手数料還流の仕組みを、小規模団体のキャッシュフローに合わせて最適化する再設計。
• iOSアプリのダッシュボード改修：当日の混雑した受付において、スタッフがiPhoneの画面一覧で全体の入場進捗や決済状況を一目で把握できるよう、情報アーキテクチャと視認性の向上。
• 外部公開へ向けたビジュアルの調律：自分たちのチームだけでなく、他の音楽団体へ正式にリリース・提供できるよう、サービスの全体的な見た目や使いやすさを整える最終ブラッシュアップ。

③ Figma MCPの登場と、Figmaをどう使うか

今回はコードファーストで実装を進め、実際の画面を見ながらAIとブラッシュアップしていくアプローチを取りました。しかし最近、Figma MCP（Model Context Protocol）が登場しましたがまだ実際のプロジェクトでその精度を検証できてはいません。Claude CodeとFigma MCPを組み合わせることで、デザインのマスターデータを常にFigma側に残し、デザイン調整がダイレクトに実装コードへと同期される環境が作れるはずです。これはデザイナーの職能を最大化する次世代ワークフローとして、次のプロジェクトではこの仕組みを入れていく計画です。