見出し画像

2022年1月24日、「採用データ分析」を事業にできるか進めてみます！（撤退を視野に入れた上で、極小粒スタート）

新田順｜ワークポッツ代表（採用,転職Tech）

6,500 words

こんばんは。

法人のハンコ業務をマジでなくしてくれ、でおなじみの新田です。

（毎回、ハンコ業務には発狂してしまいます）

さて。
今回は「採用データ分析の事業」を小さく進めてみるよ！というお話です。

決定までの背景や、これからどうするのか、思考整理のために文字にまとめてみました。

ここ最近の失敗談もいっぱい書きました。

興味のある方はご覧ください。

（書いていたら熱くなって長くなってしまいました。ご注意ください…）

これまでの背景

11月〜12月、B&CのC側の開発をしていた

2021年10月にペーパープロトタイプが完成したので、11月からは「マッチングプラットフォーム（B&C）の開発」をしていました。

ペーパープロトをつくったときに「求職者側（C）がカギを握る」と感じたので、B&Cの中でもCのモバイル開発（MVP開発）から着手しました。

B　：企業側（Webアプリ）
C　：求職者側（モバイルアプリ）
B&C：企業と求職者が交わるプラットフォーム

11月・12月で開発して → 1月10日にはローンチ → そしてユーザー獲得をしていこうという流れでした。

でもこれが、全然甘かったのです。。。

難航するプロダクト開発

当時、プロダクト開発の進捗があまりよくないと感じていました。

しかし、B側の求人を集めたり、視野にある採用活動の準備をしたり、採用コンサルの仕事をしたり、私自身も手一杯でした。

なので、まずは自分の持ち場をやり切ろうと思い、流れに身を任せていました。

・　・　・

12月上旬、話し合いの末、「ゆうたさんはデータに強みがあるエンジニアだから、プロダクト開発に強みがあるエンジニアを探して開発を加速させよう」となり、採用活動もしていました。

しかし、1人でプロダクト開発の全工程ができるようなCTOの採用は叶いませんでした。（素敵な出会いはありましたがここでは割愛）

年末年始、このままではさすがにやばいと察して、プロダクト開発に関する大量インプットを盲目的におこなってみました。

すると、私の過ちに気づいたのです。

非エンジニアが陥るプロダクト開発への理解不足

僕の考えが安易でした。。

創業からこれまで、「プロダクトなんて、1か月あれば適当に動くものくらいできるだろう。そこから修正を加えていけばいいだろう」と考えていたのです。

もちろん、「MVP開発」や「ユーザーインタビュー」などプロダクト開発の枝葉の知識は持っていました。

しかし、プロダクト開発の幹の部分を理解しきれていなかったのです。

プロダクト開発に対する知見が圧倒的に不足していたのです。

その誤認識こそが、開発がうまくいかない原因でした。

・　・　・

エンジニアリング界隈で使われている言葉を引用するのならば、
「妊婦が10人いたとしても、1ヶ月で子供が産めるわけではない」ということです。

補足
◎ 妊婦は10か月かけて、1人の子供を産む（◎ 妊婦1人×10か月=子供1人）
× だからといって、妊婦を10人集めれば1か月で産めるということではない（× 妊婦10人×1か月=子供1人）

この言葉は、「開発に人員を割いたからといっても、その人員分の短縮が見込めるわけではない」ということを言っています。
エンジニアを10人集めたからといって、プロダクトが1か月でできることはないということです。

↑この主旨に加えて、「プロダクト開発はそもそも10か月かかるものであり、1か月で生むことはできない」とも読み取れました。

（新田のぼやき…）
子供が産まれるのは10ヶ月かかるように、プロダクト開発も、進み出したら10ヶ月後までは出会うことはできない。だからこそ方向性を見定め、必要な機能なのか見定めてから進める。6ヶ月目で「やっぱり違った」となると、また1ヶ月目からやり直しになる。だから手戻りを最小限にするようなアジャイル開発が生まれたんだ。手戻りが発生しないように、検証ポイントを決めて・小さく作って・小さく検証して・改善を繰り返していくことが大切なのだ…

↑ということがよーーーくわかったのです。涙

2022年1月6日の出来事でした。

反省しすぎて、たくさんツイートしました。。

翌日7日のMTGで、ゆうたさんに謝罪しました。。。

なんとかMVPを作ってみた

学びを得て反省した私は、「スプレッドシートやノーコードでもいいから、とにかくMVPを出してみることが先決だ」と判断しました。

当初の予定通り、1月10日にひっそりと簡易サイトとスプレッドシートだけのMVPをローンチをしてみました。（公開ボタンを押しただけで、特に告知せず）（これをMVPと呼んでいいのかはさておき）

（※「とりあえずMVPを出せ」の教えは、出してみてからその核心性がわかりました。数十回と見た馬田さんのスライドはこちら↓）

なんとかMVPを作ってみたが、違うことが判明した

しかし、ここで疑問が出てきました

実際にスプレッドシートで作ってみたが、MVPとはいえこれは誰が使うんだ？私がユーザーならこれを使うのか？と疑問が出てきたのです。

