toB採用サービスのプロダクトマネジメントの成功例をできるだけ細かく解説する

2020年12月28日 15:22

LAPRAS株式会社の高濱です。名刺的にはプロダクトマネージャーという肩書きで活動していますが、弊社が導入しているホラクラシーでは仕事内容が極めて流動的なため、実態としては2020年12月現在は以下のような役割で仕事をしています。

特に大きな比重を占めているものとしてB向けサービスの戦略策定とプロダクト施策の企画があります。これらの視点を踏まえ、この記事では2020年のLAPRAS株式会社が好調であった旨を指標を交えて紹介し、それを導くひとつの要因となった（と少なくとも社内では認識されている）プロダクト施策と、プロダクトマネジメントについて書こうと思います。

● 数字からみる2020年のLAPRASのサービス

LAPRAS株式会社は、エンジニアのダイレクトリクルーティングサービスである LAPRAS SCOUT とポートフォリオの自動生成を備えた転職サービスである LAPRAS を提供しています。

採用/転職サービスとしての LARPAS SCOUT, LAPRAS としてのパフォーマンスを測る指標として社内で追っている特に重要な数値は、LARPAS社が提供するプラットフォームを通じた面談数と内定承諾数です。またプラットフォームの充実度を測るためのわかりやすい指標として LARPAS ログインユーザー数があります。本節ではこれらの数値の遷移を可能な範囲でご紹介したいと思います。

- 面談数

2019年12月から2020年12月にかけての月ごとの面談数は以下のようになっています（縦軸は秘匿してあります）。

後述するプロダクト施策もその一部ですが、2020年に入った時点で面談数を大きく増やすための様々な準備が整いつつありました。ところが2020年3月ごろからはコロナ禍の影響で採用を絞る企業などが現れ始め、ソフトウェアエンジニアも含む採用市場が急激に冷え込む期間が数ヶ月発生しました。

このトレンドがどうなるかは当時は予測が難しかったですが、特に需給のバランスが壊れているソフトウェアエンジニアの採用市場については数ヶ月で劇的な回復を見せ、今となっては体感的にはコロナ禍以前と同様の盛況っぷりを見せています。

さらに言うと、IT業界はコロナ禍による仕事のリモート化の恩恵を一番最初に受けた業界でもありました。これによってソフトウェアエンジニアの採用市場は大きく捉えて以下の2つの影響を受けたと考えています。
　1. ほとんど全ての面談がオンラインで行われるようになり、面談へのハードルが少し下がった。
　2. フルリモートワークを許容する会社の割合が増え、候補者の居住地に縛られない採用が可能になることで潜在的な候補者のプールが増えた。

これは採用にとってはポジティブで、むしろコロナ禍の前よりも採用活動が活発になる要因になっています。

面談数増のための様々な施策の影響とマクロな状況の影響で、2020年6月以降はそれまでとはまるで違うサービスと言ってもいいくらい面談が発生するようになりました。

- 内定承諾数

2019年1月から2020年12月にかけてのクオーターごとの内定承諾数は以下のようになっています（縦軸は秘匿してあります）。

2020年1-3月のQで内定承諾数が爆増していますが、前節の面談数などと照らし合わせるとこれは明らかに実力を超えた単なるラッキーによるものだと考えています。2020年4-6月はコロナ禍の影響が大きく出たQで、2019年7-9月や2019年10-12月と比べても指標が落ち込みました。

一方、面談数の爆増の影響が現れた2020年7-9月のQには過去のラッキーを圧倒的に吹き飛ばすだけの内定承諾が出ました。昨対比+108%と書く方がわかりやすいでしょうか。2020年10-12月の数値はまだfixしていませんが、前Qに迫るかそれを超える勢いがあることはわかっています。

- LAPRAS ログインユーザー数

画像がきれいなので2020年9月の10,000人突破リリースのときの画像を使いましたが、2020年12月現在でも伸び率を改善しつつユーザーが増え続けており、採用成功、ひいてはよりよいマッチングのための基盤が整いつつあります。

- 面談数増に影響したプロダクト施策

さて、特に重要な指標として追っている面談数は、先述の通り2020年の始めに比しておよそ100%強改善されました。この改善のうち最大で40%前後 (※) に寄与した可能性があると考えているプロダクト施策に、ダイレクトリクルーティングの各フローに担当者を割り当て、担当者に適切なタスクを発行する機能（以下：担当者アサイン機能）があります。

担当者アサイン機能の企画と開発のプロセスについては、もちろん改善点こそあるものの、効果的なプロダクトマネジメントの好例として扱える部分も多かったと考えています。そこで、本記事の以下の部分では担当者アサイン機能を実例として企画と開発のプロセスで有効だった思う点をまとめます。

