ブースをプロダクトとして設計する

AfterDroidKaigi2026で話した内容です
https://pixiv.connpass.com/event/403628/

Transcript

1. ブースをプロダクトとして設計する DroidKaigi 2026 ピクシブブースの裏側 gatosyocora pixiv Inc. After DroidKaigi 2026
2. gatosyocora ピクシブ株式会社 新卒 / Androidエンジニア DroidKaigi 2026 ブース設営リーダー担当 ・ブースアーキテクト設計 pixivCanvas 開発 ・今回のブース用に作成したお絵かきアプリ 2
3. 今日話すこと 「何を出したか」❌ 「どう設計したか」⬅ ブースを1つのプロダクトとみなし、 要件定義 → ターゲット → 体験設計 → 配置図 → 計測 → 振り返り をまわした エンジニアやPMが普段使っている道具は、ブースにもそのまま使える 3
4. 1. 制約と目的を整理する 制約 目的 日程 9月2日, 3日 の 2 日間 1 登壇・プロポーザルチャレンジを最大化する 全体参加者 1,300 名（前回 1,200名） 2 技術力をアピールする 3 採用につながるコミュニケーション ブース来場 想定 200 名 → ノベルティ・カードの数量根拠 スタッフは登壇者 2 名を含む兼務体制 ブース面積に限りがある やりたいことイメージ ブースアプリ展示 / アプリ以外のコンテンツ / アフター イベント誘導 / 採用情報 / アンケート 4
5. 2. ターゲット5つ × 当てるコンテンツ ターゲット MVV 技術力 会社紹介 入社する可能性がある人 • • • • 技術に興味がある人 ピクシブをあまり知らない人 • 創作体験 英語 • • 創作に触れたことがない人 • 英語話者（全行に横断） MVV → MVVページ 創作体験 → ブースアプリ 技術力 → ブースアプリ・技術記事・AfterDroidKaigi 英語 → アプリ・記事の英訳 会社紹介 → プロダクト一覧 英語話者は全セグメントに含まれる横断要件 ローカライズは Must 5
6. 3. 去年の KPT を「要件」に変換する 去年の Problem / Try（11カテゴリ）から、今年の設計判断に直結した3つ KPT インストールはハードルが高い Android 端末を持っていない人も多い KPT モニター2台 + プロポーザルボードが ブースを占有しすぎた KPT アンケートがアプリの体験に埋もれた 回答インセンティブが曖昧 要件 Web アプリで配布不要に （Compose Multiplatform） 要件 物理ボードは A1 1枚に統合 （プロポーザル・スタッフ・プロダクト紹介） 要件 アンケートはアプリから独立 別 QR + 回答でノベルティ 6
7. 4. 体験を設計する 来場者が「来て、体験して、去る」まで 体験フロー、配置図、サービスブループリント UX 設計の道具をそのまま使いました 7
8. 4-1. 体験フロー：メインコンテンツを先頭に 通りかかる （法被・モニター で認知） QR を読む （インストール 不要） チュートリアルで ドロイドくんを完成 みんなの作品 を 見て驚く 自分の作品を 作って投稿 ノベルティ + アンケート（別 QR） カードを持ち帰 り 帰宅後にもう一 度開く お絵かきアプリを触る 設計上の意図 メインコンテンツ（お絵かきアプリ）を最初に出す QR カードは「遊んでくれた人にこそ」渡す ブースを去った後にもう一度開かせるための設計 滞在してくれたら記事・プロポーザル・採用情報へ誘導する サブコンテンツ（記事・アフターイベント情報）は アプリ再起動時やフライヤーで後から気づくように 8
9. 4-2. 配置図：導線を物理に落とす 配置のポイント 通路側にモニター（アプリ・会社紹介動画） → 通りがかりに目に入りやすい 検証機を手前に → DL せずその場で触れる A1 ボード 1 枚に物理コンテンツを集約 → 面積を取らない アンケート QR とアプリ QR は別の場所に → 独 立してアクセスできる Claudeにシミュレーションツールを作ってもらいました 9
10. 4-3. サービスブループリント：アプリの層構造と同じ オンステージ 来場者が見る・触るもの アプリ紹介ポスター / 検証機 / プロポーザル紹介ボード / 法被 のスタッフ / ノベルティ / モニター(会社紹介動画) UI 層 バックステージ 現地にあるが来場者には見えないも の 景品在庫の管理 / シフト表 / 立ち回りマニュアル ドメイン層 アプリ用サーバー / 会場ネットワーク / アンケートフォーム インフラ層 サポートプロセス インフラ 当日誰が何を担当するかと、事前に用意すべき裏側が自然に出てくる 10
11. 5. 結果 155 約80% 約60% 2,000 アンケート回答数 が「通りかかって」 ブースを認知 がアプリ体験を 印象に残った アプリの ページ閲覧数 設計との対応 来場は想定 200 名 → 実際は推定 250〜300 名 印象の1位がアプリ体験、 3位にアプリの技術 「通りがかり」依存なので、立地と体験の可視化（モニター ・法被）が効いた メインコンテンツ(アプリ) → 技術訴求の導線は 設計どおり動いた 11
12. 5-2. 何が刺さったか 自由記述から 「アプリがインストールしなくても結構楽しめるところ」 「composeのwebアプリを触れた！」 「オリジナルのアプリを今回のために作ったのがすごかった」 「ぜひ、お絵かきアプリを恒常運用してほしいです」 12
13. 6. 設計どおりにいかなかったこと 1 コンテンツが多すぎた 2 チュートリアルで完成させてしまう アプリ、プロポーザル紹介、アフターイベント、アンケート チュートリアル画面で作品を作り終え、 と全て案内しようとするとオペレーションが多かった 投稿まで進まないケースが多発。 アテンド無しでも投稿に到達する導線が必要 3 技術訴求が「分かる人」にしか届かない 4 スタッフ配置やアテンドにも改善の余地あり CMP / Compose for Web の凄さは分かる人には 混雑時を想定したスタッフ配置にしたがまだ対応が難し 刺さったが、分からない人には伝わらず。 いタイミングがあった。 スタッフの知識差もありスタッフの負担にもなった 来場者へのアテンドのやり方も決めておきたい 13
14. 7. まとめ ブース設計は UX 設計と同じ道具で回せる 1 目的の優先順位 → ターゲット → 体験フロー → ブループリント → 配置図 要件定義と同じ手順で迷いが減る。 集客は「立地」と「体験の見える化」に投資する 2 認知の約8割は通りがかり 事前告知より、通路から見える体験（モニター・ポスター・法被）のほうが効く。 KPT は次年度の要件に落とすまでが仕事 3 振り返りを「要件」に変換して初めて改善になる。 14