スクールに通う前に本当にきついのか知りたい
今の職場がつらいのは自分に向いていないからなのか
結論から言うと、「Webエンジニアはやめとけ」は半分は当たっていて、残りの半分は職場の話です。技術の入れ替わりに合わせた学習や、エラーの原因を自分で追いかける作業は、どの会社に移っても付いて回ります。ここが苦痛なら、転職しても状況は変わりません。逆に、終わらない残業や放置される新人、夜中の障害対応が一人に集中するといった話は、入る会社を選べばかなりの部分を避けられます。
困るのは、この2つを混ぜたまま判断してしまうことです。仕事が合わないのか会社が悪いのか分からないまま動くと、次の職場でも同じところでつまずきます。
この記事では、きついと言われる理由を一つずつ職種の問題か職場の問題かに仕分けたうえで、入社前に職場の実態を見抜く質問や、向き不向きを1〜2か月で確かめる方法まで解説します。すでにWebエンジニアとして働いていて、やめたいと感じている人に向けた考え方もまとめました。
目次
「Webエンジニアはやめとけ」は本当?先に結論を整理
ネット上の「やめとけ」を全部真に受ける必要はありません。かといって全部聞き流すと、入社してから痛い目を見ます。理由を一つずつ見ていく前に、まずは否定的な声がどこから出ているのかを押さえておきましょう。
やめとけが当たるかどうかは「職種」より「入口と職場」で決まる
同じWebエンジニアでも、最初にどの会社へ入るかで数年後の景色はまるで違います。未経験者にレビュー担当を付けて段階的に仕事を任せる会社に入った人と、研修もないまま即戦力として案件に放り込まれた人では、1年後に身についているスキルも、仕事への印象も別物になるからです。
ネットで目にする否定的な体験談の多くは、後者の環境で消耗した人の声です。その人のつらさは本物ですが、原因の大半は会社の育て方や案件の回し方にあります。Webエンジニアという職種そのものの話とは分けて読んだほうが、判断を誤りません。
もちろん、職種そのものに付いてくる負荷もゼロではありません。そこは次の章以降で、理由ごとに職種の問題か職場の問題かを仕分けていきます。
「やめとけ」と言っているのは誰か|よくある3つの発信元
否定的な意見を読むときは、書いている人がどんな現場にいたのかを確かめる癖をつけてください。発信元はおおむね次の3つに分かれます。
| 発信元 | 言っていること・背景 | 自分に当てはまる条件 |
|---|---|---|
| スクール卒・未経験で入社した人 | 教育体制がない現場に入り、質問できないまま実務で苦労した | 実務経験がないのに、研修やレビューの仕組みがない会社を選ぼうとしている |
| 受託・下請け現場のエンジニア | 厳しい納期や頻繁な仕様変更、顧客との調整に追われている | 納期管理や要員配置に問題がある会社、下請け構造の末端にある案件を検討している |
| AIやエンジニア増加を理由に将来性を否定する人 | AIによる開発支援や人材の増加から、今後は仕事がなくなると主張する | 具体的な求人や求められる経験を確認せず、将来性に関する意見だけで判断している |
一番真剣に読むべきなのは、1つ目の未経験入社組の声です。教育体制のない会社を選んだ結果どうなるかを、これほど具体的に教えてくれる情報はほかにないからです。2つ目の受託・下請け組の話は、応募先の商流と納期の決め方を確認すれば、自分に当てはまるかどうかを判断できます。
3つ目は、話半分で構いません。現場にいない人が書いていることも多く、求人の中身まで踏み込んだ話はまず出てきません。将来性が気になるなら、こうした意見よりも、実際の求人で何が求められているかを見たほうが確実です。
Webエンジニアがやめとけ・きついと言われる理由
ここからは、きついと言われる理由を一つずつ見ていきます。どれも理由を挙げて終わりにはせず、どんな職場で特に起きやすいのかまでセットで書きました。自分が検討している会社に当てはまるかを考えながら読み進めてみてください。
リリース前と障害対応で生活のリズムが崩れる
ECサイトや予約システム、決済サービスのように、利用者が24時間アクセスするサービスでは、深夜でも障害が起きれば誰かが復旧にあたります。止まっている間ずっと売上が落ち続けるため、朝まで待つという判断はまず取れません。新機能のリリース直前には作業が詰まり、予定していた時間に帰れない日も続きます。
とはいえ、一年中この状態が続くわけではありません。厚生労働省の職業情報提供サイト「job tag」でも、システムエンジニア(Webサービス開発)の労働条件の特徴として、新サービスのリリース前などに残業が多くなる点が挙げられています。月の労働時間は全国で159時間です。忙しさは開発の節目に集中し、それ以外の時期は落ち着く、という波のある働き方です。
出典:厚生労働省 職業情報提供サイト(job tag)「システムエンジニア(Webサービス開発)」
https://shigoto.mhlw.go.jp/User/Occupation/Detail/314
※統計はWebエンジニアだけでなく、同職業が属する職業分類全体の数値です。
夜間に呼ばれる頻度で比べると、法人の業務時間に合わせて使われるBtoB向けSaaSは、一般消費者が24時間使うサービスより明らかに低くなります。それでも、顧客の業務を止める障害が起きれば時間帯に関係なく対応が必要です。BtoBなら夜間対応はないと決めつけず、当番の有無は面接で確かめてください。
個人の負担を本当に左右するのは、サービスの種類より体制のほうです。障害対応の当番が決まっていて、対応した時間が手当や代休で精算され、原因を振り返って再発を防ぐ仕組みまである会社なら、夜中に呼ばれる回数そのものが減っていきます。逆に、詳しい人が毎回対応しているような職場では、その人に負担が集中し続けます。
業務時間外の学習がほぼ前提になる
Webの世界では、使っているフレームワークのメジャーアップデートで書き方が変わったり、ライブラリのサポートが終わって別の手段への移行を迫られたりすることが毎年のように起きます。そのたびに公式ドキュメントを読み、既存コードへの影響を調べ、動かしながら理解していく作業が発生します。
業務時間内にこれを済ませられる職場も確かにあります。困るのは、古いシステムの保守が中心で、新しい技術に触れる機会がほとんどない職場です。そこで何年も過ごすと、転職市場で評価される経験が積み上がらず、気づいたときには自分の時間を使って追いつくしかなくなります。
だからといって、毎晩何時間も勉強し続ける必要はありません。現実的な線は、平日は業務で詰まった箇所の公式ドキュメントをその日のうちに読んでおくこと、休日に余裕があれば業務で使っていない技術を小さく動かしてみることです。この程度の学習を生活に組み込めるかどうかが、長く続けられるかの分かれ目になります。
1人でカバーする範囲が広く、未経験ほど消耗する
少人数のスタートアップでは、フロントエンドとバックエンドに加えて、インフラの構築まで一人のエンジニアが受け持つことも普通にあります。デザインの調整や顧客との仕様のすり合わせまで回ってくる現場もあるほどです。
経験者にとっては幅を広げる機会になります。ところが、基礎がまだ固まっていない未経験者が同じ環境に入ると、覚える範囲が広すぎてどれも中途半端なまま疲れ切ってしまいます。
求人票の「フルスタック歓迎」「裁量を持って開発できる」という言葉は、そのまま褒め言葉として受け取らないほうが安全です。成長してほしいから任せているのか、人が足りないから全部やってもらっているのか、中身は会社によって正反対だからです。大企業でも、配属されるチームが少人数なら状況は同じなので、会社の規模より配属先のチーム構成を見るべきです。
仕様が動き続けるアジャイル開発に振り回される
Webサービスは、リリースした後もユーザーの反応を見ながら機能を作り直していくのが基本です。短いサイクルで改善を繰り返すアジャイル開発では、途中で優先順位が入れ替わり、昨日まで作っていた機能が保留になることもあります。
最初に決めた仕様どおりに最後まで作り切りたい人にとって、これはかなりのストレスです。SIerでウォーターフォール型の開発に慣れてきた人がWeb系へ移ったときに一番戸惑うのも、仕様が固まる前に手を動かし始める、この進め方でしょう。
ただし、仕様が変わること自体と、無計画に振り回されることは別物です。変更の理由と優先順位がチームで共有され、それに合わせてスケジュールも組み直されているなら、変化は改善の一部として受け止められます。理由の説明もなく締め切りだけが据え置かれる職場は、アジャイルではなく単なる管理不足です。
年収が伸びる人と頭打ちになる人の差が大きい
Webエンジニアの年収は、勤続年数よりも、どこまでの役割を任されているかで決まります。仕様書どおりに実装する仕事だけを何年続けても、設計や改善の判断に関わらない限り、担当できる業務が広がらず昇給も止まりやすくなります。実装に価値がないという話ではなく、任される範囲が変わらない環境だと評価の天井が早く来る、ということです。
数字で見ると、job tagに掲載されているスキルレベル別の年収(設計・構築)は、ITSSレベル1〜2で420.0万〜620.0万円、レベル5以上で600.0万〜950.0万円です。いずれも第一〜第三四分位の範囲なので重なりはありますが、上のレベルほどレンジ全体が高い位置にあることは読み取れます。
出典:厚生労働省 職業情報提供サイト(job tag)「システムエンジニア(Webサービス開発)」
https://shigoto.mhlw.go.jp/User/Occupation/Detail/314
年収を伸ばしたいなら、コードを書く力に加えて、設計、要件の整理、コードレビュー、障害の再発防止といった役割を担える環境を選ぶことです。入社前には、入社2〜3年目の人がどんな仕事を任されているかを聞いてみると、その会社で天井がどこにあるかが見えてきます。
会社や事業が安定しないことがある
Webサービスを開発する会社には、売上の大半を一つのサービスや一社の顧客に頼っているところもあります。サービスが伸び悩んだり、次の資金調達がうまくいかなかったりすれば、事業の縮小や撤退とともに開発チームが小さくなることもあり得ます。会社によっては退職金制度がないなど、福利厚生の差も小さくありません。
安定性を気にするなら、見るべきは知名度や勢いではなく稼ぎ方です。主な収益源は何か、特定の顧客への依存度は高くないか、既存事業で継続的に利益が出ているか。上場していることや資金調達の実績は判断材料になりますが、それだけで安心できるわけではありません。求人票から読み取れない部分は、面接や企業の開示情報、転職エージェントの情報を組み合わせて埋めていきましょう。
「モダンな開発ができる」と思って入ると裏切られることがある
Web系企業に入れば最新の技術で開発できる、と期待している人は多いはずです。実際には、長年運用しているサービスほど、独自に作られたフレームワークや古いライブラリが残っていて、複雑に絡み合ったコードを少しずつ直しながら保守していることがよくあります。求人票に新規事業で使っている技術が並んでいても、入社後に担当するのは既存システムの改修だった、というずれはよく起こります。
既存システムの保守にも、障害を防ぐ設計や技術負債の解消といった、エンジニアとして確実に身につく経験があります。ただ、新しい技術に挑戦したくて転職したのなら、期待とのずれは大きな不満になるでしょう。応募時には会社全体の技術スタックではなく、配属予定のチームで使っている技術と、新規開発と保守の比率を聞いておくべきです。
未経験の入口が以前より狭くなっている
生成AIの普及で、定型的なコードの作成やちょっとした修正は、以前よりずっと短い時間で済むようになりました。困ったことに、これはかつて未経験のエンジニアが最初に任されていた仕事そのものです。入門的な実装タスクが減れば、そこから経験を積み始める入口も狭くなります。
とはいえ、簡単なコードが書けることと、実際に動いているシステムを安全に開発・運用できることの間には、まだ大きな距離があります。既存コードへの影響を見極め、仕様を正しく理解し、テストとレビューを通して問題がないことを確かめる。この部分はAIに丸ごと任せられるものではなく、企業が未経験者に期待するのもここを身につけていく力です。
人手不足だから未経験でも簡単に入れる、という話を信じて準備を怠ると、選考でまず苦戦します。未経験から目指すなら、研修の有無よりも、実際の開発に参加するまでの段取りやメンターの有無、コードレビューの仕組みを確認してください。採用した人を育てる余力がある会社かどうかが、入口選びのすべてと言ってもいいくらいです。
「増えすぎ・オワコン」と言われるが、データ上は人手不足が続いている
エンジニアが増えすぎてもう仕事がない、という意見もよく見かけます。ところが、job tagに掲載されているハローワークの求人統計では、システムエンジニア(Webサービス開発)が属する職業分類の有効求人倍率は全国2.54倍(令和7年度)です。求職者1人に対して2件以上の求人がある計算なので、少なくともデータの上では人手不足が続いています。
出典:厚生労働省 職業情報提供サイト(job tag)「システムエンジニア(Webサービス開発)」
https://shigoto.mhlw.go.jp/User/Occupation/Detail/314
※Webエンジニアだけでなく、同職業が属する職業分類全体の数値です。
それでもオワコンと言われるのは、足りていないのが実務経験のある人材だからです。経験者の取り合いが続くなかで、未経験者を育てるための求人はそれほど増えていません。人手不足とオワコン論が同時に語られるのは、このねじれが原因です。求人倍率が高いからといって、未経験でも入りやすいと考えるのは危険です。
AIによる仕事への影響や、Webエンジニアとして長く働くための考え方については、Webエンジニアの将来性を解説した記事で詳しく紹介しています。
その「きつさ」は職種の問題か、職場の問題か
ここまで挙げた理由を、職種そのものに付いてくる負荷と、職場を選べば避けられる負荷に仕分けると次のようになります。これから目指す人は応募先を選ぶ基準に、今つらい人は原因を見極める材料に使ってください。
| きついと言われる理由 | 分類 | 見分けるポイント |
|---|---|---|
| リリース前と障害対応 | 職種と職場の両方 | 障害が起きること自体は避けられない。夜間対応が特定の人に集中するかは体制次第 |
| 業務時間外の学習 | 職種寄り | 学習量は職場で増減するが、学び続ける必要そのものは消えない |
| 担当範囲の広さ | 職場 | 配属チームの人数と役割分担を見れば分かる |
| 仕様が動き続けること | 職種と職場の両方 | 仕様が変わるのはWeb開発の前提。振り回されるかはチームの管理次第 |
| 年収の伸び | 職場 | 任される役割の幅と評価制度が左右する |
| 会社・事業の安定性 | 職場 | 収益の柱と特定顧客への依存度を見る |
| モダン開発とのギャップ | 職場 | 配属チームの技術と、新規開発と保守の比率を確認する |
| 未経験の入口の狭さ | 職場(入口選び) | 入社後に育てる余力がある会社を選べるかどうか |
こうして並べると、純粋に職種の問題と言い切れるものは意外と少なく、大半は職場の選び方で変えられることが分かります。
職種そのものに付いてくる負荷(どの会社でも避けにくい)
職種の側に残るのは、つまるところ3つです。技術の入れ替わりに合わせて学び続けること、エラーや不具合の原因を自分で追いかけること、そして本番環境に手を入れる責任を負うことです。加えて、一日の大半を座って画面と向き合う働き方そのものも、どこへ行っても変わりません。
この3つのどれかを強い苦痛に感じるなら、会社を変えても同じ壁に当たります。特にエラーの原因を追う作業は、経験を積んで減るどころか、扱うシステムが大きくなるほど難しくなっていく仕事です。逆に言えば、原因を突き止めたときに手応えを感じられる人にとっては、ここがそのまま仕事のやりがいになります。
職場を選べば避けられる負荷
残業が慢性化している、夜間の障害対応がいつも同じ人に回ってくる、何を頑張れば評価されるのか分からない。こうした悩みは、職種ではなく体制とマネジメントから生まれています。保守作業ばかりで新しい技術や設計に関われない状況や、質問できる相手がいないまま新人が放置される状況も同じです。
どれも、仕組みが整った会社に移れば解消できる問題です。だからこそ、今の職場でこうした負荷に苦しんでいる人は、Webエンジニアという仕事そのものに見切りをつける前に、環境を変える道を考えるべきです。これから入社する人なら、次の章で紹介する方法を使えば、入社前にかなりの部分を見抜けます。
業態によって「やめとけ」が当たりやすい場所は違う
同じWebエンジニアでも、自社サービスを開発する会社、顧客から開発を請け負う会社、SES経由でWeb案件に参加する場合とでは、きつさの出どころが変わります。
| 業態 | きつくなりやすい場面 | 比較的避けやすいこと |
|---|---|---|
| 自社サービス開発 | サービスの売上や利用者への影響を背負った開発、障害時の対応 | 顧客都合による納期変更。技術選定の裁量は会社やチームによる |
| 受託開発・Web制作 | 顧客都合の仕様変更、複数案件の並行対応、厳しい納期 | 自社サービスの事業リスク。ただし受託先の経営や案件状況の影響は受ける |
| SES経由のWeb案件 | 参画先ごとの開発環境の違い、担当範囲の限定、下請け構造の末端にある案件 | 自社サービスの運営責任。働き方は配属先や契約内容によって大きく変わる |
自社開発なら働きやすい、SESならスキルが身につかない、という単純な図式は成り立ちません。同じ業態の中でも、ここまで見てきた体制の差のほうがはるかに大きいからです。業態は応募先を絞り込む入口として使い、最終的な判断は配属先の実態で下すのが確実です。
自社開発企業ならではの注意点は、自社開発エンジニアはやめとけと言われる理由で詳しく解説しています。SESや多重下請けの構造については、IT業界はやめとけと言われる理由もあわせて読んでみてください。
「やめとけ」な職場を入社前に見抜く確認ポイント
職場を選べば避けられる負荷が多いと分かっても、入社前に実態を見抜けなければ意味がありません。ここでは求人票、面接、企業の発信、第三者の情報という4つの経路を使って、働き方と開発体制を確かめる方法を紹介します。
求人票で見るべきところ
求人票を読むときは、キャッチコピーより具体性の差に目を向けてください。最初に見たいのは技術スタックの書き方です。使用言語が並んでいるだけの求人と、フレームワークやデータベース、クラウド環境、さらにはコードレビューの体制や開発手法まで書いてある求人とでは、開発チームが採用にどれだけ関わっているかがまるで違います。後者のように現場のエンジニアが書いたと分かる求人ほど、入社後のずれは小さく済みます。
次に、開発チームの人数とエンジニアの比率を探します。記載がなければ、少人数で幅広く任される可能性を想定しておきましょう。少人数そのものが悪いわけではなく、困ったときに相談できる相手がいるかどうかが問題です。
残業については、月平均の残業時間が書かれているか、固定残業代が何時間分に設定されているかを確認します。固定残業代が45時間分のように多めに設定されているなら、その時間に近い残業が日常的に発生しているのかを面接で必ず聞いておきましょう。あわせて、「フルスタック歓迎」「裁量大」といった言葉が並んでいる求人は、前の章で触れたとおり、人手不足の裏返しである可能性も頭に置いて読む必要があります。
未経験OKと書かれた求人の読み方は、未経験OKのエンジニア求人が怪しい?元エンジニアが見極め方を伝授で詳しく解説しています。
面接・カジュアル面談で聞いておきたい質問
リリース前の忙しさや障害対応の回し方、入社後に任される業務は、求人票からはまず読み取れません。面接やカジュアル面談では、次のような質問で実際の運用を聞いてみましょう。
本番障害が発生した場合、誰がどのような手順で対応しますか。オンコール当番や手当の仕組みも教えてください
入社後3か月程度は、どのような業務を担当する想定ですか
コードレビューは誰が担当し、どのような流れで実施していますか
大事なのは、返ってきた答えをどう読むかです。体制が整っている会社は、頻度や担当者、ルールを具体的に答えられます。答えが精神論や「その時々で」に寄るなら、仕組みがないまま現場の頑張りで回していると見てよいでしょう。
| 質問 | 安心できる回答の例 | 注意したい回答の例 |
|---|---|---|
| リリース直前の働き方 | リリースの周期と、直前に残業がどの程度増えるかを数字で説明できる | みんなで乗り切っている、その時々による |
| 本番障害の対応 | 当番表があり、対応時間は手当や代休で精算し、原因の振り返りまで行っている | 気づいた人が対応する、詳しい人が見る |
| 入社後3か月の業務 | 環境構築から小さな改修へと段階が決まっていて、レビュー担当者も決まっている | すぐに案件に入って戦力になってもらう(未経験採用の場合) |
| コードレビュー | 誰がどの観点で見るか、どのくらいの単位でレビューに出すかまで説明できる | 手が空いた人が見る、特にルールはない |
こうした質問をすると印象が悪くなるのでは、と心配する人もいるでしょう。面接をする側から見れば、むしろ歓迎したい質問です。働き方を具体的に確かめようとする応募者は、入社後に聞いていた話と違うと感じて早期に辞めるリスクが低いと判断できるからです。避けたいのは、質問が年収や休日の条件だけに偏ることです。働き方の質問は担当する業務への関心とセットで聞くと、条件面の確認も自然に受け止めてもらえます。
技術ブログ・登壇・GitHubから現場の空気を読む
企業の技術ブログやエンジニアの登壇資料、公開されているGitHubの活動からも、開発チームの姿はかなり見えてきます。注目したいのは、新しい技術を導入した華やかな話よりも、既存システムの改善や障害の振り返り、技術を選んだ理由を書いた記事です。こうした地味な記事を外に出せる会社は、課題をチームで共有し、仕組みで解決しようとする文化を持っています。
更新が数年前で止まっているブログは、発信を担っていたエンジニアが抜けたサインのこともあります。ただ、ブログがないから開発環境が悪いと決めつけるのは早計です。金融や医療のように顧客情報を扱う企業では、外に出せる内容そのものが限られます。公開情報は、面接で何を深掘りするかを決める材料として使うのが一番の活かし方です。
求人票と面接だけでは見えない情報は第三者から取る
残業の実態や離職の多さ、オンコール当番が実際にどう回っているかといった話は、採用担当者に聞いてもなかなか本音は出てきません。採用する側にとって不利な情報だからです。
この穴を埋めるのが、企業とやり取りを重ねている転職エージェントです。求人票に載らない開発体制や、過去に紹介した人が入社後どう働いているかといった情報を持っていることがあります。紹介を受けたら、残業や障害対応についてどこまで具体的に把握しているかを逆に質問してみてください。答えに詰まる担当者なら、その求人の内情はまだ十分に掴めていないと見るべきです。
経験の有無によって、頼るべき相談先は変わります。Webエンジニアの職場選びで使いやすいのは、次の3つです。
| サービス名 | 向いている人 | 職場選びで相談したいこと |
|---|---|---|
| レバテックキャリア | 実務経験のあるWebエンジニア | 配属予定チームの開発体制や、保守と新規開発の比率 |
| テックゴー | 選考対策を深めたい経験者 | 面接で働き方の実態をどう聞き出すか、企業ごとの選考対策 |
| ユニゾンキャリア | 未経験からITエンジニアを目指す20代 | 未経験者向け求人の研修内容や、入社後のフォロー体制 |
Web系に強い転職サイト・エージェントをもっと比較したい場合は、Web系転職サイトおすすめ31社を現役エンジニアが厳選!未経験OKや女性向けあり!で、特化型・総合型・未経験向けに分けて紹介しています。
Webエンジニアはやめとけが当てはまる人・気にしなくていい人
向いているかどうかを、好奇心旺盛か、論理的かといった性格診断で決めるのはあまり当てになりません。ここでは、Webエンジニアの仕事で毎日のように起きる場面に、自分ならどう動くかを基準に判断してみます。
やめておいた方がいい人の特徴
次の5つのうち、複数に当てはまり、しかも直したいとも思えないなら、Webエンジニアは慎重に考えたほうがよい仕事です。
- エラーが出たら、メッセージを読む前に誰かに聞きたくなる。Web開発ではエラーメッセージやログを読み解く作業が一日に何度も発生するため、ここを避けたい人は毎日が苦痛になります。
- 仕様が途中で変わると、気持ちを立て直せない。ユーザーの反応を見て作り直すのがWebサービスの基本なので、変更のたびに消耗していては体力が持ちません。
- 業務外に技術を触る時間を、週に数時間も確保できない生活を送っている。担当する技術が限られる職場に入ったとき、知識を補う手段がなくなります。
- 長時間の座り作業や画面を見続けることが、体質的に厳しい。作業環境の工夫で軽くはできても、デスクワーク中心という仕事の形そのものは変わりません。
- 黙々と作業できそうだから、が志望理由の中心にある。実際には仕様の確認やコードレビュー、チーム内の相談がひっきりなしに発生し、思い描いた働き方とのずれに入社後すぐ気づくことになります。
1つ当てはまった程度で、適性がないと決めつけるのは早すぎます。特に未経験の段階では、仕事の実態を知らないまま想像で答えている部分も多いはずです。判断がつかない人は、この章の最後で紹介する方法で実際に確かめるのが一番早いです。
「やめとけ」を気にしなくていい人
エラーの原因を突き止めたときに、すっきりした手応えを感じられる人は、周りの否定的な意見に振り回されなくて大丈夫です。自分が作った機能にユーザーの反応が返ってきたり、改善の結果が数字に表れたりすることにやりがいを感じるタイプも同じです。Webサービスの開発は、まさにその繰り返しでできているからです。
誤解されやすいのですが、プログラミングが三度の飯より好きである必要はありません。現場で長く働いている人を見ても、技術そのものへの熱量より、問題を解決する作業が苦にならないことや、働き方と収入のバランスに納得していることが続く理由になっている人は大勢います。
ただ、技術的な適性があっても、職場の環境が悪ければ続けるのは難しくなります。向いているかどうかと、どこで働くかは、別々に判断するものです。
迷っているなら、1〜2か月で適性を試す
向いているか分からないまま悩み続けるより、実際に一つ作ってみるほうがずっと早く答えが出ます。
最初の数週間は、ProgateやドットインストールでHTML・CSS・JavaScriptと、サーバー側の言語を1つ(RubyやPHPなど)触れば十分です。演習を一通り終えたら、教材の外に出てください。作るのは、ログインして自分のToDoを登録・編集・削除できる程度のアプリが適しています。データベースへの保存と入力チェックまで入れると、実務でつまずく箇所をひと通り経験できます。Rubyを選んだなら、Railsチュートリアルを最後まで進めるのも一つの物差しになります。完成したら、RenderやVercelなどのホスティングサービスで公開するところまでやり切りましょう。手元で動いたものが本番で動かないという体験こそ、Webエンジニアの日常に近いからです。
判断材料にするのは、完成度より詰まったときの自分の動き方です。エラーが出たらすぐ検索欄に貼り付けるのではなく、まずエラーメッセージを読み、どのファイルの何行目で何が起きているのかを自分の言葉で説明しようとしたかを記録してください。調べて解決できたときに面白さを感じたなら、この仕事の中心にある作業に向いています。何度やっても苦痛しか残らないなら、その感覚は職場を変えても消えません。
独学で1〜2か月試しても判断がつかない場合は、プログラミングスクールの無料カウンセリングや体験講座で、現役エンジニアに学習内容と仕事の実態をぶつけてみるのも手です。スクールを比較するなら、プログラミングスクールおすすめランキング19選!社会人・未経験の転職にも有利!を参考にしてください。
すでにWebエンジニアで「やめたい」と感じている人へ
今まさにWebエンジニアとして働いていて、つらさが限界に近い人もいるでしょう。退職届を出す前に、つらさの正体だけは確かめておいてください。仕事そのものが合わないのか、今の職場が合わないのかで、取るべき行動はまったく変わるからです。
辞める前に、つらさの原因を切り分ける
頭の中だけで考えていると、何もかもが嫌に感じてしまいます。おすすめなのは、1〜2週間ほど、つらいと感じた場面をその都度メモに残すやり方です。夜中に障害の電話で起こされた、レビューで同じ指摘を何度も受けた、評価面談で何を頑張ったのか伝わらなかった、というように場面ごとに書き出しておくと、後から見返したときに偏りがはっきりします。
メモを見返して、残業やオンコール、評価、放置されている感覚といった職場の体制に関わる場面が大半なら、Webエンジニアを辞める必要はありません。体制が整った会社に移れば、同じ仕事でもかなり楽になります。反対に、エラーの原因を調べる場面やコードを読む場面そのものが毎回つらいなら、職場を変えても同じ壁に当たるでしょう。その場合は、開発との距離を変える方向で次の仕事を考えたほうがうまくいきます。
入社1〜2年目で、仕事の進め方が分からない、周りについていけないという焦りがつらさの中心なら、経験を積むことで薄れていく部分も大きいはずです。ただし、質問できる相手もいないまま放置されている状態なら話は別です。その環境で耐え続ける理由はありません。新人時代によくある悩みと乗り越え方は、きつい・つらいと悩む方へ【新人エンジニアあるある11選を紹介】でも紹介しています。
Webエンジニアの経験が評価されやすい次の選択肢
Webエンジニアを辞めたいと感じていても、これまでの開発経験は次の仕事でそのまま武器になります。今のつらさの原因から逆算すると、次に選ぶべき方向はおおむね絞り込めます。
| 今のつらさの主な原因 | 検討したい次の選択肢 | 変わること・残ること |
|---|---|---|
| 受託案件の納期と顧客都合の仕様変更 | 自社サービス企業 | 納期の決め方を自社で握れるようになる。サービスの売上やリリースへの責任は残る |
| 深夜・休日の障害対応 | BtoB向けSaaS企業 | 顧客の業務時間に合わせて動くため、夜間に呼ばれる頻度は下がる。障害対応そのものはなくならない |
| 技術の入れ替わりを追い続ける負担 | 社内SE(開発寄り) | 社内システムの改善が中心になり、流行を追う圧力は弱まる。社内調整やベンダーとの折衝が増える |
| 広く浅く何でも任される状態 | QA・SRE・セキュリティなどの専門職 | 担当領域を絞って深められる。その分野の専門知識を新たに身につける必要がある |
| 実装作業そのものへの疲れ | PdM・ディレクション寄りの仕事 | コードを書く時間は減る。要件の整理や関係者との調整、意思決定の責任が重くなる |
ここで避けたいのは、Webエンジニアを辞めること自体を目的にしてしまうことです。何から離れたいのか、どの経験は手放したくないのかを言葉にしてから求人を探すと、次の職場で同じ不満を繰り返さずに済みます。
開発経験を活かして社内SEに移る道は、開発エンジニアから社内SEへ転職|コードは書き続けられる?違い・後悔しない求人の選び方で詳しく解説しています。
Webエンジニアのやめとけに関するよくある質問
30代未経験からWebエンジニアを目指すのはやめた方がいい?
やめた方がいいとは言いません。ただ、20代と同じ戦い方をすると厳しくなります。30代の未経験者に企業が期待するのは、ポテンシャルよりも前職で積んだ経験の使い道です。業界知識や顧客との調整、プロジェクトを回した経験が、開発チームのどこで活きるのかを自分の言葉で説明できる状態にしてから応募してください。
あわせて、未経験の30代を育てる体制がある会社かどうかの見極めは、20代の転職以上に重要になります。年代別の判断材料は、30代未経験からIT業界への転職は可能?難しいと言われる理由と成功する人の特徴で詳しく解説しています。
プログラミングスクール卒だと現場で通用しない?
スクールを出ただけで通用するかどうかは決まりません。スクールで書くのは、ゼロから作る小さなアプリが中心です。それに対して、現場の仕事の大半は他人が書いた既存コードを読み、影響範囲を確かめながら少しずつ直す作業です。この差に戸惑う人は多いものの、埋められない差ではありません。
入社後に伸びるのは、学んだ内容を自分の言葉で説明でき、分からないことを調べてから質問し、レビューで受けた指摘を次のコードに反映できる人です。逆に言えば、この3つができるようになるまで見守ってくれる会社を選べるかどうかで、スクール卒の明暗は分かれます。
フリーランスになればきつさから解放される?
解放されるどころか、きつさの種類が入れ替わるだけです。会社の人間関係や社内ルールから離れられる代わりに、案件を自分で取ってくること、契約や収入を管理すること、案件が切れたときに次を探すことまで、すべて自分の責任になります。技術を学び続ける必要も、会社員時代と何も変わりません。
会社員の働き方が合わないなら、まずは環境の良い会社への転職で解決できないかを考えるのが順番です。独立を検討するなら、フリーランスエンジニアやめとけは本当?会社員を辞める前に知っておきたいことを先に読んでおくことをおすすめします。
AIでWebエンジニアの仕事はなくなる?
コードを書く作業の一部は、すでにAIで大きく効率化されています。ただ、要件を理解して設計を決め、AIが出したコードが正しいか、安全かを判断し、システム全体の品質に責任を持つ仕事までは置き換わっていません。
問うべきなのは仕事がなくなるかどうかより、AIが書いたコードを読んで正しいか判断できる側に回れるかどうかです。そこを目指すなら、今のうちから生成されたコードをそのまま使わず、なぜ動くのかを説明できるまで読む習慣をつけておくべきです。
まとめ
Webエンジニアがやめとけと言われる理由の多くは、職種そのものではなく職場の体制から生まれています。技術を学び続けること、エラーの原因を自分で追うこと、本番環境への責任を負うこと。この3つは会社を変えても付いて回りますが、慢性的な残業や放置される新人、一人に集中する障害対応は、入る会社を選べばかなりの部分を避けられます。
これから目指す人は、まず小さなWebアプリを作って公開するところまでやってみましょう。エラーと向き合う作業が苦痛か、それとも面白いか。その感覚がそのまま適性の答えになります。すでに働いていてつらい人は、つらさの原因が仕事にあるのか職場にあるのかを切り分けるのが先です。職場が原因なら、仕事そのものを手放すのはもったいない判断です。
どちらの場合も、最後の判断を左右するのは入社前にどれだけ職場の実態を掴めるかです。求人票と面接で確かめられることは確かめ、それでも見えない残業の実態や障害対応の回り方は、企業の内情を把握している転職エージェントに聞くのが近道です。
Webエンジニアの職場選びを相談できる転職エージェント3選
ここでは、記事の中で紹介した確認ポイントを、実際の転職活動で一緒に詰めてくれる相談先を3つ紹介します。実務経験がある人とこれから目指す人とでは頼るべき先が違うので、自分の状況に合うものを選んでください。
現役Webエンジニア向け:レバテックキャリア
IT・Webエンジニアの転職支援に特化したエージェントです。年間を通じて企業訪問を重ねているため、求人票には出てこない配属先チームの体制や、保守と新規開発の割合といった情報を持っていることが強みです。
今の職場で保守ばかり担当していて設計や新規開発の経験を積みたい人は、まず希望する業務に本当に携われる求人かどうかを確かめるところから相談するとよいでしょう。自分の経験が市場でどう評価されるかを整理する場としても使えます。
選考対策を重視する現役エンジニア:テックゴー
経験者のITエンジニアに特化した転職エージェントで、模擬面接を回数の制限なく受けられる点が大きな特徴です。人気企業の選考を1日でまとめて受けられる1Day選考会もあり、働きながら短期間で転職活動を進めたい人にも向いています。
この記事で紹介した、リリース前の働き方や障害対応の体制を確かめる質問は、聞き方を誤ると条件面ばかり気にしている応募者に見えかねません。模擬面接の場で、働き方の実態をどう聞き出すかまで練習しておくと、本番で遠慮せずに確かめられます。
未経験からWebエンジニアを目指す人:ユニゾンキャリア
20代の未経験者のIT転職に強いエージェントです。完全無料のITスクールを使って基礎を固めながら、並行して転職活動を進められます。
未経験者にとって大切なのは、内定が出るかどうかより、入社後に誰がどう育ててくれるかです。求人を紹介されたら、研修の中身や配属先、レビューを担当する人がいるかまで遠慮なく確認しましょう。この記事で触れた入口選びの失敗を避けるうえで、こうした質問に具体的に答えてもらえる相談先を持つ意味は大きいです。
未経験者向けの転職エージェントをもっと比較したい場合は、未経験からのエンジニア転職に強い転職エージェント・サイト18選―探し方・選び方もわかるも参考にしてください。



















