こんにちは。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などに協力してもらいながら、経営戦略的なところからエンジニアの組織作りのところまでしっかり検討していくようなやり方をすれば、エンジニア採用に困ることは少なくなっていくと思います。

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

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

前回の記事から約11ヶ月が経ちましたが、現在 無職 です！w

というか普通に求職活動中なのですが、キリのいいタイミングなので、また記録を残しておきます。

関連記事

37歳Web系エンジニア3年目。生成AI（ChatGPT・Gemini）現る。

2024年7月3日

Web系エンジニアを3年頑張ってきた結果とこれから

私がWeb系エンジニアの転向を決意したのが2022年6月で当時は35歳でしたが、あれから約3年経ちました。

その当時に考えていたのは、約3年頑張れば普通にWeb系エンジニアとして働いていけるぐらいにはなるだろうと、私は不安な状態からもそう思っていました。

それから3年が経ち。。

ついに私は。。

Gopherへ進化したのであった！！

え！？

そうですね、Web系エンジニアとして普通に仕事はできるようになったし、途中から希望していたGoエンジニアの実務経験も積んで、一応Goエンジニアとして働けるようにもなりましたよ！！

順風満帆で全て希望通りというわけではありませんが、運も良くてこれまで色々な経験を積むことができました。（メインはバックエンドですが、フロントエンド開発もできます！）

とはいえ、まだまだインフラ面は弱いし、やりたいこと、やらなければならないこともたくさんあるため、Web系エンジニアの道は奥が深いなと、つくづく思います。

現在求職活動中です！【2025年5月末時点】

直近の会社については、自社開発系でGo言語のバックエンドエンジニアとして勤めていましたが、経営上の問題があって話し合った結果、会社都合退職になりました。

プロダクトのコードを見た時に、このままだと長期運営していくのは厳しそうだなと思っていましたが、それが現実的になった感じです。

まあベンチャー企業であるあるだと思うので、その点はしょうがないと思いますが、もし3年ぐらい早く私がジョインしてたら、未来を変えることができたのかも？とは思いました。

ということで現在絶賛求職活動中なんですが、今後も自社開発系のGoのバックエンドエンジニアとしてキャリアを磨きたいので、そういった仕事ができる企業を前提として探しています。

あとはこれまででちゃんとしたWebサービスの長期運用経験を積めなかったので、次は2年、3年としっかり運用経験も積んでいけるような環境も求めてます。

もし、今のこのタイミングでGoエンジニアを求めている企業さんから直接ご連絡をいただければ対応いたします。

ダイレクトマーケティングなら“低コスト”で、Goエンジニアを採用できるチャンスが、今ここにありますよ！！

次の3年間にやること

これまではアプリケーション開発の部分に注力してきましたが、これからの3年間に関しては本格的にインフラ面の強化をしていく予定です。

AWSないし、Google Cloudの知識およびスキルを磨いて、あらゆるWebサービスのバックエンドを安定して運用できるようになりたいところです。

そして現在、生成AIの進化が非常に話題ですが、もうこれは避けては通れない技術革新なので、この生成AIをアプリケーションに組み込めるようにするのは前提としつつも、生成AI関連ツールを上手く使いこなして、より効率的に開発ができるようにしないといけないと思ってます。

また、プログラミング言語については引き続きGo言語の肉付けを継続して行いつつ、今後のパフォーマンスを最重視する場面においてはRustが流行るのではと睨んでいるので、Golangをメインとしつつも、必要に応じてRustも使えるようにしていこうと考えています。

そんなRustについても最近、Rust専門技術ブログ「Rust-Tech」を立ち上げたので、Go専門技術ブログ「Golang-Tech」と合わせて、興味がある方はぜひ参考にしてみて下さい！

これまでの3年間でわかった自社開発系のWeb系エンジニアに必要なこと

これまでの3年間の経験でわかったこととして、会社に勤めて実務経験を積むのは大事ではあるものの、それ以上に大事なのが自己学習によって継続的に技術を磨いていくことです。

もちろん実務でしか積めない経験もあるので、それについては運良く携われたらラッキーですが、それ以外の部分いついてはほぼ全て自己学習で学んだことが全てだったので、継続的な自己学習ができない人については、自社開発系のWeb系エンジニアには向いていないです。

たまに「エンジニアは休みの日も勉強が必要だから大変そう。」みたいなことが話題になることがありますが、そういう考えの人は向いてないです。

例えば私なんかは趣味でプログラミングの勉強をしている感じなので、大変とか辛いとか思ったことは一度もありません。好きでやっているし、好きじゃないと周りの同業者に立ち向かえないです。今はそんな時代です。

あと企業で働く上で最も大事なことを教えます。

コミュニケーション能力っす！！

これは当たり前のことなんですが、技術はあってもこれが足りてない人は多いんじゃないかなと思います。特にリーダーやマネージャーなど、人の上に立つような人には必須です。

なのでまだ技術に自信がなくても、普通のコミュニケーション能力をちゃんと持っているなら、あとは継続的な自己学習をしていける素養があるかどうかが大事だと思うので、もしこれからWeb系エンジニアなろうと頑張っていて該当している方は、自信を持ってスキル磨きを頑張ってみて下さい！

