エンジニアから人事になってやらかしたことをふりかえる
本記事は 2023年 ジンジニア アドベントカレンダー9日目の記事です。
前日はglicoさんのフルリモート組織におけるインフォーマルコミュニケーション施策のアンチパターン３選でした。
こんにちは。人事のうえむら(@uemura_HR)です。最近親知らずを抜きました。快適に食べられるって最高ですね。
本記事では、私がエンジニアから人事になってやらかしたことを噛みしめていきたいと思います。
はじめに
私はエンプラ向けのWebアプリ開発、エンジニアリングマネージャーを計10年近くやった後、ジョブチェンジして人事を3年ほどやっています。そろそろ人事としてのキャリアを振り返るか…と思っていたところにジンジニアのアドカレを見つけ、飛び込んでみました。
色々とやってきたことはあるのでこれまでの取り組みについて書いても良いのですが、せっかくならジンジニアに興味を持っている人のハードルを和らげるような記事にしたいと思い、私の失敗談を振り返っていきます。羞恥心に打ち勝っていくぞ。
なお前提として、勤務先は以下のようなスペックとなっています。
IT企業 (HR Tech系)
社員数2000名弱、採用/人事組織50名弱
創業4年目。分社化してできた新会社
やらかし1: 序盤に兼務しすぎた
エンジニアたるものキャッチアップ速度は大事ですよね。私もそう考えていました。マネージャー経験を経てのジョブチェンジであったため、今思うと少し力み過ぎていたのかもしれません。エンジニア採用、労務対応、人材育成と3つのチームを兼務するところから私の人事キャリアは始まりました。序盤は覚えることも多く楽しめていたのですが、徐々に慣れてきて各ロールのタスクが積まれるようになったところから違和感を覚え始めました。
マネージャーに状況を理解してもらうコストが高い
兼務数が増えるほどマネージャーとの関係性も増えることになります。マネージャーは頭では兼務比率や工数を理解していても、状況をすべて把握しているわけではありません。そのため工数などのデータを元に自分の置かれている状況を理解してもらい、業務量をコントロールしたり調整を行うことが増えていきました。
労務と人材育成を同時に持つことの難しさ
あくまで仕事の性質としてという話にはなりますが、労務と人材育成を同時に持つことはあまりお勧めしません。労務対応は差し込みが多く、緊急を要する課題が突如として降ってくることがあります。高い専門知識が求められる仕事なのでエンジニア経験がある人が労務を担当すること自体は悪くないのですが、その他の業務が止まってしまうことがよくあります。一方で人材育成についてはまとまった時間が必要となる企画仕事が多い点、計画的に研修や施策をリリースする必要がある点など、労務とは異なる性質を持ちます。エンジニアの仕事にたとえると、年中新規開発をやりながら製品保守をやり続ける感じになります。(スタートアップやアーリーベンチャーではそうも言っていられないんだろうな、とも思います。)
結果的に、私は業務量が許容範囲を大幅に超えてしまう前にギブアップしました。上司が理解のある人だったので諸々かけあってもらい、それ以降は兼務することはなくなり、今のチーム(人材育成・組織開発)に専念することになりました。
やらかし2: イシューからはじめすぎた
エンジニアたるもの課題解決こそ命。現場部門にあれこれ言う前に足元の人事組織の課題を解決していきましょう。そんな風に考えていた時期が私にもありました。いや、今でもその考え自体は変わっていないのですが、課題との向き合い方がよくなかった。まだロクに関係性ができていないうちから、不満を書き溜めては1on1で上司にぶつけていたのです。これは3年前に私がしたためていたメモです。自分で見ても胸が痛みますが、ここに供養させてください。
お察しの通り、このやり方はうまくいきませんでした。それどころか、目に見えないところで信頼残高をすり減らしていたように思います。人事としてスタートしたばかりでしたから、むしろ残高のないところから借金していたのかもしれません。
これはエンジニアあるあるというよりは私あるあるかもしれませんが、理想を追求するあまり、歴史に敬意を払うことや現状を理解する姿勢が薄くなりがちなところがあります。人事という仕事は、絶えず経営や現場との対話を通じて、現状をインクリメンタルに改善していく性質がありますし、足元の組織もそうした仕事の性質を色濃く受け継いでいます。対話を通じて上司やチームメンバーと関係性を築いていくべきだったと反省しています。
やらかし3: 自動化しすぎた
エンジニアたるもの非効率な作業はできるだけなくしたいですよね。私もそうでした。人事業務には事務作業がつきもの。必ずしもITに強い人ばかりではないため、従来の運用フローが非効率に見えてきて、我慢ならん！となることがあります。そうした際に自分に課せられたタスクだけを自動化したり、自分以外のメンバーが運用できないような形で自動化を行ってしまうと、かえって全体の効率を落としてしまうことがあります。
よくよく話を聞いていくと、元々はシンプルな運用だったものが、様々な事情が積み重なって今の運用になっていることがほとんどです。こうした場合、まずは関係者との対話を通じて全体像の把握に努め、これまでの経緯に理解を示すことが重要です。また現運用メンバーの悩みに耳を傾け、今みんなが困っていることからスタートすると、改善の機運を生み出すことができます。実際に運用を改善する際には、メンバーだけでなくマネージャーを含めて提案を行い、チーム運営に支障が出ないよう工数を確保することで、改善に取り組む姿勢への信頼感を生むことができます。時間はかかりますが、周囲をうまく巻き込んで「私たちの課題」として対処することが成功の秘訣であると思います。
一方で、自分が立ち上げた仕事や自分ひとりで完結する仕事については運用フローを0から考えることができます。人が担う必要のないタスクはどんどん自動化していきましょう。また他の担当者が運用できるよう、マニュアルを整えたり、最低限の保守スキルを身につけてもらうことも合わせてやっていくと良いと思います。私もそうしてきました。
またチーム全体での運用力を高めるために自動化勉強会を開催したりもしました。結果的に数人のメンバーが業務に自動化を取り入れるようになり、たしかな手応えを感じています。
ちょうど1年前に人事内で全10回のGASを使ったプログラミング講座を実施した。当時の参加メンバーが業務にプログラミングを取り入れ始め、現場マネージャーへの定期的なデータ提供などの領域を自動化している。挑戦する姿勢もさることながら、効率化と従業員体験を両取りできている点が素晴らしい。
— うえむら (@uemura_HR) October 10, 2023
やらかし4: 情報の非対称性に固執しすぎた
エンジニアたるもの情報の非対称性には敏感ですよね。私もそうでした。人事をやってみると、経営に直結する情報にアクセスする機会が増え、会社の方向性をいち早く察知することが多くなります。一方で、社員との情報の非対称性に悩む場面があるかもしれません。
私はエンジニア時代からSlack上でtimesチャンネルを運営しており、人事になってからも継続しています。チャンネル参加者は現在370名で、日々多くの社員と交流を深めています。全社員の1/5程度が見ていると思うと気が引き締まりますね。
エンジニアから人事になった当初は、timesチャンネルを使って人事企画のプロセスを発信していた頃がありました。オープンさが大事だぞ、情報の非対称性を減らしていくぞと息巻いていました。今もその思いに変わりはありません。けれどこれは結果的に良くなかったと反省しています。人事企画は社員に広く提供されるものであり、情報提供をtimesで行うことは結果的に情報の非対称性を再生産してしまうためです。
人事企画についての発信や社員に意見を募る場合においては、組織運営上の会議体などの公式チャンネルを活用し、全員に情報が行き渡ることが保証されている状態を作ることが重要です。一方で、日頃読んでいる書籍から得た学びを発信したり、社員の良質な発言を広める際にはtimesなどの非公式コミュニティを活用することが効果的な発信に繋がります。この辺りは塩梅が難しい点でもありますが、企業毎のカルチャーやコミュニケーションポリシー、ガイドラインを理解し、信頼性の高さとオープンさを併せ持つ人事を目指していきたいものです。
やらかし5: 個人情報を社内漏えいしそうになった
人事には社員が持つ個人情報を取り扱う場面が数多くあります。自社では個人情報保護規程を定め、個人情報を取り扱う業務については厳格な運用体制を敷いています。
キャリア開発施策の立ち上げを行ったときのこと。私は自社製品を活用して社員が定期的に自らのキャリアをふりかえる仕組みを構築していました。上司と部下でキャリアについての対話を行うため、ふりかえりを行ったデータは本人と上司のみ参照できるものとする、という要件がありました。
上司と部下という条件は一見シンプルに見えますが、多くの検討すべき点があります。そもそも「上司」とは何を指す言葉なのかという点に始まり、上司が兼務する場合の取り扱い、出向社員についての取り扱い、異動後のデータの取り扱いなど、様々な点について議論を重ね、実データについても複眼で検証していきました。
しかし、稼働前の最終検証で思わぬ事実が発覚します。上司側の社員が兼務し、兼務先ではメンバーである場合に、同じチームメンバーのキャリア情報を参照できてしまうことが発覚したのです。リリース日まで猶予がないこともあり、正直焦りました。しかし冷静になって上司に相談し、再検証のためリリース日を延期してもらいました。その後設定を見直した上でテストケースを見直し、再検証を行った後、無事に施策をリリースすることができました。
人事データには、様々なエッジケースが存在します。前述した兼務におけるパターンは典型的な例ですが、それ以外にも休職・退職前後の社員や、組織構造上、他の組織と異なる構造を持つ組織など、様々なケースについて考慮する必要が出てきます。
会社が一定規模以上になると人事組織内で機能別にチームが分かれていきますが、こうしたデータにまつわるノウハウはチームに閉じられがちです。失敗経験を含めてチーム間で積極的に共有し、テストデータやエッジケースをチーム間で標準化しておくことで、人事組織全体でデータリテラシーを高めることができます。人事メンバーの誰もが安心して施策に取り組める環境を作っていきたいものです。
ジンジニアになることは、結局エンジニアであることを忘れることなのか？
ここまでお読み頂きありがとうございます。もしかすると、ジンジニアになるにはエンジニアであることを忘れる必要があるの？と思われた方がいるかもしれません。しかし、そうではないと私は考えています。エンジニア時代に培ったマインドやスキルは今でも脈々と生きています。人や組織についての技術を学び、実践することはエンジニアリングに通ずる楽しさがあります。また人事施策を継続的に改善するためには人事にアジャイルなマインドセットを根付かせていく必要があります。エンジニア採用やエンジニア組織にまつわる問題解決など、エンジニアとしての経験がダイレクトに活かせる領域も少なくありません。しかし私自身について言えば、人事としてのふるまいを身につけ、周囲から信頼される存在となってはじめてエンジニア出身であることが強みとなった気がします。多くのやらかしと向き合い、失敗から学び続ける姿勢をこの先も持ち続けたいと思います。
おわりに
いかがでしたか？
エンジニアから人事にキャリアチェンジする中で多くの失敗をしてきましたが、その中で特に印象深いものをふりかえってみました。将来的に人事をやってみてもいいかなと思っているエンジニアの皆さんの参考になれば幸いです。
私は今後の人事にはエンジニア出身者がもっと必要だと考えています。エンジニア組織の理解者であるという点だけでも十分に価値を出すことができますし、テクノロジーを活用することで人や組織が持つ潜在能力を引き出すことができる点、人事組織に多様性をもたらす点など、その恩恵は計り知れないからです。
しかし、いざエンジニア出身者が人事をやってみると、人事特有の価値観に馴染めない感覚を持ったり、今までに通用してきたことがうまくいかなかったりと壁にぶつかることが少なくありません。ジンジニアは人事全体の中で見ればまだまだマイナーで、希少価値が高い存在です。だからこそ、こうして失敗談を書くことが誰かの不安な気持ちを取り除くことに繋がるといいなと思っています。
ジンジニアアドベントカレンダーの10日目は庭屋 一浩/Kazuhiro Niwayaさんです。お楽しみに。
おまけ
私の勤務先でやっているアドベントカレンダーを紹介します。立ち寄ってみていただけると嬉しいです。
しずかなインターネットもやってます。こちらも覗いてみてもらえると嬉しいです。
それでは、皆様よいクリスマスを🎄
この記事が気に入ったらサポートをしてみませんか？