「なぜエンジニアから人事に？」への心からの回答

こんにちは。HR Tech企業で組織開発・人材育成をやっているうえむらです。本記事では私自身のキャリアについてふりかえっていきます。掲題の問いに真摯に向き合い、言語化を試みることを誓います。

なお、本記事を書くモチベーションは以下のツイートに意外と多くの反応（いいね）を頂いたことから生まれています。

自分のキャリアについて話したときにほぼ100%「なんでエンジニアから人事に？？」と聞かれるのだけど、その度にそれらしいことを言って(主に自分を)はぐらかしていることもあり、どこかでちゃんと言語化しておきたいなと思った。

— うえむら (@uemura_HR) May 21, 2024

誰の役に立つ記事か

敢えて挙げるとするならば、以下のどれかに当てはまる方に役立つ可能性があります。

• これから人事になりたいと思っている人（私が人事になるきっかけを知ることができます）

• エンジニアとしてのキャリアに悩んでいる人（私のエンジニア時代の悩みや苦労に共感頂けるかもしれません）

• うえむらのキャリアに興味がある人（包み隠さずに書いていきます）

3行で回答する

例によって記事を書くうちに長くなってきたため、結論を先にまとめます。

• エンジニアのキャリアに行き詰まり「自分は何がしたいのか？」と向き合わざるを得なくなった

• それまでのキャリアを振り返ると、人や組織について考え、向き合い続けてきたことが自分の強みであったことに気づいた

• キャリアの悩みや迷いを上司やその上司に相談するなかで、偶然にも人事の道につながるポジションを打診された

こうしてまとめてみると、明確なキャリアビジョンに基づいた決定でもなければ、なるべくして人事になったわけでもないことが分かります。キャリア自律を推進する人事という立場からは若干の気まずさがあるのですが、タイトルの通り「心からの回答」を目指してこのまま突き進むことにします。

また本記事は私のエンジニアとしてのキャリアの話が中心となっています。これは人事になるきっかけを語る上で、エンジニア時代に経験した出来事が大いに影響しているためです。エンジニアと人事は縁遠く見えてもおかしくない職種。どのようにしてキャリアの点と点がつながることになったのかを丁寧に追っていければと思います。

そもそもなぜエンジニアになったのか

エンジニアになったきっかけは、新卒入社した会社の配属先がたまたまエンジニア部門だったことでした。希望部署はコンサルタントでしたが、3ヶ月に渡る新入社員研修を通じて適性を見極められた結果、エンジニア部門に配属となりました。

ITエンジニアは今でこそ人気職種のひとつとなっていますが、私が入社した2010年当時はそこまで知られていなかったように思います。プログラミングスクールもほとんど見たことはありませんでした。そうした理由を差し引いても、当時の私は文学部出身。学生時代プログラミングどころかPCにもほとんど触ったことがなく、自分がエンジニアになるとは正直想像していませんでした。

3ヵ月間の新入社員研修では「〇〇業界の業務を効率化するシステムを考案せよ」といったお題が与えられ、自ら企画、設計、実装を行ったシステムをプレゼンテーションする流れで時が進んでいきました。特徴的だったルールのひとつに「Google検索禁止」というものがあり、インターネット利用が制限された中でもくもくと課題に取り組む、独特の環境だったと記憶しています。

今思えば当時の私にはかなり無理のある研修でしたが、エンジニアとしての適性を見極められる上では合理的な点もありました。具体的には以下のような力を3ヵ月という期間でどこまで伸ばせるかを見られていたように思います。

• 未知の課題に直面しても、その状況に留まり、自分の頭で考え続ける力

• 手を動かし、仮説検証や試行錯誤を繰り返して答えに辿り着く力

• 一日中プログラミングしていられる力

今でこそネガティブ・ケイパビリティやレジリエンスと呼ばれる困難に向き合う姿勢を新卒研修時代に養うことができたのは幸運だったと思います。無茶振りなところはあったにせよ、失敗しても何のダメージもない研修期間。挑戦に全振りすることで成長曲線を高めることができたのではないでしょうか。

