2021年10月末でLAPRAS株式会社を退職しました。創業間もない2016年11月から参画していたので、5年間働いたことになります。1社目が1.5年だったのでその3倍強働いたことになりますが、そんなに長くいたかなと思うほどあっという間な5年間でした。

5年間やってきたこと

2020年夏までにやってきたことは「LAPRAS CTOを交代します」の記事に書かれているので割愛して、最後の1年間SREとしての活動を少しまとめておきます。

上の記事で触れていた

SREに専念できるようになったらエラーレートやレスポンスタイムのサマリをサービスのステータスページで公開したりと、品質も定量的な形でユーザの皆さんにお見せしたいと考えています。

については(自分でも忘れていたのですが…)簡易的なものですが https://status.lapras.com/ に誕生しました。エラーレートやレスポンスタイムなど普段Datadogで社内で見ている数字も外部向けに公開したら皆に興味を持ってもらえるのではと思っていたのですが、残念ながらそこまで手が回りませんでした。

主に力を入れていたのはSLOの運用開始で、詳細は「LAPRASにおけるSLO運用状況」にまとめています。またインシデントを想定して対処方法を確認する避難訓練なども行いました。「LAPRASインフラチームで避難訓練を行いました

LAPRASの良さ

社内のメンバーには何度も言っているのでもう聞き飽きたという感じかもしれませんが、5年間を振り返って一番最初に出てくる感想は本当に良いメンバーと働けたなということです。

自分の中での “良いメンバー” の定義は、

  • 自分には無いものをたくさん持ってきて、一緒に働くことでプラスの刺激が得られる
  • 誰かを攻撃したり、モチベーションを下げるようなコミュニケーションをするようなEvilな人ではない

の2つを備えたメンバーのことです。

仕事内容というのは、気が乗る刺激的なタスクがあったり、時にはやる気が出ない退屈なタスクがあったりと波がありますが、一緒に働くメンバーは変わりません。メンバーが良ければ毎日が幸せです。一度も今日仕事したくないなーと思ったことがなく、毎日楽しく仕事ができていたのは良いメンバーに囲まれていたからだなとしみじみ感じます。

良いメンバーで組織を構成できたのは、代表の @hshimada_ が社内の平均よりも優秀なメンバーしか採用しないというポリシーを定めたり(組織の拡大に伴ってこれを維持し続けるのは現実的ではなく現在ではこのルールはありません)、かなりの人数になるまで全員でカルチャーチェックを行なっていたことが大きな要因だと思っています。(参考: なぜLAPRASは25人対1人で採用面接を行うのか?カルチャーマッチの重要性について)

また、大学の同期(@hshimada_, @r_takahama)と一緒に仕事ができたのも 大変幸せな経験でした。友達と仕事をすると距離感が難しいかなという不安もありましたが、馴れ合い過ぎず、パフォーマンスが最大限に発揮できる適度な距離感で仕事ができた気がしています。@r_takahama とは意図せず近いタイミングでの転職となってしまいましたが、お互い新しい環境で成長してどこかでまた一緒に働けると良いですね (参考: LAPRAS株式会社を退職します)。一気に寂しくなってしまった @hshimada_ ゴメンネ。。

LAPRASへの感謝

改めて、スタートアップに3人目のメンバーとして関わり、短期間で様々なフェーズを体験できたことは稀有な経験だったと思います。0→1の何が正解か模索するプロダクト開発から、チームマネジメントから、1→10、10→100の堅実なプロダクト開発から様々なことを体験できました。@hshimada_、本当に自分を誘ってくれてありがとう。そして卒業記念の新アイコンもありがとう!(これを機に11年間使っていたアイコンをアップデートします!!意図していないと思いますが、11年前と比べて丸い性格になったのを象徴しているようで気に入っています。)

LAPRASは優秀なエンジニアメンバーで溢れており、会社も事業も今後どんどん成長していくと思います。エンジニア採用市場のゲームチェンジャーになってくれることを信じて、今後は外から見守っていきたいと思います。

これから何するの?

11月から oVice株式会社 でLead SREとして働きます。7月頃から副業でちょこちょことお世話になっていたのですが、フルタイムでジョインすることに決めました。(読みは”オヴィス”です。”オーヴィス”とか”オヴァイス”とか色々読めてしまいますが)

LAPRASはとても居心地が良かったので、多方面でチャレンジができる環境が見つからないと外には出ないだろうなと自分でも思っていたのですが、なんとそれが見つかってしまいました。魅力的に映った部分が以下の3つです。

働く環境のチャレンジ

開発拠点が日本、韓国、チュニジア、USの4つあり、大きく3タイムゾーンで開発をしています。JST(+9), CET(+1), PDT(-7) なので勤務時間の被りがとても短く、いかに非同期で効率よく開発できるかが問われる環境です。

また上記のように多国籍チームなこともあり、開発チームの公用語は英語になっています。今後外資系の企業でも働けるように英語は身につけていきたいと個人的に思っており、日本語と英語と両方使える環境でトレーニングできることは魅力的でした。(ビジネス側のメンバーはほとんど日本なため、全社では日本語が公用語です)

ちなみに現状でいうと、5月ぐらいから英語の勉強を始めて7月に受けたTOEICで870点で、それ以降DMM英会話を毎日1,2レッスン受けてますが、仕事のMTGでは8割ぐらい言っていることは分かる、伝えたいことは3~4割ぐらい伝えられるという状況です。文章の構成が日本語と違うので、自分から発することに慣れないとスラスラ喋られるようにならなそうだなと最近感じています。。

技術的なチャレンジ

SREとして、よりトラフィックの多いサービスで高いReliabilityを保っていくチャレンジをしたいという思いがありました。oViceは急速にユーザ数が増えていて、またサービス内には通話、画面共有などインフラに負荷がかかる機能も備えています。このようなサービスを保守/運用していくことで、SREとしてまた一歩成長できそうに感じています。

アプリケーションもElixirでリプレース中であり、プログラミング言語的にも面白い挑戦ができそうだなと思っています。仕事で関数型の言語をメインで使ったことがないので、こちらも楽しみです。

リモートワーク普及へのチャレンジ

新卒でフルリモートワークの企業に就職し、LAPRASでもコロナ禍以降はフルリモートワークで働いていました。なるべく外に出たくない性分の自分としては、オンラインでいかに生産性高く働くことができるかという課題に関して強い関心を持っています。

COVID‑19の蔓延により、半強制的に多くの人がリモートワークを体験しましたが、まだまだ世の中のリモートワークツールが不十分で、特にコミュニケーション量や質に関して課題を感じた方々が多かったように思います。

