2020年も残り少なくなってきた。世界的にはコロナ恐慌に見舞われた1年だったが、LAPRASとしては資金調達や執行役員陣変更、新サービスのリリースなど良いことも大変だったことも盛りだくさんの1年であったので、プロダクト、組織、経営、そして自分という4軸でなるべく見栄を張らずオープンかつ赤裸々に振り返ってみる。

プロダクト:LAPRASを軸にしっかりと成長できた1年

2019年4月10日にリリースしたC向けLAPRASであるが、これはリリース当初から順当にユーザーを獲得して、今年の9月には累計登録ユーザー数が1万人を越えた。

Image for post
Image for post
LAPRAS 累計登録ユーザー数の変化

4−6月はコロナの打撃を受けたものの、サービスを通じて発生したマッチング数(内定受諾数)は今年の始めと比較して大きく伸びた。これはLAPRASの成長も起因していて、LAPRASでアクティブなユーザーが増えるほどにマッチング数も大きくなっている。


2020年の秋、LAPRASはミッションを変更した。今後LAPRASの向かう方向性と今後我々が採用市場で起こると信じていることを書いてみようと思う。

LAPRAS社のミッション変更

2020年の秋、LAPRASは自社のミッションを「すべての人に最善の選択肢をマッチングする」というものに変更した。

Image for post
Image for post

LAPRASはこれまで何度もミッションステートメントを変更していて、最初の「世の中のミスマッチを無くす」から、3回目の変更となる。目指しているものが変わったというよりは、これを本気で追う事業側と代表である自分の目指したいものとの齟齬を無くすためより正確な表現になった、という感じだ。

ミッションにおける「最善の選択肢」とは何か。これはいわばその人にとっての世の中の本当の「Best of All」である選択肢という意味で、自分の国や認知・手の届く範囲を越えた全範囲でのベスト、というものだ。


先日、LAPRASはいままで掲げていたバリューを一新して、新バリューを制定した。そのときのバリューの決め方や浸透させるための運用法について書いてみる。LAPRASの新バリューは、3つのメインバリューと12のサブバリューから構成されていて、よりシンプルかつ具体的になった。詳細は以下のリンクからみていただきたい。

新バリューはこちら:LAPRAS VALUES

Image for post
Image for post
LAPRASの新バリュー

バリューとは何か

バリューを社に浸透させるにあたり、まず「バリューとはこの会社では何なのか」を決めなければいけない。これは普遍的な定義である必要はなくて、その会社ごとの定義で良い。でもとにかく決めることが重要だ。LAPRASでは、バリューを以下のように定義した。


先日、Matching Intelligenceに関してGroovesとLAPRASの提携が発表された。競合どうしなのに業務提携?と驚かれた方もいたかもしれないが、私はMatching Intelligenceのビジョンを目指す上とても有効な提携だと考えている。その意味を理解していただくためにも、我々がMatching Intelligenceを通じてLAPRASで目指すビジョンを共有しようと思う。

参考記事:グルーヴスとLAPRASがエンジニア採用領域で提携(LAPRAS)
参考記事:スキル可視化ポートフォリオ「LAPRAS」が人材紹介事業拡大、Crowd Agentと連携で(THE BRIDGE)

Matching Intelligenceとはなにか

Matching Intelligenceは、LAPRASにおいてR&Dとして始まったプロジェクトで、Tech Crunchの記事 にもある通り2020年2月から開発が開始され4月からクローズドβ版の提供が開始したサービスだ。

Image for post
Image for post
LAPRAS のサービス関係図

Matching IntelligenceはLAPRASを利用するユーザーに対して、人材紹介エージェント持つマッチングに近いマッチングを提供するサービスだ。転職を希望するユーザーには希望する業界や業種、希望年収や企業のカルチャーといった構造化した質問に回答してもらい、その結果を元にしてその人に合った求人を提案する。現在、提案は5件ごとに行われ、ユーザーはインターフェイスを通じてその提案に「気に入った」「気に入らない」というフィードバックを入れることができ、そのフィードバックに従って次の5件を提案する。合計15件提案して、最終的に面談を希望する企業が決まったら、人間のキャリアアドバイザーがその会社とつないでくれる、という流れだ。

