転職市場、その入り口

これは Sansan Advent Calendar 2019 5日目の記事です。

導入

誰?

Sansan株式会社でエンジニア*1採用を担当している高橋です。 去年までSansanでサーバーサイドエンジニアやってました。 Follow me.

なんの話?

エンジニアやってたとき、採用ってよくわからんけど大変そう という印象でした*2よくわからんけど の部分の入り口を知ってもらいたいなぁと思い、記事にしてみました。

転職の入り口

ある人がポジションに応募するまではいくつかの経路があります。

自己応募

自分から、この企業に入りたい!と思って応募するパターン。 更に、これもいくつかのパターンに分けられます。

企業のWebページから

企業のWebページ*3から採用ページに飛び、ポジションを選んで「応募」をクリック。

企業側からすると、最もありがたいパターンです。なぜなら、コストが最も低いから (Webページの運用コストくらい) 。しかし、これで欲しい人に応募してもらうのは難しいです。企業イメージをいかにマスに訴えていくかがポイントです。

候補者側としても、もし行きたい企業が決まっているのであれば手っ取り早いです。

各種Web媒体から

求人を複数掲載している Web サービスから、条件を入力、絞り込んで応募する。

媒体もさらに2パターンに分けられます。求人情報や候補者をその企業がコントロールするパターンと、転職エージェントがコントロールするパターン。前者であれば、候補者は応募後に企業と直接やりとりします。後者であれば、候補者は応募後に転職エージェントとやりとりします。

企業側からすると、前者のほうがコストは低く済むことが多いです。なお、多くの場合コストは内定承諾のタイミングで発生します。初期費用が発生する、あるいはサブスクリプションの場合もあります。

スカウト

候補者がスカウトをもらうというもの。トートロジーで申し訳ないのですが、スカウトを送る主体にパターンがあるのでこんな表現になってしまいました。

企業スカウト

企業が何らかのデータベースに対してスカウトを打つというもの。データベースにもいろいろあります。上記のWeb媒体でスカウト機能があったり、あるいは各種SNSなどで声を掛けたり。Web媒体でスカウトした場合、やはり多くの場合、内定承諾のタイミングでWeb媒体に対して支払いが発生します。

通常、スカウト後は企業と候補者は選考ではないカジュアル面談を行います。候補者はカジュアル面談を経て、興味をもったら応募します。すぐに転職するつもりはない人もいるので、そうした場合はまた後日に応募することもあるでしょう。

転職エージェントスカウト

転職エージェント(この場合はヘッドハンターと呼ばれることもありますね)が何らかのデータベースに対してスカウトを打つというもの。そのデータベースは、自社が運営するWeb媒体の場合もあるし、他社が運営するWeb媒体の場合もあります (転職エージェントによって異なります) 。

その後、候補者は転職エージェントとやりとりすることになります。候補者転職エージェントと面談し、いくつかポジションを提示されます。その場で応募するか、あるいはまた別のポジションを検討するか、はたまた一旦転職はやめとくか。

転職エージェント

転職エージェントへの流入は、上記で登場した「転職エージェントが運営するWeb媒体からの自己応募」と「転職エージェントスカウト」、あとは「転職エージェントが主催するイベント」と「口コミ」あたりになります。「口コミ」とは、例えばある候補者が転職成功し、その知り合いが転職を検討していて転職エージェントを紹介する、あるいは単純にその転職エージェントの人脈からの紹介というパターンがあります。

転職エージェントも多くの場合、内定承諾のタイミングで企業へのコストが発生します。企業スカウトよりはコストが高いことが多いです。

転職エージェントも大きく2つに分けられます。初見だとわかりづらいかもしれないので、交互に読むと理解しやすいかと思います。

分業型

転職エージェント内で企業担当 (Recruiting Adviser; 通称RAと呼ばれます) と候補者担当 (Career Adviser; CA やCareer Consultant などと呼ばれます。転職エージェントによって呼称が異なります) が別れている、というものです。企業担当は、クライアントである企業に会い、ポジション詳細についてヒアリングし、候補者担当に伝えます。候補者担当は、企業担当から聞いた情報をもとに、複数の企業のポジションを候補者に提案します。選考に進んだあとも、進捗については企業、候補者それぞれの担当がそれぞれと会話します。

候補者を多く抱える、大規模な転職エージェントだとこちらを採っていることが多いです。

両面側

両手型とも呼ばれます。1人の転職エージェントが、企業にも会うし候補者にも会う、というものです。

比較的小規模、あるいは個人でやっているような転職エージェントはこちらを採っていることが多いです。こちらの流入は上記「口コミ」が占める割合が比較的高いです。

リファラ

企業の社員が、その知り合いに応募を薦めるというものです。インセンティブの仕組みは企業それぞれ。内定承諾で報奨金だったり、あるいは会食に行くとその分を補助したり。スタートアップでは内定承諾でビール1杯のこともあるかもしれません。

