ITエンジニア採用は難しい！？現役Web系エンジニア視点における問題点と解決策まとめ

こんにちは。Tomoyuki（@tomoyuki65）です。

私は元システムエンジニアで、現在はWeb系エンジニアの仕事をしていますが、最近色々な転職サイトを使ったりして色々思うところが多いです。

簡単に言うと、「なんでこんなクソみたいなやり方してるの？？？」ということが多かったりします。

これにはもちろん既存の転職サイトにおける構造的な問題も含まれていたりしますが、そもそも採用活動をテキトウにやっていることが原因なんじゃないかなと思うことも多いです。

そこでこの記事では、現役Web系エンジニアである私の視点から、ITエンジニア採用における問題点とその解決策についてまとめておきます。

もしITエンジニア採用に困っている人事関係者や、ITエンジニアについてよくわかっていない経営者の方々は、ぜひ参考にしてみて下さい。

ITエンジニア採用は難しい！？現役エンジニア視点における問題点と解決策まとめ

まず現役Web系エンジニアである私の目線から、現在のITエンジニア採用における問題点については以下の通りです。

問題点1：大量のテキトウなスカウトメール

転職サイトに登録すると、大量のスカウトメールが届くことが多いです。

ただし、本当にテキトウな文面でスカウトが届くことが多く、ただ大量にかつテキトウにスカウトメールを送っているだけで、私のプロフィールはちゃんと見てないんだなというのがよくわかり、とても悲しい気持ちになることが多いのも事実です。

このやり方では優秀なエンジニアは採用できないのは明確だと思うのですが、それがわからないような無能な人がエンジニア採用をしているということなのでしょうか？。。。

解決策

スカウトメールを送って、返信がくるのは約3%未満という話を聞いたことがありますが、だから大量にスカウトメール送信する、というバカみたいなことは今すぐ辞めましょう。

多くの場合、それはさまざまなコスト面で非常に無駄なことをしています。それだけにとどまらず、企業の信頼を落としてしまっている可能性も高いのを理解しましょう。

有名な某ユニコーン企業さんとかもそういうことをやられていて、企業としてやっていることは魅力なのに、スカウトのやり方がクソすぎて非常に残念な気持ちになりました。

今はインターネットによって良い口コミも悪い口コミも簡単に広まる世の中なので、数打ち当たるという戦法はリスクが高いです。

もし大量にスカウトメールを送る必要があるのであれば、せめて「条件に合致した方に一斉にスカウトを送信させていただいております。他の採用媒体含めて送信させていただいている可能性もあるため、重複していた場合はご了承下さい。」というような文面をちゃんと記述するようにして下さい。

今の時代、何事も信用が大事なのです。真摯な文面を心がけましょう。

問題点2：文章内の本人が送っていないという嘘スカウト

スカウト文の文面について、「株式会社⚪︎⚪︎のCTOをしているXXです。〜」というようなスカウトが届くことがあるのですが、それに返信した際に「株式会社⚪︎⚪︎の採用担当です。〜」という返答をされることが多々あります。

はい。そうですね。採用担当の方が社長やCTOなどを語ってスカウト文を送信しているというケースが多々存在するんです。

それでも一応カジュアル面談もしてみたりすることがあるのですが、結局は採用担当者がテキトウにスカウトを送信しているんだなというのがわかり、とても悲しい気持ちになることがよくあります。

こういうやり方をしていると、「企業からスカウトを送ってきたのにもかかわらず、書類選考されて落ちた。」みたいな結果を招き、それが悪い口コミとして広がる恐れがあります。

解決策

嘘つくのやめろ！！

問題点3：生成AIバレバレの気持ちが入ってないスカウト文

最近はChatGPTやGeminiなどの生成AIを使うことで、スカウトメールの文面も簡単に作ることができますよね。

そのようなスカウトメールを受け取ることも増えてきたように感じますが、明らかに生成AIで作った文面を読んだ人の気持ちを考えたことはないのでしょうか？？？？

