3度の転職経験から考える、中堅エンジニアのための転職戦略

エンジニア転職活動ハックをシェアしよう！カレンダー1日目の記事になります。

筆者について

ソフトウェア・エンジニアとして、これまでに3回の転職を経験しました。
在職期間は一番長くて10年、一番短いところで11ヵ月ほどです。

転職に成功したかどうかでいうと、ひとつの指標でしかありませんが、給与水準は転職の度に上げることができています。

これまでの経験を振り返り、「次に転職するとしたら」という立ち位置で、中堅～ベテランの転職戦略について、企業を選ぶ側面、企業に選ばれる側面の両方から考えてみたいと思います。

職探しの入口

まずは、何を使って求人情報を探すかという方法論です。
だいたい以下のような手段があるかと思います。

• 知人からの紹介
• スカウト・エージェントからの紹介
• 転職サイト・SNSで探す
• SNSやメディアでの発信
• 企業に直接応募する

知人からの紹介

だれでも利用できる手段ではありませんが、知人からの紹介（いわゆる人脈）が利用できる場合には、失敗のない転職ができる確率が（感覚的に）高い方法です。

転職する人にとっても、知人と通じて入社前に企業のリアルな実態を知ることができますし、採用側にとってもある程度スキルや人柄の知れた人を採用できるため、双方にとって失敗の少ない方法となります。

とはいえ、そうそうタイミングよく仕事を紹介してくれる知人がいるとも限らないため、すぐにでも仕事を見つけたいという場合には使えないこともある選択肢です。

長期的には、日ごろからエンジニア向けのイベント・勉強会などを通して、同業種のつながりを増やしておく戦略を取ることができます。

また、転職前の仕事のなかで取引先となる同業他社の関係会社とも、一緒に仕事をした経験からお誘いの声がかかることなどは少なくありません。

スカウト・エージェントからの紹介

ヘッドハントという形で、活躍しているエンジニアに声をかけ、好条件での転職を斡旋するスカウト業者や、転職希望者に対してプッシュ型で求人募集企業を紹介してくれるエージェントのサービスはいくつもあります。

特にIT業界は採用難がずっと続いており、経験豊富なエンジニアを採用したい企業は山ほどあるため、条件を選り好みせず紹介を受けるだけなら数に困ることはないかもしれません。

現在の仕事が忙しくてなかなか転職活動に時間を割けないような場合は、こういった受け身のサービスを利用するのも良いと思います。

転職サイト・SNSで探す

転職サイトの利用は、まず真っ先に思い浮かぶところだと思います。

転職希望者は無料で利用できるサービスがほとんどだと思いますので、まず登録しておいて損はないかと思います。
勤務地やポジション、給料など、様々な条件で求人情報をフィルタリングして探す、といったことがやりたい場合の王道だと思います。

IT転職の場合、特にソフトウェアエンジニア向けの転職サービスを利用することもできます。

Wantedlyなどは、気軽に採用担当者にカジュアル面談を申し込むことができるため、いろんな人にまずは話を聞いてみたい、といった活動スタイルには向いているかと思います。
反面、募集の時点で給与を具体的に書かないことをカルチャーとしているような面もあり、最初から待遇面でフィルタリングしたいような場合はかえって遠回りになる可能性があります。

また、今はTwitterなどのSNS上で採用担当者が積極的に求職者に声をかけたりもしています。
「エンジニア採用」「エンジニア転職」などのキーワードで検索すれば、そういったアカウントをたくさん見つけることができると思います。
一方で、スクールや情報商材に誘導しようとするアカウントも少なくないため、ノイズが多くて効率は良くないかもしれません。

SNSやメディアでの発信

今の時代、個人がSNSやYouTubeなどで発信力のあるアカウントを持っていることも珍しくありません。
そういったいわば個人メディアを所有している場合、手っ取り早いのは「転職先を探しています！」と発信することだと思います。

長期的には、そういった発信力のあるメディアを持つことを戦略とすることもできますが、あまりそればかりを目的とすると努力があらぬ方向に行ってしまうかもしれません（個人の感想です）。

また、発信力のある個人のスキルというのは誤認されやすく、過大な期待を背負って入社したら全然スキルがマッチしていなかった、ということにならないように注意が必要です。

企業に直接応募する

意外と使う人が少ないですが実は効率的なのは、思い浮かぶ企業があるならば、そこに直接応募することです。

先にも書いたとおり、今はどこの企業も慢性的なエンジニア不足であるため、通年で募集をかけているような企業も少なくありません。
企業のコーポレートサイトに行ってみれば、たいてい採用のページがあるはずと思います。

もちろん一定規模以上の企業となると、いちいち直接の応募を受け付けていないケースもあると思いますが、受付がある場合は、直接の応募は企業側の印象にも残りやすいため、おすすめです。

自己アピールの戦略

次に、どうやって希望する企業に採用してもらうか、好条件のオファーをもらうか、という戦略になります。

大事なのは、正しい餌を撒くこと