自分の限界と向き合う技術を身につけた駆け出しエンジニア時代

期せずしてエンジニアの門を叩くことになった私ですが、配属されてからは前向きに、むしろ意識高く業務に取り組んでいました。少なくとも一人前になるまではどんなに大変でもエンジニアを続けようと考えていたことを覚えています。しかし日々、分からないことの連続。自分の限界と向き合い続けるなかで、一体どうすれば生き残っていけるのか。決して自信があったわけではなく、不安の渦の中でもがき続けていました。

新人エンジニア時代の心の拠り所「経験学習サイクル」

駆け出し時代の私を支えたのは「経験→内省→教訓→実践」を繰り返す経験学習サイクルでした。特に文字として書き起こすことを通じた振り返りや、実業務の中で自然にサイクルを回せる習慣を作ったことが一人前になっていく重要なファクターだったように思います。

(後に経験学習という言葉に出会った際に「あれが経験学習かー！」となり、経験学習を経験学習することになるのはまた別の話)

配属当初は自力で解決できることがあまりに少なく、夜になっては「今日一日何をやっていたんだろう？」と空を見上げていました。成長実感どころか無力感が日に日に募っていきます。このままだとまずいと思いPDCA形式で日記をつけることにしたところ、無力感のなかにも効力感を見出せるようになりました。特にその日分かったことやできるようになったことなど、小さくでも良いので前進したことに目を向けるようにしていました。日記が溜まっていくにつれ、毎日文字に起こし続けた内容を他にも役立てられないかと思い、週末や月末にその期間のふりかえりをするようになりました。

また配属当初はシステム保守業務を担当しましたが、ユーザーからの問い合わせにうまく回答できず四苦八苦していました。先輩に質問しようにも何が分かっていないかが分からない状態。質問の意図を伝えることすらできない状況でした。このままだとまずいと思い、問い合わせの内容を定型的にノートにまとめてから質問するようにしたところ、以前よりも置かれた状況をスムーズに伝えられるようになりました。自分の仕事の進め方を書き出したものが蓄積されることで、陥りがちなパターンや理解が浅い点をメタ認知することにも役立ちました。

分かったふりをしないマインドがプログラミングスキルを高めてくれた

エンジニアの必須科目であるプログラミングを理解することにも大変苦労しました。当初はプログラムが動いているところを見ても一体何が起こっているのか分かりません。それどころか、そもそもプログラムを動かす以前の環境構築で詰まりまくっていました。何かが分かっても、すぐにまた分からないことにぶつかってしまう。文字通り分からないことの連続でした。

この時私が大事にしていたのは分かったふりをしないことでした。プログラムは動いてくれると満足しそうになるものですが、一歩踏みとどまって自分の理解度と向き合うようにしていました。具体的には何が分からないかを分かるようにするため、プログラムを1行ずつ動かし、その中で変数と呼ばれる値がどのように変わっていくかをひたすら目視したり、分からないことにぶつかる度にプログラムの文法を調べては、何が起こっているかを自分の言葉で説明できるところまで落とし込んでいました。

先輩への質問や相談においても、分からないことを正直に分からないと言うことを心掛けていました。私は同僚との競争意識が強かったこともあり、分からないことを表明することで周囲から無能だと思われるのではないかという恐れはありました。しかし実際には先輩や同僚は粘り強く相談に乗ってくれました。今思えば、私が一人前に成長することで未来のチームが楽になればという投資をしてくれていたのだと思います。私自身も教わった時間をチームの成果に役立てたいという意思を常に示し続けていました。

このように分からないことを分かることに変える努力を地道に積み上げたことは、一見遠回りに見えることではありましたが、結果的に未来の自分のキャパシティを増やし、複利的に自分を助けてくれたように思います。

つよつよエンジニアに囲まれて自らの強みを模索し続けたリードエンジニア時代