すべての人がリモートで働けるようになるとは思ってはいませんが、潜在的にリモートワークが可能な職種の人たちが特にコミュニケーション面で不自由なく働ける環境が提供でき、コミュニケーションを理由として出社させられてしまう世界を変えていきたいです。

コロナが少し落ち着いてきた今日、リモートワーク文化がどこまで残り続けるのか、それはツールの進化にかかっています。oViceを通じて働き方の選択肢の幅を増やしていきたいと思っています。

おわりに

実はoViceの開発組織は今年の夏に内製化に踏み切ったばかりで、まだまだ開発者も足りていない状況です。少しずつ足場を固めている状況ですが、そのような環境から一緒に開発組織を作り上げていただける方を絶賛募集しています!

会社概要については こちらのスライド をご覧ください。
VPoEの入社エントリー もぜひ!!

(最後にたくさん広告してしまった)

2020年10月1日よりCTOを辞任して、@rocky (興梠 敬典) にCTOを交代こととなりました。社内的には9月から役割交代をしていて、すでに新体制でゴリゴリ進捗を出していただいています。

このような記事は長くなりがりなので、最初に要点をまとめておきます。お時間がある方は最後までお付き合いください。

概要

私は創業2ヶ月後の2016年11月に創業メンバーとして入社しました。入社当時は社名がLAPRASではなくて、scoutyでした。19年4月に社名変更しています。 私が1人目のエンジニアであったこともあり、2018年7月からCTOを任せられ、約2年強の間やってきたことになります。当時は社員が19名でしたが、今は27人となりうちエンジニアが9人。売上の多くを占めるエンジニアの採用サービスである LAPRAS SCOUT の利用社数もその間に2.5倍になっています。

数字だけを見ると、この間に社員数は10人も増えていないのですが、最近は30人の壁を感じることもあり、きちんとマネジメントをして組織のアラインメントを強めていくことの重要さを感じる場面も多くなってきました。

そのような状況で、これから会社をより一層成長させていくことを考えたときに、自分のマネジメント能力でチーム・組織を引っ張って行くことが会社にとって最適解なのか不安がありました。社内には前職でCTOを経験されている rocky もおり、普段からマネジメントをそつなくこなす姿を見ていたので、彼にCTOを任せたほうがより会社の成長を早められると判断し、最終的にお願いすることとなりました。

何ヶ月も前から相談していた訳ではなく、8月上旬に突然相談して驚かせてしまった部分もあったのですが、9月からの1ヶ月の活躍ぶりからもお任せして良かったなと感じています。

私自身scoutyに入ると決めたときに、scoutyではマネジメントの勉強・経験をして、次のキャリアではもう一度技術者に戻って技術の勉強をしようと考えていました。というのはscouty入社時点で、受託開発の会社で1.5年働いた経験のみで、そのままマネージャー職を続けるには技術的な基礎能力が足りないと思っていたからです。今回CTOを辞任して、今後SREポジションを担当するのですが、もともと考えていた ”次のキャリア” を社内のポジション移動により実現でき、引き続き自分の好きな会社で新しいチャレンジができることを幸せに思っています。

次の2,3年はSREとして成長していきますが、LAPRASの事業の特性的にインフラに高負荷がかかるようなサービスではないので、サービスのエラーレートを下げたりレスポンスの高速化を図ること、高い可用性を保つことでユーザから信頼されるサービスを提供したいと考えています。

LAPRAS SCOUT を使ってエンジニア採用をしているCTOやエンジニアマネージャー、採用担当の方、また LAPRAS を使ってポートフォリオを作って楽しんでくれているエンジニアの方、引き続き自分の身近にいる方たちに満足して使ってもらえるサービスを提供していきたいと思っているのでよろしくお願いします。

サービスの信頼性に不満がある場合には @showwin まで怒りの声をお届けください!

やってきたことの振り返り

ここからもう少し詳細に書いていきます。

  • エンジニア採用
  • 開発プロセスと役割分担
  • マネジメント

の3つについて。

まず、エンジニア採用についてです。ここは自分の得意分野だなと気付けたところであり、一番うまくできたところです。採用活動をフルタイムでやっていたころの記録は6週間に渡って毎週記事を書いていたので、詳細は LAPRAS CTOが採用担当になる のシリーズをご覧ください。

今回CTOを交代してお願いすることができたのも、社内に自分よりも圧倒的に優秀な方がいてくれたおかげであり、rocky が来てくれたのも社内にすでに優秀なエンジニアが多くいたからです。創業当時から代表の島田は自分よりも優秀な人しか採用しないと言っていましたが、そのポリシーを守り続けること、そしてそれを実現するために選考中にきちんとスキルを見極めるプロセスをコストをかけてでも整えてきたことが鍵だったと思います。

私自身scouty入社前に転職活動をしていたのですが、その時に転職者として感じた選考中の不満が多くあり、LAPRASの選考プロセスではその不満をすべて潰した最高のものにしてやる!という思いで設計した部分もプラスに働いている部分が多くあると思います。これについては LAPRAS CTOが考える 採用効率化Tips 5選 のスライドでいくつかの要素を紹介しています。

次に開発プロセスと役割分担についてです。

開発プロセスはエンジニアが3人になった2017年12月頃から現在までスクラムでの開発を続けています。スクラム未経験の状態から勉強を始め、@kajinari さんにも何度か相談に乗ってもらい、開始半年ぐらいで満足がいく開発プロセスを確立できました。(参考: 洗練されていくscoutyのスクラム開発)

2018年夏頃からはホラクラシーというティールな組織体系を取り入れたのですが、ホラクラシーは誰がなにを担当するか役割分担を明らかにし、タスクの優先順位も個々人が決めるという思想を持ったものであり、スクラムの思想とは相反する部分があります。運用1年後に Holacracy と Scrum は共存できるのか という記事を書いていますが、これは未だに自分の中でベストな解答が出ていません。

今思うと、2019年夏時点で1年運用してモヤモヤしている状態だったのであれば、そこでスクラムを一度やめて、カンバン+ホラクラシーでチャレンジしてみる等やり方を変えてみるべきでした。そこで変えられていれば今日までの1年間でまた新たな知見を得られていますからね。。

ホラクラシー+スクラムでも大きく困ることなく開発を進められている状態ですが、そこに甘んじることなくより良い開発プロセスを見つけに行く動きをするべきだったなと今振り返って思います。

次にマネジメントについてです。

エンジニアメンバーは全員私よりも経験豊富で年齢も私より上なため、私が何かを教えるようなティーチングのスタイルよりも、一緒に答えを見つけていくようなコーチングスタイルのマネジメントをするように心がけていました。