一応、そのスプレッドシートには、エンジニア求人が2000件ありました。（手でかき集めてきたものです）

疑問は出てきたものの、それをもっと尖らせて、「エンジニア＞バックエンドエンジニア＞Goエンジニア」まで絞ってみるとどうだろう。
そして、「Goエンジニア 求人数 No.1」を謳えれば、Cのユーザーメリットはあるのではと考えました。

調べてみると、ある求人媒体で「Goエンジニア求人」は200件くらいでした。

「Goエンジニア求人数 No.1」でいけるのではと考え、もう少しもがいてみることにしたのです。

もがいた結果、方向性が分からなくなってしまう

しかし、もがいているうちに、率直な疑問がでてきました。

・お前がGoエンジニアなら、本当にこのMVPをつかうか？
・200件を集めた結果、「やっぱ違いました」となったら、手戻りが大きいのではないか？
・200件集めることが正解かどうか、小さく検証できないのか？
・そもそも、お前がやりたいことはこれだったのか？

いろいろ考えた結果、「ショボいMVPであってもぜひ使いたいというユーザーがいなければ、これはMVPとしても今後のプロダクトとしても価値を届けてられていないから意味がないよね」という結論に至りました。

「というかそもそも、お前自身が見てみて・やってみて、『これいいじゃん』とならない時点で違うよね」と。

また、このMVPを通していろいろな考えや学びが交錯しまくった結果、どの方向性に進めばよいかよくわからなくなってしまいました。。

「私が方向性を決めるのも大切だが、まずはユーザーに聞いてみよう」と少し開き直って、ユーザーインタビューを進めようともしました。

…しかし、どうしても「これでいいんだっけ？」という懸念が頭をよぎります。

それもそのはず。なぜなら私は、数日前に「あの大反省」をしているからです。

Goサインを出すのであれば、検証したい仮説に精度が必要です。

この時、思い切ってプロダクト開発を止めて立ち止まり、再考の時間をつくることにしました。

1月10日の夜のことでした。

無秩序のインプット、書き殴り、思考整理

無秩序にインプットしまくりました。
無秩序に書き殴りまくりました。

「そもそもオレは、何がしたくてこの会社を興したんだ？」
「採用と転職の課題ってなんだ？」
「採用と転職の理想ってなんだ？」
「いきなり理想に飛ぶことは無理だから、MVPはなんだ？検証可能な最小限のことってなんだ？」

1月15日、そんな無秩序にインプットとアウトプットを繰り返す私に、2つの光が差し込んできました。

①やりたいことは、やっぱり変わっていなかった

まず、創業者のガソリンとなる「なんのため」については、やはり変わっていませんでした。

これだけでも、私にとっては救いの光でした。

私がやりたいことは、やはり情報の整理・透明化です。
学生時代からの行動遍歴を見ても、ここに強い執着心があります。

一言で言えば、すっきりさせたいんです。

特に、自分の人生でご縁があった「採用」という仕事、その反対側でつながっている「転職」という活動、ここをすっきりさせたいんです。

自分というちっぽけな人間でも、この分野に特化してやり抜けば日本を一歩だけでも前進させられる気がするんです。

言い換えれば、xID・REINSみたいなことです。整えたい。
それをStripeのような位置でビジネスを展開したい。スケールさせたい。

（↑ここの説明は長くなるので割愛します…涙）

＜やりたいことのざっくり流れ＞
ジョブを整える→　デジタルマッチングがさっとできる→　アナログマッチング（面談/面接）の時間を長くできる→　ミスマッチを防げる→　個々人の最適化・最大化ができる・・（飛んで）・・→　GNP19位と人材評価世界31位を上げられる

まあ結局のところ、すっきりさせたいんです。

②「採用データ分析」という2つめの光

（長くなりましたが…ここからが本題です。）

突然の連絡（1月15日）

やはり採用と転職をすっきりさせたいんだなと思っていた矢先、友人の経営者から「スポットで採用データの分析BIツールをつくってほしいみたいなんだけど、いける？」と連絡がきたのです。

この連絡に、ビィビビビビイビビビッィビビビビッッビビ！！！！っときました。

なぜなら、
①新田の強みは、採用×データ
②ゆうたさんの強みも、データ
③データを軸に整える／すっきりさせることが会社の目的、そのためにタッグ組んだ
④2018年 Sansan社で依頼と全く同じプロジェクトをしていた。というか、そのプロジェクトでゆうたさんと出会った　からです！

（そこからの思考回路は少し割愛しますが、、、）

とにかく、この「採用データ分析」に対する課題解決から始めれば、元々やりたい世界観の達成に最小のリスクで強みを活かして近づけると確信しました。

まさに「急がば回れ」です。

・自分達の強みを最大に活かせて、
・プラットフォームのような超レッドオーシャンに正面衝突せずに、
・最小限でスタートできる。
・（可能であれば）BまたはCのユーザーと接点を持てて、
・（可能であれば）マネタイズもできること。

ずーーーっと上記のことを考えていたので、そこにきた「採用データ分析」はドンピシャでした。

・　・　・

しかも、探してみると「採用データ分析」に特化したサービスは見つかりませんでした。