※女性の方がコミュニケーション能力が高い人が多いと思うので、もっと女性のエンジニアが増えてもいいのではと思ってます。

最後に

ということで、私のWeb系エンジニアに挑戦した3年間についてまとめました。

まだまだ学び足りないのと、生成AIという技術革新によって今後どうなっていくのかわかりませんが、引き続きやるべきことをコツコツやっていこうと思います。

現在も尚、Web系エンジニアにキャリアチェンジしたいと悩んでいる方も多かったりするのではと思いますが、私がこれまで歩んできた経験は記事にまとめているので、よければ参考にしてみて下さい！

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

前回の記事から約半年経ちましたが、Web系エンジニアとしては3年目に突入し、加えて8月からはまた新天地で働くことになりました。

ということで、これまでとこれからについて、記録を残しておきます。

関連記事

Web系エンジニアに転生した36歳男性の記録

2023年12月31日

ベンチャーやスタートアップ企業で働くということ

私がWeb系エンジニアに転向してから現在のところを含めてこれまで2社を経験してきましたが、いずれもベンチャーやスタートアップといった企業でした。

いずれの場合も主な転職理由としては『経営方針が変わった』ことが大きかったりするので、ベンチャーやスタートアップといった企業で働くというのはそういうことなんだと、とても理解が深まりました。

そんな感じなので、企業選びでベンチャーやスタートアップ企業が候補になっている場合は、長く働くことに関しては期待しない方がよいです。

なのでもしベンチャーやスタートアップで働くことになった場合は、実務経験をしっかり積んでいくだけではなく、自己学習も継続的に取り組みながら自分の市場価値の向上を図り、いつでも転職できる準備はしておくのが大事かなと思います。

自社開発のWeb系エンジニアとしての企業選びについて

またこれまでの経験を通じて、自社開発のWeb系エンジニアとしての企業選びの際は、以下の点をちゃんと見た方がいいと思いました。

経営陣の中にエンジニアに対する理解がある人がいること

これについては、Webエンジニアの仕事は例えば営業系とは違って定量的に評価できる仕事が少ない（成果が見えにくい、短期間で売上に直結することはほぼ無い）ため、経営陣の中にエンジニアに対する理解がある人がいないと正しい評価がされない（=エンジニアとして働き辛い）ことが多いです。

そのため、社長にエンジニア経験があって仕事内容をちゃんと理解していたり、社長にエンジニア経験が無くてもコードが書けるちゃんとしたCTOがいるような企業かどうかについては、ちゃんと見た方がいいです。

Webエンジニアの組織作りをちゃんとしていること

これについては、私が経験した2社ではいずれも小さい組織であり、自分よりも圧倒的にレベルが高いWebエンジニアの社員がいなかったため、人から学ぶということはほぼありませんでした。

もちろん自社開発系のWebエンジニアになるなら自走できることは当たり前ですが、専門性が高いコアな部分は誰かに聞けた方がキャッチアップするのに効率的だったりするので、やはり周りに優秀なWebエンジニアが沢山いるような環境の方が好ましいです。

Web系エンジニアに転向してから2年経過

ということで、私がWeb系エンジニアに転向して2年が経ちましたが、実務経験だけではなく、コツコツ継続してきた自己学習も含めて、Web系エンジニアとして生きていくレールには上手く乗れたかなと思っています。

特に今は実務経験がちゃんとあるようなWeb系エンジニアの需要が高いので、選ばなければ仕事に困ることは無さそうです。

そして当初より、私は専門性としてはバックエンドエンジニアを目指してましたが、バックエンドAPIの開発部分はある程度自信がついたので、これからの1年はインフラ周りのキャッチアップを中心に進めていこうと思っています。

だいたい3年ぐらい頑張れば追いつけると思っていて、今のところ順調に成長できているので、来年の6月ごろには完全体バックエンドエンジニアになっていることでしょうw

生成AI（ChatGPT・Gemini）の影響について

そして昨今、ChatGPTやGeminiをはじめとする生成AIが盛り上がっていますが、エンジニア界隈でももちろん影響していきます。

私の場合は少し運がよく、ちょうど業務で生成AI関わる機会があったのをきっかけに、現在は普通に使うようになりました。

この生成AIに関してはちゃんと理論を調べていただくとわかりますが、完璧な答えを出してくれるものではないので、出力内容が間違っていないかをちゃんと判断する必要があります。

ただ軽く質問をしてすぐにヒントが貰えるため、その点においてはGoogleで検索するより圧倒的に効率的であり、より深く調べる際にGoogle検索も合わせて使うと普通に生産性が上がります。

つまり、これまでのGoogle検索やスマホを使いこなせるかで情報格差が生まれたように、これからの時代は生成AIを使いこなせるかどうかでさらなる格差が生まれるので、もしまだあまり使ったことがないという方がいたら、早めに使いこなせるようにしておいた方がいいです。

最後に

ということで現時点のWeb系エンジニアの記録を残しておきました。

今後についてはプログラミング言語としてはGo言語（Golang）、インフラについてはGPC（Google Cloud Platform）をメインで使っていく予定で、新しく専門のブログ『Golang-Tech』を立ち上げたりもしています。

これらも含めて、これからWeb系エンジニアとして働きたい人に何か役立つ情報を届けられたら幸いなので、よければぜひ参考にしてみて下さい！

