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
540
素早く価値を届けるために スタートアップのプロダクトデリバリー戦略
スタートアップの開発プロセスの中で、
素早く価値を届けるために工夫していることをお話しします。
Sankyo Toshio
November 02, 2022
Tweet
Share
More Decks by Sankyo Toshio
See All by Sankyo Toshio
データベースのメモリ管理周り〜OutofMemoryを撲滅したい〜
tsankyo
0
110
スタートアップの開発とクラウドサービス
tsankyo
0
160
水産業ドメイン可視化と実装のコツ〜釣って捌いて食べてみる〜
tsankyo
1
730
水産業の辛いポイント、Railsがいてくれたから乗り越えられた
tsankyo
1
980
Other Decks in Technology
See All in Technology
インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて
nwiizo
5
2.6k
クラウドサービス事業者におけるOSS
tagomoris
2
840
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
730
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
1.4k
Goで作って学ぶWebSocket
ryuichi1208
2
1.3k
表現を育てる
kiyou77
1
210
技術的負債解消の取り組みと専門チームのお話 #技術的負債_Findy
bengo4com
1
1.3k
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
2
3k
AndroidデバイスにFTPサーバを建立する
e10dokup
0
250
SA Night #2 FinatextのSA思想/SA Night #2 Finatext session
satoshiimai
1
140
全文検索+セマンティックランカー+LLMの自然文検索サ−ビスで得られた知見
segavvy
2
110
個人開発から公式機能へ: PlaywrightとRailsをつなげた3年の軌跡
yusukeiwaki
11
3k
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
427
64k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Side Projects
sachag
452
42k
Building Your Own Lightsaber
phodgson
104
6.2k
Docker and Python
trallard
44
3.3k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
330
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
The Cult of Friendly URLs
andyhume
78
6.2k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Mobile First: as difficult as doing things right
swwweet
223
9.3k
How to train your dragon (web standard)
notwaldorf
91
5.8k
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やツールなど利用して極力書かない
ご清聴ありがとうございました。