Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エンジニア目線で考える、プロダクト開発を適用したブース設計 / Booth desi...
Search
Shintani Teppei
May 17, 2023
Technology
0
720
エンジニア目線で考える、プロダクト開発を適用したブース設計 / Booth design applying product development
Shintani Teppei
May 17, 2023
Tweet
Share
More Decks by Shintani Teppei
See All by Shintani Teppei
ISUCONで型をつける
euglena1215
1
78
3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years
euglena1215
11
4.7k
モジュラモノリス、その前に / Modular monolith, before that
euglena1215
8
970
いつか使える ObjectSpace / Maybe useful ObjectSpace
euglena1215
2
190
rbs-inlineを導入してYARDからRBSに移行する
euglena1215
1
600
Ruby の型に関する活動をやっている話 / Activities related to Ruby types
euglena1215
3
310
そろそろ理解する includes / Understanding includes
euglena1215
1
880
習うより慣れる Ruby AST / Ruby AST is better to get used to than to learn.
euglena1215
2
500
Railsでエンドポイントごとのテストカバレッジを測定する / Measuring Test Coverage per Endpoint in Rails
euglena1215
1
480
Other Decks in Technology
See All in Technology
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
630
Change Managerを活用して本番環境へのセキュアなGUIアクセスを統制する / Control Secure GUI Access to the Production Environment with Change Manager
yuj1osm
0
100
Potential EM 制度を始めた理由、そして2年後にやめた理由 - EMConf JP 2025
hoyo
2
2.6k
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
7
660
日経のデータベース事業とElasticsearch
hinatades
PRO
0
230
"TEAM"を導入したら最高のエンジニア"Team"を実現できた / Deploying "TEAM" and Building the Best Engineering "Team"
yuj1osm
1
130
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
14
4.9k
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
170
組織におけるCCoEの役割とAWS活用事例
nrinetcom
PRO
4
120
OPENLOGI Company Profile
hr01
0
60k
いまからでも遅くない!コンテナでWebアプリを動かしてみよう!コンテナハンズオン編
nomu
0
150
Amazon Aurora のバージョンアップ手法について
smt7174
2
140
Featured
See All Featured
Thoughts on Productivity
jonyablonski
69
4.5k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
A Modern Web Designer's Workflow
chriscoyier
693
190k
A designer walks into a library…
pauljervisheath
205
24k
Building an army of robots
kneath
303
45k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
RailsConf 2023
tenderlove
29
1k
Building Your Own Lightsaber
phodgson
104
6.2k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.3k
KATA
mclloyd
29
14k
Transcript
株式会社タイミー Shintani Teppei エンジニア目線で考える、 プロダクト開発を適用したブース設計 @euglena1215 @RubyKaigi2023 スポンサー振り返り会!エンジニアが語る運営秘話
こう感じている方はいませんか?
こう感じている方はいませんか? 会社にスポンサーをやってほしい。 スポンサーやるならブースも出したい。
こう感じている方はいませんか? でも、ブース設計よく分からないから 強くプッシュできない...
こうなってほしい ブース設計って いつもやっていることの延長線かも?
自己紹介 新谷 哲平(@euglena1215) • バックエンドエンジニア • RubyKaigi で一番面白かったセッション: i++ •
RubyKaigi の感想: 英語のリスニング力を高めようと思いました
7
株式会社タイミー Shintani Teppei エンジニア目線で考える、 プロダクト開発を適用したブース設計 @euglena1215 @RubyKaigi2023 スポンサー振り返り会!エンジニアが語る運営秘話
目次 1. プロダクト開発フロー 2. ブース設計への適用 3. まとめ
目次 1. プロダクト開発フロー 2. ブース設計への適用 3. まとめ
2.KPIを決める 3.施策を決める 4.実装する 5.計測する 6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める タイミーアプリの1機能を題材にします ※ 機能は存在しますが、実際に行った施策の流れではありません
2.KPIを決める 3.施策を決める 4.実装する 5.計測する 6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める
1. 目的を決める 課題: タイミーで初めて働くひとが 働ける募集を見つけるのが難しい 目的: はじめてのワーカーが 働ける募集を見つけやすくする
3.施策を決める 4.実装する 5.計測する 6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める 2.KPIを決める
募集検索経由でのマッチングした募集の表示位置 マッチングした募集が上に表示されていればスムーズ に募集を見つけられたといえそう。 2. KPIを決める ① ②
4.実装する 5.計測する 6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める 2.KPIを決める 3.施策を決める
「未経験者歓迎」を設定 3. 施策を決める ユーザーストーリーを考える 働ける募集を探す お仕事が確定する
5.計測する 6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する
がんばる 4. 実装する
6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
募集検索経由でのマッチングした募集の表示位 置がn個上になった 5. 計測する ① ②
6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
ここは想定通りだった ここは想定外、考察としては... 次回は〇〇を試してみよう! 6. 振り返る
6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
6.振り返る プロダクト開発フローのステップの認識を揃える 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する これらのステップをブース設計に適用します
目次 1. プロダクト開発フロー 2. ブース設計への適用 3. まとめ
ブース設計への適用 RubyKaigi 2023 でのタイミーのブース設計で考えたことを共有します 6.振り返る 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
ブース設計への適用 6.振り返る 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
課題: タイミーは Ruby コミュニティではまだ 認知度が高くない 目的: タイミーのことを知ってもらう 今後発信する情報を見てくれる人を増やす 1. 目的を決める
ブース設計への適用 6.振り返る 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
2. KPIを決める • 公式 Twitter フォロワー数(@TimeeDev) • パンフレット配布数 今回は初ブース出展で目標値を立てるのが難しかったため、目標は立てず。 パンフレットは他社さんを参考にしつつ、とりあえず400枚持っていくことに。
ブース設計への適用 6.振り返る 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
ユーザーストーリーを考える 3. 施策を決める 気付いてブースに来てもらう Twitterフォロー 興味をもってもらう
ユーザーストーリーを考える 3. 施策を決める 気付いてブースに来てもらう Twitterフォロー 興味をもってもらう
ポイント:目を引く そもそもタイミーの色が目立つので 営業チームのブース出展で利用していたバ ナーをお借りした。 3. 施策を決める - 気付いてブースに来てもらう
ポイント:目を引く ブース外でも認知してもらうため、 タイミーキャラを肩に乗せてる社員を 見つけるとプレゼントがもらえる キャンペーンも企画 3. 施策を決める - 気付いてブースに来てもらう
3. 施策を決める - 気付いてブースに来てもらう
ユーザーストーリーを考える 3. 施策を決める 気付いてブースに来てもらう Twitter フォロー 興味をもってもらう
ポイント: フォローしてと伝えるだけではフォローしてもらえないので、 フォローしてもらえる状況をどう作るか ≒ どんなキャンペーンを企画するか 3. 施策を決める - Twitterフォロー
タイミーのオライリータワー制度に合わせて オライリー書籍プレゼントキャンペーンを実施 3. 施策を決める - Twitterフォロー
ユーザーストーリーを考える 3. 施策を決める 気付いてブースに来てもらう Twitter フォロー 興味をもってもらう
ポイント: エンジニアがパンフレットを手に取りたくなる内容を 載せられるか 表面には rails stats や Gemfile、数字で見る開発 組織、タイミーが取り組む技術課題などちょっと気に なる情報を掲載。
RubyKaigi でモチベーション上がった人向けに OSS コントリビュートに関する勉強会に誘導する動 線も。 3. 施策を決める - 興味を持ってもらう
ポイント: エンジニアがパンフレットを手に取りたくなる内 容を載せられるか 裏面には会社のことをより知ってもらうために推 しのエンジニア向け福利厚生制度を掲載。 3. 施策を決める - 興味を持ってもらう
ユーザーストーリーを考える 3. 施策を決める 気付いてブースに来てもらう Twitter フォロー 興味をもってもらう これで一連のユーザーストーリーがつながるようになった
ブース設計への適用 6.振り返る 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
制作物作成のためにはデザイナーに協力を依頼する必要がある デザイナーとのやりとりはDevEnableチームにお願いして進めたのであまり関わってお らず。 4. 実装する DevEnable チームとは? • エンジニアと協力していろんなことをやっていくチーム •
チームトポロジーの文脈から DevEnable という名前をつけている • いろんなことの中の1つの技術広報分野として一緒に進めた 詳しくは「Timee Dev Enable」で検索
ブース設計への適用 6.振り返る 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
5. 計測する
公式Twitterフォロワー数:275 → 371人 (ほぼ)100人増えた タイミーのことをリーチできる人数が1.3倍になった 5. 計測する
公式Twitterフォロワー数:275 → 371人 (ほぼ)100人増えた タイミーのことをリーチできる人数が1.3倍になった パンフレット 400枚 → 配り切った day1で想定以上に持っていってもらえたのでday2以降は控えめに配っていた
そのまま配っていれば5-600枚は配れていたはず 5. 計測する
ブース設計への適用 6.振り返る 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する
6. 振り返る パンフレットが想定以上にすぐなくなった 考察: タイミーにノウハウがなかったという前提はありつつ、 サービス紹介よりも技術的な話を中心に載せたので興味をもってもらいやすかった。 Try: 次回もパンフレットには技術的な話を中心に載せる。 パンフレットは参加人数の50%分は持っていく。(1200人だったので600枚)
6. 振り返る タイミーに興味を持ってもらった人にサービスを説明するのが困った 考察: エンジニアに興味を持ってもらいやすくするために、意図的に資料からサービス紹介は 抜いていた。 Try: サービス紹介用のパンフレットやパネル、デモ用のスマホなどサービス説明に役立つも のを持っていく。
ブース設計への適用 6.振り返る 1.目的を決める 2.KPIを決める 3.施策を決める 4.実装する 5.計測する プロダクト開発をブース設計に適用することができた
【おまけ】会社に成果を主張する RubyKaigi は難しい。 RubyKaigi は3回参加すればだんだん内容が分かるようになってくる(持論)
【おまけ】会社に成果を主張する RubyKaigi は難しい。 RubyKaigi は3回参加すればだんだん内容が分かるようになってくる(持論) スポンサーも同様に3回ブース出さないと 認知が定着しないのでは?
【おまけ】会社に成果を主張する スポンサー初回は熱い気持ちを伝えれば会社もスポンサーしてくれるかもしれないけ ど、2回目、3回目はそうともいかない。 なので、しっかり成果を会社に主張してスポンサーする理由を会社につくってあげること が大事。
目次 1. プロダクト開発サイクル 2. ブース設計への適用 3. まとめ
まとめ • プロダクト開発はいくつかのステップに整理できる • ブース設計とプロダクト開発は同じ • スポンサーになって一緒に RubyKaigi を盛り上げよう!