Web系エンジニアを目指している方は参考にどうぞ！

Laravel11の変更点を踏まえてバックエンドAPIを開発する方法まとめ

2024年5月20日

Rails7で最小構成からバックエンドAPIを開発する方法まとめ

2024年5月13日

【FastAPI入門】Dockerで環境構築してPythonのAPIを開発する方法まとめ

2024年5月4日

Expo（React Native）によるアプリ開発方法まとめ

2024年2月8日

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

気付けば、前回の記事から約1年が経ちました。。

今年は色々と忙しく、ブログを書く余裕がなかったので久しぶりの記事になりますが、年末なのでこの1年を軽く振り返っておきます。

関連記事

35歳実務未経験でもWeb系エンジニアの内定ゲット！？そして再就職へ。

2022年12月3日

Web系エンジニアとして初めての就職

前回の記事はWeb系エンジニアとしての再就職が決まってから書いたので、それからどうだったかについて書いておきます。

実際の業務や役割的なところでは、既存システムの内製化に向けた引き継ぎ、一部機能の業務設計、そのほかバグ改修などでした。

使っている技術も初めてのLaravel（PHP）やVue.js、そして一部Golangだったので、調べならキャッチアップしていった形になります。

実際に働いてみてからのギャップとしては、事業会社で既存システムは外部委託で作っていたため、残念ながら自分の近くにレベルの高いエンジニアがほぼいなかったことです。

私がイメージしてたのは自分より遥かにレベルが高いエンジニアが複数人いて、わからないことを聞けるような環境があって、そういう人たちと一緒に仕事をしながら盗めるものを盗んでいこうと思っていましたが、残念ながらそういう環境ではありませんでした。

今ならわかりますが、人手不足的な感じで採用された面もあるので、実務未経験で再就職できた場合は、エンジニアにとって学べることが多いようなレベルの高い環境で働けることはほぼ無いのかなと思います。

※つまり、再就職後もプライベートの時間を含めて自己学習を進めていかないと、一向に現役で働いているエンジニアに追いつけないということです。追いつけなきゃ自分の市場価値を上げられません。

とはいえ、実務を経験できたことや、実際に動いているコードを見れたこと、そして外部委託のエンジニアさんと関わる機会があって少し盗めるものがあったことは良かったなと思います。

そんな感じなので、頑張ってエンジニアとして再就職できたとしてもそれでゴールではなく、そこからまた新しいスタートが始まるだけなので、やっぱり好きじゃないと続けられない仕事だなとはすごい思います。

なので、もし今Web系エンジニアになりたくて頑張っている人は、今一度エンジニアの仕事が好きかどうかは確認した方がいいと思います。

※環境や年収などを選ばないならレベルが低くても働く場所はありますが、それがいやなら自分の市場価値を上げる努力が必要です。

人生紆余曲折

そんな感じでやっとのことWeb系エンジニアとして働き始めたわけですが、残念ながら人生そう簡単にはいきません。

再就職した会社がベンチャー企業だったので、社内で色々あったり、方針等がかわったりしたため、結局その会社は半年で辞める決断をすることになりました。

私としては本当にすぐ辞めるつもりは一切なかったので、非常に残念ではありましたが、前職を辞めて個人事業を数年やった経験などから、会社を辞めることについては一切躊躇はないので、仕方がない感じでした。

大手企業だったり、安定した経営をしている企業以外に就職する場合は、こういうことが起こるのは覚悟しておく必要があるでしょう。

ただ幸い、エンジニアの仕事は実務経験を増やせば増やすほど、働く場所が無くなることはほぼないような状況ではあるので、その点はいい職業だなとは思います。

積み重ねは活きてる

ちなみに私は運良く？引き抜きされた感じで、現在はそのご縁がある会社に就職して働いています。

そこで新規開発のプロジェクトがあり、ほぼゼロからのスタートで色々な開発経験を積むことができて現在に至ります。

それをある程度やり遂げて思ったこととしては、私が2022年6月頃からWeb系エンジニアに転向しようとして積み重ねてきたこと（約1年半、継続して自己学習してきたこと）がとても活きた感じでした。（就職してから新しく覚えたのはSlackやGoogle meetの使い方などですw）

とはいえ、まだまだ足りない部分も多いと感じるので、やはり3年ぐらいは積み重ねないと現役エンジニアに追いつくのは難しそうだなという感じです。

加えて、最近はChatGPTをはじめとした生成形AIの発達が著しく、エンジニアの働き方も変わっていきそうな風が吹き始めているので、その点も踏まえて柔軟にやっていく必要がありそうですが、引き続き努力は継続していこうと思います。

最後に

今働いている会社も、いつまでそこで働くかはわからないので、また来年以降に紆余曲折あるかもしれませんが、Web系エンジニアの仕事は改めて天職だと思っているので、来年以降も引き続き頑張っていきます。

そして、私がWeb系エンジニアとして学んだことに関しては、できる限りこのブログでアウトプットすることも継続してやっていくので、よければ引き続き応援のほどよろしくお願いいたします！

Web系エンジニアを目指している方は参考にどうぞ！

Laravel10（PHP）でバックエンドAPIを開発する方法まとめ【OpenAPI仕様書・管理画面カスタマイズ】