※ 人事データ分析はありましたが、どちらかといえば評価や組織のところでした。採用は思っているより独特なので別領域と私は考えています

「採用データ分析」って、たしかにずーっと課題なんです。

データに強い採用担当者でも、ちゃんとデータ取ってBIツールで可視化までするような方は見たことがありません。（どっかしらにいるとは思いますが）

じゃあ何が課題か、整理してみました。

＜採用データ分析における課題＞

0. 分析に満足していても行動できていない（今回は割愛）

★ ①ATSの分析ツール（今回の企業、2018年のSansan社）
★ ②Excelでのデータ分析の限界
★ ③採用担当のデータ分析の工数

④そもそもデータをとっていない
④ATSをつかっていない

↓図で書くと、こんな感じです。
①ー②ー③の順番で課題解決をしていきます。④はその次です。

最終的には、データ分析（①〜③）→ATS（④）→プラットフォーム（⑤）と流れで課題解決を進めていけば、我々のミッションが達成できます。

（なんのこっちゃという感じですみません）

課題を模索し続けていたから気づけたチャンス

ここ数日間、血眼になって「課題」を探していました。

それは、以下の問いのうち、②「課題」がふわっとしていたことが今回の原因だったからです。

（自戒を込めて言いますが）
課題が不明瞭だから、作ったツールが使われないのです。

課題が明確であれば、多少ダサかったりショボかったりしても、人はそれを使います。
なぜならその目の前の課題を早く解決したいからです。（お金を払ってでも）

①誰の
②何の課題を
③どのように解決するのか？
④代替品は？
⑤市場規模は？
⑥なぜあなたがやるのか？

SmartHR 宮田さん インタビュー記事より引用　https://signal.diamond.jp/articles/-/144

・　・　・

どの企業も「採用データを貯める・分析する・行動に活かすこと」に対して課題意識はあります。

ただ、なかなかできないのが現実です。

そんな中でも負けじと採用担当者は、少ないリソースを使って採用データ分析をしています。
そして、スケールすることもなく、ただただ自社内でリソースを消費しているのです。

採用データ分析があたりまえの社会を目指して

メルカリ社のように、人事部内にエンジニアを置いてデータドリブンな人事戦略をしている企業もあります。

ただ、そんな潤沢な企業は限られています。

だったら、我々が採用データ分析ツールをSaaSのかたちにして、安価で・簡単に・多くの企業で使えるようにしたらいいなと思ったのです。

SaaSといっても、最初はどちらかといえばGoogle Chromeのアドオン機能のような感じに近いかもしれません。
Chromeでは網羅できないことを、他の開発者が補完している感じです。

そうやって最初はBIツールを使いながら手作業も入れながらやりつつ、最終的には「SaaS」といえるような採用データ分析のソフトウェアを作りたいと考えています。

「採用データ分析ツール」を多くの採用チームに普及させて、まずは日本の採用を前進させたい。
そして、裏側の転職をより自由にしたい。
日本の次は、世界に横展開させたい。

言うのはタダなので、とりあえず言っておきます。

これからの株式会社ワークポッツの方向性

さいごに、まとめておわります。

これから当社の事業は、2つになります。
①採用コンサルティング
②採用データ分析　（プラットフォーム事業は休止）

1月14日に見えた「採用データ分析」という光が、今後のワークポッツの主軸となりそうです。

超ニッチな領域ですが、まずは小さく小さく回してみます。

もしかしたら2週間も経たずに「ニーズがなかった」となり終了するかもしれませんが。。。

・　・　・

ちなみに、1月14日にいただいたお話はうまくまとまり、受注の運びとなりました！🙌

採用コンサル以外では初受注となったので、ゆうたさんと一緒に喜びました🎉

「受け手が求めていることを課題解決する、対価として報酬をいただく」というビジネスの基本をあらためて学んだ気がします。

これまでは、「こういうサービスがあったらいいっしょ」と作り手目線が強く出てしまっていたなと感じます。

↑もちろん、顧客のインサイトを捉えておこなう「プロダクトアウト」も大切なのことではあります。

しかし、まずは顧客の課題から素直に解決する「マーケットイン」から成功体験を積んでいくのがベターだと経験しました。

顧客の課題解決＝ビジネスだからです。

・　・　・

スタートアップが潰れる原因1位は、「No Market Needs（買い手がいなかった）40〜50%」です。

超序盤ではあるものの、この「採用データ分析事業」では、多少なりとも避けることができた気がします。

Make Something People Want（人々が欲しいと思うものを作れ）
と、スタートアップ界隈ではよく言われます。

そりゃそうだろと思うかもしれませんが、今回のマッチングプラットフォームがいい事例です。

これだと思って進めていて、いざその時が来た時、誰も買わない（自分でさえも買わない）ということが往々に起きてしまうのです。

作り手のエゴに他なりません。

今回はたまたま「これ欲しい」というご縁に巡り会えて、ちょっとしたヒントを得ることができました。

これから先、「Make Something People Want」を実践できるように頑張っていきます。

1月24日からは他の企業にもヒアリングをしていきます。

長くなりましたが、以上となります。
最後までお読みいただきありがとうございました！

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