Tweet
Tweet

Slide 1

Slide 1 text

プロダクトドリブンにす るために行った技術投資 #CTO_PM kotamat 1

Slide 2

Slide 2 text

自己紹介 2017/4からROXXにCTOとしてジョイ ン サーバー、インフラ側のエンジニア セキュリティとか採用広報とか開発に関 わること全般やってきた 2021/10からbc PdMをやり始める 2

Slide 3

Slide 3 text

3

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

5

Slide 6

Slide 6 text

6

Slide 7

Slide 7 text

7

Slide 8

Slide 8 text

8

Slide 9

Slide 9 text

9

Slide 10

Slide 10 text

背景 10

Slide 11

Slide 11 text

前回の登壇で話したこと CTOがPMとして稼働することになった背景とその解決について話した Biz vs Devの構造 解決にはプロダクト中心に考える必要 色々前提整えてPMスタート CTOだとその前提を用意するための技術投資がやりやすい 今日はその前提を容易するための技術投資について深ぼる 11

Slide 12

Slide 12 text

プロダクトマネジメントしやすい環境の整備 技術投資 データ基盤の整理 高速に検証できる環境の整備 技術投資じゃない PRDの雛形作成 12

Slide 13

Slide 13 text

データ基盤の整理 13

Slide 14

Slide 14 text

データ基盤の整理の背景 14

Slide 15

Slide 15 text

PLO本にもあるように、データインフォームドな文化はプロダクト中心に考える上で非常に 大事 かつてプロダクトチームは、直感と専門知識だけを頼りにせざるを得なかった。しかし プロダクト主導型になるためには企業は限りなく顧客との距離を縮めなければならな い。つまりプロダクトチームはデータに執着するべきだ。さらに言えばデータに基づい てプロダクトに変更を加える意志を持ちデータがない時には実験を行いデータを収集す る必要がある。 15

Slide 16

Slide 16 text

データソースの分散という課題 事業部で見ているデータ Salesforce RDB Google Analytics それぞれに対して直接BIのようなダッシュボード機構を作っているだけ 「顧客一人がどういうジャーニーで成長したのか」を図るのは非常に難しい 16

Slide 17

Slide 17 text

結果自律的な意思決定が困難に 事業部の状況を伝えるためのデータが、毎回資料を作成するたびに属人的に吐き出され ている状態 事業責任者並びに各部署が「自分が裏付けたいデータ」だけをピックし資料にまとめて 展開しているため、全体感がわからなかった 経営会議ではそのボトルネックの認識合わせに殆どの時間が割かれてしまい、具体的な アクションへの落とし込みが感覚ベースで決まっていた 17

Slide 18

Slide 18 text

やったこと 18

Slide 19

Slide 19 text

選定基準 1. 非エンジニアの日本人でも画面ポチポチして簡単に構成を作ることができるか 2. ROXX社内で、使っているツールに連携できるか 3. エラーハンドリングができるかどうか 4. スキーマ変更に 耐えられるかどうか 5. 定期実行の自由度 19

Slide 20

Slide 20 text

構築したデータ基盤 20

Slide 21

Slide 21 text

21

Slide 22

Slide 22 text

22

Slide 23

Slide 23 text

データ基盤は運用軌道に乗った このダッシュボードは「非エンジニア」が作成。非エンジニアでも構築できることが証 明された 安全なデータということが保証されているので、誰でも気軽に触れるようになった 23

Slide 24

Slide 24 text

これからの課題 データソースの種類をもっと増やし、様々な角度からデータを見れるように ダッシュボードだけではなく、施策ごとにデータによる検証が回るようにする PMのデータリテラシーの向上 データ抽出方法の型化 ダッシュボードを充実させ、あらゆる意思決定の中心に据える データインフォームドな文化へ 24

Slide 25

Slide 25 text

高速に検証できる環境の整備 25

Slide 26

Slide 26 text

検証プロセスのジレンマ 検証初期段階では、使われる機能 かどうかわからない そのままリリースすると負債 化する 検証をすすめるには動くものを触 って貰う必要がある →動く環境を用意はするが、負債化しな いような工夫をしないといけない 26

Slide 27

Slide 27 text

一般的なジレンマの解消方法 紙芝居（Figmaなど）でUIを見せ、FBをもらう タスク代替型の機能については検証できるが ユーザが作るコンテンツが主要機能においては効果が薄い ノーコード系アプリで検証する サービス立ち上がり期においてはカジュアルに検証ができるが サービスが既に稼働している状態では連携が難しい →back checkでは施策によってはうまく噛み合わない 27

Slide 28

Slide 28 text

プルリクごとに環境を立ち上げ検証できるように 28

Slide 29

Slide 29 text

29

Slide 30

Slide 30 text

GitHubのPRで環境立ち上げ 30

Slide 31

Slide 31 text

GitHubのPRで環境立ち上げ 施策が本番反映用トランクにマージされる前に環境を立ち上げる 検証環境は /preview するときのコマンドによって公開範囲を切り替える 開発者用 利用前企業展開用 顧客展開用 環境はPRごとに疎結合な環境が実現 URLを展開するだけで施策の検証が可能 他の環境を気にすることなく環境を立ち上げられる 施策ごとにユーザが実際に触れる環境を用意することができた。 31

Slide 32

Slide 32 text

検証環境の課題感 本番環境に慣れているユーザにとっては、URLが違う環境にアクセスすることに抵抗が ある フィーチャーフラグなどを活用し、本番反映と負債化のバランスを取る別の手段が 必要に 32

Slide 33

Slide 33 text

まとめ まずプロダクトマネジメントを実施する上でベースとなるものを作ることができた。 それぞれまだまだ課題はあるものの、「なにを改善すればいいか」が明確になったので アクションはシンプルに PdMというロールではその後の改善投資は難しいが、CTOとして改善施策を回していく ことができている。 33

Slide 34

Slide 34 text

いつもの 絶賛採用活動中です！ https://herp.careers/v1/scouter/requisition-groups/29e05866-7937-49e3- baed-9fee536e9ed7 EM / バックエンドエンジニア /　フロントエンドエンジニア / デザイナー この勉強会の登壇者も募集！ 34