2023年12月29日

NextJS13でレスポンシブデザインのフロントエンド画面を開発する方法まとめ

2023年9月21日

GolangでAPIを開発する方法まとめ【Docker・Gin・Nginx・MySQL・Postman・Actions】

2023年5月6日

SPA構成のWebアプリケーションを開発する方法まとめ【Docker・NextJS（React）・Vercel・Rails7（APIモード）・AWS ECS（Fargate）】

2022年11月22日

Railsチュートリアルをカスタマイズしてポートフォリオを作成する方法【Docker・Rails7・CircleCI対応】

2022年8月15日

Railsチュートリアル（第6版）を進めるための参考資料

2022年7月16日

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

前回の記事から約3ヶ月半、私がWeb系エンジニアへのジョブチェンジを決意してからだと約5ヶ月ほど経ちましたが・・・

ついに。。

ついに・・・・！？

35歳でWeb系エンジニアの内定をゲットしたぞ！！

関連記事

1個目のポートフォリオが完成！【35歳Web系エンジニア1年目】

2022年8月16日

35歳、Web系エンジニア1年目。

2022年6月29日

35歳実務未経験でもWeb系エンジニアの内定ゲット！？そして再就職へ。

ということで、2023年2月から再就職して働くことになりました！

いや〜、今振り返ると結構長かった感じもありますが、無事に再就職も決まってWeb系エンジニアとしてまた一歩先へ進めそうです。

今回私が内定をいただいた会社はベンチャー企業なので、将来性に安定はありませんが、複数回の面談や面接を通じて、そこで働く人達と一緒に頑張って行きたいなという感じで徐々に自分の気持ちの変化があったので、内定を承諾するに至りました。

こういう気持ちの変化があったのは初めての経験だったので、自分でもびっくりしていますが、これもまた一つの出会いなのかなと思います。

※そもそもエンジニアは一度でもしっかり実務経験を積むのが非常に大事で、実務経験があれば転職活動はそれほど困らない職種でもある（IT人材不足で有効求人倍率も高い）ので、企業の将来性を気にする必要ないです。何かあったら転職しましょう。

そんな感じで、引き続きWeb系エンジニアとして頑張っていこうと思いますが、現在Web系エンジニアを目指して頑張っている方や、これからWeb系エンジニアになりたい人向けに、私がWeb系エンジニアの内定を得るまでに経験してきたことなどをまとめておきますので、よければ参考にしてみて下さい。

※前提として、自社開発系企業のWeb系エンジニアに関するお話です。もし違いがよくわからないよって方は、まずはその点からしっかり調べることをおすすめします。

技術的な部分で必要なことについて

まず、実務未経験の人が自社開発系企業のWeb系エンジニアとして採用されるために必要な技術的な部分についてですが、わかりやすいところで言うと、「Railsチュートリアル」レベルのWebアプリケーションの開発経験は最低限必要です。

というのも、私はRailsチュートリアルには取り組みましたが、それ以前から求職活動は行っていて、何度か面談や面接も経験していました。

その中で実際に働いている人たちから話を聞いて感じたこととして、ちゃんとWebアプリケーションを開発したことがあるという経験が最低限必要なんだなということが、非常によくわかったからです。

具体的には、現状IT人材不足もあってエンジニア採用が非常に難しくなっている中、特に無名の会社（名が知れた大手企業以外）はそもそも求人を出しても応募すら来ないことが多く、実務未経験でもエンジニアの素養がある人を採用するケースが存在します。

ただし、そういう無名の企業は採用にかけれる資金的余裕は無く、いくら人手が欲しくてもエンジニアの素養が無い人を雇う余裕は無いため、その足切りライン（即不採用）としての技術レベルが「Railsチュートリアル」になると思います。

※ここで言うエンジニアの素養というのは、何らかのWebアプリケーションの開発経験＋自走能力（わからないことは自分で調べ、自ら進んで仕事に取り組んでいけるような能力）の高さを指します。

そのため、「Railsチュートリアル」レベルのWebアプリケーション開発経験が無ければそもそも採用されることは一切無く、そしてこれはあくまでも足切りラインでしかないため、実際には＋αの技術レベルのアピールも必要です。

関連記事

35歳、Railsチュートリアルに挑む編【Web系エンジニア1年目】

2022年7月17日

Railsチュートリアル（第6版）を進めるための参考資料

2022年7月16日

そんな＋αの部分については、もちろん高いに越したことはなく、かつ企業によって求めるレベルは全然違うので、明確な基準を定めることはできませんが、トレンド（流行っている、よく使われている）の技術を抑えておくのは大事だと思います。

例えばDockerによる環境構築やテストの自動化に関すること（テストが書ける＋CI/CDパイプラインの知識）だったり、フロントエンドエンジニアを目指すならReactやVue.jsのフレームワーク（Next.jsやNuxt.js）の知識や経験、バックエンドエンジニアを目指すならAPIの開発やAWSに関する知識や経験が求められるので、そういったことをポートフォリオを作ってアピールできると良いです。

ただ注意点としては、現状プログラミングスクール出身でエンジニアの就職活動をしているような人材（スクールの教材で作ったポートフォリオをアピール材料に使う人）は溢れかえっているようなので、ポートフォリオを作ったり、それをアピール材料として使う際は、何らかのオリジナリティを入れてちゃんと差別化を図る必要があります。