私には理解できません。

例えば好きな人に対してラブレターを送ろうとした場合、生成AIで作った文章をそのまま伝えるのでしょうか？それで相手に自分の気持ちが伝わるのでしょうか？

文章で伝えるにしろ、言葉で伝えるのしろ、自分の言葉で伝えるようにしないと、気持ちが伝わるわけがないのです。

そのようなクソみたいな文章を送ってくる相手のことを魅力的に思うことはありません。

解決策

生成AIを使って文章を作るのはとても効率的なのでこれからの時代は積極的に使っていくべきですが、誰かに何かを伝える際には必ず自分の言葉で書き直した文章にしてから送るようにして下さい。

自分の言葉にして送ることで、あなたの気持ちを文章で伝えることが可能になります。それは生成AIや機械にはできない、人間にしかできないことなのです。

問題点4：具体的にどんな人材を募集しているかわからない求人票

私がITエンジニア向けの求人票を見て多々思うこととしては、非エンジニアの方が作ったと思われるような、具体的なことがちゃんと書かれていない求人票が多いです。

具体的なことをちゃんと書かないことにより、例えばカジュアル面談の場で質問しなければいけないことが増えるため、企業側と求職者側で無駄なやりとり、無駄な時間が多くなってしまいます。

解決策

求人票に書いておいて欲しいことは以下の通りです。

※多数のプロダクトを作っていて、それぞれ異なる技術スタックを使っていた場合、その求人票ではどのプロダクトの仕事で、具体的にどの技術スタックを使うことになるのかがわからないと、そもそも応募ができません。それぐらいエンジニア目線では大事なことです。

問題点5：雑用フルスタックエンジニア（笑）の募集

主に中小企業においては少人数で開発することが多く、優秀なフルスタックエンジニアを求めることがよくあると思います。

特にそういった時の求人票を見ると、だいたい「フルスタックエンジニア募集！年収500〜700万円」というような感じで募集がされていることも少なくありません。

ただ優秀なエンジニアがそのような求人票を見て思うことは、「あ、雑用の募集ね。。」というのが現実です。

それはなぜかというと、フルスタックエンジニアというのはフロントエンドもバックエンドもインフラも全てある程度できることが前提ですが、それぞれの領域には専門性があり、全ての領域をある一定以上のレベルでやれるような優秀な人材はほとんどいないからです。

仮にそんな人材がいたとしても、最低年収は1000万円以上になると思います。本当のフルスタックエンジニアというのはそういった存在なのです。

解決策

まずは安直に「フルスタックエンジニア」という言葉を使うことを辞めましょう。

もし業務内容がフルスタックエンジニア的なものを想定しているのであれば、フロントエンド、バックエンド、インフラの全ての領域に携わってくれるソフトウェアエンジニアを募集というような言葉に変えて下さい。

またはもしちゃんとしたプロダクトを作っている企業であれば、プロダクトエンジニアを募集するというような形でも大丈夫でしょう。

言葉の使い方を間違えると、当たり前ですが笑われることがあります。

問題点6：人気が無いのにフルリモートワーク無し

XなどのSNSではよくフルリモートワークについて燃えたりしていますよね。

コロナ禍ではフルリモートワークが流行っていったものの、最近では有名な大手企業を中心に出社回帰をしているケースも増えたりしています。

そういったニュースが増えてくると、うちの会社でもフルリモートワークは廃止しようということを考える経営者の方も多いのではないのでしょうか。

別にフルリモートワークを廃止するかどうかはその企業の自由ですが、その際には一つ確認しておくべきことがあります。

あなたの会社は、何もしなくてもエンジニアからの応募が困らないような、大人気企業なのでしょうか？

もしここで「はい。」と言えないのであれば、フルリモートワークを廃止すべきではありません。

有名で人気の企業であるAmazonなどがフルリモートワークを廃止してもいいのは、廃止してもそこで働きたいと思う人が多く、エンジニア採用に困らないからです。

