こんにちは！ROXXの福士です。

今回は発足されたばかりのback check 事業部PdMチームに所属されている、
松野さんのお仕事やチームについてお話しをお伺いしました。

ー　まず自己紹介をお願いします。

松野広志と申します。
私の経歴ですが、2001年頃より8年ほど、Sierで大手企業への人事システム導入コンサルタントとして勤務していました。製薬会社、半導体メーカー、自動車部品メーカーなどの人事部様向けに、組織・人事・給与・福利厚生・勤怠などのシステム導入に携わりました。

その後、2010年にオンラインで手軽に学習コンテンツを配信できる環境を提供したいと思い起業しました。今ではオンライン学習は当たり前ですが、当時はオンプレミス型のシステムが主流であり、クラウドでのサービス提供が可能なSaaSというものがまだ走り出したばかりで、スマートフォンもまだ普及していない時代でした。教育業界はオフラインでの学習が主流でした。学習塾や予備校が先行して衛星放送を活用していたところから、、インターネットを使った配信に切り替わろうとしているタイミングでしたので、ここに可能性を感じていました。

その後、2020年に自身の会社で立ち上げたプロダクトの一つである「チャットボット型の業務システム」を合同会社DMM.comに売却するご縁をいただき、売却とともにDMMへ入社しました。

ー　ROXXに入社を決めた理由を教えてください

HRTech系のBtoBプロダクトの提供をおこなっている、成長意欲が高い会社でプロダクトマネジメント業務（以下「PdM」）をやりたいと考えていました。経営陣がプロダクトに対して熱い思い入れのあるような環境下で働きたいと思っていました。逆の言い方をすると、規模が大きく経営陣が自社のプロダクトのことをしっかり把握しきれていないような企業への転職は避けていました。その点、ROXXは面接時に経営陣から強いプロダクトへの思い入れを聞くことができ、先陣切って事業に向き合っている姿に惹かれました。

また、back checkは求職者と企業との相性や適材適所の見極めをサポートするプロダクトで、求職者の入社後の活躍に貢献できるところに魅力を感じました。”人がどこで活躍できるのかは所属するチームに大きく影響する”という研究結果や文献を見て、私の中でずっと引っかかっていた採用のミスマッチの解決に繋がるプロダクトに携われるという期待を感じ、入社を決めました。

ー　では次に、PdMチーム発足となった経緯をお聞かせいただけますか？

これまで、開発チームがビジョン策定から仕様検討と開発まで全てを担っており、開発マネージャーと開発チームに大きな負担がかかっていました。そこで、開発以外の役割をPdMチームが担い開発チームの負担を軽減しようという話からPdMチームの発足にいたりました。

チームの発足には、開発チームの負荷軽減以外にももう一つの狙いがありました。それは、プロダクトのビジョンを示し開発の方向性を決めていくという大きな意思決定をPdMが一人で担うより、複数名で健全なディスカッションをおこないながら意思決定する方が適切な判断を下せる確率が高められることです。参加しているメンバーは、適度に責任感を感じながらディスカッションに参加できており、現時点では上手く機能していると感じています。

SaaS事業を行っている企業の事業計画は「事業の理想の姿」と「事業の理想の姿を目指す為にプロダクトはどう動いていくか」この2つが必ずセットになり、作るのに1人ではバイアスがかかりやすいといった問題があります。

例えば、見た目の良い方を先に直そうとしたり、お客様から直接言われたことや事業責任者がやりたいと言っていることを優先したりなど、無意識に判断をしてしまう恐れがあります。その結果、開発のリソースをかけてもお客様やサービスにとって重要な案件を後回しにしているのに気づかずに放っておいてしまうことがあります。そういった意味でチーム化した方が絶対に良いということです。

なので能力や背景などに関わらず数名で集まり、健全なディスカッションを通じてバイアスを取っ払うことが得られる大きなメリットであり、チームを発足した理由です。

ー　他のチームとの協働の仕方や事業貢献について教えてください