特になぜそのポートフォリオを作ろうと思ったのかというような部分については、しっかりと明確な意図が無いとダメなので、その点は面接などで突っ込まれた際にしっかり説明できるようにしておいて下さい。

関連記事

Railsチュートリアルをカスタマイズしてポートフォリオを作成する方法【Docker・Rails7・CircleCI対応】

2022年8月15日

SPA構成のWebアプリケーションを開発する方法まとめ【Docker・NextJS（React）・Vercel・Rails7（APIモード）・AWS ECS（Fargate）】

2022年11月22日

またポートフォリオについては、めちゃめちゃ凝ったものを作らないといけないというような先入観を持っている人も多いと思いますが、凝ったものを作ったとしても、企業の採用担当の人がちゃんとポートフォリオを見てくれることはほとんどない（「こういうことができるのか〜、あとは話を聞いて確認してみようかな。」ぐらいな感じでしかほとんど見てもらえないことが多い）ため、変にこだわりすぎても時間の無駄に終わります。

ポートフォリオはあくまでも「自分はこれぐらいのことができますよ〜。」というのをアピールするための一つの材料でしかなく、基本的な技術（例えばNext.jsでフロントエンド画面が作れるとか、RailsでAPIを作ってAWSにデプロイできるとかなど）は除いて、こだわって作ったアプリの中身（例えばTwitterのようなサービスが作れるとか、Instagramのようなサービスが作れるとか）が入社後の実務で直接役立つ可能性は低い（企業によって作っているものやサービスが全く違うことや、実務ではまだ答えが無いような課題に取り組んでいくため）ので、その点はポートフォリオを作る意図を履き違えないように注意する必要があると思います。

ちなみに私の場合は、『技術をキャッチアップ（遅れを取り戻すこと）するために実際に作ってみる必要があった』というような明確な意図があって作ったものをポートフォリオとして使っていたので、面接の際などにポートフォリオに関して深く突っ込まれて困った経験はありませんでした。

私が内定を得られた一番の要因について

今回は私は35歳実務未経験でWeb系エンジニアの内定を得られる結果に繋がりましたが、その一番の要因としては、『最終的には採用権限がある人（社長など）から見てその会社に合う人材かどうかという人柄の部分の相性が一番大きい』という点かなと思います。

というのも、私の場合は最終面接で社長と話をさせていただきましたが、その中で自分の人柄を上手く伝えられて、それが社長から見て相性が良さそうだなと感じてもらえたというのが、コミュニケーションを取っていて自分でもわかったので、最終的にはそこが一番大きかったかなと今はそう感じています。

ただそれと同時に、それはある種の”運ゲー”、よく言えば『出会い』みたいなものでもあるので、こればっかしは数をこなすしかない（運が悪ければ時間がかかるし、運が良ければすぐ決まる感じ）かなと思います。

※例えば一番最初のカジュアル面談（面談と言いつつ面接してる場合もあるので注意）はお互いを知る場（＋人柄を見る）、書類選考や一次面接はスキル面や人柄を見る場、二次面接以降は採用権限が高いor持っている人から見てその会社と相性が良いかを見る場かなと思います。

面接の際に大事なことについて

また、面接の際に大事なことについては、やはり他の人との差別化をしっかり図っていくことかなと思います。

私の場合もちょっと特殊な経歴（SE → ブロガー → Web系エンジニアを目指す）であり、面接の際は必ずその部分について突っ込まれたので、何度も何度も同じような説明をするのがちょっと大変でしたが、その分自然に差別化（他にいない、珍しい人材）が図られていて、相手の印象には残りやすい感じだったので、ちゃんと差別化した部分を説明したり、アピールできると個性的な武器に変わります。

それに加えて、あとはちゃんと自分の素の状態で勝負することも大事です。

例えば面接が得意な人なら良い言葉を並べて偽りの自分で内定を得てしまう人もいるようですが、それだと入社後に自分も辛くなる（期待された成果を出せない）し、会社側も採用に失敗したことになる（使ったコストを回収できない）ので、お互いにとってデメリットが大きい（時間もお金も無駄になる）です。

なので、例えば現状で自分に自信が無い部分があったとしても、それは素直に認めて面接に挑んだ方が、採用された後に何か問題になることは無くなるかなと思います。

あとは私も元々面接が得意なタイプではありませんでしたが、人間は回数をこなせば慣れる生き物なので、もしそもそも面接自体が苦手だよって方がいたら、とにかく面接の回数を増やして練習（ちゃんとブラッシュアップすること）を繰り返せば、そのうち慣れます。

そして面接に慣れれば、自分の視点からもその会社と相性が良いかどうかが判断できるようになっていくので、『面接慣れ』はめちゃめちゃ大事です。

※面接というのは、企業側が求職者を選ぶ場というだけではなく、求職者側が企業を選ぶ場でもあるため、必要以上に自分を下に見せる必要はなく、お互いに対等な立場で自信を持って面接するのが大事です。世の中には様々な企業があり、もちろんブラック企業もたくさんあるので、自分の視点からその企業がブラックじゃないかを見極めるのも非常に大事です。何か違和感を感じたら、勇気を持って即辞退しましょう。