ここ数年でリファラル活用が話題となることが多いです。コストが比較的低く済む、また「優秀な社員の知り合いは優秀であるはず」という仮説が強く支持されているという背景があります。

イベント

採用イベント、あるいは勉強会などから応募するパターン。採用イベントにも色々あり、企業が主催する場合、転職エージェントが主催する場合。また内容も単純な説明会の場合、あるいは選考会と題して、面接まで実施する場合。大手転職エージェントによる「転職フェア」みたいなものも、ある意味ここに入るかもしれません。

再アプローチ

これは何でしょうか?

一度企業が接点をもった候補者に対し、企業が再び声をかける、というパターンです。

このパターンを敢えて分ける必要はあるのでしょうか?これは、企業側のアプローチとして近年注目されているものです。

一度企業が接点をもった候補者の集合はタレントプールと呼ばれます。多くの社会人は、転職しても一定期間働き続けます。転職して一定期間経ち、「そろそろ新しいキャリアを考えてもいいかもな、とはいえわざわざ動くほどでもないな」という人は転職市場に出てきていない状態です。企業がタレントプールに継続してコネクションをもっていると、候補者が転職市場に出る前に応募につなげる可能性が生まれます。営業、マーケティング界隈で名著とされる「THE MODEL」でも、受注を逃した案件を再度追う重要性が語られています。

しかしこの手法はまだ成熟しておらず、各企業もパターンを模索しているところです。

というような話を

技術書典8 で出そうと思っています。今回は入り口でしたが、選考に入った後の話とかも含めるつもり。自社の取り組みではなく一般論にする予定です。

*1:ITエンジニアを指します。

*2:まあ大変なのは想像どおり (想像以上) なのですが。

*3:Web ではなく窓口に電話するっていうパターンもありますかね。

人前で喋るときに気をつけたいこと

最近スピーチ講座いったり鴻上尚史さんの本よんだりして、自分が気をつけたいことをまとめてみます。

声の大きさ

  • 基本的に張る。
  • 特に、文章の後半で徐々に小さくなるのを防ぐ。

声の高さ

  • 緊張すると自然と高くなるものらしく、逆に意識的に低い声を使って緊張してないと言い聞かせることも有効らしい。
  • 一定だと飽きられる。大事なところで高くしたり低くしたりする。

スピード

  • 緊張すると速くなる。自分で喋ってる言葉が耳に入るのを意識する。
  • 大事なところは特にゆっくり。

滑舌

  • スピードと同様、喋ってる言葉が耳に入るのを意識する。
  • 口の開け方。思ってるより開ける。

身振り

  • 無意識に手を振ったりすることがある。聞き手の気が散るので意味のない身振りをしない。

目線

  • 基本的に聞き手を見る。少人数であれば全員の目を見る。長さは1人あたり1文くらい、短すぎると慌ただしい。
  • 気を抜くと PC 見たり投影されてるスライド見ちゃう。キョロキョロしてみっともなくなりがち。

喋るって大変だなぁ〜〜

NETFLIXの最強人事戦略 読書メモ

 読みました。

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

 

読んで、思ったことをまとめます。以下の内容は、かならずしも本書の内容に一致するものではありません。

情報はオープンにしよう

経営陣の判断や議論の経緯、社員の不満、双方向に情報が言い合えるようにする。「このプロジェクトうまくいかないんじゃないかな...」なんて情報も大事だ。とはいえそれをうまくやるには運用を丁寧に考える必要がある。しかし経営陣が気づけなかったことを現場社員が指摘し、結果成功した、ということが NETFLIX でもよくあったらしい。

オープンな議論のためには技術が必要だ。ファシリテーションがなければ議論は容易に破綻する。社員に適切な教育をしたり、ファシリテーションに長けた社員を配置することが大事だろう。またその結果をいかに共有するかも難しい問題だ。

リクルーターはビジネスを知ろう

必要な人材はどんなスキルを求められているのかを知るべき、ということ。それができたらヘッドハントにしろスカウトにしろ、スピーディに的確に実現できる。

そのために、そもそも組織がどんな人材を必要としているのか、現場が明らかにする必要がある。いま必要な人材もそうだし、6ヶ月後にビジネスがどうなっていて、そのときに必要となるだろう人材もそうだ。成長企業は特に、それまで組織に存在しなかったポジションが求められるようになることもあるため、想像力と他社の知見が大事だろう。

人事考課を廃止できないか検討しよう

NETFLIX は人事考課制度を廃止したらしい。人事考課は、とにかく時間がかかる。とくにマネジャー層は、その時期になると相当の時間が奪われる。人事考課の目的は通常、給与計算だろう。廃止するためには給与計算の仕組みを変える必要がある。本書では「給与を業績だけに連動させる」とある。「情報はオープンに」とも関連するが、業績をいかに給与に反映させるか、の情報も明確に打ち出すことになる。このあたりは詳細に書かれていないが、慎重になる必要があるだろう。