1つ目は開発のスピードをあげていきたいです。今まではBiz側の要件をDev側に直接届ける体制だったので、これからはPdMチームがBiz（ビジネスチーム、以下「Biz」）とDev（開発チーム、以下「Dev」）の間に立ち、要件や優先度をまとめることで開発の効率化に貢献したいです。

これまでは、実際にサービスを作る人たちと、どういう意図で作るのかを考える人が一緒の状態でした。何を作り、どう作れば喜んでもらえるのかを考えることと、システムで実現していく知識を勉強しなければならなかったり、考えなければならないことも違います。それを一緒に考えるのは大変なので、私が作る側で、考える側をback check開発責任者の関家さんと役割を完全に分けることになりました。これによって関家さんを筆頭にDevはものを作ることに集中できると思います。

もう1つは、事業計画にプロダクトの姿をきちんと描いていくというところです。顧客理解を深めて未来を描くという活動を強化していきたいです。

要約すると、他チームとの協働の仕方について、既存のお客様からのフィードバックを得るためにはCS・CXチームと協働し、未来のお客様からの声をキャッチするためにはセールスチームと協働します。事業貢献としては、PdMとしてプロダクト戦略・プロダクトロードマップの作成を通じてプロダクトを通じた、お客様への価値提供について組織の共通認識を醸成し、実現に向けてPRDや仕様書、デザインの作成をおこないます。

ー　BizとDevの間に対立が起こることがあると耳にしたことがあり、その点においてPdMとして工夫されていることはありますか？

私がback check事業部に所属してから、まだBizとDevの対立を経験したことがありませんが、もしかすると、一般論として役員の中に技術者がおらずセールスから立ち上げられた企業などでは対立が起きやすいのではないかと思います。また、1件あたりの受注金額が大きいのでエンタープライズセールスでは開発の優先順位の意見対立が、今後起きるかもしれません。

対立と捉えて良いのかわかりませんが、意見の相違などはback checkでも発生していることは正直ゼロではありません。その際に、間に入って調整する機能がないと、個別最適化したシステムができてしまってプロダクトが個別最適の継ぎ接ぎのようになってしまうことが多いように感じています。 back checkのPdMとして意識して行動していることは、Biz側とDev側の両者の意見を公平に判断し、粘り強く最適解を模索し提案することで、対立が生じることを防いでいきたいと思います。

ー　PdMの大変なことややりがいを教えてください

お客様からプロダクトについてフィードバックを多数いただいております。それにお応えすることは大変であり、直ぐに対応できないことについては心苦しさを感じたりもします。いただいているフィードバックの対応は長期戦です。

チームを立ち上げる前は1人でこれに対応していたので何から手をつけていけば良いか分かりませんでした。大体、丸2年から3年程度はフィードバックをいただき続けてしまうと思いますが、それは決して悪いことではなく、お客様から期待されている証拠だと感じています。なので、ただひたすら業務的に対応していくのではなく、整理して優先順位を決めて対応していくことが1番のお仕事です。ただ大きくなると意見がたくさん出てきて1人では回らなくなり、限界があります。チームを発足したことで対応の幅は広がりましたが、そこは大変なところではあります。

あと、失敗できないというプレッシャーは大きいですが、やりがいは十分にあります。プロダクトの方向性や開発の優先順位を決めるというすごく強い権限を持たせていただいているので面白いです。色々な視点から大事な意見をもらえるので、事業的なニーズと現場が勘づいていることなどをキャッチアップし、最適なものを決めていくという感じです。今はチームを立ち上げたばかりなので大変ですが、来期以降は調整や修正になっていくので続けていれば負担は減っていくのではないかと考えています。

ー　Biz側の現場の声のキャッチアップは具体的にどのようにされていきますか？

現在はCSチームにヒアリングをしてもらっています。PdMチームが積極的にお客様へお話を伺う場合もあると思いますが、カスタマーサクセス（以下略、CS）やフィールドセールス（以下略、FS）のみなさんがお客様にヒアリングしたものをレポートとして沢山共有してくれているものがあるので、まずはそれを活用させてもらっています。back checkのCSはお客様と日々コミュニケーションを取り、本音を聞き出してきてくれるので、レポートの内容が濃くクオリティが高いので、とてもヒアリング能力が高く驚いています。