私が利用した求人サイトなどについて

今の時代において求職活動をする際は、何らかの求人サイトを利用するのが基本だと思いますが、利用する求人サイトを間違えると時間の無駄に繋がるので、その点は注意が必要です。

例えば、実務経験や実績がある人ならどの求人サイトを利用しても問題はありませんが、実務経験が無い人については、できる限り企業側にとって採用コストがかからない媒体を使うようにしないと、採用される可能性は低くなります。（上記でも述べましたが、実務未経験者を採用するのは費用対効果の面でリスクが高く、安易に採用できないため）

具体的には、「①知り合いからの紹介（最もコストが安い）  ＞＞・・（越えられない壁）・・＞＞  ②会社のHPなどから直接応募  ＞＞＞＞  ③コストが安いSNS系サービス『Wantedly』や『LinkedIn（現状は主に外資系企業向け）』などから応募  ＞＞  ④その他の一般的な求人サイトや転職エージェントなどから応募（最もコストが高い）」という順で採用コストには非常に大きな差があるため、実務経験がない人が自分から積極的に企業に応募していきたい場合は、①〜③の方法を取るのが大事になります。

特に多くの人はまず④の方法を取ると思いますが、④の方法が最も採用コストが高いため、実務未経験の人が採用されることはほとんどありません。

ただし、求人サイトに登録して企業側からスカウトが来た場合はこの限りではないため、④の方法を利用する場合は、登録するプロフィールはしっかり記載してスカウトを待ち、スカウトが来た中から選考に進んで行けば採用される可能性があります。

ちなみに私の場合も、上記の方法（エンジニアに強い求人サイト『Green』に登録し、スカウトが来た中から選考に進んだ）で採用に至ったため、実績があります。（加えて、企業側が自分のことを高く評価してくれたんだなというのがわかるので、その点は非常に嬉しく思います。）

一つ注意点としては、適当にスカウトを送っている企業が非常に多く（求職者のプロフィールをちゃんと見てない、スカウトを自動でしていて文面がおかしい、スカウトを出して応募が来てから書類選考をするなど）、求人サイトからスカウトが来たとしても、上手く機能していないのが実情なので、スカウトに対してはあまり期待しない方がいいです。

あとは応募後のやり取りにおいて、例えば企業側からの返信が非常に遅かったり、日程調整の際に企業側から19時以降の時間を指定されるなど、「明らかにブラック企業やろ！！w」と思われる企業からスカウトが来たこともあったので、ブラック企業要素についてはしっかり見極める必要があるかなと思います。何か違和感を感じたら辞退しましょう。

長期間の求職活動で発生した一つの悩みについて

私の場合は、技術のキャッチアップ（遅れを取り戻すこと）を優先しつつ、スカウトが来た場合に興味がある企業があれば選考に進んでみるようにし、ある程度技術のキャッチアップが満足できた後に自分から積極的に会社のHPなどから直接応募しようというような感じで、長い期間を前提として求職活動をしていましたが、実際には自分から積極的に応募する前に内定が得られました。（運が良かったパターンだと思います）

その長い求職活動の中で発生した一つの悩みとして、『例えば二つの企業から内定を得られた際、一方は最新技術も使っているようなモダンな開発環境であり、そしてもう一方はちょっと古いレガシーな開発環境だった場合にどちらの企業に入社するべきか』という問題です。

というのも、長い期間を前提として求職活動をした場合、時間の経過と共に自分の技術レベルが向上することになりますが、応募した企業の開発環境が自分が普段取り扱っている技術より古いレガシーな場合も増えてきます。

具体的に言うと、例えば自分は普段からDockerを使っているのに、未だにDockerすら使っていない企業だったというような感じで、「事業内容は良さそうだけど、ちょっと開発環境が古いな。。」という問題が発生する場合があります。

私の場合は幸いにも、レガシー環境の企業の方は不採用だったので、この問題は自然と解決することになりましたが、問題が発生した時はちょっと悩みました。

もちろん、面接などを通じてその企業で働く人達と一緒に頑張りたいという思いが強ければ、この問題が発生することは無いと思いますが、そうじゃない場合、つまり二つの企業で同じぐらいの条件だった場合は、この問題に直面します。

ただし、特にWeb業界においては技術の移り変わりも激しく、最新技術を使えば生産性が一気に向上することも珍しくないため、エンジニアの将来性を考慮するなら、できるだけモダンな開発環境で実務経験を積むのが正解なのかなと思います。

最後に

ということで、今回は35歳未経験でもWeb系エンジニアの内定を得られたことや、私が内定を得るまでに経験してきたことについてまとめました。

一人前のWeb系エンジニアになるにはまだまだこれから頑張らないと行けませんが、一つ良い結果を示せたのは良かったのかなと思います。

現在Web系エンジニアに向けて頑張っている方や、これからWeb系エンジニアになりたい人に対して、私のこの経験が少しでも役に立てれば幸いです。

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

前回の記事から約1ヶ月ほど経ちましたが、ようやく一つの大きな課題が完了しました。

具体的にはRailsチュートリアルを参考にしつつも、いくつかの最新技術など（Docker、Rails7、RSpec、CircleCI）を盛り込みながらところどころ手を加え、1個目のポートフォリオとして作成することです。