解決策

エンジニアの種類によってはもちろん出社必須の現場もあると思いますが、Web系エンジニアの仕事においてはその限りではありません。

Web系エンジニアにおけるフルリモートワークというのは福利厚生の一つであり、それがあるかどうかは非常に大きな要素になっています。

もちろんリモートワークは向き不向き、好き嫌いがあるため、最も良いのはフルリモートワークも出社するのも自由に選べることです。

もしあなたの企業が中小企業であり、かつ人気が無くてエンジニア採用に困っているのであれば、フルリモートワークを導入すべきです。

フルリモートワークを導入することで地方のエンジニアも採用候補になるため、そういった点でもメリットがあります。

また、リモートワークに関して否定的な意見の一つに「サボる人がいる」というのがあったりしますが、それはまた別のベクトルの話であり、そもそもそんな責任感が無い人材を雇ってしまっている企業の責任です。

フルリモートワーク人材を雇う際は、少なからず「真面目で責任感がる人材であるかどうか」はちゃんと見たほうがいいでしょう。

尚、フルリモートワークではジュニアレベルの人材のマネジメントはほぼ不可能なので、例えばもし新卒採用が必要になってきたというような場合においては、対象者が一人前になるまでは出社必須にすべきだし、マネジメントする人にも出社をお願いしなければならなくなるため、その点は抑えておいて下さい。

問題点7：人気が無いのにコーディング試験がある

エンジニアの採用フローの中にはコーディング試験がある場合があり、特に最近だと某スタートアップ企業がWebコーディング試験のプロダクトを出していたりするので、ついつい導入してしまった中小企業もあったりするのではないでしょうか。

そんなコーディング試験についてですが、私としては否定的な見解であり、コーディング試験がある企業については基本的に応募することは避けるようにしています。

実務ができるエンジニア目線としては、コーディング試験は本当にめんどくさいです。時間の無駄です。

そんな私も一度試しに受けてみたことがありますが、実際にやってみて思ったこととして、「プラットフォームが使いづらい」、「プラットフォーム慣れが必要」、「制限時間が邪魔」、「問題がわかりづらく、実務と関係ない」、「バグみたいな挙動がある」、「慣れている人が有利なだけ」というよう感じでした。

正直クソです。こんなものでエンジニアの能力を測り切れるものではありません。

なのでもしあなたの企業がコーディング試験を導入しているなら、ほんとうにそれは必要なのかをちゃんと検証したほうがいいでしょう。

コーディング試験の導入すべきであるといいことを言って勧めてくる企業があった場合は、基本的にはビジネスとして自分たちの商品を売ってお金を稼ぎたいだけです。その点は注意しましょう。

解決策

コーディング試験が効果的な場面としては、有名で人気な大手企業があって、エンジニアの応募が多すぎて全ての人の面接などができない場合です。

その場合はコーディング試験で一定以上の点数を取る必要があるという壁を設けることにより、応募者のフィルタリングが可能になるため、そういう場合は導入する価値があると思います。

逆にそういうことではなく、コーディング試験によってエンジニアの能力を測り、優秀なエンジニアを採用したいと思って導入しているような場合は、実務ができるエンジニアをフィルタリングしてしまったり、そもそも実務ができるエンジニアの応募が少なくなってしまうというデメリットもあったりするので注意して下さい。

もしあなたの企業が人気が無くてエンジニア採用に困っている中小企業などである場合、コーディング試験の導入はデメリットが大きいので避けた方がいいです。

問題点8：市場価値を見ていない年収レンジ

求人票には「年収500〜700万円」というような年収レンジが記載されていると思いますが、業務内容と年収レンジが見合ってないことも多々あります。

年収レンジが高すぎる場合は問題ないですが、逆に低すぎる場合についてはエンジニアの価値を軽視していると捉えられ、応募を避けられる可能性が出てくるので注意しましょう。

解決策

