未経験エンジニアは「うざい」と思われるのか｜職種別の「やめとけ」と入社後の立ち回り

「未経験 エンジニア うざい」「webデザイナー 未経験 やめとけ」「社内SE 未経験 やめとけ」——これらの検索に共通するのは、入社した後に自分がどう扱われるかへの不安です。技術が身につくかどうかより、現場で受け入れられるかを気にしている状態です。

この記事では、なぜそう言われるのかを構造から分解し、職種ごとに「やめとけ」の中身が違うことを整理します。そのうえで、入社後に「うざい」と思われずに立ち回る具体策を扱います。

「未経験はうざい」と言われる構造

まず前提として、未経験者そのものが嫌われているわけではありません。現場が負担に感じるのは、次のような状況です。

1. 教える側の時間が売上にならない

多くの開発現場では、担当者の時間が案件に紐づいています。未経験者を教える時間は、その担当者の作業時間を削ります。教育の時間が評価に反映される仕組みがない組織ほど、教える側の負担感が強くなります。

これは未経験者の問題ではなく、組織の設計の問題です。面接で「教育担当の方の評価に、育成は反映されますか」と聞くと、その組織が育成をどう位置づけているかが見えます。

2. 同じ質問が繰り返される

一度説明したことを再度聞かれると、教える側の負担は倍になります。悪気がなくても、記録を取っていないと必ずこうなります。

3. 何が分からないかを説明できない

「動きません」「エラーが出ました」だけでは、聞かれた側は状況の把握から始めることになります。これが積み重なると「聞き方が雑」という印象になります。

4. 期待値がずれている

未経験入社の人が「教えてもらえるのが当然」という前提でいると、現場の「自分で調べてから聞いてほしい」という前提とぶつかります。どちらが正しいという話ではなく、すり合わせがされていないだけです。

裏を返せば、これらを避ければ「うざい」と思われる要素はほぼなくなります。具体策は後述します。

職種別：「やめとけ」の中身は全部違う

同じ「未経験でやめとけ」でも、指している問題は職種ごとに異なります。ここを混同すると、自分に当てはまるかどうかの判断ができません。

Webデザイナーの「やめとけ」

主に挙げられるのは次の3点です。

• 単価の下落：制作ツールの進化と参入者の増加により、単純な制作の単価が下がっています
• 求められる範囲の拡大：デザインだけでなく、コーディング、さらにマーケティングの理解まで求められる求人が増えています
• 範囲が広がっても報酬が連動しない：これが不満の中心です

確認すべきこと：求人票で担当範囲がどこまでかを見る。「デザインからコーディングまで」と書かれている場合、実質的に2職種分の仕事です。それが報酬に見合うかを判断してください。

逆に、デザインに専念できるポジションや、上流の設計に関わるポジションでは、この問題は当てはまりません。職種ではなく、求人ごとの担当範囲で判断すべきです。

社内SEの「やめとけ」

社内SEは、事業会社の情報システム部門で自社のシステムを担当する職種です。指摘される問題は次のとおりです。

• 雑務が多い：パソコンの設定、アカウント管理、問い合わせ対応など、技術以外の作業が一定割合を占めます
• 開発の機会が少ない：開発は外部に委託し、社内SEは要件定義と管理を担う体制が一般的です
• 技術的な成長が止まりやすい：上記の結果として、実装のスキルが積み上がりにくくなります

ただし、これは目的によっては欠点になりません。業務改善に関心がある人、開発職への転職が難しい年代の人にとって、社内SEは現実的で価値のある選択肢です。前職の業務知識をそのまま活かせる点も強みです。

確認すべきこと：「開発と運用・問い合わせ対応の比率」を面接で聞く。ここが明確に答えられる組織は、役割を整理できています。

フロントエンドエンジニアの「未経験は無理」

「無理」と言われる理由は、求められる技術の範囲が広がったことです。かつては画面を作るだけでしたが、現在は設計、状態の管理、性能の最適化まで含まれる求人が増えました。

一方で、フロントエンドは成果物が目に見えるため、未経験者が実力を示しやすい領域でもあります。自分で作ったものを見せられるかどうかで、評価が大きく変わります。

インフラエンジニアの「やめとけ」

この職種については、統計と評判が真逆を示すという特殊な状況があります。詳細はインフラエンジニアは「やめとけ」なのかで、厚生労働省の統計を根拠に検証しています。

共通する構造：「職種」ではなく「入口のポジション」の話

ここまでを整理すると、共通点が見えます。

