多彩な領域のプロダクトマネージャー（PdM）が集結し、プロダクトづくりに関する様々なセッションを発信するカンファレンス「PdM Days」。全体を通してのテーマは「枠を超えて、未来のまんなかへ」。セッションを通じて第一線で活躍するPdMの視点を獲得し、これまでの自分の枠を超えて未来に挑戦する。そのきっかけを提供し、日本のプロダクトづくりに貢献していきたいという思いが込められています。

今回は、2月17日に行われたオンラインセッション「ユーザー課題に向き合うプロダクトマネージャーたち」の模様をお届け。SaaS型の保育業務支援システム『CoDMON』のPdMである彦坂春森氏（株式会社コドモン）、女性向けのお金のコーチングスタジオ『SHEmoney』を立ち上げ、現在は同サービスを含む新規事業の統括責任者を務める松尾真里氏（SHE株式会社）をゲストに迎え、それぞれのユーザー課題への向き合い方や、あるべきスタンスについて議論します。

※2024年2月17日開催の「PdM Days Day4〜ユーザー課題に向き合うプロダクトマネージャーたち〜」から、内容の一部を抜粋・編集しています。

第一線のPdMが対峙するユーザー課題とは？

加藤：本セッションのモデレーターを務めます、株式会社リクルートの加藤舞子です。プロダクトマネージャー（以下、PdM）は、会社やサービスのミッション・ビジョンに基づいてユーザー課題を特定し、それをプロダクトという形に落とし込んでいます。このプロセスにおいて重要なのは、やはり「ユーザー課題への向き合い方」ではないでしょうか。本セッションでは、「ユーザー課題に向き合うプロダクトマネージャーたち」というテーマで、ゲストのお二人のご経験をシェアいただきます。さらに、これからのプロダクトへの向き合い方、あるべきスタンスについても議論してまいります。

加藤：では、彦坂さん、松尾さんに自己紹介と、手がけているサービスの概要をご紹介いただけますか。

彦坂：株式会社コドモン執行役員の彦坂春森です。学生時代から幼児教室や保育園でアルバイトをしたり、保育士の資格を取ったりと、もともと保育や子育て支援の分野には関心を持っていました。一時期、リクルートにいたこともありますが、やはり保育業界に携わりたいという気持ちが膨らみ、コドモンへ転職。現在はPdMとして開発チームで仕事をしています。

彦坂：弊社のメインプロダクトはSaaS型の保育業務支援システム『CoDMON（コドモン）』です。これを軸に、隣接する領域として『コドモンカレッジ』という保育者向けの研修サービスや『CoDMON STORE（コドモンストア）』というtoCサイト、保活支援サービスの『Hoicil（ホイシル）』など、かなりの数のサービスやプロダクトを展開しています。

彦坂：メインの『CoDMON』について、簡単にご紹介します。「保育現場の業務省力化」と「保育の質の向上」に資する業務支援システムで、保育現場の幅広い業務をカバーしています。多くの保育士さんは「もっと子どもと向き合いたい」と思っていますが、様々な事務作業や保育計画の策定、保護者の方とのやりとりなど、その他多くの仕事に時間をとられているのが現状です。そこを『CoDMON』が支援し、子どもに向き合える時間と心のゆとりを持っていただくことを目的としています。ちなみに、現在では保育園以外にも、学童や小学校、障がい児福祉施設、塾や習い事の現場などでもご利用いただき始めています。

加藤：彦坂さん、ありがとうございます。続いて、松尾さんお願いします。

松尾：SHE株式会社の松尾真里と申します。新卒でリクルートに入社し、事業開発の領域を一通り経験した後、2020年にSHE株式会社へ入社しました。現在は女性向けのマネースクール『SHEmoney』をはじめとする、新規事業の統括責任者を務めています。

松尾：『SHEmoney』は、「同世代のリアルを学び、お金のプロと実践」を掲げた、女性向けのお金のコーチングスタジオです。メインのお客様は20代から40代の、ミレニアル世代の女性たち。さまざまなライフイベントやキャリアイベントを迎えるタイミングの女性が自分らしい人生を実現できるよう、一人ひとりの理想から逆算した資産形成を学べる学習プランをオーダーメイド型で提案しています。

『CoDMON』『SHEmoney』における「プロダクトロードマップの組み方」

加藤：それではトークセッションを始めます。用意したトークテーマは2つ。1つ目は「プロダクトロードマップの組み方」についてです。

まず、彦坂さんにお伺いします。『CoDMON』の現状の事業フェーズと、どんなゴールに向かってプロダクトロードマップを組んでいるのか教えてください。

