素早く価値を届けるためにスタートアップのプロダクトデリバリー戦略

by Sankyo Toshio

Slide 1

Slide 1 text

素早く価値を届けるためにスタートアップのプロダクトデリバリー戦略株式会社ウーオ PM 三京俊雄

Slide 2

Slide 2 text

自己紹介三京俊雄（さんきょうとしお） @3to_day 2020年にウーオに2人目のエンジニアとして入社現在はPM兼エンジニア UUUOで魚の捌き方習得中好きな魚はシロアマダイ

Slide 3

Slide 3 text

スタートアップであるUUUOの開発プロセスの中で、素早く価値を届けるために工夫していることをお話しします。本日お話しすること

Slide 4

Slide 4 text

UUUOのプロダクトの状況プロダクトマーケットフィット（PMF）を目指す ● 万全な状態でのリリースより、素早くリリースして検証 => 改善のサイクルを回すことが重要 ● とはいえトラフィックも増えてきており、パフォーマンスや負荷についても気にしないといけなくなる状況 ● とはいえ（常に）エンジニアリソースは限られている状況 ● できる限り作らない

Slide 5

Slide 5 text

UUUOのプロダクトの状況プロダクトチーム ● エンジニア ○ 正社員 4名（うち2人はPM兼） ○ 業務委託 4名 ○ 特にサーバーサイド、クライアントの区分けはない ● デザイナー ○ 1名 ○ 業務委託 1名

Slide 6

Slide 6 text

基本的な開発サイクル UUUOのプロダクト開発サイクル 1. 課題抽出 2. 優先順位検討 3. ヒアリング/プロトタイプ検証 4. 開発/リリース 5. リリース後検証

Slide 7

Slide 7 text

基本的な開発サイクル UUUOのプロダクト開発サイクル 1. 課題抽出 2. 優先順位検討 3. ヒアリング/プロトタイプ検証 4. 開発/リリース 5. 検証できる限り作らない

Slide 8

Slide 8 text

ユーザーの課題を深堀りし、プロダクトでどのような解決ができるかを探っていく。【大事にしていること】 ● セールスチーム/CSチーム/ユーザーからの声の収集 ● 実際の環境に身をおきながら体験する 1. 課題抽出

Slide 9

Slide 9 text

Before ● チケット：GitHub Projects ● ドキュメントはKibela 1. 課題抽出セールスチーム/CSチーム/ユーザーからの声の収集をしやすくするために After ● チケット：GitHub Projects上で管理 ● 優先順位決め：notion ● ドキュメント：notion

Slide 10

Slide 10 text

ドキュメントも、優先順位管理もすべてnotion上で管理することでセールス/CSからの課題提案が集まりやすくなった。 notionのタイムラインビュー素敵🎉 抽象具体 1. 課題抽出セールスチーム/CSチーム/ユーザーからの声の収集をしやすくするために

Slide 11

Slide 11 text

エンジニアでも実地検証も大事現場理解をすることで、実際にユーザーがどういう環境でどんな心境でプロダクトを使っているかを把握する ex: ネットワーク環境は？スマホをさわれる時間はあるか？... 1. 課題抽出実際の環境に身をおきながら体験する

Slide 12

Slide 12 text

PMの大事な仕事。課題の深さと、UUUOのKPIに対して最大の効果が出るものをチームで考えながら優先順位づけ。ユーザーログ(MixPanel)、実績データ（Metabase）を使って可視化 2. 優先順位検討インパクト計測

Slide 13

Slide 13 text

● ユーザー属性理解現状このタイプの出品が構成比何割(Metabaseで計測)だからこの機能を伸ばしていこう。この画面があまり使われていない(MixPanelで計測)から、この画面の改善の優先順位をあげよう。 ● これがないと離脱しそうプロダクトの影響で業務オペレーションが変わってきており、辛くなってきている ● 未来の予測/ドメイン知識これからカニのシーズンに入るから、この機能を磨いておきたい。 2. 優先順位検討その他のパラメータ

Slide 14

Slide 14 text

かなり重要で盛り上がる（🎃?）プロセス課題を深堀した後、デザイナーとプロトタイプを作成し、ステークホルダーに当てる。【気をつけていること】 ● 最低でも背景、属性の違う2人にはあてる ex: 一人は島根の漁港の人、一人は広島の市場の人 ● 必ず自分たちの仮説を持ってユーザにあてる 3. ヒアリング/プロトタイプ検証

Slide 15

Slide 15 text

Figmaのプロトタイプ機能すばらしい🎉 即日プロトタイプ公開ができる。リンク共有もできる。 3. ヒアリング/プロトタイプ検証必ず自分たちの仮説を持ってユーザにあてるプロトタイプを共有しながらZoom or LINEでヒアリング

