CTOがPMをやる事になった背景とそのための準備、これからやっていくこと
この記事は「プロダクトづくりのための挑戦とその成功・失敗談を綴るアドベントカレンダー powered by プロダクト筋トレ」の11日目の記事です。
ROXXにCTOとして入社して4年半ほど、今まで技術と名のつくものは一通りやってきたのだが、「技術」にフォーカスし続けることの限界を感じ始めたため、2021年10月ころからPMとしての活動を徐々に増やしてきている。今回はそこにいたった背景と、今後やっていこうとしていることについて述べようと思う。
今までやってきたこと
未経験CTOとして入社してからは、強みであったバックエンド、インフラを中心にフルスタックエンジニアをやりつつ、開発系職種の採用全般からback checkの技術責任者、情シスの立ち上げ、移転・社名変更、評価制度の構築など技術に関連するもので大事そうなものは色々とやってきた。
特にROXXは、採用企業と人材紹介会社を繋ぐ、求人プラットフォーム『agent bank』（https://agent-bank.com/）、オンラインリファレンスチェックサービス『back check』( https://backcheck.jp )ともに機微な情報を扱うプロダクトを運営している手前、情報の取り扱いがとても大事になると踏み、ISMSやPマークの取得といった会社全体の情報セキュリティーのマネジメントプロセス構築だけではなく、インフラからアプリケーション層全体に関連したセキュリティ対策に力を入れてきた。お陰様でセキュリティ懸念による失注は観測する範囲で発生しておらず、コンプライアンスに厳しい企業様にもサービス導入いただく状況になった。
情シス部門、backcheckの開発責任者、SREと自分が持っているタスクをそれぞれ優秀なメンバーに引き継ぐことができ、やっと自転車操業的に目の前のタスクに追われる状況が改善されつつある状況となり、腰を据えて「この会社が技術の面でどうやって勝っていくか」に向き合える状況になってきた。
DevOpsにチャレンジしてみてわかった投資するべきこと
CTOが技術投資をするといえばDevOpsがよく取りだたされるものかなと思う。事実「LeanとDevOpsの科学」ではパフォーマンスの高い企業はそうではない企業に比べて
- コードのデプロイ頻度は46倍
- コミットからデプロイまでのリードタイムは1/440
- 平均復旧時間は1/170
- 変更失敗率は1/5
(2017年時点)
という結果が科学的に出ており、パフォーマンスの高い企業を目指すにあたって避けては通れないものなのかなと思っている。
2021年4月~7月にかけて、上記観点のもとagent bank、back checkともにDevOpsに投資をしてみたところagent bankは2倍ほどのデプロイ頻度の達成、back checkはデプロイ頻度向上のための土台作りができたというところで「DevOpsに向けてチームが一眼となって取り組むことで結果は出る」ということがわかってきた。また、この結果はチームとして課題に向き合った結果であり、副次的にチーム力の高さを実感することができた貴重な体験だった。
一方デプロイが高頻度になっただけでは顧客への提供価値の総量が増えた実感は湧いておらず、このままDevOpsに投資し続けても効果を感じられるイメージがわかなかった。DevOpsへの貢献をしてくれたメンバーもそのような認識だったようで、この投資とは異なる投資をしなければ事業としてプロダクト力を上げていくことが難しいと実感した。
ほぼそのタイミングにて、ユニコーン企業のひみつなどの書籍や株式会社レクターの広木大地さんに技術顧問に入っていただき、事業状況や悩みなどを壁打ちしていく中でプロダクトマネジメントに投資をしていく必要があるということが次第にわかってきた。
プロダクトマネジメント=PL思考と開発生産性向上の間
色々と調べていく中で「技術を財務で表現する」という考え方が、ROXXの課題を的確に捉えられているなと思ったので、引用してみる。PLは損益計算書、BSは貸借対照表の概念に近く、GPは開発の生産性や組織力といったものと考える。製造の観点でいうと、ものを作る工場に投資をするとBSの資産が上がり、それが時間経過とともに物が売れてくるので売上となり、利益となっていくといったイメージだろうか。工場には様々な製造の機械があり、それらをより円滑に稼働できるようにするのがGPの投資と考えると良いかもしれない。つまりユーザの価値としては右に行くほど将来に返ってくる価値になり、左は目先の価値と言えるかなと思う。
投資家や経営陣は特に事業計画（PL）に対してどのように進捗しているのかが大きな論点であり、ROXXはいかにそのPLを達成するのかというPL達成能力が高い。これはROXXだけではなく投資家の方々からも評価頂いているところであり、ちゃんと振り返り行動変容に落とすという非常に泥臭いが常に改善するというBizメンバーの日々の働きかけによってこういった能力が組織としてついてきたのかなと理解している。
GPに関しては前述の通り、開発チーム一丸となってこの生産性に取り組むことによって向上していけるイメージが持てた。ここに投資し続けることにより「ユーザに短期間でより多くのものを届ける」ということができるイメージが湧いたと言っても良いかもしれない。
一方前述の通り、ここを向上させたとしても顧客価値が向上しているイメージがわかなかった。これはB/Sの観点での価値向上のアプローチが欠損していたためである。実際に作ったものがユーザ価値としてどのように反映されるのか、それがどのようにして将来的に売上につながっていくのかといったところに具体的な共通認識を持たずに事業運営を続けているために、どうしても短期的な課題解決にフォーカスされ、結果開発がアウトプットするものの価値検証が難しい状況が発生していた。
調べていくと、ここにはエンジニアリングとはまた違った能力が必要だということがわかってきた。プロダクトマネジメントのすべてやその他プロダクトマネジメントに関する有益な書籍を読んでいくと、かなり手広い能力が要求されるようで、これはそのままCTO業に注力しながらでは難しいなという印象を持ったので、CTO業のタスクを少しずつ剥がしながら10月よりちょっとずつback check事業部のPMをやり始めているというのが現在に至った背景である。
所信表明的なもの
自分がPMとして今後活動する上で、下記3点はコアの考えに置きながら活動していこうと考えている。
プロダクトマネジメントのノウハウを蓄積する
ROXXには明確にPMとして単独で動いている人は各事業部の本体にはいない（開発チームを見ているメンバーが開発要件を考えるなどの兼任はある）。故にここの動きに関しての会社の中でのノウハウ蓄積があまりないというのが正直なところである。書籍などには様々な知見はあるものの、やはり取り扱われている内容は抽象度が高く、自社のプロダクトにどのように生かされるのか、生かされないのかは実践をしてみなければわからない。そういった中で自分がそこに取り組んでいくことによって、成功・失敗関わらずノウハウとして蓄積していくことで、もし後任のPMが出てきたとしてもその人に対する期待値や、その人がどのようにたち振る舞うべきかの解像度が上がった状態で引き継げるのではないかと思っている。
プロダクトに必要なことはとにかくやってみる
今までは開発チームを見るという視点や、セキュリティー・法令・インフラなどの守りの部分をかなり重点的に見てきた。ただ今後はプロダクトマネジメントをしていくなかで、プロダクトをコアの考えに置きながら、Bizチーム含めて事業部全体を巻き込んで動かしていかなければならない。仮にそれが開発要件に落ちなさそうなものだったとしても、顧客からすれば価値向上につながるのであればプロダクトにとって必要なものであるはずなので、選り好みせずに主体的に解決に向けて動いていく必要があると考えている。当然自分が割けるリソースには限りがあるので、全部やるというわけではなく、顧客課題として重要なものを選り好みせずやっていくという方針で考えている。
意思決定に納得感をもたせる
プロダクトマネジメントをする上で最も大事なことは意思決定すること（ないしは意思決定をサポートすること）になるはずである。事業部にはたくさんの方が関わっていただいている中で、各々この事業に対しては色々な期待をしていただいているのがひしひしと感じられる。そういった中で次何をやっていくのかというのは納得感のある形に持っていかないと、後々のハレーションや期待する効果につながらない結果に結びついてしまう。客観性のある情報や、納得感の醸成のためのアプローチを行うことを意識して動いていきたい。
プロダクトマネジメントをする上で事前に準備したこと
いろんなPMに話を聞きに行って輪郭を掴んでいった
PMは本当に初心者だったので、右も左もわからない状態だった。書籍で得られる情報もあるが、やはり血肉となっている生の声を聞きに行くことのほうが手触り感がある情報が得られてとても良かった。PMの皆さんは面識もない状態でいきなりDMを送らせていただいてもこころよくお話伺うお時間をいただけて本当に素晴らしい方々だなと思った。ご協力頂いた方々にはとても感謝している。自分なりにノウハウを蓄積し、何かしらの形でお返しできればなと思っている。
データ基盤の整理
プロダクトマネジメントにおいて、絶対に語られるものはデータの活用である。PMは人事権を持たずして影響力を発揮する必要があるので、客観性のある情報が必要であり、それはデータによって補完される。 今までもmetabaseを使ってプロダクトに格納されているデータの可視化は行ってきたが、今後事業部全体のデータをもとに意思決定をしていかないといけないと考えていく中で営業活動のデータやマーケ活動のデータ等が必要になってくる。
AWS上でプロダクトを運用しているが、データ基盤に使うのであればBigQueryのほうが扱いやすいということで、BigQueryをベースとしたデータ基盤を構築した。
データ基盤をBQに移すことによってすでに下記のメリットを享受できている。
MySQLでは表現できないクエリ表現（WITH句やその他統計処理の関数）が使える
多少雑なクエリを書いても一瞬で返却されるので、得たい情報を得ることに集中できる
BQからスプレッドシートやデータポータルへの吐き出しが一気通貫しているため、データの検証がしやすい
GoogleWorkspaceのIDと連携できるので、必要な人に必要な権限を付与しやすい。
GCPのエコシステムに乗ることができるので、例えばnotebooksでpandas profilingをちょっと実行してみる等、データサイエンスで使われる便利な分析環境を簡単に立ち上げられる。
今後はデータ分析を事業部全体でできるようにしていきたいので、この基盤を使って事業部内で色々いじってみる時間を設けたり等、データ探索の文化を強化していきたい。
考えていることを発信する環境の構築
PMとしての活動のノウハウを蓄積していきたいという方針を掲げたが、ここには日々どういうことに躓いているのかだったり何がわかったのかなどを発信していくことが大事だと考えている。slackチャンネルを開設し、そこにPMとしての学びを投稿していくことによって、具体的に何を考えているのかの情報の非対称性をなくしていくというのはもちろん、ストックする情報とすることによってノウハウ化することができると考えた。このチャンネルではPMの週報も展開しており、活動の経緯もわかるようにしている。
議論をしやすい場の構築
PM単独で何かを推進していくというのはほとんどなく、周りの人を巻き込みながら物事を進めていくことが多くなる。共通認識を取るための手段であれば色々試していこうというのをベースに考えつつ、下記は運用に乗ってきているので継続していきたい
Miroの開設。今まで開発チームだけで使用していたものを事業部全体でも使えるようにした。議論をしながら図にまとめていく過程を通じて共通認識を取るようにしている
ヒアリングフォーマットの用意。ユーザヒアリングをする上で事前に何を聞いておけばいいかをまとめるのに使用。担当CSに同席していただきヒアリングすることが多いので、事前に共通認識を取ることに使っている
PRDフォーマットの用意。具体的になにか開発案件を進めようとしたときに、「なんでこれやることになったんだっけ？」というのを発生させないよう、共通のフォーマットで記入するようにした。成熟度が上がっていけば不要になるものもあると思うが今現状はフルフルで用意している。
プロダクトとしてのNSMの設定
ちょうどPMになるタイミングが期の目標を設定するタイミングとかぶったおかげで、PL的な目標設定だけではなく、プロダクトが向かうべき指標=NSMの設定を行える良い機会だったので、シンプルに事業として向かいたい方向を達成している指標としてふさわしいであろう数値を設定し、全体目標に組み込むことを行った。
事業責任者からも目標の周知のタイミングでその数値の共有を頂いたため、組織へのインストールも容易であり、PMとしての活動一つ一つに対して何のためにやっているのかの後押しにすることができた。
これからやっていこうとしていること
現在様々な取り組みを行っている。具体的な開発内容に関しては述べることはできないが、仕組みとしての活動として下記は行っていきたいと思っている。
データを一緒に見てワチャワチャする会
データ基盤を作っただけではデータを見る文化は作られない。新データ基盤によりデータにリーチしやすくなったことを周知していくには実際にどうやってデータを見ていくのかを実演していくのが良いかなと考えている。そうしたときに、NSMに対しての深堀りの会など具体的にどういうデータをどう解析していきたいのかというお題をセットにメンバーに共有したところ殆どのメンバーに参加意思をいただくことができた。
こういった活動を通じてちょっとずつでもプロダクトに関わる数値とそれの因果関係に触れていくことで事業部全体で事業の解像度を上げ、今後の細かい意思決定にも活かせていけるのではないかと期待している。
高速に仮説検証をできる基盤の整備
ユーザの声を聞いている中で、課題が顕になってきているので、これからは解決策の検討を行っていく必要がある。通常であればデザインモックや紙芝居のようなものを使って検証していくケースも多いのかなと思うが、back checkの最大の価値は取得できるレポートの中身であり、そこに至るためのオペレーショナル・エクセレンスも当然大事ではあるものの、結局は企業が得たい情報が得られたかどうかが大事になってくると考えたときに、単なるデザインモックだけでは表現力に限界が出てくる。また事業に関わる登場人物が多いという都合上、自分の行動が自分が得たい価値に直結しないため、UIの壁打ちだけでは真の価値の検証にはならないという事業特性もはらんでいる。
ただ一方でプロダクションレディなコードを検証のたびに書いているのでは検証そのもののイテレーションが遅くなってしまう。検証は最小限にしつつ、プロダクトとしての品質も担保していきたいとなると今の環境のみではどうしても不足が発生してしまうというのが明確になってきた。
まだ技術的には模索中ではあるが、本番環境と同程度の環境でありつつ、本番環境とは疎の環境をビジネスロジックを書くだけで簡単に用意できるようにし、ユーザや社内メンバーへの壁打ちができる状況を作れないかと考えている。
今までも開発者体験を向上させるためのプレビュー環境は用意していたものの、それだけではなくユーザ価値検証まで広げていったというところが今回の大きな差分。
この環境自体は開発者体験の向上にも寄与できるような環境となる想定でもあるため、積極的に投資していきたい。
プロダクトマネジメントとして必要なことをもっとやっていく
前述の通り、プロダクトマネジメントの本や知見を読み漁っていくと本当に範囲が広く、ここまで行くとやりきれたという状況には全くたどり着けるイメージがしない。上記のように目の前の課題を潰していきつつも、中長期的な目線にたってやっていかなければならない共通認識の獲得や未来への投資ができる環境を作っていく必要があるが、それは段階を踏んで一つずつクリアしていきたいなと考えている。
最後に
今までは技術畑の人間として、特にインフラやサーバーサイドの技術に関心を寄せていた。今後はユーザに向き合い、ユーザにとって必要なものを見つけ提供していくという全く異なる活動をしていかなければならない。ただ個人的には「課題を定義し」「課題を解決していく」活動がエンジニアリングだと考えたときに、抽象度は違えど同じアプローチだなというのを日々感じている。今までの経験を活かし、アンラーニングしながらPMの活動も全うしていきたい。