CTOがなぜPMをやりはじめたのか / Why did the CTO start doing PM

Transcript

1. CTOがなぜPMをやりは じめることにしたのか #CTO_PM kotamat 1
2. 自己紹介 2017/4からROXXにCTOとしてジョイ ン サーバー、インフラ側のエンジニア セキュリティとか採用広報とか開発に関 わること全般やってきた 2021/10からbc PdMをやり始める 2
4. PMやるまで 4
5. 2~3年見据えて絶対にやったほうが良いと思うことを注力 エンジニア採用広報 広報戦略を打ち出し、多角的に情報発信などを行う 勉強会、ブログ、登壇、執筆、etc... 詳細はこちら 情報セキュリティーの強化 両事業ともに機微な個人情報を扱っており、事業展開を考えても客観的に安心安全 なプロダクトであることが競争優位になると考えた ISMS/Pマークの取得、インフラ整備、情シス組成 その他新規事業の開発や技術支援とか諸々 5
6. 一通りやりきった上でDevOpsをやり始める DevOpsへの投資はCTOっぽい 高頻度のリリース、短いリードタイムとか憧れる 「DevOps投資しましたー」という記事とか見てた 開発スピード上げたいなと思っていて、課題感的にも良さそうに思えていた 6
7. 実際どうだったか 3ヶ月でリリース頻度は倍に 一方で「ユーザへの価値提供スピード」が上がった気がしない →もっと投資するべきことがあるのでは 7
8. 発生していた問題 Biz プロダクトの価値が上がっていない様に 感じる なんとなく開発スピードが遅い様に感じ る 使われないもの作ってるなーと感じる 今それよりも大事な機能作って欲しいな と感じる Dev なんのために作ってるのかわからないと 感じる 方針がコロコロ変わって価値が蓄積され ないと感じる やることが決まって降りてくるので社内 受託っぽく感じる 今着手できるのはこの施策なのでこれを やるしか無いと思って開発してる 8
9. いわゆる Biz vs Devの構造が発生していた 9
10. 色々と調べていくと、BizとDevの間にPMのレイヤーが必要であること がわかった ※ 詳細はプロダクトを中心に考えるとはを見てください 10
11. 他にやる人いないし自分がやるしか無いと思ってやり始める もし他にできる人がいるならとっくに解決されているはず PLを志向する人が多いなかで、その人達にプロダクト志向に変わってもらうより、自分 が変わったほうが早いと思った 11
12. PMになってやったこと 12
13. まずは書籍を読みまくる ここ1,2年で大量のPM本、勉強会がでてきた プロダクトマネジメントのすべて PLG本、PLO本 ビルドトラップ本 noteやコミュニティー活動など 複数の情報源に触れることで「何となくこんな感じだろう」という感覚を得る 13
14. 今の組織に当てはめて言語化する 「NSMはなにか」「NSM達成のためのキーファクターはどこか」「そこを攻めるための障壁 は？」「まず何を機能提供すべきか」「結果どういう組織状態になるべきか」を記載 14
15. ユーザヒアリング ジョブ理論ベースのジョブの整理 上記言語化過程で選定したターゲット企業へのヒアリング ターゲット企業のうちうまく行っているところ、行っていないところの差分を明確化 →中期開発ロードマップのいとぐちに 15
16. プロダクトマネジメントしやすい環境の整備 データ基盤の整理 高速に検証できる環境の整備 PRDの雛形作成 16
17. データ基盤の整理 今までは部署ごとにデータの格納場所がバラバラだった 営業： Salesforce CS: スプレッドシート 開発: Metabase 顧客のエコノミクス全体を見るにはデータ基盤の整理が必要 BQ + troccoでのデータ基盤の整理 詳しくはこちらを見てね 17
18. 高速に検証できる環境の整備 開始当時は「なにがプロダクトの資産になるような施策か」が明確なものが少なかった 不確実性が高いまま本番環境にデプロイしてしまうと負債化してしまう恐れ プルリクごとに検証環境を立ち上げられるようにし、高速なFBを実現 18
19. PRDの雛形 開始当時はJIRAにそのまま案件を記載。必要であればesaにその内容を「開発にわかる ように」記載 結果リリース直後に「思っていたのと違う」みたいな現象が発生 PRDを「事業部が誰でもコメントFBできる環境」と位置づけ、イケてるPRDのテンプレ ートを拝借し使った Google Docsを使うことで、テキストごとにFBをできるようにし、インタラクティブな PRD醸成基盤を構築 19
20. CTOがPMをやるメリットデメリット 20
21. メリット 21
22. 初手の動き出しが早い PMはエンジニア以上に採用が難しい。 CTOであればやるためのリソース確保がしやすい 今後の採用するときの判断基準も作れる 22
23. 不確実性の解消方法のレパートリーが多い よくあるのがFigmaで紙芝居からやるというものがあるが、同様のものがサクッと作れ るのであれば直接コードを書いたほうが早いケースも有る。 最近だとノーコードアプリだったり、スプレッドシートの関数とかでも一定検証は可能 当然動く状態のもののほうが良いFBを得られるので、コストが変わらないのであれば動 作環境を提供したほうが良い 23
24. プロダクトマネジメントに必要な環境を用意しやすい データインフォームドな意思決定が必要→データ基盤を作っちゃえ 機械学習で顧客インサイトを上げられるか検証したい→AutoMLとかざっとつないで検証 してみる なるべく本番環境を汚さずに動く環境で検証したい→GAを使ったベータ環境を作っちゃ う 24
25. 施策考案時のリスク洗い出しがやりやすい システム上こういうところにコストかかりやすそう 例外ケースはどういったところがありそうか、それをカバーできる要件はなにか 例外ケースは検証タイミングで本当に考慮すべきか 25
26. デメリット 26
27. どうしてもWhy/What/Howを混在しやすい 要望を聞いたときに「あ、こうやれば実現できそう」というのが想起できていしまう。 いかにWhyWhatに集中し、Howを開発チームが考えられるようにするかは強い意思が 必要 27
28. ボトルネックになりやすい CTOだとPMの役割だけではなく他のことも責務が発生する 採用評価などの人事系 経営としての役割 技術課題に対する考案等 やるときには「何を切り捨てるのか」を明確にし、適切に引き継がないと何もできなく なる 28
29. まとめ 本質的な課題を解決するにはCTOがPMをやらないといけないと考えてPMをやり始めた 便利な情報がたくさんあるので、CTOがPMをやるハードルはかなり下がっている CTOという特性を使って「強くてニューゲーム」ができる領域はある ただ兼務は健全じゃないので早く引き継ごう（現在引き継ぎ中） 29
30. いつもの 絶賛採用活動中です！ https://herp.careers/v1/scouter/requisition-groups/29e05866-7937-49e3- baed-9fee536e9ed7 EM / バックエンドエンジニア /　フロントエンドエンジニア / デザイナー この勉強会の登壇者も募集！ 30