現在はまだクローズドβ版で、サービスの提供価値を検証している段階だが、LAPRASを利用しているユーザーはLAPRASページからアクセスすることができる。

一人ひとりにパーソナライズされた専属マシンエージェント

Matching Intelligence の初期のコンセプトは、「一人ひとりにパーソナライズされた専属マシンエージェント」に近いもので、この名が付く前は「凄腕エージェントクローン」プロジェクトと呼ばれていた。実際に凄腕の人材エージェント数名に協力してもらい、マッチングのロジックや候補者に対する質問項目をヒアリングするなどしていた。いわば、日頃から自分に関しての情報を蓄積し、いざ転職する時には自分に合った最善の選択肢を提案してくれる専属エージェント(あるいはAIキャリアメンター)のようなものだ。今でもこの基本コンセプトは変わっていない。

エージェントと通常の検索の違いは、検索クエリがあるか無いかだ。検索というのは自分の欲しい物が明確な場合に明示的な検索クエリ(e.g. 「WEBエンジニア、東京、年収500万以上」など)を指定してほしいものを探すが、エージェントの場合は自分の状況や希望を伝えて、それにふさわしい選択肢を専門家に提示してもらう。転職のように選択肢が多く条件が複雑な分野ではエージェントのようなマッチングの仕方のほうがうまくいくケースが多い。しかし、そのように自分で調べるより良質な選択肢を提案してくれるエージェントはそう多くはない(エンジニアリング領域では特に)上、人によっても質にかなりの差が出るのが現実だ。Matching Intelligenceは、そういったエージェントによるマッチングを科学し、再現可能な形として量産することを目指している

4月から始まった初期の実験では、提案を受けた人のうち約85%の人がMatchingIntelligenceから提案を受けた企業との面談を希望した。現在は初期の提案ロジックとは変わっているが、人間のエージェントと比べても低い数字ではないだろう。体験した人に対して行ったヒアリングでは、多くの人が「自分では検索しようと思わなかったような求人を知ることができた」ということに価値を感じていた。ビジネススキーム上の制約のため形態は常に変化しているが、アルゴリズムによる人間を超える良質な提案の実現は、夢ではないようだ。

Matching Intelligence の目指す世界観

候補者を囲い込まない有機的なつながりで求人の網羅を実現


LAPRAS(scouty)がホラクラシー組織になったのは2018年3月のことで、その時は社員が10数名であったがそれから2年半ほど経つ今は社員が30名ほどになった。その中でホラクラシーとは長い付き合いになるが、ようやく見えてきたホラクラシーの長所と短所(功罪というと大げさだが)、そしてその先に見えるミッションに向けて本当にパフォーマンスを出せる組織のあり方について考えが固まってきたので、書いてみる。

我々もホラクラシーを完全に運用できていない点もあるので運用の問題をモデルの問題と取り違えている部分もあるかもしれない事はご留意いただきたい。また、あくまで会社の代表の視点であることを忘れずに(代表以外からは、別な視点が見えているかもしれない)。また、これはホラクラシー憲法version 4.xを前提にした話なので、version 5.x ではいくつか改善されている箇所もあるようだ。

憲法?バージョン?なんだか自分の思ってるホラクラシーと違うぞ?と思った方はこちらの記事からご覧いただきたい。

ホラクラシーの素晴らしい点

明瞭化されたガバナンスは素晴らしい

ホラクラシーの考案者のBrianはホラクラシーの解決する問題として「暗黙的ガバナンスの限界」「コンセンサスの限界」「トップダウンの限界」という3つの限界を上げた。そのうち、「暗黙の期待を元に仕事をしていると期待する側とされる側で期待のズレが生じ、組織にひずみが生じる」という「暗黙的ガバナンスの限界」はホラクラシーの解決する課題の中で最も重要なものと言ってもよいのではないだろうか。

ホラクラシーは組織内の役割をロールを通じて明瞭化し、共通認識を作ることによって組織から暗黙の期待をなくす。自分が暗黙の期待をしている、されていると思ったときはすぐにガバナンス(誰が何を行うか、そのためにどんな権力と責務を持っているか、という仕事の型。ホラクラシー組織に限らず存在。)を書き換えることができる。

