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
500
素早く価値を届けるために スタートアップのプロダクトデリバリー戦略
スタートアップの開発プロセスの中で、
素早く価値を届けるために工夫していることをお話しします。
Sankyo Toshio
November 02, 2022
Tweet
Share
More Decks by Sankyo Toshio
See All by Sankyo Toshio
データベースのメモリ管理周り〜OutofMemoryを撲滅したい〜
tsankyo
0
100
スタートアップの開発とクラウドサービス
tsankyo
0
150
水産業ドメイン可視化と実装のコツ〜釣って捌いて食べてみる〜
tsankyo
1
680
水産業の辛いポイント、Railsがいてくれたから乗り越えられた
tsankyo
1
960
Other Decks in Technology
See All in Technology
ゼロから創る横断SREチーム 挑戦と進化の軌跡
rvirus0817
2
270
MLOps の現場から
asei
6
650
ブラックフライデーで購入したPixel9で、Gemini Nanoを動かしてみた
marchin1989
1
540
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
280
re:Invent 2024 Innovation Talks(NET201)で語られた大切なこと
shotashiratori
0
310
非機能品質を作り込むための実践アーキテクチャ
knih
5
1.4k
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
3
2.4k
10分で学ぶKubernetesコンテナセキュリティ/10min-k8s-container-sec
mochizuki875
3
350
KubeCon NA 2024 Recap: How to Move from Ingress to Gateway API with Minimal Hassle
ysakotch
0
200
Opcodeを読んでいたら何故かphp-srcを読んでいた話
murashotaro
0
260
kargoの魅力について伝える
magisystem0408
0
210
20241220_S3 tablesの使い方を検証してみた
handy
4
590
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Six Lessons from altMBA
skipperchong
27
3.5k
How STYLIGHT went responsive
nonsquared
95
5.2k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
KATA
mclloyd
29
14k
The Cost Of JavaScript in 2023
addyosmani
45
7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.4k
Building Adaptive Systems
keathley
38
2.3k
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やツールなど利用して極力書かない
ご清聴ありがとうございました。