自己紹介
松本宏太氏（以下、松本）：ROXXの松本と申します。今回は「プロダクトドリブンにするために行った技術投資」という内容で、比較的技術寄りの話をできればと思っています。
まず自己紹介です。2017年からCTOをやっていますが、入社した時はかなりサーバーサイド側の人間で、2021年10月ぐらいからPMをやらせてもらっている感じになっています。
2つのプロダクト紹介
弊社のプロダクトの説明をしたいと思います。HRテックのプロダクトを2つ提供しています。
1つが「agent bank」というもので、採用企業と人材紹介会社さんをつなぐデータベースを提供しています。
従来エージェントさんは、日本に非常にたくさんいらっしゃって、セブン-イレブンの店舗数以上に人材紹介の会社さんは実はいらっしゃいます。そうすると、1社あたり求人を持てる数、案件数がどうしても絞られてしまいます。
そうすると、転職者の方がエージェントさんに応募をしに来た時、相談をしに来た時に、紹介できる求人が少ないような話もあったりします。そうなると最終的には転職者さんの選択肢が狭まってしまうところがあると思いますが、求人のプラットフォームをエージェントさんに展開させていただき、何万件という求人に対して、候補者の方がアプライできる仕組みを提供させていただいている感じになっています。
特に支援が必要な、私は“低年収層”と呼んでいますが、そういった方々に人材紹介のご支援が行き届くようなサービスをやっていければと思っています。
従来、低年収層の方々は、なかなか人材紹介のサポートを受けられない方々ではありましたが、人材紹介の方々を支援していくことによって、日本全体のGDPの創出みたいなところにも寄与できるようなプロダクトを提供していければと思い、日々やっています。というのが「agent bank」になります。
もう1つは「back check」というプロダクトです。
こちらは面接や書類選考とかではわからないような、人が働いた時の定性的なものや信頼をデータ化して、ミスマッチを減らしていくようなものになっています。
採用されて実際に新しい職場で働くとなっても、やはり短期で離職される方というのは一定います。それは、選考段階での不十分な選考プロセスによって発生してしまっているのかなと思っています。
それをリファレンスチェックという手段を通じて、オンラインでカジュアルにできるようになれば、ミスマッチも減っていくのではないかというところで事業展開しています。
最終的には、ミスマッチを減らす方向で事業展開をしていくことだったり、ほかの領域にも事業展開を考えてはいますが、1つ軸としては、個人が培ってきた信頼を次に活かす。信頼のデータベースみたいなところを軸に事業展開できればと思ってやっています。この（事業の）PMを、2021年10月ぐらいからやらせてもらっていたという話です。
登壇の背景
本題になります。今回の登壇の背景でいうと、前回の登壇でCTOがPMとして稼働することになった背景とその解決策をお伝えしました。
先ほどお話にあったようなBizDevの問題だったり、それを解決するために「プロダクト中心になる必要がある」ということ、その達成のために前提をいろいろ揃えてPM活動をスタートしましたが、その活動のやり方が、CTOならではのアプローチもあったという話をしていました。
今回は、そのアプローチの中でCTOらしい、技術の部分を深掘りしていきたいと思います。
前回のお話ではプロダクトマネジメントしやすい環境の整備として、データ基盤、高速に検証できる環境、あとはPRD（Product Requirements Document）の雛形作成をあげました。上記2つが技術投資の部分にかかるので、ここの部分を説明できればと思います。
データ基盤の整理の背景とやったこと
まず、データ基盤の整理の背景です。（プロダクトレッドオーガナイゼーションのような）プロダクト中心の組織について言及されている本にあるように、データインフォームドな文化は非常に大事だと思っています。
このスライドにもあるように、プロダクトチームは、データに執着してそれの達成にフォーカスするべきだと本には書いてあります。
一方で、その時の事業部の状態を見渡した時に、Salesforceだったり、リレーショナルデータベースだったり、Google Analyticsだったりといろいろなところにデータソースが散乱していました。それぞれにBIツールをつけて、それぞれの部署がダッシュボードを見ているみたいな状況です。
そうすると、それぞれの部署のやりたいことは達成しますが、顧客1人や顧客1社を中心としたジャーニーを見るのが難しいというところで、データによるサイロ化が発生しており「プロダクト中心のデータインフォームドな文化の土台が整っていない」という課題がありました。
そうすると、自律的な意思決定はけっこう難しいなと思っていて、事業部の責任者が、事業部の状況を伝えるデータは、なにかしらの資料を起こすたびに、その責任者の属人に依存して出力されてしまいます。出力するときはその人が取りたいデータだけが切り取られてしまい、それをドリルダウンすることはできない。
そうすると経営会議とかで話をする時に、「そこってなんでそのデータになっているんだっけ？」みたいな、ボトルネックの認識合わせをするために、そのデータを説明するためのデータの取り方の話をしてしまうため、本質的な議論にならないみたいなことが問題としてありました。
やったこととして、まず環境を作る必要があると思っていました。非エンジニアの方々がデータを抽出するというケースが多かったので、そういう方々でも画面をポチポチしてできるような環境だったり、弊社が扱っているツールに連携できるのかというところ、エンジニアリング特有の部分のエラーハンドリングが充実しているのかというところなどを鑑み技術選定していました。
今日は時間がないので、「最終的にこうなりました」という結論だけお話しますいろいろなデータソースからBigQueryにデータを注入して、データの3層と呼ばれているものがあり、そこで事業部特有のデータに加工して、Data Studioに出すみたいな感じになっています。
データの伝播には「trocco」というサービスを用い、データを一元的に管理していくという設計になっております。
（スライドを示して）こんな感じのダッシュボードができています。ちょっと具体的な中身は出せませんが、こんなことをやっています。
実はこのデータは、Salesforceのデータもそうですし、サービスのデータも入っているような形になっています。
実際はもう運用の軌道に乗っていて、このダッシュボードも非エンジニアの方が作っており、けっこううまくまわっているのかなと思っております。
これからはもっとデータの種類を増やしていきたいと思っています。また、ただ作っただけでは文化は作れません。データリテラシーを上げるためにこれを常に見られる状況だったり、抽出方法を型化して、ほかのPMもちゃんとデータを中心に意思決定できるようにするようなことが必要かなと思っています。
高速に検証できる環境の整備の背景とやったこと
もう1つ。高速に検証できる環境の整備というところで、検証プロセスのジレンマがあると思っていて。検証の最初のタイミングって、その機能が本当に使われるかわかりませんが、動く環境を提供しないと、（そもそも）使いたいかどうかわかりません。
動く環境を用意するには用意しますが、負債化しないようにしなければいけません。エンジニアリングとプロダクトマネジメントのジレンマがあるのかなと思っています。
一般的に、ジレンマを解消するためには紙芝居的な感じでUIを見せてフィードバックをもらう方法だったり、ノーコード系ツールで検証する方法などがあるとは思いますが、ある程度プロダクトが立ち上がっている状況だと、「ノーコードだとなかなか難しい」という課題があったり、Figmaだけでは具体的なデータが乗ってこなかったりするので、それだと検証がうまく噛み合わないという課題がありました。
実際に作ったものは、プルリクごとに環境を立ち上げられるような環境です。（スライドを示して）方向性としてはこんな感じで、Cloud RunというGCP（Google Cloud Platform）のサービスがありますが、そちらでカジュアルに環境を立ち上げられるようにしました。
ソリューション検証の環境と言っていますが、実際のAPIは本番の環境を向いているものがあったり、新しい施策のものはバックエンドに軽いAPIを作って、それでなにかしらのデータを返してあげるようなことをやっていたりします。
（スライドを示して）実際にプルリクエストでプレビューみたいな感じでやると、こんな感じで、URLが吐き出されるような感じになります。
この施策により、本番反映用のトランク、メインブランチみたいなところにマージされる前に環境を立ち上げられるので、ソースコード、本番のコードは一切汚れない構成になりました。
環境も、/previewコマンドの後にいろいろコマンドをつけることによって、公開範囲を切り替えたりできるようにしていました。
また施策ごとに疎結合にすることによって、URLを展開するだけで「このURLでちょっと検証してみてください」という案内がカジュアルにできるようになったというところが、この環境のおもしろいところかなと思っています。
この環境の課題感ですが、本番環境を使っているユーザーが、新しい環境のURLに遷移するのは、けっこう面倒くささを感じてしまうということが最近わかってきました。
技術負債のジレンマの部分をちゃんと考えた上で、最適なUXを模索する必要があります。例えばフィーチャーフラグなどを活用したり、フィーチャーフラグ専用のちゃんとしたアーキテクチャを組んでいくみたいなところをして、本番反映と負債化のバランスを取る手段を別で考慮しなければいけないというのが今の課題感です。
CTOとして取り組むことで改善施策をまわせた
まとめです。いろいろプロダクトマネジメントを実際に実施する上で必要なものを作ってきたというお話をしました。まだ課題は多いですが、あとは何を改善すればいいかということが明確になったので、改善すべきことがシンプルになり、運用が回り始めてきたと考えています。
このような、たたき台のような環境構築をPdMだけでやるのはけっこう難しいと思っていますが、CTOとして投資対象として取り組むことによって、前にすすめる原動力なれたというのが1つ学びになります。
というところでいつものやつですが、採用活動中なので、みなさんもし興味があれば、応募いただければと思っています。あとCTO兼PM会は次回もやっていければと思うので、登壇者の方がいれば、ぜひ私に連絡いただければと思っています。
以上になります。ご清聴ありがとうございました。
