1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

働いている会社がITエンジニア採用の負のループに陥っていたので、メンバーの立場から改善を試みた

Posted at

前置き

どうも、候補者の立場でテンプレート文のスカウトが来ると残念な気持ちになるみゅーみくすです。

そんな採用へのアンテナが高い筆者だからこそ、自社の採用でもそんなことはして欲しくない、していようものならば、候補者の方々に詫びて回りたい。くらいの想いを持っています。

とはいえ我はただの一兵卒(メンバー)。ということで、関心は高いけど影響としては少し弱い立場にあります。

そんな中で現職の採用が、わりかし負のループに入ってしまい、現状と自分の影響範囲で行ったことを書いていけたらと思います。

背景とかはどこまで汎化するかが難しいところです。(メタ認知力…!)

ちなみにITエンジニア採用の拠り所は以下の記事がおすすめです。候補者の立場のときにテンプレートスカウト来たときはこの記事を返信しています。

候補者側としての対企業への案内にも使えますし、自社で行う採用のベストプラクティスや認識合わせとしても使えるので言語化されていてありがたい限りです。

関心の輪と影響の輪

自分の好きな書籍「7つの習慣」に登場します

image.png

画像引用元 「影響の輪」と「関心の輪」とは? 人生が変わるか変わらないかの土台となる考え方

人の行動や世の中の情勢はコントロールできないので関心の輪。自分の考えや行動は変えられるので影響の輪になります。

関心の輪に集中することを避け、影響の輪に集中することで、徐々に影響の輪を増やすことができる。という話です。

閑話休題。本記事はある意味メンバーの立場から影響できる範囲を意識しつつトライした内容を紹介するので、ここで解説を挟みました。

背景

現職はここ1年半ほど前に募集を再開してから、1名も採用できていません。

概要

  • スタートアップ企業でITエンジニアは6〜8名
    • 内マネージャー2名。その上にCTO。IoTスタートアップなのでデバイス系のチームも別にある
    • スタートアップということもあり他部門含めそれなりに人の入れ替わりはある
  • 採用は通年行っているわけではなく、離職や増員のタイミングで開始したり終了する
  • 人事のメンバーもタイミング的にITエンジニアの採用をサポートしやすい時期もあれば、難しい時期もある
  • 今回は離職のタイミングで採用を再開
    • 業務量としてはオフショアや外部の企業に移譲したり、アウトプットを調整することで、抑えられてはいます。とはいえ会社の成長のためには新しいメンバーを迎え入れたい

採用要件を徐々に緩和していった

シニアクラス 業務経験10年以上でプロジェクトリーダー等もできる

ミドルクラス 業務経験3年以上で自走して設計、開発ができる

ジュニアクラス 業務経験1年以上で他のメンバーのサポートを適宜受けながら開発ができる

(定義は色々あるかと思いますが本記事では上記の定義で記載します)

採用対象が変わると、媒体の使い方や面談するメンバーも徐々に変えるべきでしたが、そのままになってしまいました。

ここについては後半でも触れていきます。

負のループから抜け始めたきっかけ

あくまできっかけです。動いているものがあるのでいきなりすべてを変えることは難しく、少しずつです。

まだできていないこととしては、人事メンバーとITエンジニア採用入門 を読み合わせないし、読んでもらい、会話する場を設けるということです。
(少しずつやれそうなプラクティスをエンジニア側から改善する形でも良さそう)

ふりかえりの場で採用を取り上げる

現職ではITエンジニアメンバーで月1でふりかえりを行っています。(KPTは隔月でもう隔月で別のふりかえり)

KPTの場合K,Pを各々上げ、投票が多く集まったものを会話しTを考えます。

定期的に採用がカードとして上がる中、ある日のアクションとして採用の現状共有会がセット・実施されたことで少しずつ負のループから抜け始めました。

細かい話を聞くことで、小さく変えるためのアクションも浮かびやすかったですし、大変さも分かります。

技術ブログを書くことで採用に貢献し、発言力を上げる

自分は技術ブログ(現職の場合ココQiitaのOrganization)で記事を細々と書いています。