関連記事

35歳、Railsチュートリアルに挑む編【Web系エンジニア1年目】

2022年7月17日

1個目のポートフォリオが完成！【35歳Web系エンジニア1年目】

今回考えた課題の一番の目的として、できるだけ早く最新技術を吸収したいというところでしたが、可能なら合わせてポートフォリオも作りたかったので、この形になりました。

実際に取り組んでみると、やはり環境構築が少し難しかったのと、Railsなどのバージョンを上げたことで実装方法を変えないといけない部分がところどころあったので、非常に噛みごたえのあるような内容でした。

Railsチュートリアルを終えた段階ではやっと土台が完成したかなという感じでしたが、今回の課題に取り組んだことで、土台の上に骨組みができたような感じまで基礎レベルの向上に繋がったかなと思っています。

Railsチュートリアルの次にやる課題としては非常に良かったなと思っていて、今回も合わせて技術ブログも作成しておいたので、私と同じようにWeb系エンジニアに向けて頑張っている方は、ぜひ以下の関連記事を参考にしてみて下さい。

関連記事

Railsチュートリアルをカスタマイズしてポートフォリオを作成する方法【Docker・Rails7・CircleCI対応】

2022年8月15日

最後に

私が本格的にWeb系エンジニアに向けて取り組み始めてから約2ヶ月ほど経ちましたが、ここまでほぼ毎日のようにプログラミングと向き合ってきたので、短期間で一気に成長できたのかなと思っています。

まだまだやり足りない部分も多いですが、最低限やりたいところまでは一通りできたので、一旦落ち着いたかなという感じです。

次の課題としてはSPA（シングルページアプリケーション）構成と、インフラにAWSを使うことなので、次はこれらを調べようと思っています。

あとは今回の課題で最新のRails7を使いましたが、普及するのはまだまだこれからっぽい感じで、バックエンドにRails7を使うならフロントエンド周りはHotwireという技術がトレンドになりそうな感じではあるので、Hotwireについてももっと深く調べようかなとも思ってます。

逆に言えばフロントエンドにHotwireを使わず、現在主流のSPA構成（フロントエンドにReactやVueを使う）にするなら、おそらくバックエンドにRailsを使うことは少なくなると思うので、別のプログラミング言語の選択肢も持っておく必要がありそうです。

そんな感じで、まだまだ道半ばではありますが、Web系エンジニアに向けて引き続き頑張ります！

最後に、現在Web系エンジニアとして働けるような自社開発系企業さんも探しているので、もしそういう企業さんで私のことに興味を持ってくれた方がいたら、ぜひご連絡をいただけると嬉しいです。（中長期的に貢献できる自信はあります！）

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

前回の記事でも書きましたが、私は35歳でWeb系エンジニアへの道に進むことを決めました。

Web系の技術的な部分に関してはちょこちょこやっていた経験があったり、自己学習は得意な方なので中長期的な目線ではキャッチアップしていける自信はあるのですが、まだまだ基礎能力が弱いことは自覚していました。

そこで、Web系業界では有名だと思われる、「Railsチュートリアル」という教材に挑戦してみることにしました。

関連記事

35歳、Web系エンジニア1年目。

2022年6月29日

35歳、Railsチュートリアルに挑む編【Web系エンジニア1年目】

Railsチュートリアルに関しては、ちょっと難易度が高めというのは知っていたので、とりあえず1周目は一通り読んでみる。2周目で実際にコーディングしながら進める。というような感じで進めることを計画しました。

そして実際に1周目を読み進めると、1章あたり約1時間程度かかり、全部で14章あるので、全体で約14時間程度かかりました。

内容としてはこれまでの経験があったので、ある程度すらすら読み進められましたが、第8章ぐらいからだんだん難易度が上がり、第13章や14章では実際に動かしてみないと分かりづらいなという部分も出てきました。

とはいえ、一通り読むだけならそれほど問題なかったので、全体像を掴んだ後に実際にコーディングしながら進める2周目に入りました。

2周目は想定以上に時間がかかった

そして2周目に入るわけですが、当初の予定では1章あたり1時間〜2時間程度、全体で14章あるので約30時間ぐらいかければ終わることを想定していました。

が、実際にやってみると上手くいかないところが出てきたり、横道に逸れる必要が出てきたり（別の方法でできないか検討する必要があったり）、予想以上に時間がかかりました。

具体的には1日約8時間程度で、10日ぐらいかかったので、全体を通して約80時間ぐらいかかりました。

実際に進める中で、躓きそうな部分やメモしておいた方がよさそうなポイントは以下の関連記事にまとめたので、これからRailsチュートリアルに挑戦する人は参考にしていただければと思いますが、振り返るとやはりある程度歯応えがある難易度だったかなと思います。

※Ruby on Railsというフレームワークの知識だけではなく、それを進める前提としてRuby、コマンドライン、Git、GitHub、SQL、DB、HTML、CSS、JavaScript、jQuery、Heroku（インフラ）に関するような知識をある程度かじっておく必要があった感じ。

関連記事

Railsチュートリアル（第6版）を進めるための参考資料

2022年7月16日

Railsチュートリアルが終わって