こういったお客様からのフィードバックをソリューションのネタとして活かし、プロダクトの機能開発に繋げていきます。「これだけのデータが出てきたから、こういうアイディアのソリューションが作れますよね」という元ネタが明確になり、Dev側もなんの為に作るのか分かりやすく、開発が完成した時にどちらのお客様に報告をすれば良いのか連携の取れる仕組みを作ろうと思っています。

ー　PdMチームで大事にしたい軸はありますか？

顧客視点で、時代の転換点となるプロダクトを作り続けるということと、そこにROXXとしての時代の転換点となる部分を組み合わせたものを作り続けることが我々の役割であり大事な軸になると考えています。

チームのミッションは今策定中ですが、事業部のミッションを加味してイメージを作ります。チームのビジョンは、プロダクトの明るい未来を描き続けられるチームですあり、「このプロダクトは1年後にはもっと良くなってるはずだから今頑張れるよね」というモチベーションをずっと持ち続けたいです。

そして、PdMチームが明るい未来を描けている以上はプロダクトが成長し続けるという風にしていきたいなと考えています。代表の中嶋さんがよくROXX LIVEなどでお話されていることですが、「去年を振り返るとこうだった、でも今俺たちこうじゃん、来年もっと倍になってるぜ」という、考え方的にはこれのプロダクト版のイメージです。来年はもっと良くなって、お客様をもっと笑顔にしているといった未来を我々が率先して描いていくところが大事だと思っています。

ー　現在取り組んでいること、これからやっていくことを教えてください

現在、来期のプロダクト戦略とロードマップの作成に取り組んでいます。プロダクトの未来を考えるので、早期に開発しなくてはいけないものと、不確実性が高く検証を通じて価値を見つける必要があるものと両方進めていきます。直近のback checkで言うと、リファレンスチェックにコンプライアンスチェックがつきました。こういったプラスアルファができたらもっと良くなっていくような品質の向上を、今までは中嶋さんやCOO／back check事業責任者の山田さんが行っていました。立場上お2人は忙しいので感覚的になってしまいやすいと思いますが、今後はPdMチームがしっかり検証、調査できる体制になっていくので、その中で価値があるものを見つけだし、プロダクトに組み込んでいくということをやっていきます。

すでに社内アンケートやお客様からのフィードバックでリクエストが上がっているものの中から厳選して優先度付けして、”なぜ必要なのか、リーチはどれ程のお客様が使いそうなのか、提供価値やビジネス価値はどのくらいなのか、何％の顧客が使いそうなのか、といったことに評価点を決め、お客様の満足度が上がるのか、喜ぶのか、不満を解消できるのか、アップセルに繋がるのか」といったところを数値化して並べ替えをしていきます。

プロダクトのどこが何に貢献するのか、受注率に影響しそうな開発とは何かを分割して並べ替えたりしてみている感じです。並べ替えをすることで開発の今抱えているものタスクを加味して、来期はこの順番で進めていきましょうという話をしています。

ー　では最後に、これからどんなチームにしていきたいですか？

プロダクトマネジメントには、ビジネスやデザイン、システムに関してのスキルや知識が幅広く必要です。例えば、立ち上げ当初は利用規約やホームページの作成、自分でセールスにインタビューを行うなど割となんでもやります。そのため、全てを1人でになうのは大変ですし属人化のリスクを伴いますので、メンバー同士が助けあいチームでプロダクトマネジメントがおこなえる体制を構築したいと思います。

現在のメンバーはデザイナー、エンジニア、BizDev系出身のメンバーが集結していて、個々の強みが異なり、健全にディスカッションがおこなえる構成だと思います。そんな中で知識を共有しつつ、お互いに高め合えるチームを目指していきたいと思います。

ー　ありがとうございました。

今回はPdMチームについてお話しいただきました。今後のご活躍に期待です！