エンジニアといっても使う技術スタックによって市場価値は様々で、その時々で市場価値も変わるため、ちゃんと現在の市場価値に見合った金額を提示できているかどうかはしっかり確認すべきです。

問題点9：マネジメント職は別のロール（役割・仕事）

日本のIT企業ではマネジメント職の方が年収が高かったりすることがあったりすると思いますが、マネジメント職と開発職は別々のロール（役割・仕事）であり、求められることも違うため、マネジメント職の方が年収が高いという仕組みになっているのはおかしいです。

もしあなたの企業がそのような仕組みで運用している場合、優秀で技術があるエンジニアから避けられてしまうデメリットもあるため、そういった仕組みについてもちゃんと考えた方がいいでしょう。

解決策

組織で仕事をしていく場合、人材は適材適所で配置していく方が上手く行くのは間違いないため、開発したい人には開発をやらせるべきだし、マネジメントしたい人にはマネジメントをやらせるべきです。

なので、開発職とマネジメント職は別のロールとして捉え、それぞれのロールごとに適切なグレードを設けるようにして、開発職とマネジメント職の年収の乖離が大きくならないような仕組みにすべきです。

問題点10：技術スタックがレガシー

エンジニア採用をしている企業の中には、プロダクトに使っている技術スタックがレガシーになってしまっていることも多々あると思います。

エンジニアが求人票を見る際は、ほぼ必ずモダンな技術スタックを使っているかどうかは見られてしまうため、技術スタックがレガシーだと応募者が来ないことも多いのではないでしょうか。

解決策

まず大前提として、システムは作った後は腐っていきます。作っている時はモダンな技術であったとしても、ほっとけばいずれレガシーな技術になってしまうんです。

そのため、プロダクトやサービスを長期的に運用していくのであれば、使っている技術スタックがレガシーになりそうなら、タイミングを見計らってモダンな技術にリプレイスするということも必要になるでしょう。

もしそれが様々な条件があってできなくて、それでもエンジニア採用を成功させたいとするならば、少なからずその企業のエンジニアとして働くことによって提供できることをある程度明確に提示するような形で求人票を作って募集をしていくべきです。

例えば「技術はレガシーだけど、社会的に長期的な運用が求められるシステムに携わることができ、そのエンジニアとして働くことで特定のドメイン知識にも精通できるようになったりでき、かつ能力が高い人なら早く出世もできる環境があります。」というような感じで、企業として提供できることをちゃんと求人表に書くようにしましょう。

もしそれでもエンジニア採用ができない場合、もうそれは淘汰されるしかないので、諦めて下さい。それが嫌ならシステムのリプレイスが必要です。

問題点11：優秀なエンジニアの定義を間違えている

どんな企業も優秀なエンジニアを採用したいはずですが、私が感じるのは優秀なエンジニアの定義が間違っているのではということです。

具体的には、過去に有名企業に在籍していた経験があったり、過去の経歴において求めている実務経験があることだったり、そういった過去の経験を見過ぎているなという印象です。

もしそういった経験豊富な人材を採用しようとした場合、そもそもそんな人材は数が少ないのと、採用しようとしても高い年収を提示する必要があり、コスパも悪い可能性があります。

そして優秀であればあるほど、おそらく自分で起業したり、就職するにしてもリファラル採用されることの方が多いはずなので、転職市場に出てこないことがほとんどでしょう。

そもそも社会における仕事というのは、答えがまだない問題を解決していくことが本質なので、過去に経験があるかどうかは重要ではありません。未知なる問題が発生してもそれを解決できるかどうかの方が重要です。

あとは企業の役割の一つとして、社員に対して成長の機会を与えることもあるので、現在何をしているかだったり、将来どうなっていきたいかというような、その人の人間性だったり、将来的なポテンシャルの部分に目を向けた方がいいのではないかなと、私は思います。

解決策

私が思う優秀なエンジニアの定義としては、主に以下のような人材です。

まず社会で組織に属して働くことにおいて、最も大事なことはコミュニケーション能力です。

