プロダクトドリブンにするために行った技術投資 / tech investment for product driven

https://cto-pm.connpass.com/event/245506/
CTO兼PMがぶつかった壁とその乗り越え方 vol.2
で登壇した内容になります。

プロダクトドリブンな環境を作るために行った技術投資に関して話しました。

Transcript

1. プロダクトドリブンにす るために行った技術投資 #CTO_PM kotamat 1
2. 自己紹介 2017/4からROXXにCTOとしてジョイ ン サーバー、インフラ側のエンジニア セキュリティとか採用広報とか開発に関 わること全般やってきた 2021/10からbc PdMをやり始める 2
10. 背景 10
11. 前回の登壇で話したこと CTOがPMとして稼働することになった背景とその解決について話した Biz vs Devの構造 解決にはプロダクト中心に考える必要 色々前提整えてPMスタート CTOだとその前提を用意するための技術投資がやりやすい 今日はその前提を容易するための技術投資について深ぼる 11
12. プロダクトマネジメントしやすい環境の整備 技術投資 データ基盤の整理 高速に検証できる環境の整備 技術投資じゃない PRDの雛形作成 12
13. データ基盤の整理 13
14. データ基盤の整理の背景 14
15. PLO本にもあるように、データインフォームドな文化はプロダクト中心に考える上で非常に 大事 かつてプロダクトチームは、直感と専門知識だけを頼りにせざるを得なかった。しかし プロダクト主導型になるためには企業は限りなく顧客との距離を縮めなければならな い。つまりプロダクトチームはデータに執着するべきだ。さらに言えばデータに基づい てプロダクトに変更を加える意志を持ちデータがない時には実験を行いデータを収集す る必要がある。 15
16. データソースの分散という課題 事業部で見ているデータ Salesforce RDB Google Analytics それぞれに対して直接BIのようなダッシュボード機構を作っているだけ 「顧客一人がどういうジャーニーで成長したのか」を図るのは非常に難しい 16
17. 結果自律的な意思決定が困難に 事業部の状況を伝えるためのデータが、毎回資料を作成するたびに属人的に吐き出され ている状態 事業責任者並びに各部署が「自分が裏付けたいデータ」だけをピックし資料にまとめて 展開しているため、全体感がわからなかった 経営会議ではそのボトルネックの認識合わせに殆どの時間が割かれてしまい、具体的な アクションへの落とし込みが感覚ベースで決まっていた 17
18. やったこと 18
19. 選定基準 1. 非エンジニアの日本人でも画面ポチポチして簡単に構成を作ることができるか 2. ROXX社内で、使っているツールに連携できるか 3. エラーハンドリングができるかどうか 4. スキーマ変更に 耐えられるかどうか 5. 定期実行の自由度 19
20. 構築したデータ基盤 20
23. データ基盤は運用軌道に乗った このダッシュボードは「非エンジニア」が作成。非エンジニアでも構築できることが証 明された 安全なデータということが保証されているので、誰でも気軽に触れるようになった 23
24. これからの課題 データソースの種類をもっと増やし、様々な角度からデータを見れるように ダッシュボードだけではなく、施策ごとにデータによる検証が回るようにする PMのデータリテラシーの向上 データ抽出方法の型化 ダッシュボードを充実させ、あらゆる意思決定の中心に据える データインフォームドな文化へ 24
25. 高速に検証できる環境の整備 25
26. 検証プロセスのジレンマ 検証初期段階では、使われる機能 かどうかわからない そのままリリースすると負債 化する 検証をすすめるには動くものを触 って貰う必要がある →動く環境を用意はするが、負債化しな いような工夫をしないといけない 26
27. 一般的なジレンマの解消方法 紙芝居（Figmaなど）でUIを見せ、FBをもらう タスク代替型の機能については検証できるが ユーザが作るコンテンツが主要機能においては効果が薄い ノーコード系アプリで検証する サービス立ち上がり期においてはカジュアルに検証ができるが サービスが既に稼働している状態では連携が難しい →back checkでは施策によってはうまく噛み合わない 27
28. プルリクごとに環境を立ち上げ検証できるように 28
30. GitHubのPRで環境立ち上げ 30
31. GitHubのPRで環境立ち上げ 施策が本番反映用トランクにマージされる前に環境を立ち上げる 検証環境は /preview するときのコマンドによって公開範囲を切り替える 開発者用 利用前企業展開用 顧客展開用 環境はPRごとに疎結合な環境が実現 URLを展開するだけで施策の検証が可能 他の環境を気にすることなく環境を立ち上げられる 施策ごとにユーザが実際に触れる環境を用意することができた。 31
32. 検証環境の課題感 本番環境に慣れているユーザにとっては、URLが違う環境にアクセスすることに抵抗が ある フィーチャーフラグなどを活用し、本番反映と負債化のバランスを取る別の手段が 必要に 32
33. まとめ まずプロダクトマネジメントを実施する上でベースとなるものを作ることができた。 それぞれまだまだ課題はあるものの、「なにを改善すればいいか」が明確になったので アクションはシンプルに PdMというロールではその後の改善投資は難しいが、CTOとして改善施策を回していく ことができている。 33
34. いつもの 絶賛採用活動中です！ https://herp.careers/v1/scouter/requisition-groups/29e05866-7937-49e3- baed-9fee536e9ed7 EM / バックエンドエンジニア /　フロントエンドエンジニア / デザイナー この勉強会の登壇者も募集！ 34