明瞭化されたガバナンスの利点の一つは、意思決定が早くなることだ。「誰が決めるか」ということが決まっているので、きちんと運用すればコンセンサスにはならず意思決定者がスパっと決める。そのため何かを決めるミーティングは決定内容を話し合うのではなく、意思決定者が情報を集めるために行われることが多く、時間も15分から30分であることが多い。

また、明瞭化されていることによって「◯◯は△△さんの方でやっておくべきことなのに、なんで漏れているの?」といった勝手に抱いた暗黙的が外れたときの不満は、めったに生じない。それが生まれた場合は決まったプロセスで明瞭化をすれば良いので、オープンな場で解決される。何より、「暗黙の期待はダメ。期待があるなら明瞭化して相手に伝えるべき」という空気感や文化が自然と組織に浸透するので、それにより組織のひずみが生じにくくなっているようにも思える。

一度明瞭化されたガバナンスに慣れてしまうと明瞭化されていない状態が気持ち悪くてしょうがなくなる。組織内のガバナンスをすべて明文化するのは大変だが、それほどの価値はあるだろう。

ガバナンスとオペレーションのダブルループ

組織や事業は極めて変化が激しいので、初期設計された組織構造やガバナンスが1ヶ月後も最適な形であるとは言い難い。例えば、最初は社長がプロダクトの価格を決めるのが適切だったが、数ヶ月後事業や組織が進捗した際はマーケティングチームに決めさせた方が適切である、といった具合だ。

Image for post
Image for post
LAPRASホラクラシーオンボーディング資料より抜粋

多くの組織ではオペレーションに関してPDCAや改善サイクルが回っているが、ガバナンス、特に権限や責任に関してPDCAが回っている組織は少ないだろう。責任を果たすための権限が少なければ増やす、誰が決定するのか不明確になっていれば誰が決めるかを決める、といった具合だ。この仕組があることで、組織自体がアジャイルになる。これは「誰が決めるかを決める」プロセスがしっかり整備されていないと成り立たないし、そもそも書面上のガバナンスが明瞭に整備されていないと実現することができない。オペレーションとガバナンス両方のダブルループを回せることが、複雑な環境を生き抜くための組織の必須要件なのだ。

構造化されたミーティングは素晴らしい


Image for post
Image for post

私はキャンプが好きで、先日箱根のキャンプ場に行ってきた。キャンプの帰りの定番はやはり温泉だ。箱根ということもあり、温泉には期待していたが近くに手頃な温泉が なかったため、近くにあった入湯料2000円の温泉に行くことにした(箱根でも相場は1100 - 1200円前後だ)。 サイトでも美しい写真があり、露天風呂もあるということで期待に胸を膨らませていた。

しかし、そこにいった私はがっかりした。広そうに写っていた写真とは裏腹に、小さな浴槽がひとつだけで、そこに人が群がっていた。そして、極めつけは露天風呂だ。露天風呂があると書いてある場所に行くと、そこにあったのは、ただ窓を開けただけの小さな浴室だった。たしかに浴場から見える富士山と箱根の景色は申し分なかったが、これでは2000円の価値は無い。こういった体験をするともう二度と行かないぞ、という気持ちになる。おまけに悪評のレビューも書いてやろうかと思うくらいだ。

これは良くないユーザー体験の例だ。全く同じ温泉でも、工夫すればユーザー体験は改善できていただろう。たとえば、その温泉の強みである優れた景色やよく手入れされた綺麗な雰囲気がサイトの前面に出されていれば、感じ方は変わっただろう。また、露天風呂は無いと書いてくれた方がまだ気持ちがよかった。私は露天風呂にそこまでこだわりはないので、書いてなかったとしても行くだろう。こだわりがないなら何故窓を開けただけの露天風呂に憤慨するのかって?そんなの愚問だ。ユーザーとは感情的で不合理な生き物なのだ。

