ウェブエンジニアから人事への適応
この記事はジンジニアアドベントカレンダーの2日目の記事です。
前日はtakakazu1009さんの
でした。
この記事では、ウェブエンジニアから人事に転向して丸4年が経過した私の経験をもとに、ウェブエンジニアから人事への適応過程についてまとめます。
前提 - 人事領域の経験
ウェブエンジニア時代の人事に関連する領域の経験としては以下がありました。
正式な担当としての経験はなく、単発での担当範囲に留まっています。
採用業務
マネージャーのエンジニア採用をサポートする範囲
組織関連
単発の人に関わるトラブル対応の範囲
経営戦略に直結する社内システムへの関与時に経営戦略のインプット
なお、マネージャーの経験はなく、非公式のチームリーダーやサブリーダーにあたる役割までを経験していました。
未経験から人事への適応過程
前職で初めて人事になった際の適応過程についてまとめます。
全社採用
入社直後は全社の採用施策として仕掛り状態だった構造化面接の導入を引き継いで担当しました。
ビジネスサイドから導入する形で進めていたのですが、元々ウェブエンジニア出身の私は、ビジネスサイドの方々と方針を固める調整をうまく進行することができず、
構造化面接に関する下調べ
実施プロセスの整備
プロセスの明確化
基本理解の文書整備
必要なツールの整備
評価観点の整備
評価観点を確認する質問の整備
質問を評価する評価基準の整備
構造化面接の模擬実施
を進行したにも関わらず、現場の業務負荷の影響もあり、安定運用の優先度があがらずに定着しないという結果に至りました。
この施策は進行途中のものを引き継いこともあり、今思い返すと以下の工程まで立ち返って動けていませんでした。
現場の課題感を具体的に把握すること
現場の納得感を作った上で、現場から求められる施策として実施すること
現場の稼働状況や新規施策の導入余力を把握した上で現実的な導入プロセスにすること
入社直後で現場からの信頼貯金がない状態を踏まえること
これらの前提をふまえずに進めてしまったことが失敗の原因だと思っています。
エンジニア採用
次に主担当業務がエンジニア採用の推進にシフトします。
エンジニア採用業務を始めるにあたって大まかに
エンジニア採用の選考関連の業務を担当しつつ、採用業務の現状や課題感を理解すること
エンジニア採用の現状を踏まえて、大玉の課題感を整理すること
からスタートしました。
現状理解を終え、大玉の課題を優先度順に並べ、開発部のVPoEと認識を合わた上で順次改善していくことになりました。
VPoEや各求人枠の責任を持つ開発部のマネージャーたちとエンジニア採用に対する考え方が一致していたこもあり、方針に対する認識は最初から一致していて、順調に一つずつ取り組むことができました。このあたりは私がウェブエンジニア出身であり、属性的に近いことからビジネスサイドの方々との連携よりもうまく話が進みやすかったのでしょう。
実施した施策の具体的な内容はここでは省略しますが、気になる方は以下をご覧ください。
なお、この記事の前提に記したように採用業務は多少関わったことはありますが、特に詳しいわけでは無かったため、担当するにあたって書籍・ウェブ・社外の人とのやりとりを通して急ピッチでインプットをしつつ、実際の取組みをふりかえりながら必要な知識・スキルを身に着けていきました。なお、社内でエンジニア採用について指導をしてもらえるような相手もいなかったため、自分が一番詳しくなる必要がある状態でした。
採用のプロセスは順調に整い、個別の採用業務も順調で、各求人枠も充足していきました。
プロセス改善・採用成功の双方の面から信頼貯金が貯まり始め、物事を進める際にさらに協力を得やすくなってきました。
人事評価制度担当
採用のプロセス改善が一通り落ち着き、型が出来上がってきた頃、コロナの影響もあり一定期間採用が縮小されることになりました。
薄く採用業務を継続して担当しつつ、合間の期間で人事評価制度改定および運用を担当することになりました。
はじめは人事評価制度の責任者の下で制度の担当者として
改定準備
改定内容の議論
改定内容文書化
評価システムの実装
導入対応
導入説明会の実施
運用対応
導入後の問い合わせ対応
評価に関わる相談役(マネージャー、メンバー双方)
などを担当しました。
人事評価制度の担当をするのは初めてでしたし、過去の所属でもきっちりした人事評価制度があったのは1社のみで、その会社でも制度説明は無かったので人事評価制度に関する基本的な内容の理解はほぼない状態からのスタートでした。薄く残っていた採用業務を継続して担当しつつ、人事評価制度に関して書籍・ウェブ・社外の人とのやりとりを通して急ピッチでインプットをしつつ、実際の取組みをふりかえりながら必要な知識・スキルを身に着けていきました。なお、社内でも指導をもらえるような相手もいなかったため、自分が一番詳しくなる必要がある状態でした。この点はエンジニア採用業務と全く同じ流れです。
その後、制度運用を一通り終えた後に制度に関する社内アンケートを実施し、得られた情報をもとに次の評価期間に向けて制度の改善を経営陣に提案し、改善を推進する機会を得ました。
評価期間の途中でのマネージャー、メンバーからの問い合わせや相談
年度をまたぐ際の大玉の制度改善をするための現場の部門長クラスとのやりとり
これらのやりとりから課題感を詳細に把握し、少しずつ制度運用を改善していきました。
ピープルマネジメント
採用の縮小期間を終え、再度アクセルを踏みなおすこともあり、今まで人事では私1人で担当していたエンジニア採用業務の担当者を増員することになりました。
私は人事のマネージャーではなく、いち担当者でしたが、人事部門の部門長は人事領域のエキスパートではない状態が続いていたため、新任の採用担当者を採用し、受け入れ、戦力として立ち上げるまでの過程はすべて私が検討し、検討内容を部門長に提案し、承諾を得つつ進める形になりました。そこで
などを行いました。
幸い私のリファラルにより即1名の採用に至り、今度は部門内の入社オンボーディングおよび育成基盤の整備です。
部門入社オンボーディング
オンボーディングコンテンツの整備
育成基盤の整備
各グレードごとに以下を整理
担当する業務
担当する業務に必要となる知識・スキル
また、これらの育成基盤をもとに週次の1on1やペアワークを通して育成をしていきました。
結果として、新メンバーは半年後には1人でエンジニア採用業務の担当者の内容について一通りを任せることができる状態になりました。
1社目でのポイント
うまくいった点
うまくいった点として2点あります。
1つ目に、初めての領域を担当する場合も、教えてもらえるのを待つのではなく、
自分自身で徹底したインプットを行うこと
継続的なふりかえりで継続的に改善をすること
を継続することで素早くキャッチアップしていくことができました。
また、インプットだけではなく、自分の知識や経験をブログでアウトプットすることでより深い理解を得つつ、人事領域に関わる社外の人の役にも立ち、結果として他社の人との交流が広がり、情報交換できる相手が増えたり、登壇・発信の大きな機会をもらえたりとポジティブなサイクルが巡っていました。
特に人事になると同時にころちゃん https://twitter.com/corocn と立ち上げたジンジニアコミュニティで継続的に情報交換できる場を得られたのは大きかったです。
新しく取り組む対象について必要な内容を自発的に学習すること自体はエンジニア時代から慣れていたので、特に問題ではありませんでした。
2つ目に、仕事がうまく行き始めた時期をふりかえると信頼貯金の有無が大きかったと感じています。
エンジニア採用業務を担当し始めた時期から
成果を出す
信頼を得る
新たな挑戦をする
が巡りはじめました。また、ある程度信頼が高まると社内の人から相談を受ける機会も増えてきました。
相談された結果としてまた信頼が蓄積し、なにか物事を進めるときに協力してもらえる人が増えていきました。
このあたりは担当者としてのウェブエンジニアの業務では実感しにくい部分で、人事になって初めて関わる部分でした。
開発者としてもマネージャーやリードエンジニアなど周囲を巻き込んで物事を進める担当をする場合は似たような場面は発生していたでしょうが、私は担当者範囲だったのでそういった機会はあまりありませんでした。
難しかった点
難しかった点として3点あります。
1つ目に、実践の重要性があります。エンジニアとしての開発は業務外でも手を動かして実践できる部分がありますが、人事領域の実務は業務を通しての経験が必須になるものが多くあります。そのため、未経験ながら実践を通して失敗をしつつ学ぶ必要もありました。このあたりは、信頼を積み重ねることと失うこととのバランスに関わるため、未経験なりにある程度の失敗はしつつも成果そのものは出して信頼を得る事自体が周囲の協力を得るために必須であり、それ自体が継続的な成功のために必要なため、「未経験のことでも一定以上の成功率を出せること」という難点がありました。このあたりはかなり薄氷で、なんとか失敗で信頼を失うよりもはやく信頼を蓄積することができたのだと思っています。
だだ、私の場合、自分の成功を強くサポートする人がいなかったので自力でなんとかする必要がありましたが、サポートをしてくれる人が身近にいればハードルは下がるでしょう。
2つ目に、人とのやりとりに関わる立ち回りの重要性があります。エンジニアの業務と比べて他者とのやりとりが重要な場面が多くあります。
現場からの要望が元々あり、それを実現するような取り組みは話が進みやすいですが、人事目線では課題感があることは分かっているが、現場から見ると課題感を持っていないような場合、一緒に取り組んでもらうための説得が必要になります。こういった際に、説明内容の説得力だけではなく、普段からの関係性や信頼が重要になります。
こういった部分は、エンジニアでマネジメントも経験したことがない立場だとあまり経験がなく、はじめはかなり苦戦した部分でした。
これに関しても実践の話と同様に失敗をしつつ、ふりかえりから学んでいきました。また、自分ひとりでは難しいときは、社内外の人に相談することもありました。
3つ目に、人事の業務は開発者の業務に比べて割り込みや複数施策を並行して動かすような事が多く、スイッチングコストが高めになりがち、という部分があります。
そのため、エンジニア時代以上にタスク管理におけるタスクばらしをしっかりするようになりました。どこまで進んだか細かな単位で確認可能にしておけば、割り込みからの復帰がしやすくなります。
予告
別途ジンジニアアドベントカレンダーの5日目に「担当者から部門長への適応」についてまとめます。
まとめ
ウェブエンジニアから人事に転向して丸4年が経過した私の経験をもとに、ウェブエンジニアから人事への適応過程についてまとめました。
あくまで1人の経験の例に過すぎないので、万人に当てはまるとは限りませんが、これから人事領域に踏み出そうとしている人の参考になれば幸いです。
ジンジニアアドベントカレンダーの3日目はbobさんです。お楽しみに。
関連情報
いただいたサポートは新たな知識の習得のため書籍購入費にあてさせていただきます。