Fuda

背景と課題定義：個別実装の限界と、買う側として感じた入場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でファンに共有するだけで、誰から何枚売れたのかが主催者側のダッシュボードにリアルタイムで自動集計されます。購入者側にも出演者を選択させる余計なステップを踏ませず、今時のコミュニケーション動線に最適化されたスマートな集計システムを実現しました。これにより、チケット販売は単なる「決済手続き」を超えて、コミュニティの運営負荷を劇的に下げる体験へと昇華しています。

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

3ヶ月でWeb、iOSネイティブアプリ、さらに決済基盤までを一人で構築できた背景には、AIを単なるコード生成ツールとしてではなく、対等なデザインレビューのパートナーとして扱い、開発ワークフローを効率化したことにあります。

今回のプロダクト開発においては、私自身が直接エディタでコードをガリガリと記述する手法は採っていません。構造設計や全体のアーキテクチャの組み立てからAI（Claude）に自然言語で相談しながらベースを構築。UIの構築にあたっては、デザインシステムコンポーネントであるshadcn/uiを採用することで、フロントエンドの実装スピードを大幅に引き上げました。

また、開発時は音声AIツールであるAqua Voiceや、ブラウザの要素を直接指定してコード修正を行うAgentationを完全にメインの道具として使いました。修正したいUIの箇所を直接クリックして構造データをAIへ渡し、「この余白を少し狭く」「この要素を右に寄せて」と口頭で指示を出すことで、手動でのタイピングを徹底的に排除。「デザイナーの目によるクオリティレビュー」と「AIの爆速のコード修正」を完全に同期させました。

AIとのラリーの中で思い通りのレイアウトにならない場合は、「UXデザイナーの観点で複数案を出して」「PMの視点から仕様を再考して」といったペルソナ（役割）をAIに与えて解決。提示された複数の選択肢に対し、「他の画面と配置の一貫性が保たれているか」「 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側に残し、デザイン調整がダイレクトに実装コードへと同期される環境が作れるはずです。これはデザイナーの職能を最大化する次世代ワークフローとして、次のプロジェクトではこの仕組みを入れていく計画です。