プロダクト価値を、 チームが使える判断軸に変える

Transcript

1. プロダクト価値を、 チームが使える判断軸に変える Product Engineer Session #10
2. ⾃⼰紹介 2021年 株式会社viviON ⼊社 ⼤学卒業後、組み込みソフトやゲーム開発を経験し、現在 はモバイルアプリを主軸としたプロダクト開発に従事。 「常に挑戦し続ける」をモットーに、新たな技術や領域へ 精⼒的に取り組んでいます。 趣味は10年以上続けているエレキギターです。⾳楽好きが ⾼じて同⼈⾳楽に出会い、そこから同⼈作品の⾯⽩さ‧ク リエイターの熱量に惹かれてきました。 北原 智義（Tomoyoshi Kitahara） ソフトウェアエンジニア
3. 私の働き⽅：ユーザー価値から実装までを往復する 課題設定‧指標設計‧実装‧検証まで、⼀連のプロダクト開発に関わる Core 会社のミッション‧事業⽬標 Why 誰の、どんな課題を解くのか What どんな体験を届け、何を優先するのか Why‧What‧How を往復しながら開発 How どう設計‧実装し、効果を検証するのか
4. 会社紹介 株式会社viviON ユーザーとクリエイターが楽しみながら、幸せに⽣きていける社会にする。 事業内容 主なサービス 秋葉原から世界へ。総合⼆次元コンテンツサービスを展開。 電⼦コミック「comipo」、クリエイター応援 クリエイター向け‧ユーザー向けの両⾯で、すべての⼆次元 「GENSEKI」、翻訳「みんなで翻訳」、VTuberプロダク 好きを幸せにする事業を⾏う。 ション（あおぎり⾼校∕ゆうぎり⾼校）など多数。 WE'RE HIRING ⼀緒に働く仲間を募集中です 採⽤ページはこちら
6. 今⽇伝えたいこと 判断軸を仕組み化 すると、 チームが プロダクト価値を継続的に改善できる
7. 01 判断できないチームで起きていたこと 02 プロダクト価値を、共通の判断軸に変える
8. あなたのプロダクトは、いま どれだけ価値提供ができていますか？
9. 私たちのチームには、答えがありませんでした 80% 20% バグ対応 プロダクト開発 開発時間の80%がバグ対応 に消え、 プロダクト開発は20%しかできていなかった。
10. ユーザーからのお問い合わせも、殺到していた
11. ⽬指すのは、開発時間の80%をプロダクト開発に使える状態 80% 20% バグ対応 プロダクト開発 開発時間の80%をプロダクト開発に使えること。
12. 原因は、チームで共有された判断軸がなかった 優先度が⼈による 開始と終了を決められない 次の注⼒先を決められない 個⼈の判断⼒ではなく、優先順位と終了条件を決める共通基準がありませんでした。
13. 01 判断できないチームで起きていたこと 02 プロダクト価値を、共通の判断軸に変える
14. 判断軸を仕組みにする、4つの要素 守りたい プロダクト価値 現状を測る指標 ⽬指す⽬標⽔準 定期確認と対応ルール 何を守るのかを⾔葉にして、 価値を守れているかを、 どこまでやれば良いかの いつ確認し、悪化したら チームの共通認識にする ログで観測できるようにする 基準を数字で決める 何をするかを決めておく
15. 判断軸を仕組みにする、4つの要素 守りたい プロダクト価値 現状を測る指標 ⽬指す⽬標⽔準 定期確認と対応ルール 何を守るのかを⾔葉にして、 価値を守れているかを、 どこまでやれば良いかの いつ確認し、悪化したら チームの共通認識にする ログで観測できるようにする 基準を数字で決める 何をするかを決めておく
16. ユーザーは、アプリを開いてから どの瞬間に価値を感じているのか？
17. ユーザー体験をチームで発散し、まとめた Breadth = 幅‧広がり 新規DL数 シェアからの流⼊数 タッチポイント増加 どれだけ多くのユーザーが アクティブに利⽤しているか？ Depth = 深さ ユーザーが訪問時に体験する関与の深さは？ Frequency = 頻度 ⾳声作品との出会いの強化 再⽣率 継続⾳声再⽣時間 シェアした数 安定化 ⾳声プレイヤーの磨き込み 1⽇の⾳声再⽣回数 7⽇以内の再訪率 通知の許諾率 ユーザーがどれぐらい頻繁にきているか？ Efficiency = 効率 タスク完了までの速度は？ ユーザーが価値にすぐ到達できるか？ 起動から再⽣までの時間 クラッシュ率 安定化 施策連携の強化
18. DLsite Soundに 初回再生後、 7日以内に アプリを起動して 作品を再 生した ユーザー数 定着することで もっと音声作品が 楽しめるようになり、 LTVも 上がる
19. 技術問題を、守るべきプロダクト価値の問題として捉え直した 技術問題としての捉え⽅ 「バックグラウンド再⽣に不具合がある」。個別のエラーを修正する技術タスクとして捉えていた。 捉え直し プロダクト価値からの捉え⽅ 守る価値は「ユーザーが作品を途切れず聴き続けられること 」。 バックグラウンド再⽣の不具合を、その価値を損なう問題として捉え直した。 ユーザー価値への影響を基準に、対応の優先度を議論できるようになった
20. 判断軸を仕組みにする、4つの要素 守りたい プロダクト価値 現状を測る指標 ⽬指す⽬標⽔準 定期確認と対応ルール 何を守るのかを⾔葉にして、 価値を守れているかを、 どこまでやれば良いかの いつ確認し、悪化したら チームの共通認識にする ログで観測できるようにする 基準を数字で決める 何をするかを決めておく
21. 7⽇以内の来訪 アプリを開いた後にハマって使い続けてもらう 体験の阻害要因削除 起動から再⽣ までの時間 クラッシュ率 唯⼀無⼆の視聴体験 再⽣率 独⾃機能の 継続⾳声 利⽤数 再⽣時間
22. 再⽣品質を数値化し、改善対象を判断できる状態にした STEP 1 計測ログの追加 初回再⽣と継続再⽣の成功‧失敗を記録するログをアプリに追加した。 STEP 2 成功と失敗の定義 再⽣の成功‧失敗を判定する条件を定義し、チームの共通基準にした。 STEP 3 再⽣成功率として可視化 再⽣成功率 ＝ 成功数 ÷（成功数＋失敗数）として可視化し、継続的に確認できる状態にした。 感覚ではなく数値で、OS別‧初回∕継続別の問題を⽐較できるようになった
23. 判断軸を仕組みにする、4つの要素 守りたい プロダクト価値 現状を測る指標 ⽬指す⽬標⽔準 定期確認と対応ルール 何を守るのかを⾔葉にして、 価値を守れているかを、 どこまでやれば良いかの いつ確認し、悪化したら チームの共通認識にする ログで観測できるようにする 基準を数字で決める 何をするかを決めておく
24. 測ってみると、iOSの初回再⽣率はAndroidより約10%低かった version iOS 初回 iOS 継続 Android 初回 Android 継続 2.14.2 87.9% (86,793) 92.4% (101,277) 97.6% (49,115) 98.0% (64,840) 成功率 = started / (started + no_sound)、括弧内は試⾏数
25. 再⽣開始成功率 バージョン別⽐較 version iOS 初回 iOS 継続 Android 初回 Android 継続 2.14.2 87.9% (86,793) 92.4% (101,277) 97.6% (49,115) 98.0% (64,840) 2.15.0 91.2% (18,178) 95.7% (24,017) 97.9% (6,696) 98.7% (9,331) 2.15.1 90.5% (98,449) 95.4% (134,961) 98.0% (52,402) 98.7% (77,545) 2.15.2 91.4% (94,109) 96.8% (130,398) 98.1% (46,559) 98.8% (68,836) 2.15.3 91.5% (134,357) 96.9% (186,646) 98.3% (69,502) 98.8% (105,208) 2.15.4 91.3% (39,490) 96.9% (54,697) 98.0% (20,681) 98.7% (30,664) 2.15.5 91.2% (79,952) 96.9% (109,323) 98.1% (42,493) 98.8% (62,804) 2.16.0 91.2% (115,970) 97.0% (163,458) 98.3% (61,970) 98.8% (92,008) 2.16.1 92.1% (15,849) 97.2% (19,266) 98.8% (9,614) 98.7% (13,574) 成功率 = started / (started + no_sound)、括弧内は試⾏数
26. 再⽣成功率90%を、リソース配分を切り替える基準にした 終了条件がなかった 再⽣品質を改善する必要があることは分かっていた。 しかし、どこまで改善すれば通常のプロダクト開発に戻ってよいのか、その終了条件がなかった。 理想は99%。ただし全リソースは注げない 品質としては100%に近い状態が理想で、当初は全体の再⽣開始成功率99%を⽬標にした。 ⼀⽅で、99%に到達するまで全リソースを投⼊し続けると、 ユーザーへ新しい価値を届ける開発が⽌まってしまう。 99%と90%の役割を分けた 99%は⽬指したい品質⽔準。 90%は 品質改善を優先するか、プロダクト開発へ移るかを切り替える、運⽤上の判断基準 として置いた。
27. 判断軸を仕組みにする、4つの要素 守りたい プロダクト価値 現状を測る指標 ⽬指す⽬標⽔準 定期確認と対応ルール 何を守るのかを⾔葉にして、 価値を守れているかを、 どこまでやれば良いかの いつ確認し、悪化したら チームの共通認識にする ログで観測できるようにする 基準を数字で決める 何をするかを決めておく
28. 90%を、完了条件と再対応条件にした 改善を始める判断 改善を終える判断 再⽣率が90%に届いていなければ、 90%まで回復すれば、完了と判断して次へ 再⽣安定化を優先 する 進む
29. 90%を下回ったら、Slackに⾃動で通知される 再生率監視 Bot ⚠ iOS 初回再生率が 90%を下回りました 直近の再生率がしきい値 90% を下回っています。再対応条件に該当するため、対応 を検討してください。 誰かが意識して⾒に⾏かなくても、悪化をチームが検知できる
30. 1か⽉の安定実績を根拠に、通常のプロダクト開発へ移⾏ 品質指標 iOS初回再⽣成功率は91.0%となり、基準の90%を達成 。 Android初回‧継続、iOS継続を含む 4つの指標すべてが、1か⽉を通して基準を達成した。 ユーザー影響 再⽣関連の問い合わせ状況も改善し、 ユーザー影響の⾯からも「再⽣安定」を達成した と判断した。 継続的な検知 1か⽉のアラートは0回 。 今後90%を下回った場合も、Slackで⾃動検知し、品質改善を再び優先できる。 判断 品質の安定と再対応の仕組みを確認できたため、品質を監視しながら 通常のプロダクト開発へ移⾏ した
31. まとめ 4つの要素が、プロダクト価値を判断軸に変えた 守りたい プロダクト価値 現状を測る指標 ⽬指す⽬標⽔準 定期確認と対応ルール 何を守るのかを⾔葉にして、 価値を守れているかを、 どこまでやれば良いかの いつ確認し、悪化したら チームの共通認識にする ログで観測できるようにする 基準を数字で決める 何をするかを決めておく
32. 結果 結果 開発時間の80%を、プロダクト開発にあてられるようになった 80% 20% バグ対応 プロダクト開発
33. 実施したこと 判断軸は、数値に応じた⾏動まで決めて初めて仕組みになる 1 守るべきプロダクト価値を定義 2 コア価値を、計測可能な指標へ分解 3 ログを実装し、再⽣成功率を可視化 4 90%を運⽤基準に、判断と再対応を仕組み化 チームの迷いがなくなり、品質を維持しながら次の価値開発へ進めるようになった
34. 判断軸ができ、チームの向きが揃った 次の注⼒先をチームで決められる！
35. ご清聴ありがとうございました