新人エンジニアリングマネージャを採用脳にする
僕が所属している会社では、スクラム採用という名の下でエンジニアも採用に携わっています。多くはチームメンバーとして面接に出てもらって、お互いの相性を見たり、アトラクトとして参加してもらったりという手段なのですが、そもそもの面接母数を増やすためのスカウトは主にマネージャ職にやってもらっています。
下記引用は他社様の話ですが、改めて、やっぱりそうなんだよなぁと思って見ていました。
しかもエンジニアを採用するためには、いま自社で働いているエンジニアの稼働時間のうち2～3割を採用、つまり選考のために割いてもらう必要があります。
マネージャがスカウトを行うメリット
マネージャがスカウトを行う理由は、チーム組成を担う仕事として、プレーヤよりもマネージャの方が主体的に動けること、人を見る目を養っていく仕事が故に、良い人材へアプローチできることを意識してやっています。スカウトは、こちらが先んじてスクリーニングしているが故に、やはりエージェントさんの紹介よりもチャレンジングな人選も含めて人のマッチ率が高い、つまり、面接通過率が高いという特徴があります。
一方で、一言でマネージャと言っても、ずっとマネージャをやってきた人もいれば、ちょっと前までプレーヤーとして活躍して、マネジメント職について経験が少ない人達もたくさんいます。成長前提の組織においては、どこかしらどこかの役割において新人さんがいて、マネージャも例外ではなく、育成、成長を前提とした目標管理をしないと、ただそこに人がいるからと言って、特定の仕事に対して一人前のパフォーマンスを出せるわけではありません。
スカウトを行い面接を通じて人を採用するためには、テクニカルなノウハウは必要で、一例でいうと、
・限られた情報からの人選
・スカウト文面の書き方
・カジュアル面談や面接で聞くことの質の向上
・我々の事業に共感してくれるアトラクトメッセージを洗練させる
・人の特徴を知り、一緒に働ける人材であるかを見極める
・採用する人の成長の道筋を見極めて、給料をあげていける人材か？それをうながせる相手であるかの覚悟ができる
などなどがあります。
これはこれで重要で、実際に採用活動をしながら振り返りを行うことで精度を高めていきますが、とはいえ、PDCA的に採用の質をあげていくためにもある程度、スカウトを行い、カジュアル面談を実現し、ある程度、その人にとっての成功、失敗事例が存在してからが、この改善のチャンスだとも言えます。
よく経営者が話がうまいのは、社員、パートナー、投資家に話をする場数をこなしているからだと言われますが、採用も場数が重要です。コミュ力は生来備わってるものではなく、対話しながら培うものです。
なにより、エンジニア採用にあたって同じ目線で話すことができるのがエンジニアリングマネージャが採用に携わる理由と言えるでしょう。これまでのキャリアと自社のドメイン知識を活用しながら、やってほしいことをマネージャとしての責任を持って言葉として伝えていくことこそが内定承諾につながるわけです。
マネージャのマインドセット問題
そのためにも、まずは場数をこなしながら人をアトラクトするスキルを改善していくことが、本人の成長の早道となっています。しかし採用活動初期においては、まず、この採用活動の速度を出すのがそもそも大変だったりします。
当然、マネージャですから時間の使い方は本人に委ねられているのですが、それまで開発のプレーヤーとしてやってきているが故に、特に新人マネージャは、それまで目を配ってきた開発のことサービスのこと、そして、新しく始めたメンバーのマネジメントにマインドシェアを持っていかれがちです。ざっくり言うと、こんな脳内構成になっているでしょうか。
もっと明確にセキュリティとかサービスのパフォーマンスというキーワードを入れても良かったかもですね。僕たちは日常起きうるアラート対応が24/365で最優先にマインドシェアに存在していますよね？その時点でゲタを履いているわけです。
これらをどうにかこうにか整理しながら、以下のように持っていく必要があります。
僕自身も以前CTOとして働いていた時でさえ、この状態に持ってくるのに苦労しました。
とにかく、採用活動が重要なタスクであり、チームを成長させる道筋なんだ、ということを体で理解するためのフェーズが存在します。ある種プレーヤーとしてのマインドセットをアンラーニングするプロセスが必要で、それが数ヶ月は必要です。組織の役割を整理し、自分の言葉で人を採用できるようになるまでに、人によっては半年ぐらいかかるのかもしれません。
僕の場合は、社長との1on1で、このことを言われまくって少しずつ心の中の自覚を持っていったという流れがあります。開発担当役員である今は、それを僕やマネージャの上司であるManger of Managers が担います。テクニカルな採用スキルは並行して身につけていくものの、このマインドシェアが実現できてなければ、すべては掛け算はゼロになり採用は実現できません。
僕の実体験としても、コードを書くために深く深く集中している時に違うタスクを振られるのは非常に苦手でした。一言でいうと不快になります。プレーヤとして技術に向うのが縦方向に深く集中するベクトルだとすると、人に会って面接をするのは、我々の取り組みについて表現可能なことを、心を平面方向に広げながら会話するという感じで、直行したイメージを持っていました。以前は面接の時間が来た時のスイッチングコストに苦労した時期もあり、そんな辛い思いをするならばと、段々、コードに向き合うのをやめていきました。プレーヤーとしてのマインドセットをまるごと他の人に任せていくことにしてマインドシェアの隙間を徐々に開けていったわけです。
だからこそ小さな組織だと、最初の数人の採用が一番大変ですね。
採用活動をマネージするために
採用は各社困っていて、冒頭のラクスルの松本社長の引用記事は海外人材に活路を見出しているという話で、そういう諸先輩方の取り組みも参考になります。まだまだチャレンジのベクトルはたくさんあるということでしょう。
しかし、ことスタートアップ初期のチームであれば、数少ないCTOクラスの人材がどうにかこうにかマインドシェアを変えながら人材採用を実現していることでしょう。小さなチームであればこそ、一人あたりの影響力が大きいので、一人の採用ミスはチームに大きなダメージをもたらすこともあり、より採用しにくい状況を生むというフェーズでもあったりしますね。
プレーヤーとしてのエンジニアという仕事は、ものすごく細かいところに目を見張って、不具合発生可能性というリスクに目を向け、その改善に集中するというのをコードで表現するのがスキルセットであったりもしますので、正直、採用なんて自分の得意な仕事でもなんでもないし、もっとコードやプロダクト開発、運営に集中したいと思ってしまいますし、実際、それを求めてフリーランスになる人もいてもいいぐらいの大きな分岐点だとも思います。ただ、どうにかこうにか頑張って、組織が大きくなって、そこで活躍している人たちが増えてくれると、それはそれで楽しいものです。
人がいない時は、ただただ人がいないという前提に基づいた悩みしかないですが、人が増えると、コミュニケーションに関するいろんな問題や軋轢が増えたりして、今度は問題が起き続けるという状態になりますが、そっちの方が考えられることが増えて楽しい状態になったりします。
何より自分よりも優れた人材や成長期待の高い人材に自社のビジネスに共感してもらい、人材への投資の形で採用を実現し、プロダクトの質をあげ、ビジネスの成功につなげ、チームメンバーのさらなる成長や期待値のアップに連動する昇給を実現することで、自分自身の報酬自体もあがるという構図が作れます。
それまでのキャリアとは非連続な活動を求められて大変な仕事だなと思います。マネジメントに求められる、組織を作る、開発進捗の実現、採用の実現というのは、それまでやっていた要件から仕様を積み上げて実現可能性を確保するという、技術力を下地にコンピュータをロジックで制御するためにコードを書く仕事とは違って、対人に対して不確実性を御す仕事であると考えてみると、共通点が見えてくるというものではないでしょうか？
この記事が気に入ったらサポートをしてみませんか？