Slide 16

Slide 16 text

from: https://twitter.com/shin_sasaki19/status/1580756540927401984 3. ヒアリング/プロトタイプ検証必ず自分たちの仮説を持ってユーザにあてる

Slide 17

Slide 17 text

ある程度の課題感がわかり、この課題の解決が必要だと判断した時点でプロトタイプを何パターンか作成何もない状態でのヒアリングよりも、何かプロトタイプ（たたき）がある状態でヒアリングするとヒアリングが進めやすく効率が良い。 3. ヒアリング/プロトタイプ検証必ず自分たちの仮説を持ってユーザにあてる

Slide 18

Slide 18 text

【大事にしていること】 ● Staging環境を安心/安全/最適にする ● Review Appの活用 ● モバイルアプリリリースの自動化 4. 開発/リリース

Slide 19

Slide 19 text

After ● 全てのアプリでStagingアプリを作成 (Build Flavorで切り替え) 4. 開発/リリース Staging環境を安心/安全/最適にする Before ● アプリは一つでAPIのエンドポイントを切り替えられる状態本番アプリ本番アプリ本番アプリ Stagingアプリ Stagingアプリ Stagingアプリ以前は管理者メニューだけ提供していた

Slide 20

Slide 20 text

Staging接続中がわかるよう、ラベルで可視化（安心感）新規参入のメンバーにも使ってもらいやすい状況になり開発効率もアップ本番からStagingへのデータ反映をスクリプトで行いやすくしてデータの最適化 4. 開発/リリース Staging環境を安心/安全/最適にする

Slide 21

Slide 21 text

管理者は、ユーザー切り替え機能で、各組織単位のテストも容易に。完全にユーザーと同条件でのテストができる 4. 開発/リリース Staging環境を安心/安全/最適にする

Slide 22

Slide 22 text

● HerokuのReview Appを活用 ○ PRをあげるとそのソースで検証環境が作成される 4. 開発/リリース Review Appの活用

Slide 23

Slide 23 text

4. 開発/リリースモバイルアプリリリースの自動化 After ● Flutterでクロスプラットフォーム開発 ● GitHub Actionsでデプロイ自動化 Before ● iOS(Swift), Android(Kotlin)でソースは別 ● デプロイは手動

Slide 24

Slide 24 text

（悩み） App Store Connectへのアップロードが遅いので、(20分ぐらい) StagingアプリはApp Distributionへのアップロードに変えたい。 4. 開発/リリース

Slide 25

Slide 25 text

CS, プロダクト, セールスだれもがデータ検証できるように（データ民主化） ● CS リリースした機能が使われているかどうか ● プロダクト Crashしていないか、どこがオーバーヘッドになっているか（一応CrashLyticsも入れているが、MixPanelでもチェックしている） ● セールス担当顧客の動き、売上をチェック 5. リリース後検証 MixPanel: 簡単に時系列分析ができる。クラッシュも把握できる Metabase: SQL知らなくてもデータ分析できる

Slide 26

Slide 26 text

5. リリース後検証 Before ● スプレッドシートで管理 ○ リアルタイム性がない ○ みづらい After ● Metabaseで管理 ○ グラフでわかりやすく ○ 開きやすい、共有しやすい

Slide 27

Slide 27 text

5. リリース後検証全員で同じダッシュボードを毎日見れるグラフを伸ばすモチベーションが生まれる

Slide 28

Slide 28 text

ユーザーに素早く価値を届けるためにUUUOがしていることまとめ ● いかにはずれのないところで機能を作るように動くかプロトタイプ検証、ユーザー理解をして、極力無駄なものは作らない ● 検証しやすい環境を作る ● リリースプロセスは自動化する ● 機能の成功、失敗にいかにはやく気づけるか（検証・データの民主化）

Slide 29

Slide 29 text

一皮むけた？自分は開発特化型のエンジニアでしたが、使われないプロダクトを作ってしまった反省からプロダクトを成功させることのできるエンジニアになりたいと思った。 UUUOに入ってからデザインスプリントの考え方、プロトタイプ検証のやり方を学んだ。

Slide 30

Slide 30 text

一皮むけた？ Before ● 使われないものに長時間かけてコードを書く After ● コードを書く前のプロセスに時間をかけ、確信のあるものだけにコードを書く(そうでないと怖くてコードがかけない） ● コードを書くまでのプロセスは長いが、無駄が減るので結果として高速になる ● OSSやツールなど利用して極力書かない

Slide 31

Slide 31 text

ご清聴ありがとうございました。