エンジニアの中には技術はあってもコミュニケーション能力が低い人が一定数いると思いますが、そういう人材は残念ながら組織における優秀な人材には該当しません。

特定の領域においては専門性や技術的なことが必須で一番大事になることもあると思いますが、多くの場合はコミュニケーション能力が一番大事であり、その次に技術的な要素になると思います。

次にその人がエンジニアの素養があるかどうかは非常に重要です。それを判断する一つの方法としては、「普段から技術的な勉強をしていくのが苦では無く、好きで趣味のようにやっているかどうか」です。

よく「エンジニアは土日も勉強しないといけないから大変」みたいなことを言う人がいたりしますが、そういった考えに共感するような人はエンジニアに向いていないので採用すべきではありません。

現在の競争社会における優秀な人材になっていくためには勉強し続けるのは必須であり、それをするためには自分が好きなことである必要もあるため、エンジニアにとっては普段から趣味のように技術をキャッチアップできるかどうかは非常に大事なことです。

あとはインプットだけでなく、アウトプットも定期的にちゃんとやっていることも非常に大事なので、何らかのアウトプット活動をしているような人なのかはちゃんと見るべきです。

上記のような要素を兼ね備えた人材であれば、基本的には自走できる人材だと思うし、何か問題があっても自分で解決していける人だと思うので、まだ経験が浅くても将来的には優秀なエンジニアになっていくでしょう。

問題点12：エンジニアを採用しても辞めていく問題

やっとのことエンジニアを採用できたとしても、「すぐに辞めてしまう」ということもよく聞いたりしますよね。

優秀な人材であればあるほど常に高みを目指しているため、求める環境が無くなれば辞めて行ってしまうのはしょうがないことです。

それを少しでも食い止めたいということであれば、優秀な人材の声には常に耳を傾け、その人が求めるポジションや役割を会社として適宜提供し続けていくしかないです

そもそも、人が会社を辞めるのを無くすことは不可能です。

その点については無駄なことは考えずに諦めましょう。

解決策

人が辞めていくのを無くすのは不可能なので、辞めていく時は快く送り出し、辞めた後に「あの会社は働きやすくて良かったな」と思ってもらえるような環境作りに力を入れた方が後々会社のためになることが多いと思います。

最近だとアルムナイ制度（退職者との組織的な繋がりを維持し、再雇用や新たな関係構築につなげる仕組み）がある会社も存在するので、そういった制度を作ったりするような形で頑張って行った方が合理的です。

問題点13：プロダクトの魅力を語れないスタートアップ経営者

とあるスタートアップのカジュアル面談にて、これから作ろうとしているAI関連プロダクトの詳細について聞いたことがありました。

その際には顧客の問題解決のためにこういったものを作りたいというのはよくわかったのですが、ただ現状想定しているものが単なるツール的なもの（他社プロダクトとの連携を前提としているようなもの）を想定していて、将来的にそのプロダクトをどのようにしていきたいのかという、プロダクトを作っていく魅力の部分について語れない経営者の方がいました。

はっきり言うと、それだと優秀なエンジニアが協力してくれることはありません。

優秀なエンジニアの方は基本的に魅力的なプロダクトの開発に携わりたい生き物なので、魅力もないプロダクトを開発するために、わざわざリスクを取ってスタートアップに入社することはないです。

もしそれでもそういったものを作りたいなら、外部のIT企業にお願いして作ってもらうしかないと思いますが、それだとお金のためにぼったくられることも多かったりするので、いつかどこかで破綻すると思います。

解決策

非エンジニアの経営者で、あまりソフトウェア開発の知識が無いのであれば、できるだけ早い段階で技術的に詳しいアドバイザーなどに相談し、作ろうとしているプロダクトに何か問題がないかはチェックしてもらった方がいいです。

問題点14：人売りIT企業多すぎ問題

日本でエンジニアの仕事を探そうとすると、SIerやSESといったサービスの提供を事業としているIT企業が非常に多いです。