職種	「やめとけ」が指しているもの	確認すべきこと
Webデザイナー	担当範囲の拡大と報酬の乖離	求人ごとの担当範囲
社内SE	雑務の比率と開発機会の少なさ	開発と運用の比率
フロントエンド	求められる技術範囲の広さ	成果物で示せるか
インフラ	入口の運用・監視の働き方	入口が運用か構築か

いずれも職種そのものが悪いのではなく、特定の求人・特定のポジションが問題になっているという構造です。したがって判断すべきは「この職種をやめるか」ではなく、「この求人が自分に合うか」です。

求人票の読み方は未経験エンジニアの求人の見分け方、職種全体の比較はエンジニア職種の違い完全整理で扱っています。

入社後に「うざい」と思われないための具体策

ここからが実用的な部分です。技術力ではなく、振る舞いで差がつきます。

1. 質問の形式を固定する

質問するとき、次の4点を必ず添えてください。

• 何をしようとしているか：目的
• 何をしたか：実行した操作やコード
• 何が起きたか：エラーメッセージや実際の挙動
• 何を試したか：自分で調べた範囲と、その結果

この形式で聞かれると、答える側は状況把握の時間が不要になります。同じ質問でも、聞き方だけで相手の負担が半分以下になります。

2. 時間を区切って聞く

「30分考えて進まなければ聞く」というルールを自分で決め、それを周囲にも伝えておいてください。聞かずに半日溶かすのも、すぐ聞くのも、どちらも評価されません。基準を明示している人は、判断を委ねられている感覚を与えません。

3. 教わったことを記録し、二度聞かない

最も効果があります。教えた側が「前にも言ったな」と感じる瞬間が、心証を最も下げます。逆に、記録して二度聞かない人は、それだけで信頼されます。

4. 相手の時間を奪っている自覚を示す

「お時間よろしいですか」の一言があるかどうかで、印象が変わります。形式的なようですが、相手の作業を中断させているという認識の有無が伝わります。

5. できることを先に引き受ける

テストの実行、ドキュメントの更新、環境の確認。技術力がなくてもできる作業は必ずあります。教わるだけの存在から、少しでも負担を減らす存在に変わると、関係が変わります。

6. 成長の兆候を見せる

先週教わったことを今週使えている。同じ種類のエラーを自力で解決した。こうした変化が見えると、教える側は「投資が回収されている」と感じます。逆に変化が見えないと、負担だけが残ります。

入社1年目に起きることを時系列で知っておく

不安の多くは「何が起きるか分からない」ことから来ます。典型的な流れを示します。

1〜3か月目：何も分からない時期

専門用語、社内の略語、システムの全体像。すべてが不明な状態です。この時期は分からないのが当然で、周囲もそう思っています。焦る必要はありません。

やるべきことは、聞いたことを記録することだけです。用語集を自分で作ると、3か月後に効いてきます。

4〜6か月目：最も心が折れやすい時期

基本的なことは分かってきたが、自分で何かを完結させることができない。周囲との差を最も感じる時期です。「向いていないのでは」と考え始めるのもここです。

この段階での対処は、比較対象を他人ではなく3か月前の自分にすることです。記録を取っていれば、確実に進んでいることが見えます。

7〜12か月目：小さく任される時期

限定された範囲の作業を任されるようになります。ここで初めて「役に立っている」という感覚が生まれます。同時に、任された責任の重さも感じ始めます。

1年経った時点で得られるもの

最も大きいのは、職務経歴に書ける実務経験です。この時点で「未経験」ではなくなり、2回目の転職では選択肢が大きく広がります。最初の会社が合わなかったとしても、1年は区切りとして意味があります。

教える側は何を見ているか

立場を変えて考えると、対処すべきことが明確になります。教育を担当する側が気にしているのは、次の3点です。

1. 投資が回収されるか

教えた時間が、将来その人の戦力化として返ってくるか。成長の兆候が見えるかどうかが、この判断に直結します。先週教わったことを今週使えているか。それだけで印象が変わります。

2. 自走できるようになるか

いつまでも同じ密度で教え続けることはできません。調べ方、詰まったときの切り分け方を身につけているかを見ています。答えを教えるのではなく調べ方を教えようとする人がいたら、それは見捨てられているのではなく、自走してほしいという意図です。

3. チームに悪影響がないか

納期に影響が出ていないか、他のメンバーの時間を過度に奪っていないか。ここは組織の問題でもありますが、本人が配慮を示すかどうかで受け取られ方が変わります。