様々な問題はあれどおそらく最大の問題は、その温泉にはおそらくユーザー体験に責任を持ったすぐれたUXデザイナがいなかったのだ。温泉に入りながら、すぐれたUXデザイナはユーザー体験を改善するために何をすべきなのかについて考えてみた。

温泉に入りながら、このユーザー体験を改善するにはどうすればいいのかを考えてみた。

「デザイン」から「マネジメント」へ

最近ではUXに関して様々な複雑な定義や、ユーザージャーニーやペルソナを整理する体系化された手法が発明されてきた。それらが役に立つ場合もあるが、実際のところ、それらを理解した上で実際のユーザー体験の改善に活かすのはとても難しい。

この問題を考えるに当たって、まず、UXへの考え方をシンプルにしよう。ここではUXデザインを単純化し、UXデザインの目的を、「ユーザーの満足度を最大化すること」と捉えてみる。こう表現すると一見小難しいが、満足度とはつまり、5つ星レビューのスコアのことだ。

ユーザー体験を構成する要素は複雑で、サービスの内容のほか、

  • 価格やコストパフォーマンス
  • 利用前の期待と実際のギャップ
  • スタッフやサポートチームの対応
  • 利用した時の状況(たまたま天気が良かった、他の客がうるさかった 等)

こういったものまで含まれてくる。先の例でも、800円の利用料で、露天風呂などと書いていなければ無駄に期待することもなく、5つ星をあげられたかもしれない。こう考えてみると、UI/UXデザインなどと表記されるのはとても変な話だ。インターフェイスなど、ほんの一部分に過ぎない。


Image for post
Image for post

最近のベンチャー企業のウェブサイトには、どこも美しく綺麗なミッションステートメントが書いてある。まるで、ビジョン・ミッション・バリューその3つをウェブサイトに掲げることがITスタートアップ界の法律であるかのように、どこも似通ったことを言っているように思える。

最近は本当にワクワクするミッションを掲げる企業や組織を頻繁には見ないが、良いと思えるミッションにはいくつかの特徴がある。最近、組織のミッションについて考えることが多くなったので、良いミッションとそうでないミッションは何が違うのかについて考えてみようと思う。

良いミッションは明確である。

良いミッションは、組織のゴールや目的として明確に意識できるものだ。逆に明確でないミッションというのは、たとえば「〜を通じて笑顔が絶えない社会を作る」といった、達成したか達成していないかがよくわからないようなものだ。こういった目標を追うのは、曖昧な気分になる。ミッションが不明確だと、自分たちが存在したことによって変わったか変わってないかがよくわからない。少なくとも、計測可能なものであるべきだ。

時折CEOは、「会社としていろいろなことをやる」ため、会社の目的であるミッションをあえて不明確にすることがある。これは最低のやり方だ。それは「ミッションはあくまでお飾りで、せいぜい会社に人をつなぎとめておくための道具だ」と言っているようなものだ。組織のためにミッションがあるのではない。ミッションのために組織があるのだ。

良いミッションは野心的である

明確だが野心的でないミッションは、「全国大会で金賞を取る」「国内での最短での上場記録を作る」「◯◯業界で世界一の売上を作る」とかそういった類のものだ。つまり、野心的であるとは、誰もやったことのないくらい難しく、それでいて実現されたときにワクワクするほどの変化を起こすものだ。上に挙げた例は、たしかに難しいことではあるが、その実現の前と後で世の中に与える変化が小さい。一部の人の共感は得られそうだが、より多くの人を動かすには少し物足りない。ただ、野心的だが明確でないミッションよりは、いくらか明瞭な行動指針になるだろう。

良いミッションはあなたが本気で信じている

明確で野心的なミッションを持つことは重要だ。だが、その二つよりも重要なことがある。それは、あなたが本当にそのミッションを信じているということだ。ビジョンやミッションは、人や株主をつなぎ止めたり、ウェブサイトに美しく掲げるためにあるのではない。あなたが本気で目指している夢でなくてはならない。本気で信じているかどうかを見極める一つの方法は、そのミッションが達成されたときに組織が解散してもいいと思えるかだ。実際のところ、組織のためにミッションがあるという状態に陥りがちだが、本来であればその関係は逆であるべきだ。株主がいるとか、会社として存続させないといけないといったしがらみはあるものの、創業者は常に自分らの目的を問い続け、ミッションのために組織があるという状態を保ち続けなければいけない。