2018年に知って惚れたアーティスト

以前から活動していた方々もあり。去年はこちら

関取花

youtu.be

広島にいったとき、たまたまラジオの公録をやっていた。いい声〜と思って CD 買った。歌詞も良い。めっちゃ良い。魂。

ルックスで売ってないのも好き。

John OFA Rhee

youtu.be

Spotify で流れてきた。ふだん韓国の曲は全く聞かないけど、ドラムにしろギターにしろ音が良くて気に入った。韓国も良いじゃない。となった。

スペクトラム

youtu.be

スタン・ハンセンの入場テーマのアーティスト、というのは知ってたけど、ある曲をアレンジして演奏することになって他の曲を知った。クソかっこいい。ラッパやべぇしベースも鬼

Kutiman

youtu.be

ファンクやらアンビエントやらダブやら、ひたすらに音とグルーブが気持ちいい。

学びたい技術と今の理解

2019年に学びたい技術がいろいろある。現時点でのふんわりした理解をまとめておく。

GraphQL

GitHub 製。REST のツラミを解消するクエリ言語。 REST だとエンティティごとにエンドポイント用意して、それぞれクエリを受けて、という実装をする必要があるが GraphQL ならエンドポイントはひとつでよく、 json でクエリ条件を記述する。

わからないこと

  • サーバー側どんな実装になるのか
  • レスポンスコードどうなるのか
  • ページネーションどうするのか
  • 複数エンティティとれる??みたいな噂があるけど、実装どうするのか

Flux

フロントエンドのアーキテクチャ設計思想。 React と相性がいい。

わからないこと

  • フレームワークがあるのか
  • vuex は Flux なのかか
  • 実際どうなのか
  • MVC / MVVM と書き味どう違うのか

gRPC

Google 製の RPC 用プロトコル。 Protocol Buffers でシリアライズする。 Go と相性がいい。

わからないこと

  • Go 以外はどうなのか
  • どんな実装になるのか
  • そもそもなんで RPC したいんだっけ

Firebase

GCP の 1 サービス。CRUD 程度の簡単な API 実装が吸収できるらしい。

わからないこと

  • コスパどうなのか
  • エラー処理どうするのか
  • バージョン管理どうするのか
  • デプロイどうするのか

Service Worker

Web ブラウザのバックグラウンド JavaScript 実行環境。たぶん並列処理っぽいことができる。たぶんキャッシュもうまいこと扱える。

わからないこと

  • 実際なにができるのか
  • PWA との関係
  • 仕様としてどこまで確立しているのか

2018年

1年を振り返ります。いろいろやってた気がしてけどそうでもなかった。あと月で偏りがある。


1月 たぶん仕事してた

2月 サービスローンチ

3月 面接に加わる

4月 勉強会登壇、ダテカン13回定期、柏交響楽団エキストラ

5月 広島ひとり旅

6月 バンドアレンジ、植樹

7月 オペラ祭り、部長陣議論ファシリ

8月 マインドフルネスの会、イタリア演奏旅行

9月 北海道、秘密のプロジェクト

10月 技術書典

11月 朝日新聞デビュー、初プロレス観戦、phantom参加

12月 人事部へ異動、ダテカン14回定期、大喜利

 

ま、でもいろいろチャレンジできた1年でした。これからはチャレンジだけじゃなくて成果に繋げていきたい所存。

Clean Architecture より、3つのプログラミングパラダイムの本質

読んでいます。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

第3章~第6章で、3つのプログラミングパラダイムについて語られています。

Uncle Bob (著者の愛称) いわく、これらそれぞれはプログラマーに何か能力を与えるのではなく、プログラマーの能力を制限している。すなわち「何をすべきではないか」を規定しているのだ。構造化プログラミングは直接的な制御の移行 (goto) を封じ、それてによってプログラムの反証可能性を確実なものにする。オブジェクト指向プログラミングはポリモーフィズムによる依存関係逆転によって、制御の移行の方向を制限する。関数型プログラミングは、変数を固定にし、代入を制限する。これらによって、コードベースに秩序がもたらされる。

これは味わい深い話だ。コードベースでは数十年にわたってこうした「何をすべきではないか」を学んできた。アーキテクチャレベルではどうだろうか?恐らく「どんな実装をすべきでないか」を完全に制御できるようなアーキテクチャは現実的ではない(実装者に依存する)だろう。これをどうやって規定し担保していくか、がソフトウェアアーキテクチャの難しさだろう。たとえば Microservices Architecture は最近、山のように「すべきではない実装」が書籍だったりブログだったりで報告されているが、それらを厳密に体系立てられたパターンとして制限できるような仕組みが生み出されるには至っていない。ソフトウェアアーキテクチャはまだまだ進化の途中だ。