読者です 読者をやめる 読者になる 読者になる

採用の科学

BizReach社主催のプロリクルーターカンファレンスに参加してきたのでメモ。

Pro Recruiter Conference 2017

f:id:charly24:20170223004950j:plain

参加のモチベーションは、もっとエンジニア採用うまくするために何かヒントは無いかなというのと、採用学の研究をされている横浜国立大学大学院の服部さんの話しを一度ちゃんと聞いてみたかったから。 会場は録音や撮影はNGとのことだったので、学びの要点をまとめておく。

他に特に面白かったセッションとしては、アマゾンジャパンのTalent Acquisition Managerの篠塚さんの話しはとても勉強になった。

プロリクルーターとは

アマゾンジャパンの篠原さんの話しの中で、プロリクルーターを高級なお寿司屋さんのメタファーで説明されており、すっと理解できました。

  • 高級なお寿司屋さん:顧客一人ひとりを細かく把握して、ニーズを見て提案できる
  • プロリクルーター:候補者個別の情報を見てどうマッチするかを判断して次の工程に適切にレコメンドできる

※回転寿司のように同じ寿司ネタをみんなに同じように出す=どの候補者に対しても同じ対応をする採用担当者をアメリカでは「ベンディングマシーン/自動販売機」と読んでいるようです

また、アマゾンジャパンでは、リクルーティングにフォーカスできる環境のために、採用に特化するプロリクルーター・採用業務のサポートをする人・プロセス全体を俯瞰して簡素化する人(Cost per Hireの最適化〜採用のアセスメントには莫大なリソースがかかるので、どう自動化して正しく採用するか)は明確に分けているとのこと。

最近エンジニア採用に注力していたので、漠然と人事 に興味を持つようになっていましたが、人事機能と採用機能は明確に分けていくべきとの話しを聞き、組織の改善そのものにも興味ありますが、採用・リクルーティングなんだなと理解できたのは学びでした。

※採用がおもしろいと感じるのは、面談で会った人に弊社のことを説明して、帰るときにはその弊社のことをより深く知って興味を持ってくれるようになってることに喜びを感じているようです

採用を科学する

先のアマゾンジャパンの篠原さんの話しとリンクしますが、服部さんによる採用学の話しも面白かったです。 「プロリクルーターの育成が急務」とのことで、いくつかの研究結果を聞けました。

2005年のChapmanの研究(おそらくこちらで、$11.95かかりそうだったのでAbstractしか読んでないですが、ハイパフォーマーに与える因子のメタ分析の研究結果。Applicant attraction to organizations and job choice: a meta-analytic review of the correlates of recruiting outcomes. - PubMed - NCBI)によると、リクルーターの行動が仕事や組織の特徴と同等に影響を及ぼしており、括弧内が「影響を及ぼしている度合い」として、以下の結果だったとのこと。

  • 仕事や組織の特徴(57)
  • リクルータの人柄(50)
  • リクルーターの振る舞い(26〜42)

また、リクルーターに対して候補者が「専門知識を保有している」「人物としてこの人は信頼できる」と認識できるかが重要とのことで、経験則ととても一致してました。

面談中、私の技術や組織やプロダクトに関する説明に興味持ってもらえたり、余談多く本心からの「個人的にはこんなことしていきたいんですよ〜」という話しに聞き入ってもらえた時は、候補者さんからのレピュテーション向上できたなと感じることができていたので、リクルータの能力値・言動が求職者の入社意思決定を左右しているのはそのとおりだなと。

他には、リクルーター言語化能力として言葉にするうまさが大切で、「優秀ですね」「コミュニケーション能力ありますね」という単語一つとっても腹落ちする言葉かどうかで変わってくるというのもその通りだと思います。うちの人事担当者はMTG中でも相手が吸収しやすい適切な言葉をていねいに使うのは、なんらかそういった教育を受けた・経験を積んできたのかなと改めて感じました。

服部さんの採用学に関する統計資料は【採用学 I】採用学研究所 服部泰宏准教授 ☓ ビズリーチ|「良い企業・成長する企業」の 採用活動の分析などにまとまっているので、一読の価値があるかと思います。

これからもエンジニア採用がんばってこう。