技術ブログは採用につながる側面があるのに、採用の〜〜の部分はもったいない状態というのを主張し、「貢献したいけど障壁がある」「自分がやっている活動が効果を発揮していない」というアピールすることで、影響の輪が小さいながらも発言力が上がり意見を通しやすくしました。

技術ブログが採用に直接関わるかというと、あくまで候補者が見たときに会社の雰囲気が分かることで、応募してもらいやすくなったり、カルチャーミスマッチが減る側面です。

(著名になれれば直接の応募につながったり、スカウトメッセージ送るときのアドバンテージになります)

次章で採用の現状共有会で聞く中などで起きていた内容などを整理します。

何が起きたか

人事や外注先に任せっきりになってしまう

ITエンジニアのメンバーが離職し、採用を再開する際に、人事のメンバーが手厚い状態だと経験もあるので自ずと人事主導で進める力学が働きます。

これが会社規模が大きく通年採用とかだと戦略的にエンジニアも巻き込みながらとかできるでしょうが、メンバーの離職のタイミングや会社の規模拡大の状況次第で採用の停止、再開を行き来する場合は知見も溜まりにくくこうなりがちだと思います。

人事に加えて、離職によって生まれた人件費があり予算枠的に取りやすく、転職サービスやエージェントに費用をお支払いすることで、採用活動自体を外注化していく力学も働きやすいです。
採用が停止と再開を行き来する状態はスポット的な業務でもあるので、せっかくエンジニアメンバーがキャッチアップしても採用ができると終わりで工数を投入しにくい側面もあります。

[修正済み]募集要項がExcelで作った求人票になっていた

1年くらいこの状態でした。
(想像ですが、シニアメンバーを募集する際にエージェントを使うと共通フォーマットとして求められる求人票になって、ミドルメンバーを募集する際も流れでそのままに。という感じだと思います。)

導線としては以下です。

会社HP > 中途採用ページ > ITエンジニアの応募はこちら > Googleフォーム(冒頭に募集要項リンク) > Excelで作られた求人票

硬すぎてスタートアップの雰囲気に合わず、他人におすすめしにくい

以前Wantedlyを運用していましたが、採用クローズや諸々のタイミングで使わなくなってしまっていましたが、再開しました。

こちら

[少し改善]リファラル採用をお願いされるがやりにくい

先程のExcel求人票もそうですが、社内のメンバーが求人票だけを見ても必須要件のニュアンスが分かりません。例えば自社で扱っていない言語の経験者はどうか。マイナーな開発経験はどうか。など

そもそもミドルメンバーがシニアメンバーの知人がいるかというと難しい。

またリファラルの延長線にある以下のようなシーンでもやりにくくなります。

  • 外部の勉強会とかでやんわりと声を掛けるシーンとか
    • 「こんなビジネスをやってて自分はこのポジションで…実は採用もしてて〜なポジションが…」
  • 登壇や技術ブログ書くときに載せにくい

少なくとも採用可否の権限を持っているマネージャーにどれくらいのニュアンスなのかをすり合わせる場を30分くらい設けると良いと思います。(実際にリファラルできるかは置いておいて)

ここらへんが明確になると、知り合いの一歩先の人にも声をかけやすくなります(個人的には)

現場で採用要件が緩和されてもメンバーが把握できない

当初の募集はシニアクラスでしたが、半年〜1年採用が上手く行かなかったこともあり、話を聞くと内々では緩和する方向(心づもり)で動いていたようです。

シニアからミドルというのを経て直近ではジュニア:1年くらい業務経験があれば。という話もありますが募集ページはそのままです。

必須条件と推奨条件も改めて見直すとなった場合、文言やバランスもあり、会話の中のニュアンスでわかるものを、落とし込むのには一つ手間があります。手間を掛けるとペルソナの設定などもありますし…

どこかの流路からは書類応募は結構あり大変という話もあり、通常採用はそのままだが、リファラル(社員推薦)なら緩和という間のパターンもあるかと思います。

各メンバー採用に課題感を持っているけど、アクションができない

(リファラルの話と近いですが)

会社からリファラルを是非と言われても知人の紹介はアテがなければ終わってしまう

冒頭に触れたようにKPTとかのふりかえりの場で最近採用できていないという課題に触れる機会はあるけど、アクションが難しいという状態になります。

