「難しい」「出来ない」は「なぜ」で分解して考える
INST石野です。
最近知り合った石倉さんがすごくいいnoteを書いていました。ちょっと僕の周辺でも話題になっております。
とても優秀な方で、リクルートでHR系の営業→立ち上げ間もないリブセンスで事業部長→DeNAでEC系の営業責任者→採用責任者などなどというすごいキャリアの方です。少し一緒にお仕事させていただいたりしておりますが、極めて実務ベースが強く、オペレーション処理能力も高い、めっちゃ優秀です。全然僕なんかより仕事できますw
石倉さんのnoteはエンジニア採用って難しい難しいってみんな言うけど、果たしてどのくらい難しいのか考えてみるというアプローチ方法で、前編は市場データと推測で難易度予測を、後編は自身の経験や知人からの意見をまとめて「じゃあどうアクションするのか」というのをまとめられております。
採用手法に関してはぜひ石倉さんのnoteを見ていただくことにして、こういった思考の仕方がすごく大事だなと思いましたので、なぜ僕がそう思ったのかを書いていきたいと思います。
「難しいよねー」「そうだよねー」では一生問題は解決しない
エンジニア採用が難しい、というのはずっと昔から言われていることですね。僕も人材紹介やってたことありますが「ウチエンジニアめっちゃ取れてますわ、はっはっは」なんて経営者や人事採用担当の方にはお会いしたことがありません。
多くの人材紹介会社の営業担当の方でもエンジニア求人をお預かりしたら、「エンジニアっすかー、厳しいと思いますけど頑張ります!」と口では言いつつも、半ば気持ちは諦め気味になり、「ちなみに経理のポジションとかってないですかね?」とか聞いたりすることもあるでしょう。なんてったって推薦すら出来ないということも全然ありますからね。
ここで
「なんで採用できないのか、一緒に考えてみませんか?」
と言える営業は、少し「お?こいつ出来る?」と思われる可能性があります。少なくとも僕はそう思いますかね。
「難しいですよねー、できないですよねー、そうですよねー」と同調ばかりしてくる営業担当は多分本当に使えません。言われたオーダーに合致する人だけ自社のDBで探して、いなかったら二次媒体のDB探して、「ダメでしたわー」と報告するだけ。一歩も、どころか1㍉も採用成功に近づかない。
採用ができない、という事実だけ確認するのではなく、それはなぜ出来ないかを因数分解して、分解された因数を一つ一つ潰していくことでしか課題は解決されないのです。因数分解って英語でFactrizationって言うんですってね。今回調べたんですけどすごくハラオチしました。
採用を成功させるためのスキルを人事と紹介会社/採用サービスが補完しあう事が大事
極論を言うと、人事採用担当の人が
・現場から上がってくる求人オーダーをちゃんと理解して
・今人材紹介会社が見ている求職者DBをくまなくチェックして相場観を完璧に頭に入れてあって
・それじゃ無理、こうしないと取れないとちゃんと現場にフィードバックできて
・スカウトが打てて、面接で口説けて
となったら、人材紹介会社の存在価値はほぼゼロになってしまうと思います。
でも多くの人材紹介会社がビジネスを成功させられているのは箇条書きで書いた項目や、それに付随する何処かが採用企業側に欠けているからでしょう。採用担当と紹介会社がニコイチで採用を成功させるためのスキルを補完しあうことで採用が初めて成功するのではないかと。
それを、オーダーもらってきて「そうですよねー、採れないですよねー」と鸚鵡返しするだけでは全然問題外です。それでいいと思っている人事の人もどうかと思いますけどね。
採用にありがちな課題「穴埋めだけしようとする」「既存メンバーと同スペック要求」
多くの難解なオーダーはこの2つで生じているのではと思います。
「25歳くらいでー、気が利いてー、英語もできてー、OAスキルも高くてー」
おい、それって辞めた(もしくは辞める予定)の人のコピーロボット採用しようとしてるだろ、というやつ。まあ、その辞める予定の人の保有スキルがそんなに高くなければ、難しくないオーダーである場合も多いですが、企業側は主に既存社員の活躍を成功体験として次にそのポジションに入る人にも求めがちです。
・本当に25歳位でなくては行けないのか?35歳とかまで年齢許容できないか?
・気が利く?ってどういうこと?
・英語Must?どのくらいの頻度で英語使うの?外部の翻訳会社使うじゃだめなの?
・OAスキルが高いってどのくらい?Accessバリバリこなせないとダメ?他のツールで補完できない?
条件については、こんな感じで掘り下げていくことが大事かと。
育ってきた環境が違うから~と、山崎まさよしが歌っていましたがまさにその通りで、完璧に同じ人間なんていないので、穴埋め採用、既存メンバーと同スペック要求なんて無理な話です。現場は「あの人がもう一人いたら良いのに」「あの人と同じことやってもらうから同じ条件」とオーダーをあげてきます。そこをちゃんと噛み砕かないとね。
僕が思うにエンジニアはもっと稼げて良いはず。受託開発が悪。
幸いなことにINSTにはスーパー優秀なエンジニアが2名おりまして、ふたりともフルスタック。サーバーサイドからアプリケーション、最近はUIまでデザインできるようになるというまさに神人材です。
自社サービスを作ると決めたひとつの要因は、エンジニアの人を正当に評価したいと思ったからというのもあります。
受託でどっかで見たことあるシステムと似たようなシステムを開発しても、それは時間の切り売りに過ぎず、給料を上げてあげることは困難だと思いました。なので、自社サービスを作ってもらって、僕が頑張って売って、利用して下さる企業を増やして、その上で追加開発をすることで(例えば有料オプションとか)、その追加開発のバリューが×(かける)導入者数分にレバレッジがききます。
ショット型ではなく、サブスクリプション型のビジネスモデルで勝負することで、エンジニアも営業も、頑張れば頑張るほど評価できるようになるなと。※これは僕の持論なので、ショット型でしか売上を上げることが難しいビジネスモデルや領域もたくさんあるのはわかっております。
企業側もエンジニア人材の評価を「労働工数」だけではなく、携わったシステムの売上に連動させるなどすれば、もう少しエンジニアの人達に給与をあげることができるようになり、採用力がつくんじゃないかなーなどと思ったりしました。
受託開発のエンジニアベースの給料がなんとなく「相場」的になってるからあんまり希望が持てないんじゃないかなと。
石倉さんのnoteみて思ったことをつらつらと書いてみましたが、やっぱり最近思うのは、採用担当総メスライオン化がこの後の日本には必要ということですかね。ちなみに今日はメスライオンと石倉さんとランチです。楽しみ。
石倉さんの会社はこちら→働き方ファーム
それでは。
Kosuke