はじめに

リクルートのHR領域の人材紹介事業（『リクルートエージェント』）で、「求職者と企業双方の希望を叶えるマッチング機会を創出する」ことを目指し、日々プロダクト開発に取り組んでいます。本記事では、僕（野村）がプロダクトマネージャーとして、あるプロジェクトで何を考え、どう実行し、どんな学びを得たのかをご紹介します。

今回ご紹介する内容は、顧客への価値提供を目的に、人×生成AIによる社内DXを通じた広義でのプロダクト体験刷新に向けた実体験となっております。

プロダクトマネージャーを目指す方はもちろん、プロダクト開発およびプロジェクト推進に関わる方にも、何かしらの気づきを持ち帰っていただけたら幸いです。

プロジェクトについて

■データから見えた問題
僕が担当するプロジェクトは、人材紹介事業の中でも人材を採用したいと考える企業向けのプロジェクトです。
しかし、顧客から求人募集のご相談をいただいてから求人票を公開するまでのリードタイムが長く、その結果、顧客に求職者を紹介するまでに時間がかかってしまうという大きな問題に直面していました。これは「早く良い人材を紹介する」という価値を実現する上で大きな障壁となっていました。

私たちのサービスに求人を預けてくださる顧客は、採用を急いでいるケースがほとんど。その顧客の要望に応えつつ、求職者を紹介するまでのリードタイムを短くすることは、意義のあることなのではないか？という仮説を持ちました。

■描いた理想像
この仮説を持って、我々は一つの理想像を描きました。

「最短で求人票を公開できれば、より早く顧客が会いたいと思う方を紹介できるのではないか」

この理想を実現するために、プロジェクトを立ち上げました。

立ち上げ時の思考プロセス

■現状把握
プロジェクトを始める際、まず徹底的に取り組んだのは現状の営業の業務プロセスの理解です。
求人票を『リクルートエージェント』のサービスサイト上で公開するまでに、「誰が」「どのタイミングで」「どのような意図で」「何をして」「それがどこにつながって」などの細かな粒度での業務フローの理解にこだわりました。

それこそ、実際に「明日から営業としてこの業務をやって！」と言われたら、「できます！」 と言えるくらいに解像度を上げにいきました。

■理想像の実現に向けた、初手実現したいUIUXの定義
現状を洗い出してからは、理想の実現に向け、プロダクトのなにを解決すべきか？という課題仮説の洗い出しに取り組みました。

この手の洗い出しは、出し始めるとキリがないのですが、まずとにかく多く洗い出すことを意識しました。そこから、

①すぐに解決すべき課題
②インパクトが大きいのでチャレンジしたい課題
③簡単に解決できるけどいつでもいい課題
④後回し・もはや所与とすべき課題

に分類し、整理していき、解決すべきことをシャープにすることと、何を所与に置くかを意識し、理想のUIUXを定義しました。

シンプルに考える重要性

UIUXの課題を考え出すと色々出てくるのですが、結局のところ、
・その部分をなくすか？
・それともぎゅっと縮めるか？
の二択でしかないので、俯瞰してみたときに、「ここってそもそもなくせないんだっけ？」といった視点を行き来しながら考えることが重要だなと、この経験から思いました。

例えば飲食店のタッチパネルで注文・支払いする際に、「このボタン、本当に必要？」（＝なくせる？）とか、「メニュー選択と支払い、もっと一緒にできない？」（＝縮める？）等を考えるイメージです。

使う人が迷わず、いかに最短で目的にたどり着けるようにするのかが重要だと思います。

そして、最後にそういったプロセスを経て描いた理想のUIUXは、自分がやるなら本当にできるか？ を検証し、そもそも定義していたUIUXに大きな欠陥がないかを見つけることを意識しました。

■生成AIを活用したアプローチ
現状分析を経て、一つの仮説を立てました。

「顧客と営業の求人打ち合わせの場で、生成AIを使って会話内容に基づいた求人を即座に生成し、その場で顧客と求人文面等をすり合わせた上で、求人公開まで至れないか？」

この仮説の背景には、「早く採用したいから人材紹介業者である我々に依頼発注しているわけなので、”スピード”を重視しているのではないか？」と考えました。

顧客の採用枠数も面接枠数も限られているゆえ、どれだけ早く顧客に求職者を紹介するかが事業成長のキーになるはずだと。

つまり、「早く公開する→早く求職者を推薦できる→早く会いたいと思う（書類選考合格に値する）方に会える可能性を高められる」という流れを想像し、それであれば、AIも活用して求人を即時公開して早さを生むというアプローチをあてることで、より早く募集要件にあった人材を紹介し、採用成功までのリードタイムを短くできるのではという狙いです。

検証設計と実行

■小さく始めて学びを得る
プロダクトマネージャーの方々には釈迦に説法だと思いますが、高速で検証→改善サイクルを回すべく、まずはプロジェクトチームを小規模につくり、実験を開始しました。