メンバーが主体的に(影響の輪として)できることとして

  • 知人等の紹介
  • 技術ブログの執筆
  • 勉強会での登壇(ちょい宣伝)
  • 懇親会でのちょい宣伝

があるかと思います。ここまで上げた採用状況に関するすり合わせができていれば、多少なりとも動きやすくなると思います。

逆に採用メンバーが手放すことでメンバーが関われる領域もあります

  • カジュアル面談や一次面接の参加

別項目でも触れます

[改善済み]カジュアル面談が会社説明になってしまっていた

ベストプラクティスはこちら

ちなみに最大のアンチパターンは合否を判断してしまう。でその次に一方的な会社説明になってしまう。です(すまぬ)

一応これも採用の共有会で分かり、事前に候補者の方にはどんなカジュアル面談にしたいか聞いたうえでやれるとよいですよね。ということで合意を得ました。

[改善中]面談するメンバーが固定化されている

上記とも少し似ています。

カジュアル面談、1次面接は人事と、マネージャーで固定。

2次もマネージャーが登場という形で、固定化されてしまっていました。

これが当初行っていたシニアメンバーの採用だと問題なかったのですが、徐々にミドルやジュニアクラスの採用となったときに、候補者の方が会話するエンジニアがマネージャーのみだと、会社として魅力的に映るかというと少し弱いと思います。

年齢が近しいかちょっと先のロールモデルになりそうなメンバーが出たほうが良いとふりかえると感じます。

採用共有の場でメンバーにもカジュアル面談や一次面接にも出ようということで合意しましたが、それから面談の機会が少なく実質的にあまりできていない状態です。

余談ですが、以前の採用ではメンバーも面談に出ている時期もありました。
これを踏まえるとシニアクラスの採用から要求を下げたときにこういう状態に陥りやすい気がします。

以前使っていたEntrance bookが非公開のまま

以前の採用で作ったのですが、採用がクローズしたタイミングでメンテナンスが止まり、今回の採用でも使われないままとなってしまいました。

非常にもったいない。

メンバーがどこまで編集するかというのもありつつ、変化が激しいスタートアップで細かい部分を更新するのが億劫になるのも分かります。

これもある意味当時のシニアメンバーを採用しようとしたときに利用するエージェント等では、必要度はそこまで高くなかったという話もありました。ミドルやジュニアを対象にするのであれば情報として出しておきたいところです。

本記事の執筆に合わせて再度プッシュします。

自分の場合はカジュアル面談も億劫で、できる限り必要な情報は言語化されていて参照した後に、テキストで疑問を解決できればカジュアル面談無しで応募でも良いと思っています。
なので、採用媒体に乗せきれない細かな情報をEntrance bookや技術ブログで感じ取れると大変ありがたいです。

おわりに

なかなかセンシティブな領域なので、言語化に気を使いました。社内での確認も気を使っていただきました。ありがとうございます。

ふりかえると誰が悪いというわけでもなく仕組み的に陥った要素も多いかと思います。

とはいえベストプラクティスから外れた採用活動は結果に繋がらないという裏返しはありますし、候補者の方のためには好ましい状態ではありません。

ウルトラCとして自分が先頭に立って採用を行うというカードはあるようにも見えますが、いろんな側面で障壁はあります。

  • いちメンバーが会社の看板として出していいのかという側面
  • 採用のベストプラクティスの押し付けになってしまう可能性
    • 会社としてどう落とし込んで実践するかが大事
  • ズブの素人
    • やったところでうまくいくかどうかは別
  • 自分がやっている業務をすべて投げ出せない & 自分としても投げ出したくない
    • そもそも自分が行っているインフラ・データ領域の採用ではない…
    • 採用ポジションによれど、ある程度マネージャーの出番は必要

当人が見える景色は違う側面もあり、いちメンバーとして一気に状況を変えることは難しいですが、ふりかえりで議題に上げたり、自分のように「技術ブログを書いているのでもっとここを変えてほしい」というアピールで、少しずつ変えることは可能かと思います。
自分も当事者になった際は理想と現実に挟まれる自身がある。

採用していますので、興味がある方は覗いて頂けると幸いです。採用ページからでも、私個人X宛でもお気軽にご連絡ください。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?