Fuda
チケット・入場・決済サービス
Role
プロダクトデザイナー / 個人開発
Duration
2026年3月 – 6月一般リリース予定
Platform
Web / iOS
ORIGIN
自分自身が「主催者」だったから、作れた
Fuda はアイデアから生まれたプロダクトではなく、私自身が運営に関わってきた経験が出発点になりました。
始まりはホームページ制作
アカペラ団体から「サイトを作ってほしい」という依頼がきっかけ。その後、問い合わせフォーム、エントリーフォーム、チケットフォームへと範囲が広がっていった。
WordPress × Stripe の限界を感じた
チケットフォームを WordPress に組み込んで動かした。しかし次のイベントでも同じことを繰り返す負荷が大きく、「専用プラットフォームを作ればいい」という発想が生まれた。
現地の現金払いという分断
オンラインでは購入できるのに、当日の現地ではクレジットカードも PayPay も使えない。学生・社会人アカペラに多い「取り置き → 現地払い」文化をオンラインで完結させたかった。専用端末を持ち歩かない小規模バンドでも iPhone 1 台で対面決済できる「iPhoneでタッチ決済」のアイデアへ。
市場の空白 × 前作「Pintio」の経験
安価なプラットフォームがサービス終了予定に。代表のツテでプロの音楽家や他団体への展開も見えてきた。前作 Pintio で掴んだ開発の勘所を活かし、Fuda の本格開発へ踏み切った。
Problem
ツールの寄せ集めが、 現場を重くしていた
チケット業務の分断が、3つの深刻な痛みを生んでいた。
01
当日の運営の負荷
受付対応・現金管理・二重入場チェックの属人化
02
データが溜まらない
誰が何回来ているか、どの出演者経由で売れたかがわからない
03
お金まわりのリスク
振込確認・返金・分配の手作業はミスと信用リスクに関わる
Product Screens
主催者ダッシュボード
PC前提の管理画面。売上・販売枚数・受付状況をリアルタイムで把握できる。
User Design
3つの利用シーンに細分化
「すべてをレスポンシブで1つに」ではなく、シーンごとにデバイスを決め打ちし、それぞれを最適化する方針。
観客
チケットを買う人
スマホで縦スクロール1本で完結。 迷わせずにチケット購入まで
主催者
イベントを管理する人
PCで情報密度・編集効率を優先 shadcn/uiをベースに広い作業領域
当日スタッフ
現場を動かす人
iPhoneで片手・オフライン耐性。 iPhoneのタッチ決済・QR 受付・色で状態判定可能
観客が見る公開ページ
Product Thinking
デザインの外にあった、難しい判断
UIをどう作るかだけでなく、「プロダクトとして何を決めるか」という判断も難しいものだった。
01
手数料の設計
Stripe 手数料・プラットフォーム手数料・主催者の受取額のバランスを、競合調査と収益モデルを見ながら設計した。高すぎると使われない、低すぎると持続しない。
02
キャンセルポリシーの設計
主催者ごとに方針が異なる中で、観客・主催者・プラットフォーム三者の信頼を壊さないルールを考えた。柔軟性と明確さのバランスが難しかった。
Outcome
成果と現状
まず自分たちのグループで本運用し、その後ほかの団体へ順次開放する計画で進んでいる。
01
3つの異なる体験を1つのプロダクトとして設計
観客・主催者・当日スタッフで、デバイスも画面密度もインタラクションもすべて別に設計。「全部レスポンシブで 1 つ」にしない判断がプロダクトの核になった
02
マルチテナント実装済み
複数団体の管理基盤を構築。段階的な開放が可能な状態
03
Apple 審査対応済み
「iPhoneでタッチ決済」の要件を満たすオンボーディング・審査ドキュメントを整理