就活・転職活動において企業に気に入られるためのノウハウは数多ありますが、まず意識すべきは、 気に入ってもらいたい人に気に入ってもらうこと だと思います。

具体的には、カジュアルな文化の企業で働きたいなら、応募や面接の段階から、フォーマルなお作法を意識しすぎないことです。
面接に私服で行ったことで落とされる企業ならば、スーツを着て行って採用され、入社してからカルチャーフィットしていないことに気づくより、私服で行って面接で落とされたほうが良いです。

在職中から、ポータブルなスキルの取得を心掛けること

転職を意識し始める前から長期的に取るべき戦略としては、なによりポータブルなスキルの向上に努めることです。

どんな仕事でも多かれ少なかれ、その企業・その状況でのみ有効なローカルなスキルというのが存在し、日々意識せずに働いていると、そういったローカルな仕事への最適化ばかり進んでしまい、気づけば他の環境で使える能力になっていない、ということが起こりがちです。

特定のニッチな言語・製品のスキルばかり強化しないように努めること。
それだけでなく、AWS, Git, MySQL のように極めてメジャーなツールを利用しているときであっても、 今のやり方は本当に一般的なベストプラクティスなのか？ ということを気にする癖をつけておくべきです。

一方で、ニッチな領域の高度な専門スキルを身に着ける必要性に迫られるケースは少なくありません。
その場合であっても、「ニッチな専門スキルを調査し、効率よく学ぶ」というスキル自体は極めてポータブルなスキルですので、そういう視点で、やはりポータブルなスキルを向上する機会とする意識を持てると良いかと思います。

担当プロジェクトでの活動・成果を記録し続けること

いざ転職する段階になって、職務経歴書として過去にやってきたことを書きだそうとすると、なかなか全て思い出すことができないものです。
仕事でやったことはすべて自身の経歴として（業務PC以外の場所に）記録していく習慣をつけると良いと思います。

記録すべきは、担当プロジェクトの規模・期間、自分の役割、利用した技術、うまくいった点・いかなかった点などです。
特に、挫折や困難を乗り越えたエピソードというのがみんな好きなので、記憶の新しいうちに記録に残しておくと良いかと思います。

仕事以外でのアウトプットを続けること

これも長期的な戦略として、日ごろから技術的なアウトプットを続けておくことです。

アウトプットとして考えられるものは、今だとたくさんあります。
Qiitaのような技術ブログだけでなく、個人で作ったWebサービス・モバイルアプリ、githubのリポジトリ、AtCoderなどの競技プログラミング成績、Stack Overflowでの回答記録、勉強会の主催でも良いと思います。

自分のスキルレベルをわかりやすくアピールできるというだけでなく、継続的に学び続ける姿勢を伝えられる良い材料となります。

スキルの可視化

上記のアウトプットとも関連しますが、転職の際に、自分のスキルをどうやって見せるかはしっかり考える必要があります。
フォーマットの決まった職務経歴書を埋めるだけでは勿体ないです。

例えばばりばり手を動かすエンジニアとしての転職ならば、プログラミング言語のような粒度の大きいレベルの経歴だけでなく、利用したSaaS、フレームワークからDDDなどの設計アーキテクチャ・開発スタイルに至るまで細分化したレベルで、何を何年やり、どれくらいの習熟レベルなのか（主観的にでも「指導可能なレベル」など）まで書いておくべきです。

また、いざ転職する段階であっても、 スキルというのはある程度かさ増しが可能です。
特に React, Next.js などのフレームワークやライブラリのレベルでは、1,2日でも時間をかければ、「まったく利用経験なし」から「趣味で触った経験あり」程度にはランクアップすることができ、労力以上に与える印象を変えることができます。

スキルを見せる手段としては資格の取得もありますが、個人的には、すでに経験豊富な領域であればわざわざ資格をとらずとも見せる方法はいくらでもあり、どちらかというと業務経験や自信のない分野でこそ、客観的な証明として利用できるものかと思います。

ただし、前述のとおり、本来得意なわけでもない領域でとった資格をアピールすることにより、間違った餌を撒くことにならないよう注意が必要です。

企業選択の戦略

次に、自分にあった企業をどのように選ぶかという面から考えてみます。

前提として、転職の目的を整理する

転職にはさまざまな目的があると思います。

• 人間関係のリセット
• 給与アップ
• 労働環境の改善
• スキル向上
• 業種の変更

今の仕事にそこそこ満足しているので、すぐ転職したいわけじゃないけど…という場合でも、どういう条件が揃えば転職を考えるのか、定期的にプライオリティを整理しておくことはキャリアプランを考える上でも大事なことです。

ケプナー・トリゴーの決定分析で比較する

通常は転職活動中に複数の転職先候補ができると思います。
その際に、評価基準を目に見える項目にして、点数表のような形にしておくと、誤った直感による判断を避け、ある程度選択に安定性を持たせることができると思います。
最終的には必ずしも最高得点の企業を選ぶことにならなくても良いですが、評価・選択が妥当であったか後から振り返るための材料にもなります。

