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
素早く価値を届けるために スタートアップのプロダクトデリバリー戦略
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Sankyo Toshio
November 02, 2022
Technology
720
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
素早く価値を届けるために スタートアップのプロダクトデリバリー戦略
スタートアップの開発プロセスの中で、
素早く価値を届けるために工夫していることをお話しします。
Sankyo Toshio
November 02, 2022
More Decks by Sankyo Toshio
See All by Sankyo Toshio
広島発!スタートアップ開発の裏側
tsankyo
0
450
データベースのメモリ管理周り〜OutofMemoryを撲滅したい〜
tsankyo
0
180
スタートアップの開発とクラウドサービス
tsankyo
0
220
水産業ドメイン可視化と実装のコツ〜釣って捌いて食べてみる〜
tsankyo
1
920
水産業の辛いポイント、Railsがいてくれたから乗り越えられた
tsankyo
1
1.2k
Other Decks in Technology
See All in Technology
AI-DLCを “そのまま導入しなかった”話 ~組織に合わせてアジャストした 私たちの実践共有~
hiroramos4
PRO
1
440
SRE歴2ヶ月でも開発6年の知見を活かして、チームで止まっていた環境改善を前に進めた話
a_ono
0
110
ぼっちではじめた登壇が「51名」「241件」の発信に化けた
subroh0508
1
330
AI Agentをシステムに組み込む前にゆるく向き合ってみる
hayama17
0
170
CVE-2026-20833_脆弱性対応とAES 化について
jukishiya
0
110
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
11k
PostgreSQL 19 新機能概要 OSC Hokkaido 2026
nori_shinoda
0
260
從開發到部署全都交給 AI:實作 AI 驅動的自動化流程
appleboy
0
180
「勝手に広まる」人気 AI エージェントを爆速で作ろう!(AWS Summit Japan 2026講演資料)
minorun365
PRO
10
2.6k
Flow 不死:AI 時代 DevOps 的不變本質
cheng_wei_chen
2
550
GitHub Copilot運用のリアル ~AI Credit時代にどう向き合うか~
takafumisu2uk1
0
490
アラート調査向けAIエージェントの本番導入とその後/AI Agents for Alert Investigation: Production Deployment and After
taddy_919
1
250
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
55k
Ethics towards AI in product and experience design
skipperchong
2
320
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
400
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
620
How STYLIGHT went responsive
nonsquared
100
6.2k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
56k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
470
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
620
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.3k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.2k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
310
Transcript
素早く価値を届けるために スタートアップのプロダクトデリバリー戦略 株式会社ウーオ PM 三京俊雄
自己紹介 三京俊雄(さんきょう としお) @3to_day 2020年にウーオに2人目のエンジニアとして入社 現在はPM兼エンジニア UUUOで魚の捌き方習得中 好きな魚はシロアマダイ
スタートアップであるUUUOの開発プロセスの中で、 素早く価値を届けるために工夫していることをお話しします。 本日お話しすること
UUUOのプロダクトの状況 プロダクトマーケットフィット(PMF)を目指す • 万全な状態でのリリースより、素早くリリースして検証 => 改善のサイクル を回すことが重要 • とはいえトラフィックも増えてきており、パフォーマンスや負荷についても 気にしないといけなくなる状況
• とはいえ(常に)エンジニアリソースは限られている状況 • できる限り作らない
UUUOのプロダクトの状況 プロダクトチーム • エンジニア ◦ 正社員 4名(うち2人はPM兼) ◦ 業務委託 4名
◦ 特にサーバーサイド、クライアントの区分けはない • デザイナー ◦ 1名 ◦ 業務委託 1名
基本的な開発サイクル UUUOのプロダクト開発サイクル 1. 課題抽出 2. 優先順位検討 3. ヒアリング/プロトタイプ検証 4. 開発/リリース
5. リリース後検証
基本的な開発サイクル UUUOのプロダクト開発サイクル 1. 課題抽出 2. 優先順位検討 3. ヒアリング/プロトタイプ検証 4. 開発/リリース
5. 検証 できる限り作らない
ユーザーの課題を深堀りし、プロダクトでどのような解決ができるかを探ってい く。 【大事にしていること】 • セールスチーム/CSチーム/ユーザーからの声の収集 • 実際の環境に身をおきながら体験する 1. 課題抽出
Before • チケット:GitHub Projects • ドキュメントはKibela 1. 課題抽出 セールスチーム/CSチーム/ユーザーからの声の収集をしやすくするために After
• チケット:GitHub Projects上で管理 • 優先順位決め:notion • ドキュメント:notion
ドキュメントも、優先順位管理もすべてnotion上で管理することで セールス/CSからの課題提案が集まりやすくなった。 notionのタイムラインビュー素敵🎉 抽象 具体 1. 課題抽出 セールスチーム/CSチーム/ユーザーからの声の収集をしやすくするために
エンジニアでも実地検証も大事 現場理解をすることで、 実際にユーザーがどういう環境でどんな心境で プロダクトを使っているかを把握する ex: ネットワーク環境は? スマホをさわれる時間はあるか?... 1. 課題抽出 実際の環境に身をおきながら体験する
PMの大事な仕事。 課題の深さと、UUUOのKPIに対して最大の効果が出るものをチームで考えな がら優先順位づけ。 ユーザーログ(MixPanel)、実績データ(Metabase)を使って可視化 2. 優先順位検討 インパクト計測
• ユーザー属性理解 現状このタイプの出品が構成比何割(Metabaseで計測)だから この機能を伸ばしていこう。 この画面があまり使われていない(MixPanelで計測)から、 この画面の改善の優先順位をあげよう。 • これがないと離脱しそう プロダクトの影響で業務オペレーションが変わってきており、 辛くなってきている
• 未来の予測/ドメイン知識 これからカニのシーズンに入るから、この機能を磨いておきたい。 2. 優先順位検討 その他のパラメータ
かなり重要で盛り上がる(🎃?)プロセス 課題を深堀した後、 デザイナーとプロトタイプを作成し、 ステークホルダーに当てる。 【気をつけていること】 • 最低でも背景、属性の違う2人にはあてる ex: 一人は島根の漁港の人、一人は広島の市場の人 •
必ず自分たちの仮説を持ってユーザにあてる 3. ヒアリング/プロトタイプ検証
Figmaのプロトタイプ機能すばらしい🎉 即日プロトタイプ公開ができる。リンク共有もできる。 3. ヒアリング/プロトタイプ検証 必ず自分たちの仮説を持ってユーザにあてる プロトタイプを共有しな がらZoom or LINEで ヒアリング
from: https://twitter.com/shin_sasaki19/status/1580756540927401984 3. ヒアリング/プロトタイプ検証 必ず自分たちの仮説を持ってユーザにあてる
ある程度の課題感がわかり、この課題の解決が必要だと判断した時点で プロトタイプを何パターンか作成 何もない状態でのヒアリングよりも、何かプロトタイプ(たたき)がある状態で ヒアリングするとヒアリングが進めやすく効率が良い。 3. ヒアリング/プロトタイプ検証 必ず自分たちの仮説を持ってユーザにあてる
【大事にしていること】 • Staging環境を安心/安全/最適にする • Review Appの活用 • モバイルアプリリリースの自動化 4. 開発/リリース
After • 全てのアプリでStagingアプリを作成 (Build Flavorで切り替え) 4. 開発/リリース Staging環境を安心/安全/最適にする Before •
アプリは一つでAPIのエンドポイントを切り替えられる状態 本番アプリ 本番アプリ 本番アプリ Stagingアプリ Stagingアプリ Stagingアプリ 以前は管理者メニュー だけ提供していた
Staging接続中がわかるよう、ラベルで可視化(安心感) 新規参入のメンバーにも使ってもらいやすい状況になり 開発効率もアップ 本番からStagingへのデータ反映をスクリプトで 行いやすくしてデータの最適化 4. 開発/リリース Staging環境を安心/安全/最適にする
管理者は、ユーザー切り替え機能で、各組織単位のテストも容易に。 完全にユーザーと同条件でのテストができる 4. 開発/リリース Staging環境を安心/安全/最適にする
• HerokuのReview Appを活用 ◦ PRをあげるとそのソースで検証環境が作成される 4. 開発/リリース Review Appの活用
4. 開発/リリース モバイルアプリリリースの自動化 After • Flutterでクロスプラットフォーム開発 • GitHub Actionsでデプロイ自動化 Before
• iOS(Swift), Android(Kotlin)でソースは別 • デプロイは手動
(悩み) App Store Connectへのアップロードが遅いので、(20分ぐらい) StagingアプリはApp Distributionへのアップロードに変えたい。 4. 開発/リリース
CS, プロダクト, セールスだれもがデータ検証できるように(データ民主化) • CS リリースした機能が使われているかどうか • プロダクト Crashしていないか、どこがオーバーヘッドになっているか (一応CrashLyticsも入れているが、MixPanelでもチェックしている)
• セールス 担当顧客の動き、売上をチェック 5. リリース後検証 MixPanel: 簡単に時系列分析ができる。クラッシュも把握できる Metabase: SQL知らなくてもデータ分析できる
5. リリース後検証 Before • スプレッドシートで管理 ◦ リアルタイム性がない ◦ みづらい After
• Metabaseで管理 ◦ グラフでわかりやすく ◦ 開きやすい、共有しやすい
5. リリース後検証 全員で同じダッシュボードを毎日見れる グラフを伸ばすモチベーションが生まれる
ユーザーに素早く価値を届けるためにUUUOがしていること まとめ • いかにはずれのないところで機能を作るように動くか プロトタイプ検証、ユーザー理解をして、極力無駄なものは作らない • 検証しやすい環境を作る • リリースプロセスは自動化する •
機能の成功、失敗にいかにはやく気づけるか(検証・データの民主化)
一皮むけた? 自分は開発特化型のエンジニアでしたが、 使われないプロダクトを作ってしまった反省から プロダクトを成功させることのできるエンジニアになりたいと思った。 UUUOに入ってからデザインスプリントの考え方、プロトタイプ検証のやり方 を学んだ。
一皮むけた? Before • 使われないものに長時間かけてコードを書く After • コードを書く前のプロセスに時間をかけ、確信のあるものだけに コードを書く(そうでないと怖くてコードがかけない) • コードを書くまでのプロセスは長いが、無駄が減るので結果とし
て高速になる • OSSやツールなど利用して極力書かない
ご清聴ありがとうございました。