よく、「ミッションやバリューを会社に浸透させるにはどうしたらいいか」という質問をされることがある。そのためには、まずは綺麗なミッションステートメントを並べて自分自身を騙さないことだ。逆に、組織の創業者や社長のような組織内で一番権力のある人が本気で信じているのであれば、組織は自然とその達成の方向に向かっていくだろう。組織を大きなことを言うために嘘をつくくらいなら、小さくても本気で信じているミッションを掲げる方が遥かにマシだ。

良いミッションは人を動かす

別に明確でないビジョンや野心的でないミッションを持つことがかっこ悪いだとか、それを達成することに意味がないだとか、そういったことを言うつもりはない。ただ、そういったミッションは人を動かす力が弱いのだ。逆に、良いミッションは人を動かす。人を動かすということは、良いミッションの特徴というよりはむしろ定義のようなものだ。ビジョンやミッションは人を動かして士気を高めるための道具ではないが、良いと思えるビジョンやミッションには常にそういう性質がある。報酬も、名誉も、自己存続も、自己実現も、自分のスキル向上も大事だが、それよりも人は使命や社会的意義を求めるものだ。


日本初のAIヘッドハンティングサービスと銘打ったscoutyの事業を開始しておよそ3年が経った。その3年でサービス運営を行ったり、海外でのトレンドを見ていく中で、採用のあり方の変化や、今の採用方法の限界や、次の採用のあり方がだんだんと見えてきたので、今回はそれをまとめようと思う。

なお、LAPRAS SCOUT(旧scouty, 2019年4月より社名・サービス名変更)は現在はエンジニア採用に特化しているので特に前半はエンジニア採用に限定した話ではあるが、その多くは他の職種にも適用できる話ではあるので、採用全般の未来と考えていただければ良いと思う。

日本のエンジニア採用の現状

大前提として、日本は今深刻なエンジニア(IT人材)不足である。IT人材需給の予測では、エンジニアは2018年時点で22万人、2030年までに約45万人不足すると言われている[1]。人材の供給量はほとんど増えない一方で、需要が右肩上がりで伸びている。

Image for post
Image for post
出典:経済産業省-IT人材供給に関する調査2019

特に、クラウドサービス、ビッグデータやIoT、人工知能といった先端技術人材においてはさらに需給バランスが崩れており、従来型のIT人材より不足する傾向がある。


前回執筆した ホラクラシー組織への誤解と本当の意味 では、「ホラクラシー組織」という言葉が「ルールがなく、フラットで上司がいない組織」のことではないということを書いた。ホラクラシーとは、ホラクラシー憲法という組織に関する法律に基づいて組織運営をおこなうフレームワークのようなもので、いわば組織構造のOSのひとつだ。ホラクラシー憲法は翻訳すると3記事にまたがるほど長いもので、これを理解するには骨が折れるため、未だその実態が何なのか理解されていないのが現実だ。

そこで、今回の記事ではホラクラシー憲法におけるルールや機能をわかりやすく箇条書きでまとめていく。LAPRASのホラクラシー公開組織図を参考にすると理解が深まるだろう。

基礎の基礎

  • ひずみ(英語だと Tension)とは、理想と現実のギャップのこと。ホラクラシーは、組織内のひずみの最小化を目指している。
  • ガバナンスは、「誰が何をミッションとしているか」「誰にどんな権限があるか」「誰が何をやらなければいけないか」という仕事の型。「誰がイベントの参加者管理をするかが決まってない」はガバナンス上の問題。
  • オペレーションは、ガバナンスに基づいて行う仕事の遂行。「イベントの参加人数が集まらなかった」はオペレーション上の問題。