「聞ける人がいない」場合の対処

最も深刻なのがこの状況です。客先に一人で常駐している、教育担当が不在、質問できる雰囲気がない。個人の努力では限界があります。

できること

• 社外に聞ける場所を作る：学習コミュニティなど、無料で質問できる場を確保しておきます
• 記録を残す：自分で解決した過程を書き残すと、同種の問題に速く対処できます
• 上長に状況を伝える：「質問できる相手がいない」は、感情ではなく事実として報告できます
• 期限を決める：半年経って状況が変わらないなら、環境を変える判断をします

独学状態でのつまずき方と対処はプログラミング独学で挫折する原因と対策にまとめています。

入社前に見分ける方法

入ってから気づくより、面接で確認するほうが確実です。次の質問が有効です。

• 「未経験で入社された方は、現在何名いらっしゃいますか」：実績の有無が分かります
• 「教育担当は決まっていますか」：仕組みがあるかどうか
• 「育成は担当者の評価に反映されますか」：教える側の負担構造が見えます
• 「未経験の方が最初につまずくのはどんなところですか」：具体的に答えられれば、育てた経験があります
• 「入社1年目は具体的に何を担当しますか」：配属後の実態
• 「配属先はいつ決まりますか」：入社時点で未定なら、希望が通るとは限りません

4番目が特に効きます。「特にありません」という回答は、未経験者を育てた経験がない可能性を示します。

それでも合わないと感じたら

上記を実践しても、環境そのものに問題がある場合があります。次のような状況は、個人の努力では解決しません。

• 質問できる相手が物理的にいない：一人で客先に常駐している、教育担当が決まっていない
• 質問すること自体が咎められる：育成の体制が存在しない組織です
• 未経験入社者が定着していない：構造的な問題がある可能性が高い

この場合、実務経験を1年積んでから次を考えるのが現実的です。1年あれば「未経験」ではなくなり、2回目の転職では選択肢が大きく広がります。

学習面での「無理・きつい」についてはプログラミング未経験は「無理」「きつい」のか、年代別の戦略は社会人からプログラミングは遅い？で扱っています。

年代によって変わること

「30代 未経験 エンジニア 無理」「webデザイナー 未経験 30代 無理」といった検索も多くあります。年代で変わるのは能力ではなく、求められ方です。

• 20代：ポテンシャル採用の枠があり、教わる立場でいることが自然に受け入れられます
• 30代：前職の経験との掛け合わせを求められます。「教わるだけの人」という位置づけだと居心地が悪くなりやすい年代でもあります
• 40代以降：技術以外で貢献できる領域（業務知識、調整、後進の育成）を早い段階で示すことが重要になります

年代が上がるほど、「教わる」と「貢献する」を並行させる必要が出てきます。前職の経験が活きる場面を自分から見つけにいく姿勢が、周囲の見方を変えます。

よくある質問

未経験だと本当に嫌われますか

未経験であること自体で嫌われることはありません。負担に感じられるのは、聞き方が雑、同じことを繰り返し聞く、成長が見えない、といった具体的な振る舞いです。いずれも改善できます。

質問しすぎるとダメですか

回数より聞き方です。整理された質問なら、頻度が高くても負担は小さくなります。逆に整理されていない質問は、1回でも負担が大きくなります。

調べても分からないときはどうすればいいですか

時間を区切って聞いてください。「30分調べて、○○と△△を試しましたが解決しませんでした」と伝えれば、丸投げとは受け取られません。

社内SEは本当に成長できませんか

開発スキルは積み上がりにくいのが実情です。ただし業務改善や要件定義の経験は積めます。何を成長と定義するかで評価が変わります。

Webデザイナーは本当に単価が下がっていますか

単純な制作の単価は下がる傾向にあります。一方、設計や戦略まで担当できる人材の需要は残っています。範囲を広げるか、上流に進むかで状況が変わります。

まとめ

「未経験はうざい」と言われる背景にあるのは、教える時間が評価されない組織構造と、質問の仕方・期待値のずれです。いずれも個人の振る舞いで大きく改善できます。

職種別の「やめとけ」は、それぞれ指している問題が違います。Webデザイナーは担当範囲と報酬の乖離、社内SEは雑務の比率、フロントエンドは技術範囲の広さ、インフラは入口のポジション。職種ではなく、応募する求人ごとに判断してください。

そして入社後に効くのは技術力より、質問の形式を固定すること、時間を区切ること、二度聞かないこと。この3つだけで、現場での立ち位置は大きく変わります。