エンジニアとしてのいろはを学びつつ一通りの業務を経験していった後は、徐々に新規機能の開発に軸足を置くようになりました。周囲で新規開発に携わるエンジニアは高い技術力を有しており、タフな面子が揃っていました。

技術力だけで見ると周囲のエンジニアと私とでは天と地ほどの実力差があり、別の方法で貢献しなければ自分の居場所はないと思っていました。様々な自己啓発書を読むなかでストレングス・ファインダー(現 クリフトンストレングス)に出会い、自分の強みを活かすことで道を拓いていく考え方を知りました。

リードエンジニア時代のストレングスファインダーによる上位資質

上位資質のなかでも特に「戦略性」と「個別化」にはしっくりきました。これまでの人生を振り返ってみても、一貫してこれらの強みを活かして難局を乗り越えてきた実感があったためです。その他の資質についても、特に社会人以降の環境に自らを適応させるうえで意識してきた要素であり、たしかにそうだなと思えるところがありました。

これらの強みを元に、戦略性による構想力・企画力を自らのリーダーシップの核として持つこと、そして個別化を活かしたチームビルディングを通じて組織成果への貢献を模索していきました。設計力、技術力といったエンジニアとしての必須科目における弱みを自らの資質でカバーすることで、周囲から認められる成果を安定的に上げられるようになっていったように思います。

チームを通じて成果を上げるということを初めて意識したのもこの頃でした。利用ユーザー数百社のエンタープライズ向け製品を開発していたこともあり、製品の各機能ごとにチームが編成され、チーム単位で動いている環境でした。チームをリードする役割になった当初はそれまでの上司の運営方法を見様見真似で実践していましたが、それだけでは不十分だと考え、チームビルディングやマネジメント関連の書籍を読み漁り、自身のチーム運営に取り入れていました。

技術力で周囲を牽引することはできませんでしたが、チームワークについては人一倍よく考え、実践していたように思います。チーム共通のゴールを明確に示し、適切に役割分担を行い、進捗を日々確認し、何かあったらいつでも相談できる関係性を築く。GRPIモデルを知ったのは人事になってからのことですが、当時のチームを振り返ってみるとすでに実践していたことも多かったように思います。

新規事業への挑戦の果てに組織崩壊を経験したエンジニアリングマネージャー時代

リードエンジニアとして主に新規機能開発に携わった後、社内で大々的に新規事業を立ち上げる動きがありました。従来の主力製品とは異なるビジョンを掲げる点に魅力を感じ、私も自ら手を挙げて異動することになりました。異動後は環境の変化にまたしても四苦八苦することになります。特に当時の先端技術をキャッチアップすることには苦労しました。やはりここでもテクノロジーへの苦手意識に日々悩まされされつつ、それでもなお、未知なるものに挑戦することへの衝動によって自らを鼓舞していました。

新規事業では従来製品とは全く異なるコンセプトで開発を進めていました。当時はトップダウンが強い社内風土で、製品コンセプトについても責任者の頭の中にあるものを理解し、具現化する方法論が取られていました。文字通り社運をかけた新規事業であったため責任者の求める水準は非常に高く、またメンバーもそれに応えようと必死でした。毎日のように新しいプロトタイプを作っては、レビューで無数のフィードバックを受け、その言葉の端々から次のヒントを手繰り寄せる。正解が見えないまま試行錯誤を繰り返すなかで、徐々に人も組織も疲弊していきました。

私はそうした厳しい環境のなかでも、どうすれば自分やメンバーがモチベーションを維持して働き続けられるかに興味を持ち続けていました。昔から逆境になるほど燃えるところがあったように思います。いくつかの機能を何とかリリースにこぎ着けることができました。しかし、最終的に新規事業は失敗に終わりました。目には見えない形でしたが、組織崩壊に近い状況も発生していたように思います。気が付くと私自身の気持ちも折れてしまっていました。

エンジニアとして一人前になるまで走り続けようと決めてからここまで、その決定に疑いを持つことはありませんでした。しかしこの時はエンジニアとしてのキャリアに限界が来ていることを感じていました。