私自身技術を使ってものづくりをすることが好きな人間なので、最初はマネジメントは向いておらず、長く続かないのではないかと不安に思う部分もあったのですが、いざやってみると楽しい部分も多くありました。1on1を通じて、メンバーが直面している困難の解法を一緒に考えたり、エンジニアとしてのキャリアを一緒に考えたり、自分が壁打ちすることで何かを掴み先に進んでいくメンバーの様子が見れるのは嬉しい瞬間でした。

一方で独学でコーチングをかじっただけなので、自分自身でもうまくできていないと感じることも多々あり、次回またマネージャーになる際には資格を取りに行くぐらいまで勉強をしてみたいです。

また、対メンバーの個別マネジメントではなく、CTOとして開発組織をどのような組織にしていきたいのか、それをどう経営を結びつけるのかという点は自分の力不足でうまく貢献できませんでした。EMレベルの動きはできるけど、CTOとしては…という部分もあったように思います。

うまくできたこと、できなかったことを列挙してきましたが、これから会社が成長しより大きなエンジニア組織になっていくと、自分が苦手として挙げた部分がより重要になってきます。

苦手な部分を克服して私がCTOを続行する選択肢もありましたが、自分の現時点での興味がそちらよりも技術の方に向いていたこともあり、CTOを交代いただくことにしました。

これからなにやるの

高々2年程度ですが、少しマネジメントをかじってみて、今は3~5人ぐらいの1チームを見るマネージャーのポジションが向いていそうだなと感じており、しばらくはそのポジションに必要なスキルを身につけることに時間を割きたいと思っています。このポジションは自分もある程度手を動かしながらメンバーのマネジメントもしていく立ち位置で、技術力とマネジメント力の両方が問われます。

レイヤーとしてはインフラからバックエンドの開発が好きなので、k8sやDDDなど次の10年でデファクトになっていき、かつアーキテクトとしてチームにレバレッジをかけながら貢献できる分野の知識を習得していくつもりです。

社内では Service Reliability サークル のLead Link(SREチームのリーダー的なポジション)にアサインされているので、しばらくはインフラの面倒をみながらサービスの信頼性を高めていくことを担当します。直近はサービスの信頼性を高めることよりも、新規機能開発の方が優先度が高く、半分ぐらいはソフトウェアエンジニアをやる事になりそうですが、SREに専念できるようになったらエラーレートやレスポンスタイムのサマリをサービスのステータスページで公開したりと、品質も定量的な形でユーザの皆さんにお見せしたいと考えています。(LAPRASには「オープンであれ」「推測より計測」というアクションアジェンダがありますからね!)

LAPRASのアクションアジェンダ

上で言ったような、ビジネス的なKPIにクリティカルには効かないけれども、ユーザやエンジニア視点で面白そうな良いことやってるね!と思われることもやっていきたく、それがブランディングに繋がって良いエンジニアが集まってくれるようになると信じています。

冒頭でも書きましたが、同じ会社にいながら新しいチャレンジができることは幸運なことです。一度上のポジションになると、役職が下がるような異動は心理的ハードルが高くなりがちですが、ホラクラシーがそのハードルを下げてくれた部分もあります。(マネジメントする/される関係はあれど、各々が自分の得意分野をもってそこで裁量をもって活躍するような組織体系です)

私は社会人経験1.5年でのscoutyジョインでしたが、学生起業や私のような経験が浅い若手の起業の場合には、会社のフェーズに合わせてより経験豊富な方に経営ポジションを変わってもらう事は、会社を成長させる上で有効な選択肢の1つなのではと感じます。

また今回のCTO経験を通じて、創業から上場まで、またそれ以降も継続して経営に携わられている方々は改めてすごいな…と感じました。

最近LAPRASでは Matching Intelligence という、Web上の(ほぼ)すべての求人から個々人に合うキャリアを提案するサービスの開発に注力しています。

“LAPRAS Matching Intelligence” とか “Matching Intelligence” でググっても TechCrunchさんに書いていただいた記事 が一番上に出てきて、サービスサイトが全然出てこないのですが、 https://site.lapras.com/matching-intelligence がサイトのページになります。まだβなのでSEOも何も考えてないのです、ごめんなさい。

今回はそんな Matching Intelligence を社内実験した際に、被験者として感じたことを書いてみたいと思います。もちろん自社サービスなので宣伝記事に見えると思いますが、自分自身結構衝撃だったのでぜひみなさんにも体験して欲しいという純粋な思いも強いです。

その前に Matching Intelligence の開発背景を少し。Matching Intelligence は誤解を恐れずにいえば、機械による自動転職エージェントです。なぜ機械がやる必要があるかというと、人間(転職エージェント)には世の中に存在する求人が多すぎて、正しく比較検討して転職候補者に最適な選択肢を提案することはできないからです。また、転職候補者が能動的に転職サイトで求人を探す場合には、サービス内の検索条件の表現力が弱く自分にフィットする求人が出せない、あるいは興味のない求人まで出てきてしまって選別が大変という課題があるように感じています。

そこで Matching Intelligence では、年収や勤務地などのいわゆる基本的な必須条件で求人を絞りつつ、そこから先は転職候補者からのフィードバックを得ながら提案する求人をブラッシュアップしていく手法を取っています。まるで転職エージェントと「こういう仕事どうですか?」「あー違いますか。ではこちらは?」「あ、これは近いのですね。そうしたらその求人に近いこちらなんてどうでしょう?」と対話しているようにです。(実際にはそんな対話機能はなくてGoogle スプレッドシートに提案結果のフィードバックを書くだけな訳ですけども…笑)

現在は1回で5つ提案される求人に対して、フィードバックを3回ほど繰り返す形を取っています。

2回目に私に提案された求人とそれに対するフィードバック

で、実際にMatching Intelligenceに提案された求人の質なのですが

「え、、これはすごい…」

となりました。
上のスクリーンショットが実際に提案された求人に対する私のフィードバックなのですが、5つ提案された求人に対して4つは面談して話を聞きに行っても良いかもと思いました。(念の為補足しておくと、現職のCTOの立場はとても楽しんでいて、すぐに転職を考えている訳ではないです!)

自分がいちエンジニアとして働いている立場だったら普通に話を聞きに行っていたような気がします。