ということで、なんとか短期間でRailsチュートリアルの学習を完了させることができました。

今思うのは、Webアプリケーションを作る上での基礎的な部分をこの教材を通して学ぶことができたので、前よりも確実に基礎能力が上がり、自信にも繋がったと思います。

とはいえ、まだまだやり足りない部分も自覚（もっともっとやり慣れる必要がある）しているし、もっと新しい技術をキャッチアップして取り入れないとだめなのはわかっているので、引き続き頑張ろうと思います。

最後に

今回は35歳Web系エンジニア1年目の私が、Railsチュートリアルに挑戦した話を書きました。

Railsチュートリアルを通じて、やっと自分の中での土台が完成したように感じたので、これからさらに新しい技術をキャッチアップして肉付けできたらなと思っています。

次はRubyやRailsのバージョンを新しいものに変更、DockerやCI/CDパイプライン、そしてRSpecも組み込みながら、いくつかのカスタマイズも加えつつ、最低限ポートフォリオとして使えるようなWebアプリケーションの構築を目指したいと思っています。

そこまで上手くてきたら、次はオリジナルアプリケーションの構築に加え、AWSやGCPの知識や経験を増やしていきたいと思っているので、引き続き頑張ります。

最後に、現在Web系エンジニアとして働けるような自社開発系企業さんも探しているので、もしそういう企業さんで私のことに興味を持ってくれた方がいたら、ぜひご連絡をいただけると嬉しいです。（中長期的に貢献できる自信はあります！）

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

私は前職でSEをしていましたが、2018年1月からは独立開業してブロガーの道に進みました。

それから約4年、ブログを中心にしつつも、大好きなゲームに注力し、そしてYouTubeも頑張るなど、自分の好きなことに全力で取り組んで来ました。

ただ残念がら、そういった道で生計を立てることは叶わず、お金も尽きてしまったので、今後はまた社会に出て頑張ろうと思っています。

※ブログでお金を稼ぐ方法はわかりましたが、改善するためには投資する資金（＋時間）が必要になるため、今すぐ改善するのは無理だと判断しました。

35歳、Web系エンジニア1年目。

じゃあ、どういった方向性で進んで行こうかというところなんですが、色々考えた結果、やはり私は前職での経験からも、IT業界でエンジニアとして活動した方が、おそらく自分の力も活かせるし、色々な面で社会貢献にも繋がって行くと思うので、またもう一度エンジニアに戻ろうと考えています。

ただし、前職のようなSIerの働き方は私には合わないため、今後はWeb系エンジニアとして働いて行けるように、本腰を入れて取り組んで行く予定です。

35歳、Web系エンジニア1年目。頑張ります！

かつてはITエンジニア35歳定年説なんてものも流行ってはいましたが、Web系エンジニアの職業としてはまだまだ歴史が浅い方だと思うので、実際のところどうなのかはわかりません。

ただある程度適性があって、やる気があり、そして努力もし続けられるなら、今からでも技術的な部分も含めて色々と周りに追いついて仕事をして行くことは十分可能だと考えています。

もちろん、実際にいい感じで仕事が見つかるかは正直わかりませんが、私としては一歩ずつその方向性に向けて進んで行くのみなので、コツコツ頑張って行こうと思います。

まあ、なんとかなるっしょ！（ポジティブ思考）

今後の活動方針について

ということで、今後の活動方針としては、Web系エンジニアとして働くためにも、技術的な部分の向上に取り組みつつ、仕事探しも行う必要があったりするので、これからはブログやゲーム、そしてYouTubeでの活動は少なくなります。

ただ独立してからこれまでの期間において、ブログを書いたり、YouTube用の動画編集をしたりすることに対しては、ある程度自分のものになった（当たり前のように出来るようになった）ので、今後も引き続きそれらのアウトプット活動は続けながら、色々と価値を提供できたらなと思っています。

また、ゲームに関しては一切諦めるつもりはなく、将来的にプロゲーマー的な活動をしていきたいという夢は変わらないので、ゲーム活動も引き続き出来る時間を使って頑張る予定です。

ただ練習時間などは確実に少なくなるため、今後はプレイするゲームを絞って取り組む予定ですが、今のところはもう一度スマブラに注力しようと考えています。

※スマブラに関しては、これからオフライン大会などに積極的に参加して慣れて行きたいなというようなタイミングでコロナが流行り、オフライン活動が縮小してしまったため、積極的な参加が叶いませんでしたが、2022年6月現在はコロナが落ち着いて来て、オフライン活動も活発になって来たため、これからまた頑張りたいところです。

あとは最近、最新作であるストリートファイター6の情報も解禁されましたが、スト6はまた格ゲーが盛り上がるビッグタイトルの一つになりそうな感じではあるので、発売後はプレイすると思います。

最後に

今回は久しぶりに私の人生に関する記事を書きました。

前職の仕事を辞めてから独立し、結果としては失敗に終わった感じではありますが、お金と時間を自分に投資し、全力で自分の好きなことに取り組めたことで、残りの人生において自分の進むべき方向性は定められたため、一歩踏み出したことには一切後悔はありません。

今後の私の人生がどうなるかはわかりませんが、私としては自分のやれることを一つずつこなして前に進んで行くのみなので、今後も前向きに頑張りたいと思います。