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
Sankyo Toshio
November 02, 2022
Technology
0
600
素早く価値を届けるために スタートアップのプロダクトデリバリー戦略
スタートアップの開発プロセスの中で、
素早く価値を届けるために工夫していることをお話しします。
Sankyo Toshio
November 02, 2022
Tweet
Share
More Decks by Sankyo Toshio
See All by Sankyo Toshio
データベースのメモリ管理周り〜OutofMemoryを撲滅したい〜
tsankyo
0
140
スタートアップの開発とクラウドサービス
tsankyo
0
180
水産業ドメイン可視化と実装のコツ〜釣って捌いて食べてみる〜
tsankyo
1
780
水産業の辛いポイント、Railsがいてくれたから乗り越えられた
tsankyo
1
1k
Other Decks in Technology
See All in Technology
Claude Code Actionを使ったコード品質改善の取り組み
potix2
PRO
4
1.8k
AIのAIによるAIのための出力評価と改善
chocoyama
1
520
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 完全版 / Building a C Compiler for PHPers Who Want to Dive into Low-Level Programming - Expanded
tomzoh
3
1.4k
Observability infrastructure behind the trillion-messages scale Kafka platform
lycorptech_jp
PRO
0
130
AIの最新技術&テーマをつまんで紹介&フリートークするシリーズ #1 量子機械学習の入門
tkhresk
0
130
強化されたAmazon Location Serviceによる新機能と開発者体験
dayjournal
2
170
Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025
iselegant
16
4.9k
Oracle Cloud Infrastructure:2025年6月度サービス・アップデート
oracle4engineer
PRO
2
150
フィンテック養成勉強会#54
finengine
0
120
[TechNight #90-1] 本当に使える?ZDMの新機能を実践検証してみた
oracle4engineer
PRO
3
140
2025/6/21 日本学術会議公開シンポジウム発表資料
keisuke198619
2
480
Agentic Workflowという選択肢を考える
tkikuchi1002
1
420
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
32
5.9k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
700
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
Music & Morning Musume
bryan
46
6.6k
GraphQLとの向き合い方2022年版
quramy
46
14k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
How STYLIGHT went responsive
nonsquared
100
5.6k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
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やツールなど利用して極力書かない
ご清聴ありがとうございました。