ケーススタディ・予約プラットフォーム（2025）
PIARY：予約データをもとに、週末イベント予約フローを再設計した
Pia街コンは、PIARY株式会社が運営する予約プラットフォームです。街コン、婚活パーティー、恋活イベントを一元的に検索・予約できます。「街コン」は都市部で開催されるグループ型の出会いイベントで、日本独自の形式です。私はこの案件で、データ分析からFigmaでの設計、React/TypeScriptでの実装まで単独で担当し、本番リリースしました。
役割
デザイナー兼エンジニア（単独）
期間
2ヶ月（2025年8〜9月）
ツール
Figma · React · TypeScript
納品物
本番リリース済み
設計プロセス
データ分析→仮説定義 (JTBD)→設計・実装→計測・振り返り
01 / 課題の発見
設計の出発点は予約ログだった。
依頼は「予約フローを改善してほしい」でした。スコープは定義されておらず、どこが本当の問題なのかを特定するところから始める必要がありました。最初の仕事はフォームを触ることではなく、過去3ヶ月分・192件の予約ログを抽出して時系列で眺めることでした。
曜日別イベント開催数
土55・日35 — 週末で全体の83.3%
予約が発生した曜日
平日にも広く分布 — 59.3%が平日に予約
ひとつ目、イベントの83.3%が週末（土日）に集中していました。土曜だけで全体の約51%です。このアプリは実質的に「週末イベントの予約プラットフォーム」だと、数字が示していました。
ふたつ目、その週末イベントの予約のうち59.3%が平日に発生していました。つまり「平日の昼間に、スマホで、週末の予定を探している」ユーザーがプラットフォームの多数派だったのです。その多数派が、毎回5ステップの検索フォームを通過させられていました。
もうひとつの数字が重かった。週末イベントのキャンセル率は36.7%（うちユーザー起因は21.1%）に対し、平日イベントは11.1%。週末は平日の3倍のキャンセル率だ。衝動的に予約し、急ぎで進め、後で取り消す——摩擦の多いフローがそのまま数字に出ていました。
既存の検索フロー
訪問のたびに繰り返す必要があった5ステップ。
02 / 仮説：Jobs-to-Be-Done
Jobs-to-Be-Doneフレームワークで、2つの異なる利用パターンを整理した。
Clayton ChristensenのJobs-to-Be-Done（JTBD）フレームワークを適用しました。データを見ると、ユーザーは同じアプリを「まったく異なる2つの仕事」のために使っていることがわかりました。
少数派の仕事
（探索型）
多数派の仕事
（即決型）
ユーザーの言葉
「将来の予定のために、イベントをゆっくり探したい。」
「水曜日。今週土曜の予定を今すぐ決めたい。」
旧UIとの相性
03 / 検討した代替案
最終案に至るまでに3つの代替案を検討し、却下した。
フォームに「週末」フィルターを追加
フォームを開く行為そのものが摩擦だ。チェックボックスを追加しても、その摩擦は消えない。
保存済み検索プリセット
初期設定が必要。ユーザーの行動は毎回「初回訪問」に近く、プリセットを設定するほどの継続性がなかった。
カレンダーUIの改善
「探索して回る」モデルをきれいにするだけ。「即決したい」ユーザーの仕事を速くはしない。
✅ 採用案
ホームに「今週末行ける」セクションを追加
ジオロケーションとセッションデータを使い、ホームを開いた瞬間に「あなたのエリアで今週末に開催されるイベント」を表示する専用セクションを実装。検索フォームに触れずに、多数派の仕事を一発で完結させる。
04 / 解決策
「今週末行ける」セクションをホームに追加し、3つの設計判断の根拠を示す。
インテリジェントなスコーピング
設定
「今週末」と「来週末」の2タブ構成。
理由
データ上、予約の大多数はイベント開始から7日以内に発生していた。3〜4週間先を表示しても「ノイズ」になるだけ。
目的
選択肢を2週間に絞ることで、1タブあたり十数件のスキャン可能なリストに収める。これはHickの法則の応用——選択肢を減らすほど、判断にかかる時間は短くなる。
入力ゼロのコンテキスト
設定
エリアを自動検出。
理由
「あなたの現在地を教えてください」と聞くこと自体が摩擦だ。
ロジック
ゲストユーザーは東京（最大ボリューム）をデフォルト表示。ログインユーザーは登録エリアを自動参照。ページが読み込まれた瞬間、関連イベントが目に入る——「検索」から「発見」へ、即座に切り替わる。
スキャン型 vs 入力型 UI
設定
情報密度が高く、コントラストの強いイベントカード。
理由
スピードが目的のとき、ユーザーはイベントが「行く価値があるか」を確認するためだけに詳細ページを開きたくない。
ロジック
優先表示は4つのデータポイント：イベント名、日時、エリア、リアルタイムの残席数。操作モデルを「絞り込んで探す」から「見た瞬間に選ぶ」に転換した。
05 / 配置の根拠
ホームはすでに機能していた。新しいものを足すなら、壊さない場所に置く必要があった。
人気エリアセクションはユーザーに「どこで出会いたいか」を意識させる。その直後に「今週末、そのエリアで行けるイベント」を見せれば——意図と選択肢が一致した瞬間に届けられる。
「人気キーワード」はその下に残した。まだ何を探すか決まっていない人のための場所として。新しいセクションは、決めかけている人だけに割り込む。
Before
After
4つの根拠
01
マインドセットが整ったところに答えを差し出す
「人気のエリアから探す」をスキャンしたユーザーは、頭の中でエリアをすでに意識している。そのタイミングで「そのエリアの今週末」を見せる。考えるきっかけを与えるのではなく、考えている最中に答えを差し出す。
02
すでに機能しているものは壊さない
検索フォーム・キャンペーンバナー・オススメセクションは既にCVRに貢献している。その上に割り込めば、既存の成果を食う。ページ中盤への挿入は、既存の導線を残しつつ新しい需要だけを捕まえる最小限の介入。
03
多数派のニーズが、離脱より先に目に入る位置
予約の83.3%が週末向けだが、ユーザーが途中で離脱すれば意味がない。ページ中盤はまだスクロールが届く領域で、離脱が跳ねる前のゾーン。多数派に応えるセクションは、多数派が見られる場所に置く必要があった。
04
スクロールとともに視点が絞られていくリズム
良い情報設計にはリズムがある。オススメ（全体）→ エリア（場所で絞る）→ 今週末（時間＋場所で絞る）。この位置に差し込むことで、ページがランダムな羅列ではなく、決断へと導く流れになる。
06 / 結果と、正直な計測事情
2025年9月にリリース。予約行動が変化した――データが示せることと示せないことについて正直に記す。
ローンチ前後の予約データ（108件 vs 87件）を比較したとき、3つの行動変化が見られました。
予約タイミングのシフト
当日予約率
Before
41.1%
After
23.1%
↓ 18pp
予約リードタイム中央値
Before
1日
After
4日
↑ +3 日
ユーザーは土曜の朝に慌てなくなった。当日予約率は41.1%から23.1%へ低下し、週末イベントに限ればリードタイムは2日から6日へ伸びた——「今週末」タブが狙っていた行動そのものだ。
キャンセル率——分解してわかったこと
総キャンセル率は上昇した。しかし種別に分けると全く別の話が見えてくる。
ユーザー起因キャンセル
↓ 改善Before
21.1%
After
13.5%
総数を押し上げたのは主催者側の要因であり、予約体験とは無関係だ。
“計測は設計の成果物だ。仕様書に属するものであり、振り返りに属するものではない。”
— 計測についての振り返り
次にやり直すなら
計測計画をリリース前の仕様書に入れる。初日から追いたい3つのこと：
週末セクション経由の予約コンバージョン——全体の予約数ではなく、モジュール経由の完了数を個別に計測する。
キャンセル種別をデータスキーマで分離——ユーザー起因と主催者起因を最初から別フィールドで持つ。
予約リードタイムをダッシュボード指標に——最も強いシグナルだったが、振り返りで発見した。初日から追うべきだった。
07 / 学び
このプロジェクトが教えてくれた4つのこと。
データは問いを見つける。フレームワークが答えを見つける。
83.9%という数字は「何かがおかしい」ことを教えてくれた。何を作るかは教えてくれなかった。答えは「このプロダクトはどんな仕事のために雇われているのか」と問うことで見つかった——スプレッドシートからではなく。
平等な扱いが、公平な扱いとは限らない。
旧来の検索フォームは全ユーザーに同じ5ステップを課していた。実際には、83%の多数派が毎回最も無駄な作業をしていた。多くの人が必要とするショートカットを設計しながら、残りの人のためにフルパスを残す——それがより誠実な選択だった。
集計指標は真実を隠すことがある。
総キャンセル率はローンチ後に上昇した。そこで止めていたら失敗と結論づけていた。種別に分解すると、UXは機能していた。報告する価値のある指標は、原因別に分解する価値がある。
計測計画は機能と一緒にリリースする。
最も強いシグナル——予約リードタイムのシフト——は振り返りで発見したものだった。初日から追っていれば、数ヶ月ではなく数週間で検証できていた。今後の仕様書には「これが機能したとどうわかるか」の項目を必ず入れる。