大手企業ならまだ問題ないと思いますが、多重下請け構造になってしまっている中小企業が非常に多いのも現実です。

結局、そういった中小企業が多いのは、経営者だけが甘い汁を吸えるようなビジネスモデルになっているからです。

ただ最近だと生成AIも発達してきて、非エンジニアの方でもシステム開発のハードルが下がってきているので、そういった中小企業の仕事が無くなっていくのは時間の問題かなと思います。

解決策

生成AIの発達次第で、特に中小企業は案件獲得が厳しくなっていくのが想定されるため、多重下請け構造での稼ぎがメインになっている中小企業はご注意下さい。

はっきり言ってそういったサービスを提供するようなビジネスモデルは時間の切り売りをしているだけでバイトするのと変わらず、優秀なエンジニアほど魅力を感じなくて避けていくので、優秀なエンジニアの獲得はより厳しくなっていくと思います。

自社プロダクトを作る気が全くないIT企業は淘汰されろ！

問題点15：リファレンスチェックという糞システム

選考フローの中に「リファレンスチェック」というのを導入している企業があります。

このリファレンスチェックというのは、企業が採用候補者の前職の上司や同僚など、候補者をよく知る第三者に対して、候補者の働きぶりや実績、そして人物像などを問い合わせるような採用活動のことです。

最近だとリファレンスチェック用のSaaSなどもあり、メールや発行したURLなどを共有して回答してもらうような形式で行われています。

これは企業側にとっては採用候補者の第三者目線の評価が聞けるというメリットはあるのもの、逆に採用候補者側としては過去に一緒の働いたことがある上司や同僚などの誰かにリファレンスチェックへの回答を無償でお願いしなければならないという、心理的ハードルもめちゃめちゃ高いこともしなければならないという、非常に糞システムであることが最大のデメリットです。

いや別に人気企業で採用に困ってないなら導入してもフィルタリング効果があるのでいいですが、そうじゃないのにこれを導入している企業は頭が悪いのではないでしょうか。

世の中にはこういったことを気軽に頼めるような人脈形成が得意な陽キャの人が沢山いるということなのでしょうか？？

私はそうじゃない人の方が多いと思うし、これを導入することによって、逆に陽キャ系のキラキラ人材みたいな属性の人しか集まらないのではないでしょうか？？

別にそれでいいなら問題ないですが。。。

これを導入していて、人手不足とか言ってないですよね？？？😊

解決策

これについても採用に困っているなら導入すべきではないです。

これがあるだけでそもそも選考に進まないという人も一定数いるので、自分で自分の首を絞めることになります。

もしどうしても導入したいというなら、対応するのが厳しいという人に対しては、無理に強制せず、柔軟な採用フローにするようしっかり検討しておくべきです。

ITエンジニアの採用方法やコツ

上記ではITエンジニア採用における様々な問題点や解決方法についてご紹介しましたが、ITエンジニア採用を成功させるための基本的な方法についてご紹介しておきます。

少なからず以下のことは確実に必要だと思うので、こういうのが出来ていなかったなというのがあれば、ぜひ参考にしてみて下さい。

尚、エンジニア採用のために技術ブログをやっている企業もあったりしますが、技術ブログはその会社でしか知り得なかった貴重な情報を無料公開し、それによって社会に貢献することで価値を示せる効果はありますが、それが組織作りにおけるアピール機会としてはそれほど効果はないと思います。

もし広報活動をSNSなどで行おうとするのであれば、例えばnoteで人の感情に訴えかけるような企業の魅力を伝える記事を書いたり、会社の魅力や社内環境をわかりやすく伝えられるようなYouTube動画を公開したりしていく方が効果的です。

ITエンジニアに人気の環境について

次にエンジニア目線で魅力的に映る企業環境についてご紹介しておきます。社内環境を整える必要がある場合は参考にしてみて下さい。

尚、2025年9月時点におけるモダンな技術スタックの例としては以下の通りです。