※ 「最大で40%前後」と書いているのは、A/Bテストなどを実施できたわけではないためもちろん正確な影響は測れず、「機能を利用いただいた企業の面談数の伸び率」などからありえる影響の範囲を算出したものだからです。

● プロダクトマネジメント論の不安定性と実例の重要性

実例の紹介に入る前に、そもそもなぜ実例を紹介することが重要だと思っているかについて言及しておきたいと思います。

「プロダクトマネージャー」という職種、あるいは「プロダクトマネジメント」という概念が流行して久しく、海外だけではなく日本でもそれ関連のアウトプットを多く見るようになりました。
ただ、学習を深めるという観点では教材は十分であるとはいえず、教科書としてよく挙げられる本なども結局、「ちゃんとロードマップ作ろう」「ユーザーの行動を理解したり声を聞いたりしよう」「開発チームとうまくやろう」「プロジェクトマネジメントもデザインもマーケティングもやろう」といった抽象的な内容に終始してしまっている印象があります（そもそもプロダクト開発なんていう極めて分散の大きいトピックを抽象化したらそうなってしまうのは仕方ないと思うし、書籍の役割としてはそれでいいのかもとも思います）。

僕が読んで作った資料ですぐ引用できるものを以下に掲載しておきますが、誤解を恐れずに言えば「プロダクト開発にまつわる全てに精通して全てをがんばってやれ」みたいな内容です。

このようなプロダクト開発にまつわる全てを実行できる超人もいることにはいるかもしれませんが稀なはずで、実際のところ「プロダクトマネージャー」と呼ばれている人がしている仕事の内容は職場によってかなり異なっているはずです。最近ちょうどDMMの松本さんもそれっぽいことを言及されていてそれな〜〜〜と思っていたところでした（ツイートの意図を間違って理解していたら申し訳ないですが...）。

PdMについて、しっくり来る一般化された職責の区分があるというよりは、事業の性質やポートフォリオに応じて適応していこうということなのかな。事業に関わる組織全体を指揮するのか、あくまでプロダクトに閉じるのか、など。事例調べる。
— 松本勇気 (@y_matsuwitter) December 20, 2020

プロダクトマネジメントをしている人間からすれば自分がしている仕事の範囲は他の会社でのプロダクトマネージャーの仕事と比べてどうなのか？といったことには非常に興味があります。だからこそ、書籍に書くような内容ではない、より具体的な事例の公開と蓄積が非常に重要であるはずだと考えています。

● 具体例：担当者アサイン機能の企画と開発のプロセス

前置きがあまりにも長くなりましたが、以下では先述した担当者アサイン機能の企画と開発のプロセスについて有効だったと思う点をまとめます。

この例で題材として扱われているのはエンジニアのダイレクトリクルーティングサービスである LAPRAS SCOUT です。ソフトウェアエンジニアを採用したい企業が使う採用サービスのひとつで、 LAPRAS の登録者のみならず、Web上に何かしらのアウトプットをしている人の情報をクローリングしており、スコアやタグといった客観的な指標をもとに候補者を探すことができます。

- 課題を整理する

ソフトウェアエンジニアの採用市場は特に需給のバランスが崩れていて、需要に対して供給がまったく追いついていません。エンジニアの教育事業も流行してはいますが、企業が求めている「ある程度コードが書ける人」「マネジメントもできる人」といった、採用に足る能力をもったエンジニアは、供給の増え幅よりも需要の増え幅のほうがずっと大きいです。そのため、エンジニアの採用は年々難しくなっているといっても過言ではありません。

そんな市場環境のなか、2019年末ごろの時点で、ダイレクトリクルーティングは難しいものの、「こうやれば採用できる」というベストプラクティスのようなものはLAPRAS社内では見えていて、もちろんキックオフや日々のサポートのなかではそれをお伝えしていました。そして、そのようなプラクティスを実行しているクライアントは十分な成果を出していました。一方、そのプラクティスには「採用のための工数の確保」「エンジニアの動員」といった項目も含まれますから、どれだけ教えても、どれだけ促しても、ベストプラクティスを実行できない企業もたくさんありました。

成果が出ない要因の多くは、まとめると「運用がうまくいかない」ということなのですが、これをブレイクダウンして課題を整理する必要があります。課題の洗い出しや整理の方法としてよく取り上げられるのはユーザーの行動の分析やユーザーへのヒアリングです。これら非常に重要で有効な手段ですが、B向けサービスはデータの量が不足しがちで、データから定量的に行動を分析するのは難しいことが多いです。また、ヒアリングはもちろん可能な範囲で実施するのですが、現実的に利用できる自分の工数には限界があります。そこで、分析やヒアリングによる示唆の発見をより効率よく行う方法として有効なのが、日常的にユーザーと接する役割を持っている社内の人を通じて情報を吸い上げることです。LAPRAS社には Product Feedback というロールがあり、ユーザーからの声を適切に抽象化してプロダクト開発サイドに届けてくれる役割が明文化されています。