方法のひとつとして、KT法として知られるケプナー・トリゴーメソッドのうち、決定分析（DA）の手法を用いることができます。
大まかにだけ説明すると、条件としてMUST（絶対条件）とWANT（あると嬉しい）を洗い出し、WANTのほうは項目ごとに重みづけをして点数付けするという手法です。

たとえば、以下のような項目を作ることができます。

• MUST
  • 年収が○万円以上
  • 転勤なし
• WANT
  • 利用技術が魅力的(5)
  • 残業が少ない(2)
  • 事業に実績／将来性がある(3)
  • 待遇が良い(4)
  • チームメンバーが良い(2)
  • 職場の立地が良い(1)

WANTのカッコ内が重みづけの値になります。
企業へ応募の際は、まずMUST条件を全て満たしていることを確認します。
それから、WANT条件の各項目について、すべて10点満点で採点し、それぞれに重みづけの値をかけた点数の合算がこの企業の点数となります。

		重み	A社	B社	C社
MUST	年収○万円以上	-	○	○	○
	転勤なし	-	×	○	○
WANT	利用技術が魅力的	5	8	9	5
	残業が少ない	2	7	9	2
	事業の将来性	3	7	2	9
	待遇が良い	4	5	7	10
	チームメンバー◎	2	8	6	7
	職場の立地	1	6	1	8
点数			117	110	118
備考			転勤あるため 候補から除外

入社前に企業を知るために

前項のWANT条件のなかでも「チームメンバーが良い」のような項目は、入社前にどうやってわかるんだ、という話になると思います。

ここでは、そういった入社後に初めて分かって後悔する原因になりがちな要素について、入社前にどうやって把握するか、ということのヒントを書いておきます。

インターンができればてっとり早い

入社前にインターンやテスト雇用といった形で、一定期間お試しで働くことができれば、それが一番確実な方法だといえます。

しかし実際には、ゆっくり休んでもいられない状況でインターンのような時間を確保することは難しいですし、企業側としても短期間だけのテスト雇用を受け入れる体制があるとは限りません。

多くの企業には、入社後にいわゆる「試用期間」が設けられていますが、どちらかというと企業にとっての保険のようなもので、あまり機能しているとは思えません。

採用試験としてのプログラミング課題を歓迎する

選考段階でプログラミング課題を設けている企業は多くあります。
コーダーとして転職するならば、このような課題は応募者にとっても時間をかけてでも取り組むべきものです。

特に、課題として提出して終わりではなく、提出後にエンジニアのレビューを受ける機会をもらいましょう。
このようなコードレビューが実際の仕事の形にいちばん近く、技術レベルやカルチャーのフィットを確かめる絶好の機会となります。

個人的な判断の指標としては、たとえば以下のようなものがあります。

• 課題に対し、（合格なのに）エンジニアからフィードバックの機会をとってもらえない
  • ⇒技術レベルが低いか、少なくともコードレビューの文化がなさそう
• 「なんでここで改行しないの？」のような本質的でない指摘ばかりされる
  • ⇒全体として技術レベルが低いか、少なくとも全体でレベルの底上げをする仕組みがなさそう
• 指摘は正しいが、強い言葉で否定される
  • ⇒チームに心理的安全性がなさそう

一緒に働くエンジニアとの面談の機会を必ずもらう

エンジニアではない人事部や経営層との面接だけではなく、エンジニアとの面談の機会を最低1度はもらうべきです。
実際に一緒に働くことになる人と会話する機会をもらわない理由はありません。
リモートワークでない場合、あわせてオフィスで働いている様子を見せてもらうとなお良いですが、セキュリティ上の理由で難しい場合もあるかもしれません。

一緒に働くメンバーの人となりを知ることができるというだけでなく、開発のスタイル・文化が自分にマッチしているか確認できる機会ともなります。

個人的には、新しい技術を取り入れて改善していく文化のない組織で働くことはストレスになるため、ある程度レガシー度を測るような質問もしたりします。

• CI/CDでどんなことをしているか
• コードレビューはどういうタイミングで実施しているか
• テストコードをどういう方針で書いているか

期待される役割を確認する

たとえば入社しようとする企業の技術レベルが低いとか、快適な開発体制が整っていないという状況でも、リードとしてそれらのレベルアップを期待されての入社なら問題ないということもあると思います。

逆に、モダンな環境でバリバリコーディングできると思って入社したら、配属されたのは化石のようなシステムの保守部門、ということになると悲劇です。

お互い「思っていたのと違った」ということになると不幸なので、経営層や上司となる人間に、どういう役割を期待しての採用かということは必ず確認しておいたほうがいいです。

さいごに

以上、ご参考になれば幸いです。

新人エンジニアとして入社したばかりのような人にとっても、いつでも転職できるような準備と心がけを持っておくことは、会社にしがみつかずに済むという意味で精神衛生上も良いことだと思います。