ロール

  • ロールは、目的領域(ドメイン)・責務 の3つの要素を持つ。
  • 普通、一人の人が複数のロールを担い、複数人の人がひとつのロールを担うことある。
  • 「責務」はそのロールがやらなければいけないこと。たとえば、オフィスインテリアロールは「オフィス家具の選定を行う」を責務にもつ。
  • 「ドメイン」は他のロールが犯してはいけない領域のこと。つまり、このロールが優先的に行使できる権限やリソース。たとえば、オフィスインテリアロールは「オフィスインテリア(内装・家具含む)の決定権」をドメインにもつ。
  • 他のロールのドメインにリソースを使いたければ、そのロールに許可を取る。同意の上ならOK。
  • 「目的」は目的。すべての責務やドメインはこの目的を果たす上で必要でかつ十分なものであるはず。
Image for post
Image for post
オフィスインテリアロールの目的・ドメイン・責務

サークル・任命

  • どんなサークルにも、Lead Link, RepLink, Secretary , Facilitator の4つのロールがある。
  • サークル内のロールのアサイン(任命)は、Lead Link が行う。ただし、Rep Link, Secretary, FacilitatorはLeadLinkがアサインできない。この3つは選挙で決まる。選挙は3ヶ月〜1年に一回やる。
  • サブサークル(サークル内のサークルのこと)のLead Linkは、スーパーサークルのLead Linkが任命する。


Image for post
Image for post

これは、プロダクトマネージャの役割を持つ人材がいないスタートアップや、プロダクトマネージャを任されたが何をすればいいかよくわからない人、あるいは現にプロダクトマネジメントを担当しているがより仕事の質を高めたい人に向けた記事だ。

プロダクトマネジメントをしない開発形態

何か製品を作ってサービスを提供する組織において、プロダクトマネジメントというものをせずにサービス開発を行うことは、事実上可能だ。

アーリーステージ

アーリーステージでのプロダクトマネジメントをしない開発形態というのは、創業者が思いついたアイディアを勢いで創業者かエンジニアが実装して製品化したりするものだ。

その後のステージ

製品をゼロからつくるアーリーステージを超えて製品を改善する期間に入った開発形態でも、プロダクトマネジメントを行わずに製品開発を行うことが可能だ。その形態は、社内のカスタマーサクセス担当・セールス担当・エンジニア・デザイナが顧客の要望や、時に思いついたアイディアをベースに開発チケットを作成し、主にエンジニアが開発段階で仕様を考えていくというものだ。この形態においては、仕様に関しては明確なオーナーが定まっておらず、時にビジネス担当者がリクエストを行ったり仕様を指定したりする。これは、看板管理をしているような開発でよく見受けられる。

プロダクトマネジメントをしないことのリスク

アーリーステージ

アーリーステージにおけるプロダクトマネジメントをしないことの最大のリスクは、プロダクトがラーメン代を稼ぐ前に資金が切れることだ。創業者が思いついたアイディアを勢いで実装したものは、統計的に言ってはじめの段階ではまず売れることはない(知り合いや最初の数顧客に売れることはあっても、市場を大きく取ることはできない)。大小含めいろいろなピボットを繰り返すことでプロダクトマーケットフィットにたどり着くことができる。

プロダクトマネージャがいない組織の場合、プロトタイプをつくることなく勢いで実装したものを顧客に提供することになるが、これはピボットのコストが非常に高く、あとで顧客のニーズと違う事がわかってもこれを巻き戻すコストは計り知れない。結果、最後まで方向転換できず、資金切れ間近で大きなピボットを強いられることになる。

一方でプロトタイプというのは取り壊すことを前提にして作るので、実装前段階で高速に実験を回すことができる。良いPMは、最初の段階で売れないことを前提に製品開発をする。創業者が思いついたアイディアは、最初の段階では仮説に過ぎない。プロダクトマネージャはその仮説の体系だった検証方法を理解しているので、創業の段階で創業者はプロダクトマネージャに自分の思いついた仮説の検証を任せるべきだ。あるいは自分がプロダクトマネージャになるか。

その後のステージ

通常、アーリーステージを抜け一定の顧客やユーザーが獲得できた段階では、複数の異なるセグメントの顧客が混合している。セグメント・属性が異なれば当然ニーズが変わってくるが、基本的には一つのソリューションで複数の異なるセグメントを喜ばせることはできない。結果として、顧客が欲しがったものをただ作っていく体制だと、機能追加のフォーカスはどんどん散逸化し、結果としてどのセグメントにも刺さらない製品が出来上がる。