彦坂：現在の『CoDMON』のフェーズでいうと、柱である保育園のドメインはPMF期に入っています。学童などの隣接セグメントは、その一つ前のフェーズのものも入り混じっているような状況ですね。

プロダクトロードマップについてですが、まず、どの企業でもSaaSのサービスで重視されるのは、アカウント数とARPU（アープ）、チャーンレートといったところかと思います。『CoDMON』の場合でいうと、当初は保育ドメインに特化してアカウント数を伸ばしていくことにフォーカスしていました。ただ、ある程度、堅調に伸びていく見込みが立った段階で少し悩みが出てきて、チャーンレートやARPUに対していかに向き合うかといったことも考えたり。そうした指標レベルでの細かい優先順位の検討を含めて、ロードマップに適宜変更を加えながら進めています。

加藤：その「悩み」というのは、具体的にどんなことですか？

彦坂：2つあります。1つはARPUが全く上がらなかったこと。もう一つはプロダクトの安定稼働という点で課題があり、「このままではユーザーが離れてしまうのではないか」という危機感を覚えたことです。ARPUに関しては、プロダクトの改善どうこうではなくマーケティング側からのアプローチで対応することにしたのですが、問題は安定稼働の部分。ここはやはり最優先で取り組むべきだと考え、当時のロードマップをいったん全て白紙にして、内部品質の改善やプロダクトの安定といったところを軸に据えて開発を行う時期が半年くらいありましたね。

ちなみに今のロードマップの組み方は、中期経営計画のようなものを定め、半年に1回の頻度で見直しながら、何にどれくらい工数を割くかを都度決めています。その大きな方針に基づくものとは別に、各開発チームのPdMが優先順位を見て、その時々でやるべきことやチームごとの役割分担を判断している部分もあります。

加藤：松尾さんが担当する『SHEmoney』はいかがですか？　プロダクトの現在のフェーズと、ロードマップの組み方を教えてください。

松尾：『SHEmoney』のフェーズはPMFの前段階というところです。それと、プロダクトロードマップですよね……、正直、これが難しいなと思っていて。というのも、いかにPMFさせればいいか考えている段階って、戦略がどんどん変わるじゃないですか。当たると思って開発した機能が全く使われない、なんてことも多いので。

結局、私たちもプロダクトロードマップを作りはするものの、開発してみてダメだったら仕切り直して、ということを繰り返しながらやっています。2023年の11月には『SHEmoney』のサービスをいったん全て壊してから作り変えていて、ロードマップも新しく組み直しました。PMF前だからというのもありますが、結構ドラスティックに進めていますね。

加藤：ちなみに、サービスを全て作り変えることになった理由は何だったのでしょうか？

松尾：まず、売上が思うように伸びなかったこと。サービスのローンチから1年半が経ち、グロースハックをやりながら少しずつ上向いてはいましたが、ここから指数関数的に伸びるかというと、現在の延長線上では難しいだろうと判断しました。そこで、改めて大規模なパネル調査やユーザーインタビューを実施し、定量と訂正、どちらも根拠を持った形で半年間のプランニングを行ってからサービスをリニューアルしたんです。また、リリース後もしっかり当てにいくことを意識してグロースさせた結果、フルリニューアル後は売上が2倍に、利益率も大きく改善されました。

加藤：「当てにいく」というと、具体的に何をやったんですか？

松尾：施策前に必ずテストマーケをするみたいな、ある意味当たり前のことですね。まずは粒感が小さいところでテストマーケを行って、そこから当たりそうなものだけをピックアップし、恒久的な機能としてプロダクトに実装していく。その当たり前を凡事徹底することで、着実にグロースできるのではないかと思っています。

どう判断する？「ユーザーの解決課題」の優先順位

加藤：2つ目のトークテーマは、「ユーザーの課題解決の優先順位」についてです。 彦坂さん、松尾さんともにプロダクトを通じてユーザーの様々な課題に対峙されています。ただ、一見ペインが大きそうな課題でも、それが売上やアカウント数の増加につながるかどうかの判断は難しく、プロダクトに組み込むか否かを迷ってしまうこともあるのではないでしょうか。『CoDMON』や『SHEmoney』ではそうしたペインポイントをどう判断し、施策の優先順位にどう反映しているのか教えていただけますか？