これは、 Product Feedback のアウトプットのひとつである「ユーザーが解約する要因を分解したマップ」の一部です。僕1人で作ったわけではないのですが、すごい分解能で作られていると思います。

これらを踏まえて、「運用がうまくいかない」要因の多くを解決できる方法を考えた結果、ベストプラクティスに従った運用をプロダクト的に促すために、担当者ごとに適切なタスクを発行する機能を作ることを決めました。

- 仮説を整備する

機能開発に限らず、施策を実施する際には期待する効果などを含めて仮説を立てておく必要があります。

今回の機能開発で立てた仮説は大きく分けて2つで、
　1. 機能が使われる
　2. 機能を使ったユーザーは運用のレベルが上がる
です。

前者に関しては仮説の設計を失敗しました。「機能をリリースすればそれだけでこのくらい使われる」「使われなかった場合は機能を消す意思決定の材料にする」といった内容なのですが、いままでプロダクトになかった新機能は浸透までに時間がかかります。プロモーションや紹介といった手段を尽くした上で使われなければ機能は消すべきですが、リリースして数ヶ月の段階で早々に機能削除の意思決定ができるような仮説ではありませんでした。結果として、「仮説で置いたレベルでは使われなかったけど、使われるような施策をいくつか打とう」といったネクストアクションになってしまい、当初の仮説からのブレが生じてしまいました。

後者に関しては概ねよい仮説の設計でした。あらかじめ今回の施策の対象となるユーザーの集合（運用がうまくいっていないユーザー）の定義を明確にできていたことで、それらのユーザーのふるまいの変化を振り返ることができ、結果として「機能を使ったユーザーは、使っていないユーザーに比べて確かにベストプラクティスに近い運用ができている」であろうことを確認することができました。

- 仕様をデザインする

今回の機能開発ではユーザーが置かれている状況に応じて適切にタスクを発行する必要がありました。要求仕様を決定するに際して、ありえるパターンを効果的に網羅するために、ユーザーの行動をシミュレートするウォークスルーを実施しました。典型的なユーザー群の行動を数パターン想定して、いつ何のために何をするかを時系列で記述しておきます。それぞれの時間で齟齬が発生しないように条件を組み立てていくことで、仕様策定の時点で考慮漏れを減らすことができ、結果としてより洗練された仕様を作ることができます。

僕はSIerで仕事をしたことはないのですが、（今回プロジェクトを一緒に進めたSIer経験者の談をもとにしても）SIerでいうテスト仕様書を先に作っておくみたいな状況に近いのかなとは思っています。小さな機能開発でこうした作業をする必要は必ずしもありませんが、複雑性がある程度大きい場合にはユーザーの行動のシナリオを作っておいた方が結果的には手戻りが小さくなった体感があり、手段として持っておくことは有効だと感じました。

仕様やワイヤーフレーム/デザインをどのように表現するかについては様々な方法がある上、今回の開発で特別な方法に頼ったわけではないので詳細は割愛します。要求仕様は社内のドキュメントベースである esa.io に文字ベースで書いていっただけです。

- 実装しリリースする

仕様を決め、デザインをお願いしたのちは、機能の実装に入ります。今回の機能開発では僕が直接コードを書くことはなかったため実装の内容については言及できませんが、リリースまで含めた一連のフローの中で特に有効だと感じたのはフィーチャーフラグの導入です。

今回の機能開発はユーザーから見た画面の変更を伴う上、タスク等の新しい概念や通知系が追加されるため、急に全体に導入すると混乱を招くおそれもありました。フィーチャーフラグを導入することで適切なユーザー群から順次新機能を開放していくことができたため、混乱が発生してサポートがパンクすることもなければ、致命的なバグが発生しないかどうかの確認をすることもでき、良いことずくめでした。

● おわりに

プロダクトマネジメントの実例には価値があるという考えのもと、自分が関わった中で割とうまくいったと思っているプロダクトマネジメントの例を紹介しました。もちろん Product Feedback、デザイナー、エンジニアといった、一緒にプロジェクトを推進した同僚の知見を集積したものなので、僕の記事にしてしまっていいかは怪しいところではあります...。

本記事で紹介した機能開発もよく考えれば2019年末から2020年頭にかけての話で、それから1年揉まれたことでプロダクト企画サイドは当時に比べてだいぶ賢くなった実感があります。賢くなったことでプロダクトに載せたい機能のアイデアはたくさんあるのですが、我が社もITスタートアップのご多分に漏れずエンジニアが足りてないので、枠は多くはありませんが採用してます。ご興味のある方は是非よろしくお願いいたします。

2020年にお世話になったみなさま、誠にありがとうございました。
2021年もよろしくお願いいたします。

この記事が気に入ったらサポートをしてみませんか？