しかも、顧客は課題についてはプロフェッショナルだが、使用可能な技術やデザインに関する知識はなく、ソリューションに関しては大して深く考えていない。プロダクトマネージャは重要な課題を明らかにし、ひとつの課題に対して可能な複数のソリューションを考え、その中からベストなものが何か吟味しないといけない。これには利用実績の調査やユーザーへのヒアリングを必要とし、エンジニアが実装の片手間でできるようなものではない。このプロセスを省略すると、機能ごとの一貫性は失われ、どのセグメントにも刺さらず、プロダクトの重要指標を大して改善しない製品ができあがっていく。

プロダクトマネジメントを始めたらやること

プロダクトマネジメントを始めることと、プロダクトマネージャを採用することは同等ではない。プロダクトマネージャの肩書の人間がいてもプロダクトマネジメントができていない組織もあれば、その逆もある。プロダクトマネージャがいる場合もいない場合も、上のようなリスクを回避するために以下のことから始めるとよいだろう。

1. 製品のプロトタイピングを行う

これは主にアーリーステージのリスクを回避するために最も基本的なことだが、製品を本リリースするまえにモックを作ってニーズを検証することだ。ピボットは製品開発前に行うのが理想ということだ。これに関しては専門的に扱った文献があるので、そちらに委ねたい。

2. プロダクトのターゲットセグメントを明確化する

プロダクトマネジメントの教科書には「どの顧客を対象とするかを決めるべし」と書いていることが多いが、むしろセグメントを決める意味は、「どのセグメントには売らないか」を明確にすることにある。ターゲットセグメントでない顧客がほしいというものは、むしろ作ってはいけないのだ

例えばエンジニア採用サービスであれば「エンジニアを採用したいITベンチャー企業」というざっくりとしたものであってはいけない。ポテンシャル層の人材を大量に採用したい企業と、優秀層をヘッドハンティングしたい企業では、当然提供するべきものも変わってくる。彼らの予算や、採用したい人材の像、他に使っている採用サービスなど、さまざまな要素の中で自社製品の利用の決め手となる要素を探さなければいけない。単純な固有属性(Bなら企業規模、Cなら年齢等)よりも、ニーズの違いが生じる特徴を探し出すことが重要だ。

3. 製品のKPIを定める

プロダクトマネジメントのいない開発形態だと、機能開発のフォーカスが散逸化してしまうため、劇的に数値改善することは稀だ。良いプロダクトマネージャは、ゴールを達成するのに重要と思われるプロダクトの特定の数字にフォーカスし、顧客が言っていないことでもそこのフォーカスめがけて仕様をつくる。これは受動的な製品開発では起こりにくいことだ。

このためには、製品のゴールから分解したKPIを定める必要がある。それに目標を設定して、優先度の評価をその指標ベースでやっていく。たとえば採用サービスであれば、毎月の面談数や、それに至る前の閲覧候補者数、あるいはセッション(訪問)あたりの閲覧候補者数などだ。

4. プロダクトロードマップを作る

プロダクトロードマップというのは、ビジネスニーズや全社的な戦略に合わせ、N年後にプロダクトがどうなっているのかというビジョンとそこに至るまでのマイルストンを定義したものだ。Nの数字としては3〜4年が妥当といわれるかもしれないが、自分としては半年、長くても1年で十分だと考えている。スタートアップにとっては半年後の未来は予想できず、不用意に先のことを考えてもどうせ変更することになるので、直近のプロダクト開発に関わることを考えれば十分だろう。

5. 顧客のPainの優先度を明らかにする

重要な課題にフォーカスするための方法は、ペインマップを作ることだ。ペインマップは顧客がゴール達成のために課題に感じている辛さ(Pain)を重要な順に並べ、それぞれの因果関係をまとめたものだ。

About

Hiroki Shimada

CEO & Product Manager at LAPRAS Inc. / MSc in Artificial Intelligence at University of Edinburgh / Alumni of KUIS(Kyoto University Information Science)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store