※迷ったらメルカリの技術スタックを真似するのがいいです。

ITエンジニア採用でおすすめの採用媒体（サイト）について

私は色々な転職サイトを使ってみましたが、2025年9月時点でおすすめの採用媒体（サイト）についてご紹介しておきます。

1. 各種SNSによるダイレクトリクルーティング

私がこれからの時代においてもっとも良い方法として思っているのは、各種SNS（X、Facebook、LinkedInなど）を利用したダイレクトリクルーティングです。

対象者を探すのは大変ですが、対象者がいれば直接コンタクトを取って交渉できる可能性があるため、採用コストを安くできたり、人との繋がりを作っていける活動になるからです。

特にこれからの時代は、よりダイレクトリクルーティングが発展していくのではと思っているので、どうしてもエンジニアが採用できないという企業さんは、一度SNSで人材を探すのを試してみてはいかがでしょうか。

2. 転職ドラフト

実務経験があるエンジニアが使うべき転職サイトで最も合理的なのは、転職ドラフトです。

求職者登録には実務経験が必要で審査もあり、プロフィールもしっかり書く必要があります。

そして企業側がスカウトをする際は、最初に年収提示が必須になって、スカウト文も丁寧に作って送る必要があるため、求職者側と企業側がお互いに合理的なやり取りが可能になっています。

3. Findy

GitHubやブログなどを用いてアウトプット活動をしっかりやっている人がよく使っているのがFindyです。

求職者側視点でも自社開発系企業が多く、求人を探しやすいなという印象が強いため、2025年9月時点においては優秀な人材が集まりやすいサイトです。

求職者視点ではサイト自体がモダンでシンプルで使いやすい感じなので、自走できるような優秀なエンジニアを探している場合は、一度利用してみてはいかがでしょうか。

4. ビズリーチ

実務経験があり、大企業出身者やマネジメント職の人材を中心に集めたいなら、ビズリーチがおすすめです。

私も登録しているため、エンジニアも一定数いますが、エンジニア目線では転職ドラフトやFindyの方が求人を探しやすいため、技術力があるエンジニアの採用にはそれほど向いていないので注意です。

5. WantedlyやGrenn

実務経験よりも、若手やポテンシャル採用をしたい場合は、WantedlyやGreenを使って探すのが無難です。

Wantedlyは共感で繋がるビジネスSNS、GreenはIT人材向けの求職サイトですが、それぞれ低い年収レンジでスカウトが来ることが多い感じです。

最後に

今回は現役Web系エンジニアである私の視点から、ITエンジニア採用における問題点とその解決策についてまとめました。

ITエンジニア採用が難しく、苦労している企業さんが非常に多そうですが、

それはやり方が間違っているだけじゃない？

と、私は伝えたいです。

今回ご紹介したような考え方などをしっかり持っているようなCTOなどに協力してもらいながら、経営戦略的なところからエンジニアの組織作りのところまでしっかり検討していくようなやり方をすれば、エンジニア採用に困ることは少なくなっていくと思います。

もし現在エンジニア採用でお困りの人事関係者や経営者の方がいたら、ぜひ今回ご紹介した内容を参考にしてみて下さい。

The following two tabs change content below.

• この記事を書いた人
• 最新の記事

Tomoyuki

SEを5年経験後、全くの未経験ながら思い切ってブロガーに転身し、月間13万PVを達成。その後コロナの影響も受け、以前から興味があったWeb系エンジニアへのキャリアチェンジを決意。現在はWeb系エンジニアとして働きながら、プロゲーマーとしても活躍できるように活動中。

最新記事 by Tomoyuki (全て見る)

• ITエンジニア採用は難しい！？現役Web系エンジニア視点における問題点と解決策まとめ - 2025年9月15日
• Rust専門の技術ブログ「Rust-Tech」を開設しました！ - 2025年5月30日
• Web系エンジニアを3年頑張ってきた結果とこれから - 2025年5月30日