実は前の転職のとき、転職意欲は全く無かったのですが自分の市場価値を知りたいなと思って 転職ドラフト に登録したら、現職の給与の1.5倍ぐらいの額を提示されて、いつの間にか転職を考えていたという体験をしているのですが、今回のMatching Intelligenceでもそれに近い感覚を覚えました。こんなに面白そうな仕事で今よりも給与たか(ry

ということもあり、ぜひ皆さんにもMatching Intelligenceを体験してもらいたいなと思っています!

どう良かったのかもう少し詳細に書くと、希望の給与水準を満たしつつ、今までの経験を活かしながら、次のチャレンジができて、しかも楽しそうな事業領域の求人が提案されました。実際に転職するかというと、あとは会社のカルチャーだったり、そこで働いているメンバーなどが検討要素としてあると思いますが、オープンなデータから見える範囲ではかなりマッチ度が高かったです。(あとは自分がそこに受かるスキルがあるかですね!)

ちなみに社内のエンジニアのメンバー8人に対しても同じように被験者になってもらったのですが、面談に行きたい率が平均60%という結果となりました。私自身転職サイトで求人を探すときに、見た求人の6割で面談に行こうと思ったことはないですし、転職エージェントさんに提案された企業でもそこまでの高確率でいきたいなと思ったことはないので、そこそこ良い精度が出せているのではないかと思っています。

冒頭でもお伝えしたとおり、Matching Intelligenceはまだβ版で仮説検証の段階なので、Webサービスにはなっておらず、Slackに招待してやり取りさせてもらったり、Google スプレッドシートに入力してもらったりとUIは正直イケてないです。

それでもよろしければ、ぜひ登録してみてください。
きっと自分では見つけられなかった求人に出会えます。

特に以下に当てはまりそうなかたはぜひ!

  • なんとなく自分のやりたいことは見えているんだけど、それに合致する求人を探すのがだるくて現職で続けているんだよね
  • 新型コロナウィルスで会社ちょっとヤバそうだから、もしいいところあったら転職してもいいかなって…
  • 絶賛転職中でいろいろ企業見たけどパッとするところがなくてさ…
  • どれどれ、Matching Intelligence の学習データになってやんよ

Matching Intelligence: https://site.lapras.com/matching-intelligence

昨今のコロナウイルスの影響で技術系イベントの開催が困難になっているため、オンラインで積極的にアウトプットしていこう!という活動 LAPRAS Member’s Output Relay を社内で行っており、その一環でこの記事も書いています。こういう活動をしようよ!ってメンバーから声が上がってくるのは嬉しい限りです。

この記事では LAPRASLAPRAS SCOUT のWebアプリケーションの開発を行っているチーム(社内では WebApp チームと呼んでいる)が定期的に見ている指標についての話です。

プロダクトの指標は追いかけていない

いきなり見ていない指標についての話ですが、WebApp チームではプロダクトのKPIは追いかけていません。会社によっては「エンジニアチームが〇〇の機能の△△率をN%以上にする」というようなプロダクトの指標を追いかけていることがあると思いますが、LAPRASではこの指標はプロダクトマネージャーが責任をもって見ています。これは一長一短だと思っていて、それについては後ほど書きます。

WebAppチームが見ている指標

隔週のミーティングで確認している指標たち

WebAppチームはスクラムで開発しており、スプリントの期間を2週間としているため、それと同じ周期で各種指標を確認しています。このミーティングはホラクラシー組織におけるTactical MTGに当たるのですが、その説明をしていると長くなるので割愛します。

各指標のタイトルを眺めると分かるように、かなり開発側に寄っています。プロダクトの品質という観点では、以下の4つを見ています。

  • エラーの発生件数
  • ユニットテストのカバレッジ
  • サービスの稼働率
  • SlowQueryの発生件数

テストのカバレッジは80%以上を保つことを目標にしていて、最近は83%前後を推移しているような状況です。細かくテストを書きすぎても、価値の低いテストでCIが長くなるなどの問題が発生するので、目標を高く設定しすぎないようにしています。

サービス稼働率は、今は神経質になりすぎるよりも開発速度重視ということで、目標を99.8%に設定していますが、だいたい99.98~100%の間に落ち着いています。

開発プロセスの観点では以下の2つです。

  • 開発着手からリリースまでのリードタイム
  • 開発速度の遷移

スクラムで開発をしているので、開発速度はベロシティをそのまま指標として使っています。開発者とProduct Ownerが入れ替わったり、新しいメンバーが入ったりしてなかなかメンバーが固定されないため、意外と純粋な速度の比較は難しいです。

開発着手からのリリースまでのリードタイムはアジャイル指標としての意味を持っています。似たような指標に広木さんが提案している d/d/d という指標があります。

d/d/d も良い指標ですが、今の開発プロセス的には小さなデプロイをガンガンしていくよりも、3,4タスクぐらいをまとめた中規模リリースを週に3回ぐらいやっていくスタイルのほうが合っているため、デプロイ数ではなくて開発着手からリリースまでにかかった時間を指標として用いています。

Slackbotで計測できるようになっていて、どれぐらいのStory Pointのタスクがリリースまでに何日かかったのか見ることができます。(社内にパッチョが好きな人がいる影響でSlackbotにはhoge-pacchoの名前が付けられます。deliは delivery の意)

こんにちは LAPRAS CTO の showwin です。

LAPRAS CTOが採用担当になる-1週目
LAPRAS CTOが採用担当になる-2週目
LAPRAS CTOが採用担当になる-3週目
LAPRAS CTOが採用担当になる-4週目
LAPRAS CTOが採用担当になる-5週目

の記事に続いて、最後の6週目です。

LAPRAS社内では 100日後に死ぬワニ と同じぐらい最終週のこの記事を期待されているようですが、特に気にせずいつものペースで書いていきます!

6週目のこの記事では LAPRAS SCOUT の使い方 — 上級者編、6週間採用担当をやってみて気付いたこと、6週間のメトリクスを書いていきます。

LAPRAS SCOUT の使い方 — 上級者編

LAPRAS SCOUTについての説明や使い方の初級編は 先週の記事 に書いたので読んでない方はまずそちらをご覧ください。

前回はLAPRAS登録者に対して、興味通知を送って、リアクションが返ってきた候補者に対してメールを送る方法の説明をしました。しかし、それだけではリーチできる層が限られてしまうので、今回はスカウトメールを執筆していくことでLAPRAS非登録者に対してもリーチしていく方法の説明をします。

登録者に対してスカウトを送っていくのは他の採用サービスでもよくある機能ですが、非登録者(ネット上にアウトプット&連絡先を公開している人全員)に対してスカウトメールを送っていくことができるのがLAPRAS SCOUTの強みです。

スカウトメールをどういう手段と捉えるか

スカウトメールを何を実現するための手段だと捉えて送っていくのか、意外と企業によって分かれると思います。例えば

  • 今転職活動をしていない人も対象として、スカウト送信&カジュアル面談を実施していく。
    => 長期の採用・広告の目的も含む
  • 転職活動をしているだけに対象を絞って、すぐにでも選考に進んでもらうような文面で案内していく。
    => 短期採用に絞って、不要な面談のコストを下げる目的
  • (詳細に書かれている)求人情報をスカウトメールに添付して、企業&ポジションについてより詳細に知ってもらう。
    => 自分に合う企業&ポジションかどうか候補者自身に判断してもらう

などが考えられます。

まずは自分たちがどのようなスタンスで、どこを目指してスカウトメールを送っているのか明確にしましょう。ここがふわっとしていると、受け取った候補者も自分とマッチしているのか判断がつかなかったり、あまり転職考えていないけど話聞きに行って良いのかな…と迷ってしまいます。

今回の6週間でスカウトを書いていた時には上記の1つめと3つめの部分を重視していました。

2週目の記事 にも書いたようにLAPRASでは公開できる情報は積極的にオープンにして求人情報(採用要件)を書いています。例えば、Senior Software Engineer, Frontend のポジションの採用要件は http://bit.ly/lapras_jd_senior_swe_frontend_2020 な感じです。スカウトメールにはこれに加えて https://speakerdeck.com/lapras/lapras-company-profile の会社紹介スライドのURLも一緒に添付しています。

戦略としてはこの2つを候補者の方に読んで頂ければ、会社の情報やポジションの仕事内容を高い精度で把握してもらうことができ、カジュアル面談をしなくても候補者自身でここで活躍できそうかをある程度判断してもらうことができます。

スカウトメールを書くのが大変という声

LAPRAS SCOUTを運用している方からよく聞く声として

  • 全然スキルマッチしない人と面談することになるのは避けたいので、候補者選定時に候補者の情報をくまなく見てしまって、スカウトメール送信までとても時間がかかる
  • 候補者に魅力的に感じてもらうためにパーソナライズした文章を書きたいが、どう魅力を伝えてよいか分からず筆が止まってしまいスカウトメールが送れない

というものがあります。

1つめの問題については、私はネット上に公開されている情報だけでその方のすべてのスキルや志向を把握することができないと思っており、すべての情報を見ることは諦めています。こちらが候補者の情報をくまなく調べて、ポジションにマッチするかどうか判断するよりも、候補者自身にマッチするかどうか判断してもらう方がより正しい判断ができると考えているためです。そのため、ネット上に出ている情報を見て、少しでもそのポジションで活躍できそうな可能性があれば積極的にスカウトメールを送るようにしています。そして、候補者自身にそのポジションにマッチするかどうか判断してもらい、もし興味を持ってくれたのであればカジュアル面談でもっと詳細にお話をしましょう!という思いでスカウトを送っています。

2つめの問題に関しては、候補者が次にやりたいことがネット上の情報からわかっている場合には、「それを実現できる環境を提供できますよ!」と強く訴求することができますが、LAPRAS SCOUTでは必ずしもやりたいことがわかっている候補者ばかりではありません。その場合にはなぜあなたに声をかけようと思ったのか、どこに魅力を感じたのかについて強めにメールに書き、候補者が弊社のどこを気に入ってくれるかは求人情報や会社情報の資料から候補者自身に見つけてもらうのが良いと思っています。そうすることで、メール執筆時に「この候補者は弊社のどこに魅力を感じるのだろう🤔」といくら悩んでも(高い精度では)正解が見つからない問題について考える必要がなくなると思います。

CX (Candidate Experience)を損なうことなく効率を上げる

スカウトメールの質は時間をかけるほど高くなっていくと思いますが、採用担当者としては興味を持ってもらえるかどうかわからない、またスキル的にも期待している水準を超えているかわからない候補者に対して1通1時間もかけることはできません。(候補者側の立場になればそれだけ手の込められたメールがもらえたら嬉しいですけどね!)

冒頭に書いたようにどこを目指してスカウトメールを書くのかを明確にして、そこにフォーカスして(逆に目をつぶるところはつぶって)効率よくスカウト文面をかけるようになることが長期に渡ってに運用を続けていくためのコツかと思います。

6週間採用担当をやってみて気付いたこと

一番の驚きは、思った以上に細かなタスクに時間を取られて、スカウトに割ける時間がないことでした。スカウトに割けた時間は週6~8時間ぐらいだったと思います。

細かいタスクとは以下のようなものです。

  • 面談日程調整
  • 面談前の準備(候補者の情報整理)
  • 面談後の情報整理
  • 選考の案内
  • 選考中の課題に対する質問の回答
  • (自分が面接をしない場合に)面接官との情報のやりとり
  • 候補者との連絡が止まっていないか確認

これだけみるとなんだ、1つ10~20分で終わるじゃん!と思うのですが、これが1日に何個も降ってくるので合計すると2~4時間取られます。マルチタスクが得意な方であればもっと効率よくできるのかもしれませんが、僕の頭はシングルコア シングルスレッド 3.6GHzなCPU(?)なのでコンテキストスイッチが大量に発生すると効率が落ちます…

これに加えて面談が1日1,2件あって、それ以外のMTGも入るともう8時間です。スカウトは1日3件書くことがノルマでしたが、毎日3件ずつコツコツ書くというよりは、時間が取れた日に2時間まとめて10人分コメントを書くような動きをしていました。

これらの細かな作業を効率化しようと思うと

  • 1通目のスカウトメールに日程調整用のURLリンクを添付して、面談日程決定までのやり取りの回数を減らす
  • カジュアル面談を録音して、その音声を文字起こしして勝手にまとめを書いてくれるサービスを利用する (今はないので、NLPの神たちよ作っておくれ🙏)
  • 候補者への連絡忘れがあったらリマインドしてくれるサービスを利用する (LAPRAS SCOUTは実装済です!)

あたりでしょうか。候補者への返事を書いている時に別の事やらないといけなくなり、文面作成途中のまま返事忘れていることがたまにあるので、連絡が途切れていないかいつもそわそわしてしまいます。私のような心配性な人にはリマインド機能はありがたいです。

6週間のメトリクス

1週目の記事で書いたように今回の6週間で正社員4人採用することが目標でした。それが達成できたのか数字ベースで見ていきます。

  • スカウト送信数: 120通
  • カジュアル面談数: 26 + α (今週分のスカウト返信結果)
  • 選考数: 8 + α (まだ面談してない人もいるので)
  • 業務委託決定: 2人 + (1人 相談中)
  • 正社員採用: 0人

うっ…

タイムラグがあるので正社員採用0名ですが、今選考に進んで頂いている方を考慮すると2名採用できるのではないかな〜?という感じです。

いずれにしても目標達成はできませんでした。

ずっと採用に時間をかけているわけにはいかないので、社内の状況を見ながら来週から注力していく場所を探っていこうと思います。

感想

フルタイム採用担当をやってみたことで視野が広くなったので、6週間という期間で得られたものは(6週間開発を続けているよりも)かなり多かったです。

今まで採用には自社のプロダクト LAPRAS SCOUT しか使ってこなかったのですが、今回 Wantedly もガッツリ使ってみて、うちのプロダクトに足りていない部分や弱点にも気付くことができたので、採用文脈以外でも役立ちました。

この6週連続記事の企画自体はPR担当の @tetsuyaito_2 から提案頂いたものだったのですが、自分の思考の整理にもなりめちゃくちゃ良かったです。テツさんありがとう!!

こんにちは LAPRAS CTO の showwin です。

LAPRAS CTOが採用担当になる-1週目
LAPRAS CTOが採用担当になる-2週目
LAPRAS CTOが採用担当になる-3週目
LAPRAS CTOが採用担当になる-4週目

の記事に続いて5週目です。

5週目のこの記事では LAPRAS SCOUT の使い方 - 初級者編、今週やったことを書いていきます。

LAPRAS SCOUTの使い方 - 初級者編

今週は自社サービスの LAPRAS SCOUT を使って採用活動をしていたので、ついにその使い方を説明してみたいと思います!来週は上級者編を書きます。

LAPRAS SCOUTとは

そもそも、LAPRAS SCOUT はなんやねん?というところからですが、ハイレベルのエンジニアの採用を得意とするダイレクトリクルーティングのサービスになります。他の採用サービスとの一番大きな違いは、転職者のデータベースをネット上のデータをクロールしていくことによって作成していることです。

一般的な採用サービスであれば、転職を考えている候補者がそのサービスに登録して自分のプロフィールを記入して、企業の人事はその情報を見ながらスカウトを送ります。LAPRAS SCOUT の場合にはGitHubやQiita、Connpassなどエンジニアがよく使うSNSをクロールしてそこから名寄せして候補者のプロフィールを組み立てており、その情報を見ながらスカウトを送っていきます。そのため他のサービスと比べると候補者の数が多く、2020年2月時点で140万人ほどのデータを保有しています。

また、LAPRAS SCOUT にも lapras.com (以下、LAPRAS)というエンジニアが自分のポートフォリオを見ることができるサービスがあり、LAPRAS SCOUTで自分がどう見られているのか確認できますし、自分の転職意欲や今後やっていきたいことを記入することができます。自分のプロフィールも公開することができ、私のページは https://lapras.com/public/YOTRM10 です。(人事の方は LAPRAS SCOUT でこのような候補者ページを見てスカウトを打つことになります)

LAPRAS SCOUT初心者向けの効率良い使い方

先程説明した特徴もあり、LAPRAS SCOUT は使い慣れるまでに少しハードルが高いツールになっています。特に、オプトインしていないユーザに対していきなりスカウトメールを送ることになるので、失礼のないように丁寧にパーソナライズしたメールを送るところで苦労しているお客さんが多いように感じています。

私がおすすめするのはまずは LAPRAS に登録しているユーザに絞って検索をかけて、声をかけていく方法です。

LAPRAS登録ユーザのみに絞っての検索

転職意欲がない方を除くと良いでしょう。また「やりたいこと、興味のある仕事・分野」を記入している人のみに絞ることもできるので、母集団が減り過ぎなければそのフィルターも有効にすると良いです。

この条件で検索すると、転職も視野に入れていて、今後何をやっていきたいのか明らかになっている方たちが出てくるので、既存の採用媒体でスカウトを打つのとほとんど同じ方法で進めていくことができます。

そのようにして探した候補者に対してアプローチする方法が2つあります。1つはスカウトメールを送ること、もう1つは興味通知を送ることです。

こんにちは LAPRAS CTO の showwin です。

LAPRAS CTOが採用担当になる-1週目
LAPRAS CTOが採用担当になる-2週目
LAPRAS CTOが採用担当になる-3週目

の記事に続いて4週目です。

4週目のこの記事ではスカウトメール執筆の仲間を作る話、採用効率化ツールの続き、今週やったことを書いていきます。

スカウトメール執筆の仲間づくり

私はリファラル採用に続く効率の良い採用手法はダイレクトリクルーティングだと思っていて、採用担当になった1週目から継続的にスカウトメールを送り続けています。

1,2週目は毎日5通を目標に、3,4週目は毎日3通を目標にして、4週間弱で合計60通のスカウトメールを送りました。

ひとりで孤独に月60通送り続けると(私の場合は)精神的に辛くなってしまうので、周りの力を借りながら動いています。今回はどういう体制でスカウトメールを送っているのか書いていきます。

メインは人事担当とのペア執筆

私は人に刺さる文章を書くのが苦手で、推敲にとても時間がかかるタイプなのですが、候補者探索や良さそうな候補者に対してコメントを残していくのは得意領域です。逆に人事担当は技術のことは詳しくわからないが、スカウトは打ち慣れていて文章を書くのは得意な方であることが多いです。(うちも例に漏れず。とはいえ必要な知識はちゃんと持っていますが)

そこで私が候補者選定→コメント残すまでを担当して、文章執筆は人事担当に依頼する。そして上がってきた文章を私がレビューして技術的な言い回しに違和感がないか確認して送信するという作業分担でスカウトメールを書いています。

私が選定→送信まで一気通貫で行うと、1人あたり30分ぐらいかかりますが、分担することで1人当たり合計10分程度まで効率化できています。(もちろん質は落としておらず、一人ひとりにパーソナライズした文章をお送りしています)
選定からコメントに5分、コメントからの文章作成に5分という内訳です。

コメントの内容は「その方の良いところ」「どう訴求するか」の2点について、それぞれ1~2文程度で書いて渡しており、お互いにそれでやりやすいねといって進めているような状況です。

チームメンバーとの協力

採用含め、組織を作っていく部分はCTOの役割でもありますが、メンバーにもその視点は忘れてほしくないと思っており、週に1時間を確保してエンジニア全員でスカウトタイムを実施しています。

そのスカウトタイムは
・合計4ポイント獲得した人から終わってOK
・1人選定→コメントまで行ったら1ポイント
・1人コメントから執筆→送信まで行ったら2ポイント
・1人選定→送信まで続けて実行したらボーナスで+1ポイント
というルールで活動しています。

このようなルールにした背景は、脳のスイッチングを避けて効率を上げるために選定を連続でやりたい人や、1人送信すればOK!という気持ちで取り組みたい人もいると思い、自分のやりたいように動いてもらいたいな思ったためです。

前回の記事で 採用を効率化するためにエンジニアリングした話 を書いて、今回も下でまたその話をしますが、これに似たような別の効率化ツールを作ってスカウトタイムに活用しているエンジニアもいました。(こういうところハックするのは私も大好きなので、いいぞいいぞ!!と思いながら見ていました)

まとめ

特に優秀なエンジニアの採用においてはスカウトメールを書いて送るダイレクトリクルーティングは効率の良い採用方法だと思っていますが、その一方で大変な面もあります。何事も1人で大変な作業を抱え込んでしまうと辛いので、うまく周りを巻き込みながら一緒に力を合わせて進められる仕組みづくりが大事ですね。

採用効率化ツールの開発-続編

引き続き空き時間でWantedlyのスカウト機能を使いやすくするChrome拡張を作っていました。

今回はその候補者を最後にいつ見たのか確認するための最終閲覧日時情報を表示する機能を追加しました。

似たような別の条件で検索した場合(例えば Vue.js と Nuxt.js)検索結果に同じ人が出てくることがあります。その時に前回もこの人みた気がするな🤔と思いながらも、詳細ページ見てみるとやはりその人だった、ということが起きて候補者探索の非効率さを感じていました。

この機能はそれを解消するためのもので、候補者を見て1時間以上が経つと最終閲覧日時が表示されます。(1時間以内なら自分の脳を頼れると信じているためです!逆に1分後とかに出てきてもうるさいですしね。。)

このChrome拡張機能を公開しようと思って今朝準備をしていたのですが、個人のGoogleアカウントのDeveloperアカウントがBANされていたのを思い出して公開できませんでした。。5年前ぐらいに開発した拡張機能に対して違反報告が多発したのか、3年前ぐらいにBANされてそのままなんです(笑) アカウント復元依頼をしたので来週には公開できるように祈っています🙏

今週やったこと

今週の振り返りをメモ程度に。

  • スカウト15通 (1日3通目標 + 3件)
  • カジュアル面談4件 (うち選考案内 2件)

スカウト業務とカジュアル面談とメンバーとの1on1をやっていたら1週間が終わってしまった。祝日が1日入って週4日になると、なかなか新しいことをする時間が取れない。とはいえChrome拡張の開発も進んでいるので、調子はまぁまぁ。これは最終的にちゃんと公開して世の中の採用担当の方に使ってもらいたいなと思っているのでがんばるぞ。

採用担当としての成果は今週は80点ぐらい。
選考に進んでもらっている方も増えてきたので、一緒に働くことになるメンバーが増えると良いな!

こんにちは LAPRAS CTO の showwin です。

LAPRAS CTOが採用担当になる-1週目
LAPRAS CTOが採用担当になる-2週目

の記事に続いて3週目です。

3週目のこの記事では採用要件作成時に抜けていた視点と、採用を効率化するためにエンジニアリングした話、今週やったことを書いていきます。

採用要件に抜けていた視点

先週の記事で「採用要件を書く時に気をつけること」について書きました。

という反応を反応を頂けて嬉しいです。

ただ、今週転職エージェントの担当者さんと話をしていてある視点が抜けていることに気づきました。私自身今まで全く考えたことがなかったのですが、それは「そのポジションを経験することで候補者さんのキャリアにどうプラスになるのか」というものです。

LAPRASの場合、会社単位では例えば

  • プロダクトを10→100にスケールさせるところの経験が得られる(仮説検証を繰り返しつつ、運用の経験もできる)
  • ex-テックリード、ex-CTOがいるような技術的に強いメンバーと一緒に働くことで技術的にスキルアップできる

のようなものがあり、次に転職する時に同じようなフェーズのスタートアップ企業に転職しやすくなったり、より技術力が求められるような企業にも応募できるようになったりするでしょう。

ポジションで言えば、例えば Senior Software Engineer, Frontend であれば

  • フロントエンド周りの設計方針から技術選定まで責任を持って意思決定をしていたという実績ができる

という形で示すことができ、この経験により他の企業への技術顧問などができるようになるかもしれません。

カジュアルで候補者の方と話をしていても自分のキャリア形成について明確なビジョンを持っている方はかなり少ないですが、面接官として「このポジションを経験することでこういう選択肢が増えますがどうですか?」と提案できる状態にしておくのは、よりポジションを魅力的に見せるために大事な要素だなと感じました。

候補者が保有するスキルや現在の状態によって、そのポジションが与えるキャリアへの影響は変わってくるので一元的にキャリアにこうプラスになりますよ、というのは採用要件に書きづらいかもしれません。しかし、少なくともカジュアル面談では候補者の経験を聞いた上でそれが提案できるようになれたら良いなと思っています。

採用を効率化するためにエンジニアリングした話

今週はWantedlyを使ってスカウトを打っていました。いやいや、自社サービスの LAPRAS SCOUT 使えよ!って話ですがせっかく採用をフルタイムでやる機会なので、他社さんのサービスも積極的に使わせてもらっています。 (LAPRAS SCOUT の使い方は最後の週に書く予定です)

Wantedlyのスカウトはだいたいこのような条件で数百人ぐらいに絞りながら、送りたいかどうかだけを上から下まで見みて、送りたい人は別でメモを残しておく、ということをしていました。

なぜ上から1人ずつ送っていかないかというと

・選ぶ脳と文章を書く脳のスイッチングコストが大きいので同じ作業を繰り返したほうが効率が良い
・数百人全員に対して選定しながらスカウトを送っていては1日で終わらないので途中で中断する必要があるが、再開するときにどこまで見たのかわからなくなる (検索結果も表示順序が変わる気がする?)

という2つの理由からです。

で、上から見ていくのですが、全体のうち何割ぐらい見終わって後どれだけ頑張れば終わるのか見通しがつかなくて辛かったので、何人見たのかわかるChrome Extensionを作りました。

こんにちは LAPRAS CTO の showwin です。

先週の LAPRAS CTOが採用担当になる-1週目 の記事に続いて2週目です。

2週目のこの記事では採用要件とスキルチェックについて考えていること、感じたことを書いていきます。(今週のアクションまとめも)

採用要件を書く時に気をつけること

一般的にどうするのが正解なのかをここで書くのはおこがましいので、LAPRASのエンジニア採用で気をつけていることを書いていきます。

ぼくが採用要件を書く時に一番大事にしているのは、候補者がそれを読んだ時に「LAPRASに入社したらこういう働き方をするのか!」とイメージできるようすることです。

私自身は3年半前に転職活動を1度経験しており、その時に感じたのが

・あと何回選考したら内定を出してもらえるのだろう

・選考が進んでいるのはいいけど、これで給与低かったら今までの時間無駄だよな…

・内定頂いたのは良いけど、入社後に何をするのか、だれと働くのか全然イメージができていないな…

というものでした。

結局内定を頂いた企業には転職せずに、LAPRASの創業メンバーとして働くことになったのですが、もしあの時にどんなメンバーとどんな仕事をするのか明確にイメージできていたらその企業にお世話になっていたかもしれないなと今になっても思います。

今LAPRASで募集中のポジションで一番情報量が多いのが Software Engineer, Frontend のポジションですが、現在社内で抱えている課題から選考フロー、報酬に関しても記載しています。スカウトメールを送る時にはこの採用要件を添付しており、カジュアル面談をしなくても最低限気になる部分は確認できるようにしています。

また、カジュアル面談ではそれを読んでいることを前提として話ができるので、より詳細な部分に集中して話をすることができ、バックログにはどんなタスクがあるとか、レイヤードアーキテクチャで開発していてこんな感じのコードを書いているよとか、実際にコードをお見せする時間も取ることができています。

採用要件の見直し

採用要件は一度作ったら終わりではなく、採用できるまで定期的に改善を続けていくべきものだと思っています。今週ちょうど見直しの必要性を感じたポジションがあったのでその話をします。

それは Software Engineer, Customer Reliability のポジションです。このポジションを作った背景から説明をすると、今は顧客からの問い合わせをカスタマーサクセスが一次受けし、技術的な内容であればバックエンドエンジニアにエスカレして、手が空いている人が対応するというフローになっています。しかし、問い合わせ数が多く差し込みタスクが増えると、頭のスイッチングコストによりエンジニアの開発効率が落ちてしまうという問題がありました。そのため、テクニカルサポートを専任で行う方(上の採用要件, CRE)を採用して、今のバックエンドエンジニアは機能開発に集中するという方法で対策しようとしました。バグ報告やデータ不整合の問い合わせが多いので、CREの業務範囲には問い合わせ対応に加え、バグ修正やデータメンテナンスを行う事まで入っています。

今週はこのポジションの採用に力を入れようと決めて、毎日5通ずつスカウトメールを送っていたのですが、普段のスカウト返信率に比べて低く、また返信があってお話してもあまりこのポジションが刺さっていないような印象を受けていました。このポジションにマッチする人材はWeb系よりもSIerに多い印象だったので、エージェントさんにも紹介の依頼をしていたのですが、エージェントさんからもこれができるスキルを持った方は確かにいるが、その職を希望する方はかなり少ないとアドバイスを頂きました。(コードが書ける人だと技術力を伸ばしていきたい欲が強く、開発メインの業務の方を好むとのことです)

CREについて調べるとReproさん、はてなさん、メルカリさんあたりの話がよく出てくるので、実際に働いている方に聞くのが早いと思い、知り合いにReproさんのCREチームのリーダーの方を紹介していただき、中の様子を伺うことにしました。

その結果、市場にはほとんど存在していないような人物像を採用要件として定義してしまっていることに確信を持つことができました。CREを採用しない代わりに、

  • バックエンドエンジニアがシフト制でテクニカルサポート担当をして、できるだけ開発に集中できる環境を作る
  • バックエンドエンジニアの採用を1人増やすことで1人あたりの負担を減らす
  • そもそも問い合わせが来ないようにバグを減らしプロダクトの品質を高める

をする良さそうで、CREは採用しないということになりそうです。
結論としては当たり前のことなのですが、改めてバグ修正の優先度を上げることの重要性に気付けました。

このように採用したいと思っていたペルソナが市場に存在しないことは多々あり、要件を分割して2人採用するとか、今回のように社内の体制を変更することで課題を解決できることがあります。採用要件を作ったけど、いい人が全然いない…と考えるのではなくて採用要件側の見直しも大事だと感じました。

採用基準の認識統一

こちらも今週起きた事件から学んだことですが、チーム内で採用基準の認識を統一しておく事が重要です。特に今まで採用してこなかったようなポジションの場合には気を付けましょう。

昨年までLAPRASには採用ポリシーの一つに「社内の平均よりも高いスキルを持っていること」というものがありました。それを実現するために、エンジニアのスキルチェックでは、技術課題に対して採点基準を明確に決めており、事前に社員に解いてもらい社内の平均点を算出しておく、そしてそれを超える点数であればスキルチェック通過!というルールで運用していました。それによって客観的に判断でき、チーム内でもほとんど合否判定で割れることはありませんでした。

しかし今回募集していた Software Engineer, Backend のポジションはそのポリシーには該当しないポジションであったため、合否判定が曖昧で問題が発生してしまいました。

  1. 1次スキルチェックにて満点に近い回答を提出して頂いた候補者の方がいた。
  2. 2次スキルチェックでは1問回答できない問題があったが、1次スキルチェックの結果も良かったので通過とした。(念の為にできなかった問題を家で解いて再提出してもらうことにした)
  3. 再提出、再々提出してもらったが満点回答ではなく、合否判断がメンバーで分かれ、最終面談の直前にお見送り連絡をすることになった。(1人でもNGがいたら通過させないルール)

というものでした。候補者さんの都合で1月中にこちらからオファーを出す必要があるタイトなスケジュールの中進める必要があったとはいえ、2次スキルチェックは通過とお伝えして、最終面談の準備も進めてもらっている中「やはり2次スキルチェックはNGでした」と伝えるのは候補者体験を考えたら絶対にやっていはいけない対応です。毎朝Slackのワークフローで「候補者の気持ちを考えて行動します」を頭に入れている身としても絶対に許されません。

これが二度と起きないためにもう一度チームメンバーを集めて、このポジションに求めていることの認識合わせをすることにしました。

特に今まで採用をしたことがないような性質を持っているポジションでは選考基準が曖昧になりがちで、その認識がズレていることで場合によってはこんな問題さえ起きうるということに気付かされました。

今週やったこと

今週の振り返りをメモ程度に。

  • スカウト25件送信
  • 面談1人
  • スキルチェック2人
  • エージェントに問い合わせ4社
  • スキルチェック1つ作成
  • CREのヒアリング

スカウトは毎日安定して5通書けている。今週はターゲットがズレていたCREのスカウトばかり送っていたので返信率が低く辛かった。先週バックエンドの業務委託で2人お願いできる方が決まったので焦りはそんなになくて、来週以降は Senior Software Engineer, Frontend, Senior Software Engineer, Architect 辺りを探していきたい。ただ毎週スカウト25通も送れるほど対象者が多くない気がするので通数を減らして質をあげたスカウトを送りたいと思っている。

以上、2週目でした。今週は70点ぐらいかな。

showwin (Shogo Ito)

LAPRAS株式会社 CTO / 開発に関する話はMediumに書いていく

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