インフラエンジニアのスキルが採用プロセスに活かせた話
この記事は、ジンジニア アドベントカレンダー Advent Calendar 2023の3日目の記事です。
前回は、てぃーびーさんのウェブエンジニアから人事への適応でした。ウェブエンジニアから人事への適応過程がつづられていますので、ぜひお読みください！
はじめに
私は元インフラエンジニアで、現在はDevRel（Developer Relations）を担当しています。また、エンジニア採用と支援も継続しています。今回は、インフラエンジニアとしてのバックグラウンドが採用プロセスに活かせたことに気がついたので、その話をまとめます。
採用に求められる応答速度
今年は100人以上の方とカジュアル面談を実施しました。
その実現の鍵となったのはダイレクトリクルーティング（いわゆるスカウト）です。今年はテキストのやりとりを通じて候補者のかたとコミュニケーションを取り続けました。
そのときの改善の話はこちらのソフトウェアエンジニア採用のフロー効率の改善にまとめています。今回は、その際に重要だった成功要因である応答速度の速さに注目して紹介します。
採用に限らずビジネスの一般論として、迅速な即時対応が求められます。候補者のエクスペリエンス視点に立つと、連絡のやり取りが早ければ早いほど良いです。候補者の動きを素早く捉えて反応することが大切です。
しかし、素早い反応と対応をするのは難しいものです。また、候補者のその時々の事情もあります。そこで、採用プロセスの効率を追求するツールの導入と、候補者の気持ちの理解のバランスを取ることが、採用担当者にとって大きな課題となります。
まずは、ツール導入の話を紹介します。
日程調整ツールの導入
やりとりで時間を要する要因の1つに日程調整があります。
その対策に日程調整ツールを導入しました。これによりスケジュールの空き時間を探しやすくし、候補者の方へ予定を伝えやすい状況を作り出しました。ツールの選択肢は複数ありますが、私はSpirにお世話になっています。
Spirの良い点は、候補者がログイン不要で別日程の提案ができることです。ツールを介してお互いの都合を即時に確認できるため効率的です。このツールの活用により、候補者への連絡は日程調整から始めることができました。
候補者の行動変化をSlackで検知する
次に、ダイレクトリクルーティングでは採用媒体のSaaSを利用しています。検索すればさまざまなツールが出てきますが、以下の例ではSlack連携に対応しています。
ただし、注意点として個人情報を扱うため、Slackの通知先はパブリックチャンネルではなくプライベートチャンネルを使用します。また、利用する採用媒体に合わせて通知内容を絞る必要があります。
Slack連携に対応していない場合（メール通知含む）や、メールがやりとりの中心である場合、通知に気がつける仕組みが必要になります。この対策はメール転送を利用したSlackのDM用メールアドレスの活用が便利です。
さきほど紹介したSpirもSlack通知をヘルプで案内していますので、参考にして導入します。これにより、候補者の変化を捉える通知先をSlackに集約することができました。
あとは、これらの通知にいかに迅速に反応し対応するかの判断力が重要となります。
インフラエンジニアとしてのスキルと採用プロセスの結びつき
監視アラートと候補者変化
さて、ここまでお読みいただくとおわかりかと思いますが、私はインフラエンジニア時代のスキルを活かせることに気づきました。Slackの通知にいかに迅速に反応するか。これはオンコール対応の経験が大いに役立ちます。
インフラエンジニア時代、システムの異常やパフォーマンスの低下を検出するための監視サービスの導入を経験しました。例えば、Mackerel+PagerDutyでインシデント管理に携わっていました。Slack通知も基本としていたため、目についたときの判断や通知整理の方法に慣れています。
もちろん、システムと人間は異なりますので、同列に考えることはできません。しかし、アラートの先に実際の顧客がいるという事実は採用活動においてもオンコール対応においても重要な考え方に思います。
つまり、採用活動においても顧客視点が必要です。
障害対応経験を顧客視点に活かす
システムの障害発生時に迅速かつ効果的に対応した経験は、採用プロセス中に生じる問題や課題に対し、迅速に対処し解決することに活かせます。Slack通知の集約は、迅速な対応を促すシグナルです。
候補者の心境の変化は、各種採用媒体の機能を活用することで捉えることができます。転職意欲の変化やリアクションの通知に反応し、候補者の関心の変化や疑問点に即座に気づき、適切に対応します。もちろんSlack経由です。
これにより、候補者一人ひとりの価値観に合わせた有益な情報交換に時間をかけることができます。このバランスが本来やりたかったことで、顧客中心の採用アプローチにつながると思います。
候補者の方とのコミュニケーションを取る大切さを前提に、ツールの導入が必要不可欠で課題解決につながると感じました。なお、採用の顧客視点の考えはこちらのインタビュー記事にまとめられています。
データをダッシュボードで捉えたい
監視対応が可能になれば、次はデータ分析の仕組みを見直します。
採用プロセスに応じてデータを蓄積していますが、現在は手動での対応が多くを占めています。スプレッドシートを用いてピボットテーブルとグラフを生成し、仮説の検証や現象の捉え方に最近は力を入れています。
この整備は来年に向けた課題だと感じています。
このように、一度エンジニアリングの視点を得ると、DataDogのようなダッシュボードが必要と感じるようになりました。これはBIツールの活用につながると気づき、Looker Studioの使用を模索しています。意思決定に役立つデータの可視化はオブサーバビリティ(可観測性)の向上とも言えます。
まとめ
ツールの導入意識やアラート対応の即時性に関する考え方は、インフラエンジニアのスキルセットが活かせることに気がつきました。システム化されたアプローチは、採用プロセスにおいても有効です。
これにより、候補者の本質的なニーズに対応するために、より多くの時間とリソースを割くことが可能になります。効率性と人間性の両立が、採用活動における顧客視点の鍵であることを実感しています。
次の課題であるデータ活用についても、可観測性を意識してダッシュボードを基にした意思決定ができる仕組みを構築していくことを目指していきます。
今回の話は、どの立場や職種経験であっても、具体と抽象のバランスによってそれぞれのスキルを活かせる話でもあります。重要なのは、過去の経験を柔軟に解釈し、新しい環境や課題に応用するマインドかもしれません。
必要だから行動する。その結果、エンジニア採用に関わったり、技術広報に手を挙げたり、データ活用を意識したりと、自己変革を繰り返すようになるなるのかもしれません。
さいごに
インフラエンジニア時代に出会ったこちらの本の引用で話を締めたいと思います。
ウェブオペレーションは技芸であり、科学ではない。正規の学校教育・資格・標準は(少なくとも今はまだ)ない。我々のやっていることは、学習にも習得にも時間がかかり、その後も自分自身のスタイルを模索しなければならない代物である。「正しい方法」はどこにも存在しない。そこにあるのは、(とりあえず今は)うまくいくという事実と、次はもっと良くするという覚悟だけだ。
https://www.oreilly.co.jp/books/9784873114934/
インフラエンジニア時代に身につけた技芸が私の仕事のベースにあると思っています。VUCAで正解がないといわれる時代の中で、もっと良くするという覚悟をこれからも持ち続けたいです。
引用画像：https://www.dl.ndl.go.jp/api/iiif/2591730/R0000156/1528,1644,4440,3144/328,/0/default.jpg
この記事が気に入ったらサポートをしてみませんか？