結果は概ね良好で、狙い通りのUI/UXと検証結果を実現できました。そして掲げていた成果指標や、リードタイム指標にも蓋然性の高い結果をプロジェクトとして作ることができました。

この成功を受けて、僕たちはこのプロジェクトの展開範囲を拡大することを決めました。

しかし、ここで予期せぬ問題に直面することになります。

直面した問題

■成功体験が隠した問題

実験対象を拡大した際、プロダクトの利用率が想定を大きく下回りました。当初は「顧客と営業が会議での打ち合わせを要する依頼が少ない（つまりこのUIUXがハマるような事象が少ない）」という声に注目していましたが、実はその背後に、より本質に近そうな仮説が隠れていました。

■仮説
それは、「実は営業的には「プロダクトの新たなUIUXへの不安」という、そもそも心理的なハードルが高く利用に踏み切れないのではないか？」という仮説でした。

小規模実験の際にも、実はなかなか営業現場で活用できないケースがあったのです。その時は上述したように「このUIUXがハマるような事象が少ない」と解釈・整理していましたが、実は「顧客との打ち合わせで必ずUIUXに沿った理想の営業プロセスを達成できるかわからないから不安」という気持ちがあったのではないか？ というものです。

例えると、「打席に立ったら、必ずホームラン打ってね」って言われて、「ホームラン打てなかったら失敗ケースとして解釈される」みたいな感じです。

もちろん他にも機能的に「プロダクトのここが使いづらそう」とかそういった仮説はあるのですが、恐らく上述した仮説が、利用者の日常に馴染みづらい、最も大きい要因だったのではないかと思っています。

現在はこの問題を解決するために、当初の理想として置いていたUIUXの基準をレベルごとに分け、段階を踏んでゴールを達成する方針で推進しています。
上記の例でいうと、「ヒットでも全然成功です。なんならバット振って当たれば御の字です」程度にするイメージです。

スケールを狙う際の「成功事例」の重要性

スケールを経験されている方からすると当たり前かもしれませんが、「成功事例の早期創出および展開」はとても重要です。

数人規模でのR&Dにおいては、全員の距離が近い環境を担保しやすいことから、成功体験の共有と具体的なナレッジシェアが容易なので、利用促進しやすく実験もしやすいのですが、ことスケール性が出てくると、人数も増えてくるので、様々なユースケースにおける成功事例を適宜全員に伝わる形でアウトプットし広めていくことがキモだなと痛感しています。

この取り組みを通じて、利用者を上記の４象限で大別して考えるのが大事だなと実感しました。

① 意欲が高く、真っ先にプロダクトを使ってくれる人達
② プロダクトを使いこなす努力をしてくれる人達
③ プロダクトを使いこなせるが、代替ツール・方法を知っているので、そちらに流れる人達
④ プロダクトに何かしらハードルを感じ使わない人達

①②の人たちは、率先して利用するのですぐに価値を感じてもらえるのですが、ボリュームゾーンは③や④なので、いかにそこの人たちに「使おうと思ってもらえて、徐々に成功体験を積み価値を感じてもらえるか？」が重要で、そこで使えるのが成功事例です。

身近な人の成功事例をリアルに伝えることで、1歩踏み出してくれるようになり、「こんな使い方もできるんだ！」というイメージにより利用が促進されていったので、成功事例というツールで、「ヒットにも、色々な打ち方があるよ！」をたくさん作って広めることが大切だなと実感しました。

学び

ユーザーにとって有用なプロダクトを一気に使ってもらえるようにするのではなく、MVP（Minimum Viable Product）を作れたら、”それを最も理想的な使い方をできる人を最短で最大化”するために、指標の毀損はない前提で、「利用者の日常に馴染ませるために、いかに心理的ハードルを下げるか？」を思考・定義し、実行することの大切さを学びました。

あくまでも、ゴール（理想のUIUXを実現できる状態の人を最大化する）はブラさずに
・理想を達成するとどういうインパクトが出るか？　が見えたので、プロダクト利用者を増やす際は
・敢えて「理想より、2,3歩手前」にハードルを置き、利用の障壁を下げ、
・利用者を最大化してから、ゴールに向けたロードマップを企てていく
ということが大事だと思います。

重要指標は上手くいっているという成功体験に慢心せず、小さな違和感にも敏感であり、違和感が出たら徹底的に深掘りにいき、解決の方向性をしっかりと考えることの大切さを、身をもって学びました（我ながら、猛省しています）。

どんなプロダクトでも、使っていただけなければ元も子もないので、まずは「良いモノ」の兆しが見えたなら、まずはそのプロダクトをスムーズに活用できる人を最大化し、並行して理想のハードルを実現できる人も増やしていくという進め方が良いのではと気づけました。

to C / to B問わず、似たような壁に直面している方はぜひ参考にしていただけますと幸いです。