彦坂：コドモンの場合、手掛けるプロダクトの数が多く、各プロダクトのユーザーからさまざまなご意見・ご要望をお受けします。ただ、たとえば顧客接点のあるメンバーが「ここ、使いにくいから直してほしい」というご要望を受けたとしても、メインではないプロダクトのピンポイントな課題を改善しにいくことが、ARPUなどの指標の向上につながるかどうか判断できず、二の足を踏んでいるところがあったんです。
しかし、私たちのメイン事業であるSaaSのモデルは「顧客に期待し続けていただくこと」が何より重要です。たとえ隣接プロダクトとはいえ、ユーザーがずっと気になっていることが解消されない状態が続くと、関係性を毀損してしまう。今では、こうした改善にはしっかり取り組むべきだろうと考えるようになりました。
もちろん、指標に大きな影響を与える、あるいは当たる確率が高いと見込まれる課題が最優先ではあるのですが、たとえ小粒でも「ユーザーの期待のベクトルを維持する」ことにつながる課題であれば、しっかり工数を確保しようということですね。

加藤：そうしたユーザーからの声や課題って、どう拾い、どのように管理しているんですか？

彦坂：先ほども言ったように顧客接点のあるメンバーが直接聞きとる場合もありますし、サービスのお問合せフォームに送っていただく場合もあります。それらが社内のSlackにどんどん流れてきてPdMがチェックするという、すごくシンプルな仕組みですね。

加藤：松尾さんもうなずかれていますが、同じようなやり方でユーザーの声を収集・管理しているのでしょうか？

松尾：そうですね。弊社の場合もWeb上に「目安箱」のようなものがあり、それがSlackと連携されています。そこに流れてくるユーザーの声は、経営陣も含め毎日チェックしています。あとは、SHE独自でいうと、ユーザーとの距離がすごく近いからなのか、X（旧Twitter）などにペインポイントをポストしてくださる方も多いです。「この機能ってどうなってるのかな？」や「こうしてほしい」といった声を拾って、施策の検討材料にしています。

加藤：それらの優先順位のつけ方で、何か工夫されていることはありますか？

松尾：少し前までは、いわゆる「声が大きい人」や説明が上手な人の施策ばかりが通っていたのですが、それだけだとあまり良くないよねということで、今はRICEスコアなども導入し、リーチやインパクト、それをやる意味がどれくらいあるのかをしっかりと整理した上で、おしなべて判断をするようにしています。また、弊社では2週間単位でスプリントを行い、その都度、優先順位をつけて「やる・やらない」を判断していますね。

ただ、なかにはそうしたRICEスコアなどで定量的に判断できないものもあると思っています。たとえば、インパクトを算出することはできないけれど、ユーザーからたくさんの問い合わせがきているもの。先ほどの彦坂さんのお話にも通じますが、そうした課題に取り組むかどうかについては、意思のある人がしっかりと判断して通す必要があるのではないかと思います。

加藤：お二人とも、ありがとうございました。それでは最後に、本セッションをご視聴いただいた方に向けてメッセージをお願いします。

彦坂：今回のテーマは「ユーザー課題に向き合うプロダクトマネージャーたち」ということでしたが、弊社もそうですし、どの会社のPdMも悩みながらユーザー課題やプロダクト開発に向き合っていると思います。今回は私がお話しさせていただく立場でしたが、私自身も普段は世のPdMの方々が発信されている記事などに数多く触れて、さまざまなことを学んでいます。ですから、これからもお互いに頑張って、その頑張った痕跡を世に発信していきましょう。そうすれば、結果的にみんなが助かって、日本のプロダクトやサービスがどんどん向上していくと思います。

松尾：彦坂さんがおっしゃる通り、PdMって本当に正解がないものですよね。プロダクトのフェーズや会社の規模感によっても正解の判断基準が変わり、道に迷ってしまうことも多いと思います。ただ、それでも情報を集め、その時々の最適解を提示し続ける力が、PdMには求められているのではないでしょうか。その力を養うには、やはり情報交換が大切だと思います。私からも逆にみなさまから学ばせていただきたいので、引き続きよろしくお願いいたします。

お知らせ｜プロデザ室は仲間を募集しています

プロダクトデザイン室の募集情報は〈こちら〉のサイトからご確認いただけます。ぜひご一読ください☆
https://blog.recruit-productdesign.jp/

お願い｜noteのフォローをお願いします！

こちらのnoteアカウントをまだフォローしていない方！ぜひフォローしてくださいね。皆さんのキャリアやお仕事に役立つ記事を発信していますので、絶対損させませんよ！！！

お願い｜できれば公式X（旧twitter）もフォローをお願いします

プロダクトデザイン室の公式X（旧twitter）ではイベントの見どころやオリジナルコンテンツを更新しています。ぜひフォローしてください。
https://twitter.com/Recruit_PD_PR