いったい自分は何がしたいんだろう？

ようやくその問いに真剣に向き合う時がきたのです。

エンジニアから人事へ染み出していく

ここまでのエンジニア人生をふりかえると、私自身は一貫してテクノロジーへの苦手意識を持ちつつ、関心領域である人や組織についての技術を学び、実践し続けることで弱みを補ってきたことが分かってきました。

エンジニアという人種は、真面目なのか不真面目なのかよく分からないところがあります。子供のように率直な不満を漏らしたり、相手との距離感がうまく掴めずに苦労したりする一方で自身が生み出す成果物に対して厳しい視点を持ち、もっと強くなりたいと自己研鑽を重ねるプロフェッショナルとしての姿勢を持ち合わせている。そんな愛すべきエンジニアたちに囲まれて過ごしたことで私自身も成長することができました。こうした背景からエンジニアがいきいきと働ける環境づくりに貢献したいという思いが育っていきました。

同時に、あれほど優秀なエンジニアが集結しても、組織としては成功に至ることができなかった事実も私のなかに残り続けていました。様々な層で、様々な要因が積み重なった結果ではありました。しかし敢えて真因をひとつ挙げるなら、チームや組織を効果的にワークさせることへの関心の薄さが常に自分たちの足を引っ張っていたことに無自覚なまま、個の力を高め続けようとするカルチャーが招いた結果であると私は考えています。個の力と組織力を掛け合わせることへの価値に目を向けていたなら、また違った未来があったのかもしれません。(※歴史にタラレバはない)

このように自分自身の指向や忘れられない課題に目を向けるなかで、ぼんやりとではありましたが、今後自分が携わりたい領域が浮かんできました。人や組織が持つポテンシャルを引き出すことでエンジニアに貢献したい。エンジニアリングマネージャーという役割を超えて、人そのものがボトルネックとなっている問題解決に携わりたい。

こうしたキャリアについての迷いを上司やその上司に隠さず相談してきたことが、今思えばエンジニアから人事へのキャリアチェンジの一歩目でした。相談を重ねるなかで、ある日上司から「うえむらさん、うちの会社のエンジニア採用を助けてもらえない？」という打診を受けることになります。採用市場の変化で優秀なエンジニアを確保することが難しくなり、人事が困り果てている。エンジニア組織から採用にコミットしてくれる人を出してほしい。会社からそのような要請があり、私に白羽の矢が立ったということでした。

私は採用に強い興味を持っていたわけではありませんでしたが、人や組織に関わる入口となるプロセスに携わることで自身のキャリアにおける次の一歩としての可能性が拓ける予感があり、このオファーを受けることにしました。

このような流れを経て、私はエンジニア組織と人事を兼務する形でエンジニア採用に関わることになりました。最初から人事になろうと決めていたわけではなく、人や組織をより良くしたいという私の思いと、会社側の要請がマッチする点が重なったことが人事への道につながっています。もしも上司やその上司が辛抱強く私の話を聞いてくれなかったとしたら、おそらく私は別の道を選んでいたのだろうと思います。彼らが私と会社とをマッチングしてくれたことで私は自社にとどまり、次の一歩を見出すことができました。

おわりに

本記事では私がエンジニアから人事にジョブチェンジすることになったきっかけについて書きました。ターニングポイントとなる出来事や背景となるエンジニア時代のキャリアを中心に、タイトルにも挙げた「心からの回答」に辿り着けたように思います。

なおエンジニア採用に携わった後も紆余曲折は続くのですが、長くなってきたのでこの辺りで切り上げることにします。気が向いたらまた続きを書くかもしれません。ここまで読んでいただきありがとうございました！

人事に来てからやらかしたことをまとめた記事もあります。お時間のある方はこちらもご笑覧ください。

本記事を通じて私のキャリアに興味のある方や、これから人事を目指したい方とつながりができると嬉しいです。興味を持ってくださった方は、Xなどを通じてご連絡ください。

それでは、また。

うえむら（@Uemura_HR）