p.s. 服部さんの話しの中で、TOPパフォーマーの採用に関する研究は海外ではとても盛んで、記事を書く中でたまたま見つけたTop 15 Recruiting Statistics for 2014にはJobviteの統計によると米国労働者の71%は雇用/転職市場にいる、94%が転職にLinkedInを利用しているが採用側の利用は36%など、調べてみると色んな情報を得られそうです。 転職顕在層向けのサービスは当然として、これからはより転職潜在層へのサービスが増えてくるんだろうなと。

データ分析環境の構築

2017年に利用していく技術領域にてJupyterで視覚化するための環境を構築すると書いてましたが、一部構築できたのでこちらにも記述しておきます。

JupyterHubでGitHub認証×Django連携するデータ分析環境を構築する

以下のような構成でELB→EC2→nginx→JupyterHub(Tornade)→Django→RDSという流れが構築できます。 f:id:charly24:20170219181718p:plain

環境としてはDjangoを利用できるように設定してますが、JupyterHubのKernelの仕組みを利用すればRailsやその他コマンドライン環境をつなぐこともできるはずです。

構築しようとした背景としては、以前Tableauを導入したところ重量級過ぎてビジネスサイドに利用されなかった経験もあり、誰でも一定のITスキルを持っていればパラメーターを変更するだけで視覚的に結果を確認できる環境はあった方がいいなと考えたところからです。DailyでマスクされたDBを構築する仕組みも別途あるので、 Redashと連携させるのも良さそうです。

2017年に利用していく技術領域

2016年6月16日にレクミーキャリアをリリースして約半年、会員登録したユーザーさんへのマイページの提供や、裏側のキャリアアドバイザーさんが業務を回すための予約管理やユーザー情報把握の仕組みなど、必要最低限の機能は提供することができたと思います。 recme-career.jp

現在レクミーキャリアの開発メンバーは2名ですが、まだまだユーザーさんへの価値提供のために必要なものは多く、今後利用者も増え開発エンジニアが増えていく前に構築しておくべき技術領域を整理しておこうと思います。 ここ半年間、大きな負債を残すことなく開発を続けてこれた反面(負債を少なく保つために心がけたことは別途記事にします)、以下のような箇所はまだまだ改善ができると考えてます。

  • データ分析
  • インフラ
  • フロントエンド開発
  • スクラム開発

データ分析

新卒側のレクミーのマネージャーをしていた頃、データ分析の必要性を感じTableauの導入を行いましたが、その後社内にTableauを利用する文化を育てることができず頓挫してしまったという経験があります。 Tableauがやや重量級で、使いこなせなかったという理由はなくは無いが、それより日々の業務に直結するユースケースを提供して、データを分析することによってユーザーさんへの価値が向上する・そのためBIツールをこう使っていこうというストーリーを提供しきれなかったのがメインの理由だとは考えてます。 Tableauを再トライするのか、もっと簡単なデータ可視化ツールなどを提供していくのかはまだ決めてませんが、社内でデータ分析を行いユーザー理解を深める機運は一つ作っていきたいと考えてます。

また、ユーザー行動/基本情報から特徴を把握して、より適切な求人情報を提供するための仕組みを提供することも1つのミッションに掲げていこうと考えており、手段が目的にならないように気をつける必要はありますが、SparkでPython使って高速に特徴抽出を行ったり、機械学習を利用してユーザーによりマッチする情報を抽出する必要があると思います。 とはいえ最初のアプローチのためにはJupyter使ってPandasの内容を視覚化してくことからなのかなと思ってます。今までその辺りが苦手て、Slackで事前に組んだKPI数値をチームメンバーに流すにとどまっているので改善できるはずです。

インフラ

現在、インフラの専任の担当者という方はいません。 新規サービスを立ち上げるときにはサーバーサイドのエンジニアが自身でインフラを構築して、その際のナレッジを構築手順書という形でまとめて、その手順を元に開発環境を構築することで成り立っています。 AWSずっぷりで構築しているためスケールアウトさせる際にはEC2をコピーしてELBに追加することで対応可能ですし、nginxやsupervisordやuwsgiなどの設定ファイルはGitHub管理されているためある程度は安全ですが、オペレーションミスの低減や構築&破棄が簡単にできる仕組みの構築のためにインフラのコード化は早めにやっておきたいなと考えてます。 また、開発環境/テスト環境用がメインの目的になると思いますが、さくっと立ち上げて捨てやすいという意味でDockerは本格導入しておくと幸せなことは多いと考えてます。

フロントエンド開発

2016年、食わず嫌いだったフロントエンドのFWを利用してみてかなり感動をしたことを覚えています。 今までjQueryでフロントエンドを構築していたため1画面での機能が増えてきた際に複雑になりがちで、他人が書いた表面のコードを修正するのがつらかったのですが、かなり薄めのFWでしたがVueを利用することでかなりさくっとそれなりの規模(jQueryで書いていたら2週間程度と想定していた)の予定管理画面をほんの数日で構築することができました。 Vueを利用することで(これは巷のフロントエンドFWの多くに言えることだとは思いますしjQueryでできないことではないと思いますが)きれいにサーバーサイドとフロントエンドを分離することができ、実際数百行程度のコードを書いてみた感想として、動作の流れも分かりやすくHTMLとロジックの分離度合いがとても適切で、Vueの分かるエンジニアなら後から保守に入っても修正しやすいコードになっていると思います。 そんな経験もあり、レクミーキャリアの裏側をAPIとVueでのフロントエンドにきれいに分離するための土台構築&実施をしていこうと考えています。競争力のある使いやすい裏側にするためには、今はこのアプローチがいいのかなと思っています。 ※デザイナーさんとの協業をどう進めていくかというのは今後課題になりそうですが

スクラム開発

チームがスクラムな状態にあるという状況の定義がまだ自分の中で得心できていませんが、2016年はスクラム的なプロジェクト運営にトライした年ではありました。 レクミーキャリア開発チームでは、イテレーション単位を1週間にして、

  1. イテレーション初日にプロダクトオーナーとともにキックオフ(スプリント計画)をしてその単位での作業量をメンバーに割り振る
  2. 毎朝、朝会(デイリースクラム)をして前日の進捗と本日の予定、困っていることをチームで共有する
  3. 単位としては長いが、約1ヶ月に1回の単位で振り返り(スプリント振り返り)を行い、チームのアウトプットをレビューする
  4. 仕様はGitHubのIssueにまとめて、PR単位でレビューを行い適宜リリースする
  5. 別途、毎週1回KPTとして開発チーム全体の改善案をまとめる

※全てがスクラムの儀式というわけではないが、開発の大きな流れとしては上記のように進めている

という進め方は一定まわるようになってはきているがまだまだ改善の余地があり、

  • イテレーション毎にざっくりと見積もって入るが過不足が毎回あり、ベロシティが安定しているという状況ではない
  • デザインスケジュール・仕様詳細FIXのために、スプリント計画参加者だけでじゃそのタイミングで要件が固まりきらないことがある

と、平たく言うと計画の部分に課題を感じているので、私以外のメンバーもスプリント計画の中で開発スケジュールが明確になるまで要件を詰められるように事前準備をしておき、計画終了後には全員が同じレベルの情報を得ており開発に集中できる状況を作っていきたいと考えております。

おわりに

新年2記事目にして2500文字オーバーの記事を書いてみましたが、まだまだ長文を書いた際の文章力が無いなぁと反省。。 もっとまとまっていて読みやすく、読んだ方にとっても価値ある文章となるよう精進していきます。 とはいえ、最初に頑張りすぎてガス欠にならないようにも注意しないと。

2017年ブログはじめました

2017年、あけましておめでとうございます。 知識の整理とアウトプットによる弊社価値向上を狙い、日々ブログ記事を記述していくことにします。

主に以下のようなことを記述していき、技術ネタやWEB業界/スタートアップ(って表現が正しいのか)に興味がある方にとって価値あるブログになっていけるよう精進してまいります。

  • スタートアップでのプロジェクトマネジメント
  • エンジニア採用に関する知見
  • プロダクト開発について
  • DjangoAWS機械学習などの技術知識
  • etc...

2017年は、以下を目標にします。

  • 年間50記事以上記述する
  • 50冊以上の書籍を読了する
  • 映画を25本見る
  • 毎月テーマを決めて、学ぶ
  • エンジニア採用の土台を確立させる
  • スマホアプリを作成してリリースさせる
  • 英語力を向上させる(TOEIC XXX点を目標にする)
  • 勉強会での発表を行う(定量目標未定)
  • ゴルフで120を切る(初めて3ヶ月、現在150。。)