ITエンジニアの種類を一覧にまとめてみた｜未経験におすすめの職種は？

◆はじめに｜未経験からエンジニアを目指すなら、まず「職種選び」で迷わないことが大切

この章では、未経験者がエンジニア職種を一覧で見る前に、どこを基準に読めば迷いにくいかを整理します。
Webエンジニア、インフラエンジニア、テストエンジニア……名前だけ見ると似ていて、最初は本当にややこしいですよね。

・「エンジニア 未経験 種類 一覧」と検索する人が知りたいこと

「エンジニア 未経験 種類 一覧」と検索している人が本当に知りたいのは、職種名を覚えることではありません。
知りたいのは、「自分が未経験で入社したら、最初にどんな仕事を任されるのか」ではないでしょうか。

それは、職種名だけでは実務の粒度が見えにくいからです。
同じITエンジニアでも、画面を作る仕事、サーバーを管理する仕事、テスト項目を確認する仕事、社内の問い合わせに対応する仕事では、1日の動き方も、必要なスキルも、向いている人のタイプも大きく変わります。

厚生労働省の職業情報提供サイト job tag でも、職業ごとに仕事内容、タスク、必要な知識・スキル、関連資格などを確認できるようになっています。
職種は「名前」ではなく、タスクの集まりとして見るほうが、未経験者には判断しやすいんですよね。
※参考: https://shigoto.mhlw.go.jp/User/

私自身も最初は、エンジニアといえば「プログラマー」であり、「コードを書く仕事」くらいの粒度で見ていました。
ところが現場を知るほど、設計書（作る機能や処理の流れを書いた資料）を読む、テスト結果を残す、別チームに確認する、といった細かい作業まで含めて仕事が成り立っているとわかりました。

なので、この一覧記事では「Webエンジニアとは何か」だけで終わらせません。
初期業務、使うツール、伸ばせるスキルまで一緒に見ていくと、職種名のラベルに振り回されにくくなります。

・この記事では転職ノウハウではなく「自分に合う職種の選び方」に絞って解説

この記事では、履歴書の書き方や面接対策よりも、自分に合う職種をどう見分けるかに絞って解説します。
転職活動の細かいテクニックより先に目指す方向がズレていると、学習内容も求人選びも噛み合いません。

というのも、未経験者の最初の迷いが「採用されるか」より前に、「そもそも何を目指せばいいのか」で止まりやすい点にあります。
JavaScriptを学ぶのか、Linux（サーバーでよく使われるOS）を触るのか、SQL（データベースから情報を取り出す言語）を覚えるのかで、最初の3ヵ月の過ごし方は変わるんです。

ここでは、判断軸を5つに分けます。

判断軸	見るポイント
仕事内容	何を作る、守る、確認する仕事か
初期業務	入社後すぐに任されやすい作業は何か
学習内容	HTML/CSS、Java、Linux、AWSなど何を触るか
働き方	リモート、夜勤、問い合わせ対応との相性
将来ルート	1年後、3年後にどの職種へ広げられるか

たとえば「人と話すのが苦手だから、黙々とコードだけ書きたい」と考えてWeb系を選ぶと、要件確認（作るものの条件を整理すること）やコードレビュー（他の人がコードを確認する作業）で戸惑うかもしれません。
逆に、会話が苦ではない人なら、ヘルプデスクや社内SEからITの現場感をつかむルートも候補に入ります。

この章から先は、「おすすめ職種ランキング」を読む感覚ではなく、自分の希望条件を作業レベルに翻訳する感覚で読んでみてください。
職種名よりも、最初に任される作業が「画面作成」なのか「アラート確認」なのか「テスト実行」なのかを見ると、判断が一段具体的になります。

・未経験者は“入りやすさ”だけで選ぶと後悔しやすい

未経験者が職種を選ぶとき、“入りやすさ”だけで決めると、入社後に「思っていた経験が積めない」と感じやすくなります。
入口の広さと、そこで増えるスキルは別物なんですよね。

なぜなら、同じ「未経験歓迎」でも、配属後の作業がまったく違うためです。
テスト実行で仕様理解を深める現場もあれば、監視画面を見てアラートを一次対応する現場、PCの初期設定やアカウント発行を中心に回す現場も出てきます。

たとえば、次のようなズレです。

• コードを書きたいのに、手順書どおりの確認作業が中心になる
• インフラを学びたいのに、問い合わせの一次受付ばかりになる
• リモート希望なのに、端末設定のため出社が多くなる
• AI系を目指したいのに、Excel集計だけで技術範囲が広がらない

もちろん、入口業務そのものが悪いわけではありません。
テスト実行から仕様書の読み方を覚える人もいますし、ヘルプデスクでユーザーの困りごとを聞く経験が、社内SEの強みになることもあります。
でも、その入口から次にどこへ進めるかが見えないまま選ぶと、後から進路変更がしんどくなりやすいです。

求人を見るときは、職種名より先に「入社後3ヵ月で何をするか」「半年後に触れる技術は何か」「1年後に担当範囲は広がるか」を確認してみてください。
この3点が見えると、“入りやすい職種”と“自分の経験が積み上がる職種”を分けて考えやすくなります。

まずはここまでで、職種一覧を読むための地図を用意しました。
次の章では、未経験者が最初の候補に入れやすい職種を、入口業務とセットで見ていきます。

◆1. 未経験者が最初に選びやすいおすすめの職種

この章では、未経験者が最初の候補にしやすい職種を、希望条件ごとに整理します。
「早くIT業界に入りたい」「コードを書きたい」「安定して働きたい」など、入口の決め方は人によって違いますよね。

・早くIT業界に入りたいなら、まず候補に入れたい3つの仕事

早くIT業界に入りたい人は、最初から職種名のかっこよさで選ぶより、未経験者でも担当範囲が切り出されやすい仕事を見るほうが現実的です。
候補にしやすいのは、ヘルプデスク、テスト・QA補助、運用監視の3つです。

そう言えるのは、どれも最初の作業が比較的見えやすいからです。
ヘルプデスクなら問い合わせ対応やPC設定、テスト・QA補助ならテスト項目の実行、運用監視ならアラート確認や手順書対応から始まることがあります。
いきなり大きな設計を任されるより、作業の入口が小さく切られているんですよね。

たとえば、ヘルプデスクでは「ログインできない」「プリンターにつながらない」「アカウントを発行してほしい」といった相談に対応します。
テスト・QA補助では、仕様書（システムの動きや条件を書いた資料）を見ながら、画面操作、入力チェック、不具合の記録を行います。
運用監視では、監視ツール（システムの異常を知らせる仕組み）で通知を確認し、決められた連絡先へエスカレーション（上位担当者へ引き継ぐこと）する流れもあります。

ただし、早く入れる可能性がある仕事ほど、次の移動先をセットで見たいところです。
「問い合わせ対応だけで終わるのか」「テスト設計まで広がるのか」「監視から構築へ進めるのか」で、1年後の経験値はかなり変わります。
求人票では、職種名よりも研修後の配属先、最初の3ヵ月の作業、半年後に触れるツール名を見てみてください。

・プログラミングをしたい人は、開発系の中でも何を選ぶべき？

プログラミングを仕事にしたい人は、開発系をひとまとめにせず、「画面を作りたいのか」「裏側の処理を作りたいのか」「業務システムを直したいのか」で分けると選びやすいです。
同じコードを書く仕事でも、使う言語、読む資料、関わる人が変わります。

それは、開発系の中にも入口がいくつかあるからです。
Webの見た目を作るならHTML/CSS、JavaScript、Reactなどに触れやすくなります。
ログイン処理やデータ登録を作るなら、PHP、Java、Python、SQL（データベースを操作する言語）などの理解が必要になる場面が出てきます。

私自身、仕事でコーディングを始めた頃は、うまくいかないことが多くて、教育係の先輩に何度も質問していました。
エラー文を見ても、どこを直せばよいのかすぐには分からないんです。
そのたびに、自分で調べた内容、試した修正、表示されたエラーを整理してから聞くようにしていました。

未経験から開発系を狙うなら、最初に作る成果物も職種に合わせたほうが話しやすいです。
フロントエンド寄りなら、入力フォーム、検索、スマホ表示の調整。
バックエンド寄りなら、ログイン、投稿、編集、削除、データ保存。
業務アプリ寄りなら、一覧表、CSV出力、権限ごとの画面表示などが説明材料になります。

「コードを書きたい」だけだと、求人の前で迷いやすくなります。
まずは3社分の求人で、使用言語、担当工程、最初に任される改修内容を見比べてください。
JavaScriptだけを学ぶのか、JavaやPHPも候補に入れるのかが、そこでけっこう見えてきます。

・安定した需要を狙うなら、インフラ系が候補になる理由

安定した需要を重視する人は、インフラ系を候補に入れておくと判断の幅が広がります。
インフラ系は、サーバー、ネットワーク、クラウド（インターネット経由でサーバーなどを使う仕組み）など、ITサービスの土台を扱う仕事です。

というのも、サービスを作る会社だけでなく、使う会社にも土台を支える仕事が必要になるからです。
Webサイト、社内システム、ECサイト、予約システム、勤怠管理ツールなどは、裏側でサーバーやネットワークが動いています。
画面がきれいでも、土台が止まればユーザーは何もできません。

IPAの「DX動向2025」でも、DXを推進する人材について、量・質の充足状況、人材獲得や育成の課題が扱われています。
企業がデジタル化を進めるほど、アプリを作る人だけではなく、システムを動かし続ける人の役割も見えやすくなるんです。
※参考: https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html

未経験からインフラ系を見るなら、いきなりクラウドエンジニアだけを狙うより、運用、監視、保守、構築補助まで含めて見るほうが現実的です。
Linux（サーバーでよく使われるOS）、TCP/IP（通信の基本ルール）、DNS（ドメイン名をIPアドレスに変換する仕組み）、AWSなどを少しずつ触る流れになります。

とはいえ、インフラ系は働き方の確認も欠かせません。
障害対応、夜勤、シフト勤務、休日対応がある現場もあります。
安定需要だけで見るのではなく、勤務時間、監視だけで終わらないか、構築やクラウドへ進む機会があるかまで確認すると、入社後のギャップを減らせます。

・年収アップを目指すなら、将来伸ばしやすい分野を見よう

年収アップを狙うなら、最初の入りやすさよりも、2年後・3年後に説明できる技術経験が増える職種を見たいところです。
入社時の給与だけで判断すると、あとから「作業は慣れたけれど、評価される材料が増えていない」と感じることがあります。

なぜなら、エンジニアの評価が、単なる作業量だけではなく、任せられる範囲で変わりやすいからです。
決められた手順をこなすだけの状態から、原因調査、設計、改善提案、自動化、レビューまで広がると、職務経歴書に書ける内容が変わります。

たとえば、同じテスト系でも、テスト実行だけなら入口の経験です。
そこからテスト設計（何をどう確認するかを組み立てる作業）、不具合分析、自動テスト（プログラムでテストを自動化する仕組み）に進めると、QAエンジニアとして説明しやすくなります。
インフラ系なら、監視からログ調査、手順改善、クラウド構築補助へ広げたいですね。

開発系で年収を伸ばしたい人は、言語名だけでなく、担当工程を見てください。
画面修正だけなのか、詳細設計、データベース設計、API（システム同士をつなぐ窓口）の実装まで触れるのかで、3年後の見え方は変わります。
副業やフリーランスを視野に入れるなら、Web制作だけでなく、保守、改修、要件整理まで経験できると案件の幅も広がります。

最初の1年は、派手な肩書きよりも「何を任されるようになったか」を記録しておくと後で効きます。
チケット管理ツール、GitHub、設計書、障害報告書、テストケースなど、実際に触ったものをメモしておく。
職種名より、積み上がる証拠を残せる現場かどうかを見てみてください。

・リモートワークを狙いやすい職種と、実は難しい職種の違い

リモートワークを狙うなら、職種名よりも「作業がオンラインで完結するか」を見るほうが正確です。
Webエンジニアだから必ず在宅、ヘルプデスクだから必ず出社、というほど単純ではありません。

そう言えるのは、リモートのしやすさが、成果物、セキュリティ、端末作業、顧客対応の有無で変わるからです。
コード、設計書、テスト結果、チケット（作業依頼を管理する単位）がクラウド上で完結する仕事は、リモートと相性がよい傾向があります。
一方で、PCの初期設定、社内ネットワーク機器の確認、顧客先での機器交換がある仕事は、出社や現地対応が入りやすいです。

リモートと相性を見やすい仕事を挙げるなら、Web開発、バックエンド開発、クラウド運用、QAの一部、データ集計・分析補助などがあります。
ただし、未経験のうちは教育、質問、レビューのために出社を求められるケースも珍しくありません。
最初の数ヵ月だけ出社し、その後に週2〜3日在宅へ移る現場もあります。

逆に、端末キッティング（PCの初期設定）、社内ヘルプデスク、ネットワーク機器の設置、オンサイト保守（現地での保守対応）は、完全リモートだけを前提にすると候補が狭くなります。
「リモート可」と書かれていても、実際には月数回の出社、障害時の現地対応、研修期間中の出社が含まれることもありますよ。

リモートを重視するなら、求人票では勤務地よりも作業場所の条件を見てください。
確認したいのは、研修期間の出社有無、週の出社日数、使用ツール、チームの連絡方法、端末作業の有無です。
希望条件を満たす職種だけでなく、その職種の中でリモートに向く作業を選ぶ感覚が必要になります。

ここまで見ると、未経験者が最初に選びやすい職種は、希望条件によって変わるとわかります。
次の章では、エンジニア職種をもう少し広く6分類に分けて、全体像から整理していきます。

◆2. エンジニア職種の全体マップ｜未経験者はまず6分類で理解しよう

この章では、エンジニア職種を「開発系」「インフラ系」「品質保証系」「サポート・社内IT系」「データ・AI系」「上流・マネジメント系」の6つに分けて見ていきます。
名前を全部覚えるより、どの場所を担当する仕事なのかをつかむほうが迷いにくいです。
職種一覧を見て頭がごちゃっとしているなら、まずはこの地図から一緒に整理してみましょう。

・開発系｜Webサービス・アプリ・システムを作る仕事

開発系は、Webサービス、スマホアプリ、業務システムなどを作る側の仕事です。
未経験者が「エンジニア」と聞いて最初に想像しやすいのも、この開発系ではないでしょうか。

それは、成果物が目に見えやすいからです。
ログイン画面、検索機能、予約フォーム、管理画面、決済処理など、ユーザーが直接触る機能に関わることが多いんですよね。
ただし、開発系といっても、画面を作る人、裏側の処理を書く人、業務アプリを直す人では、毎日の作業が変わります。

たとえば、WebサービスならHTML/CSS、JavaScript、React（画面を作るためのライブラリ）に触れることがあります。
業務システムならJava、PHP、C#、SQL（データベースを操作する言語）を使い、既存機能の修正やデータ登録処理を担当するケースもあります。
ゲーム感覚で新機能をポンポン作るというより、既存の仕組みに合わせて慎重に直す作業も多いです。

開発系を見るときは、「どの言語を使うか」だけで判断しないほうが安全です。
求人では、画面、API（システム同士をつなぐ窓口）、データベース、テスト、レビューのどこまで触るのかを見てください。
同じ開発系でも、触れる範囲で3ヵ月後の学び方が変わります。

・インフラ系｜サーバー・ネットワーク・クラウドを支える仕事

インフラ系は、システムが動くための土台を支える仕事です。
画面を作るというより、サーバー、ネットワーク、クラウド、セキュリティ設定など、サービスの裏側を整える役割ですね。

どんなアプリやWebサービスも、動かす場所がなければ使えません。
サーバー（システムを動かすコンピューター）、ネットワーク（通信の通り道）、クラウド（インターネット経由でサーバーなどを使う仕組み）が止まると、利用者はログインも注文もできなくなります。
目立ちにくいですが、止まると一気に存在感が出る分野なんです。

具体的には、Linuxの基本操作、ネットワーク疎通確認、ログ確認、バックアップ、アラート対応、AWSやAzureの管理画面確認などがあります。
未経験者の場合、最初は監視、運用、手順書に沿った確認から入り、少しずつ設定変更や構築補助に近づく流れもあります。
黒い画面をずっと眺める仕事、というより、異常を見つけて原因の場所を切り分ける仕事に近いです。

IPAの試験区分一覧でも、ネットワークスペシャリスト、データベーススペシャリスト、情報処理安全確保支援士、ITサービスマネージャなど、技術領域ごとの区分が用意されています。
エンジニア職種を1つの塊ではなく、分野ごとに分けて見る視点は、学習順を決めるときにも役立ちます。
※参考: https://www.ipa.go.jp/shiken/kubun/list.html

インフラ系を候補に入れるなら、勤務形態もセットで見てください。
夜勤やシフトがある現場もあれば、クラウド運用中心で日勤の現場もあります。
職種名だけではなく、監視、運用、構築、クラウド、セキュリティのどこに近い仕事なのかを見ると判断しやすくなります。

・品質保証系｜テストやQAで不具合を防ぐ仕事

品質保証系は、システムやアプリが想定どおりに動くかを確認し、不具合を見つけて品質を守る仕事です。
「テストするだけ」と見られがちですが、実際には仕様理解、観察力、記録の正確さが問われます。

不具合の見つけ方ひとつで、開発チームの動きやすさが変わってくるんです。
「動きません」だけでは原因を追いにくいですが、「iPhoneでログイン後、検索ボタンを2回押すとエラーになる」まで書けると、修正担当者が再現しやすくなります。
テストは地味に見えて、開発工程を横から理解できる入口でもあるんですよね。

具体的には、テストケース（確認する手順をまとめたもの）に沿って画面を操作し、期待どおりの結果になるかを見ます。
不具合を見つけたら、発生条件、操作手順、画面キャプチャ、ログ、再現率などを残します。
QA（品質保証）寄りになると、テスト計画、品質基準、リリース前の判断にも関わることがあります。

未経験者が品質保証系を見るなら、テスト実行だけで終わるのか、テスト設計や自動テストまで広がるのかを確認してみてください。
自動テストでは、SeleniumやPlaywright（画面操作を自動化するツール）を使う現場もあります。
開発職へ近づきたい人にとっても、仕様書、画面、データ、エラーの関係を学べる職種です。

・サポート・社内IT系｜社内や顧客のITトラブルを解決する仕事

サポート・社内IT系は、社内の人や顧客がITを使うときの困りごとを解決する仕事です。
ユーザーに近い場所で働くため、技術だけでなく、相手の状況を聞き取る力も必要になります。

理由は、問い合わせの裏にある本当の原因が、言葉だけでは見えにくいからです。
「メールが使えない」と言われても、パスワード忘れ、通信不良、アカウント停止、メールソフトの設定ミスなど、原因は複数あります。
相手がITに詳しくない場合、こちらが質問を分解していく必要が出てくるんです。

具体的には、ヘルプデスクなら問い合わせ対応、PCの初期設定、アカウント発行、パスワード再設定、プリンターやネットワークの確認などがあります。
社内ITや社内SE寄りになると、SaaS（インターネット経由で使う業務ソフト）、資産管理、セキュリティ設定、社内システムの改修依頼の整理まで関わることもあります。
人と話す場面が多いぶん、感謝の言葉が返ってきやすい仕事でもありますよ。

ただ、サポート系を選ぶときは、対応範囲を必ず見てください。
一次受付だけなのか、原因調査まで任されるのか、社内システムの改善にも関われるのかで、身につく経験が変わります。
電話対応だけが多い現場なのか、チケット管理ツールや手順書改善まで触れる現場なのかも見たいところです。

未経験者にとっては、IT用語を現場の言葉に変換する練習になります。
将来、社内SEやインフラ系に進みたい人は、端末、アカウント、ネットワーク、業務システムのどれに多く触れる仕事かを確認してみてください。

・データ・AI系｜データ分析や機械学習を扱う専門領域

データ・AI系は、データを集め、整え、分析し、意思決定や自動化に活かす専門領域です。
AIという言葉だけを見ると派手ですが、実務では分析前の準備がかなり大きな割合を占めます。

なぜなら、AIや分析モデルが、きれいなデータなしではうまく動かないからです。
売上データ、顧客データ、アクセスログ、問い合わせ履歴などは、そのまま使える形で置かれているとは限りません。
表記ゆれ、欠損値（値が入っていない状態）、重複、古い項目を直してから、ようやく分析に入れることもあります。

具体的には、Excel、SQL、Python、BIツール（データをグラフや表で見やすくするツール）を使う場面があります。
データエンジニア寄りなら、データ基盤（データを集めて保管・加工する仕組み）を作る仕事に近づきます。
データサイエンティスト寄りなら、統計、仮説検証、機械学習（データからパターンを学ばせる技術）の理解も必要です。

未経験からいきなりAIモデルを作る仕事だけを狙うと、求人との距離を感じるかもしれません。
最初は、データ集計、SQLでの抽出、ダッシュボード作成、レポート更新から入るルートも見ておくと現実味が出ます。
「AIを作る人」だけでなく、「AIや分析に使えるデータを整える人」も候補に入れてみてください。

・上流・マネジメント系｜設計・管理・提案に関わるキャリア

上流・マネジメント系は、作る前の整理や、作っている途中の進行管理に関わる仕事です。
未経験から最初に担当する職種というより、開発、インフラ、サポートなどの経験を積んだ先で見えてくるキャリアとして考えると自然です。

というのも、上流工程では「何を作るか」「誰がいつまでに進めるか」「どこにリスクがあるか」を整理する場面が増えるからです。
要件定義（必要な機能や条件を決める作業）、基本設計、詳細設計、進捗管理、課題管理、顧客への説明など、コードを書く以外の時間も多くなります。
技術を知らなくてよい仕事ではなく、技術を前提に人と情報をつなぐ仕事なんですよね。

私の経験でも、同じプロジェクト内に複数のチームがあり、別チームとの打ち合わせが何度もありました。
海外メンバーと日本語でやりとりする場面もあり、英語が必須というより、相手の意図を確認しながら話を前に進める力が問われました。
「黙々と作る」だけでは済まない場面が、年数を重ねるほど増えていった感覚があります。

具体的な職種としては、システムエンジニア、プロジェクトマネージャ、ITコンサルタント、ブリッジSE、社内SEの企画寄りポジションなどがあります。
未経験の段階では、議事録、仕様整理、テスト観点の整理、問い合わせ内容の分類など、小さな整理業務から近づくケースもあります。

上流・マネジメント系を目指すなら、最初の職種で「説明する経験」が増えるかを見てください。
設計書、議事録、課題表、スケジュール、顧客向け資料に触れる機会があると、あとでキャリアの幅が広がります。
この分類は、今すぐ選ぶ職種というより、2年後・3年後にどちらへ広げるかを見るための目印です。

6分類で見ると、エンジニア職種は「どれが上か」ではなく、担当する場所が違うだけだとわかります。
次の章では、この分類を踏まえて、職種名だけでは見えにくい「最初の仕事」にもう一段踏み込んでいきます。

◆3. 職種名だけで選ぶと危険？未経験者が見るべき「最初の仕事」

この章では、職種名と入社後すぐの作業がズレる理由を、職種別に具体化します。
「開発系ならすぐコードを書けるはず」「AI系なら分析モデルを作るはず」と思っていると、配属後に戸惑いやすいんですよね。
職種一覧を見るときは、肩書きよりも最初の30日〜3ヵ月で何を触るかを見ていきましょう。

・開発系の入口｜いきなり新規開発ではなく、修正・テストから始まることも多い

開発系の入口では、いきなり新規機能を丸ごと任されるより、既存機能の修正、画面表示の調整、テスト確認から始まることがあります。
「コードを書く仕事」と聞くと、白紙のファイルに新しい機能を作る場面を想像しがちですが、現場では既に動いている仕組みを壊さず直す作業も多いです。

それは、業務システムやWebサービスには、既存の設計、命名ルール、データベース、レビュー手順があるからです。
未経験者が最初から全体構造を把握するのは相当むずかしいので、ボタンの文言修正、入力チェックの追加、一覧画面の項目追加など、小さな変更から慣れる流れになりやすいんですよね。

私自身も、配属後すぐに開発だけを任されたわけではなく、2ヵ月ほどテスト業務を担当してから、コーディングや設計へ少しずつ広がっていきました。
当時は「早くコードを書きたい」と思っていましたが、テストで画面の動きや仕様書の読み方を知ったことで、あとから修正作業に入りやすくなった感覚があります。

開発系求人を見るときは、「開発」と書かれているかだけでなく、最初のタスク名を見てください。
チケット対応（作業依頼を小さく管理する単位）、バグ修正、単体テスト（部品ごとの確認）、コードレビュー（他の人がコードを確認する作業）に触れるなら、入口としてはかなり実務に近いです。

・インフラ系の入口｜監視・運用・手順書対応から経験を積むケースがある

インフラ系の入口では、サーバーをいきなり設計・構築するより、監視、運用、手順書対応から始まるケースがあります。
クラウドやセキュリティに興味がある人ほど、最初の作業が地味に見えて不安になるかもしれません。

というのも、インフラの仕事では「止めないこと」が価値になるからです。
設定を1つ間違えると、ログインできない、予約できない、決済できない、といった影響が出ることもあります。
そのため、未経験者はまず、何が正常で、何が異常なのかを見分けるところから入ることが多いんです。

具体的には、監視画面でアラートを確認する、ログ（システムの動作記録）を見る、手順書に沿ってサービスを再起動する、障害発生時に担当者へ連絡する、といった作業があります。
運用監視では、Zabbix、Datadog、CloudWatchなどの監視ツール名が求人や現場資料に出てくることもありますね。

ここで見るべきなのは、監視だけで終わる現場か、運用改善まで触れる現場かです。
たとえば、アラートの一次連絡だけなのか、ログ調査、手順書の修正、AWS設定の確認まで任されるのかで、半年後に話せる経験が変わります。
「インフラ系」とまとめず、監視、運用、保守、構築補助のどこに立つのかを確認してみてください。

・テスト・QA系の入口｜テスト実行・不具合報告で開発工程を理解する

テスト・QA系の入口では、テスト項目を実行し、不具合を記録する作業から始まることが多いです。
地味に見えるかもしれませんが、開発工程の流れを横から学べる入口でもあります。

なぜなら、テストでは仕様書、画面、入力データ、エラー表示、修正後の確認まで一通り見るからです。
コードを書かなくても、「この条件だと動く」「この組み合わせだと壊れる」という目線が育ちます。
この目線は、あとで開発やQA設計へ進むときにも使えるんですよね。

具体的には、ログイン、検索、登録、編集、削除、CSV出力などを、テストケース（確認手順をまとめたもの）に沿って確認します。
不具合を見つけたら、発生した画面、操作手順、期待結果、実際の結果、スクリーンショット、再現率を残します。
「なんか変です」ではなく、修正担当者が同じ現象を再現できる書き方が求められます。

テスト・QA系を見るときは、テスト実行だけなのか、テスト設計、品質分析、自動テストまで広がるのかを見たいところです。
JSTQB（ソフトウェアテストの資格体系）やSelenium、Playwrightといった単語が出てくる求人なら、品質保証の専門性へ伸ばす余地があります。
最初の報告書づくりを雑に扱わず、再現手順をきれいに残せる人は、チーム内で頼られやすいです。

・ヘルプデスク系の入口｜問い合わせ対応や端末設定でIT基礎を固める

ヘルプデスク系の入口では、問い合わせ対応、PC初期設定、アカウント発行、パスワード再設定などを通じてIT基礎を固めます。
「エンジニアなのに電話対応？」と感じる人もいるかもしれませんが、現場のITは人が使って初めて動きます。

なぜなら、トラブルの多くが、技術だけでなく利用状況とセットで起きるからです。
同じ「ログインできない」でも、パスワード期限切れ、権限不足、ネットワーク不調、ブラウザ設定、SaaS（インターネット経由で使う業務ソフト）の障害など、原因は分かれます。
相手の言葉をそのまま受け取るだけでは、原因までたどり着けないんですよね。

具体的には、社内PCのキッティング（初期設定）、Microsoft 365やGoogle Workspaceのアカウント管理、VPN（社外から社内ネットワークへ安全につなぐ仕組み）の接続確認、プリンター設定などがあります。
問い合わせをチケット管理ツールに記録し、対応履歴を残す現場もあります。

ヘルプデスク系を見るなら、一次受付だけで閉じるのか、原因調査や改善提案まで関われるのかを確認してください。
社内SEやインフラ系へ広げたい人は、端末、ネットワーク、アカウント、業務システムのどれに多く触れるかを見ると、次のキャリアが想像しやすくなります。

・データ・AI系の入口｜分析より前に、データ整理や集計を任されることもある

データ・AI系の入口では、いきなり機械学習モデルを作るより、データ整理、集計、抽出、レポート更新から始まることがあります。
AIという言葉の華やかさだけで選ぶと、最初の作業との落差に驚くかもしれません。

理由は、分析やAIの前に、使えるデータを用意する工程があるからです。
表記ゆれ、空欄、重複、日付形式のズレ、古いマスターデータが残ったままでは、きれいなグラフも正しい予測も作れません。
いわば、料理の前に材料を洗って切る段階ですね。ここを飛ばすと、料理などできたものではないです。

具体的には、Excel、SQL、Python、BIツール（データをグラフや表で見える化するツール）を使う場面があります。
Pythonを使う場合でも、最初はpandas（表データを扱うライブラリ）で欠損値を確認したり、列名をそろえたりする作業が中心になることもあります。

総務省の情報通信白書でも、企業活動や社会生活でのデータ活用、デジタル技術の利用が継続して扱われています。
データ・AI系を考えるときは、AIモデルそのものだけでなく、その前段にあるデータ収集・整理・活用の流れまで見ておくと理解しやすいです。
※参考: https://www.soumu.go.jp/johotsusintokei/whitepaper/

未経験者がデータ・AI系を見るなら、「分析」「AI」だけでなく、最初に触るデータ量、使うツール、SQLの有無、レポート更新の頻度を確認してみてください。
分析職に近づく入口なのか、単純なExcel作業で止まりやすい現場なのかは、ここでだいぶ差が出ます。

・「やりたい仕事」と「最初の配属業務」がズレる理由

「やりたい仕事」と「最初の配属業務」がズレるのは、本人の希望だけでなく、現場側の受け入れやすさで最初の作業が決まるからです。
未経験者の場合、会社はまず、リスクが低く、確認しやすく、教えやすい作業から任せることが多いんですよね。

というのも、現場には納期、品質、セキュリティ、顧客対応があるからです。
新機能開発、サーバー設定、AI分析のような仕事は、失敗したときの影響範囲が大きくなりやすいです。
そのため、最初はテスト実行、ログ確認、問い合わせ整理、データ集計など、切り出しやすい作業から始まりやすくなります。

ここで見たいのは、「入口業務そのもの」よりも、その後に広がる導線です。
たとえば、テスト実行からテスト設計へ進めるのか、監視から構築補助へ進めるのか、問い合わせ対応から社内システム改善へ関われるのか。
最初の仕事が地味でも、次の担当範囲が見えていれば、経験として積み上げやすいです。

求人や面談では、次の3つを聞けると判断しやすくなります。
1つ目は、入社後1ヵ月で任される作業。
2つ目は、3ヵ月後に増える担当範囲。
3つ目は、半年後に触れる技術やツールです。

職種名は入口の看板であって、実際に経験になるのは毎日の作業です。
次の章では、開発系の職種をさらに分けて、プログラミングを仕事にしたい人がどの選択肢を見ればよいかを整理していきます。

◆4. 開発系エンジニア6職種｜プログラミングを仕事にしたい人の選択肢

この章では、開発系エンジニアの代表的な6職種を、仕事内容と未経験者が見るべき違いに分けて整理します。
「コードを書く仕事」とひとことで言っても、設計寄り、画面寄り、裏側寄り、アプリ寄りで動き方はかなり変わります。
プログラミングを仕事にしたい人ほど、職種名の響きではなく、どの部分を作るのかを見ていきましょう。

・プログラマー｜コードを書いてシステムを動かす基本ポジション

プログラマーは、設計書や仕様書をもとにコードを書き、システムを実際に動かす役割です。
開発系の中でも「作る作業」に近く、未経験者がプログラミング職をイメージするときの中心に置きやすい職種ですね。

なぜなら、プログラマーの仕事が、処理を具体的な命令に落とし込むところにあるからです。
たとえば「会員登録できるようにする」と言われても、画面入力、入力チェック、データ保存、エラー表示、確認メール送信など、細かい処理に分けて考えます。
その分解をコードにするのが、プログラマーの腕の見せどころなんですよね。

使う言語は現場によって変わります。
Web系ならJavaScript、PHP、Ruby、Python、業務システムならJava、C#、VB.NETなどが出てきます。
最初は1つの言語で変数、条件分岐、繰り返し、関数、クラス（処理やデータをまとめる仕組み）を覚える流れになりやすいです。

私の経験では、1つの言語に慣れると、別の言語も「書き方は違うけれど考え方は似ている」と感じやすくなりました。
もちろん、最初から何でも読めるわけではありません。
でも、条件分岐やデータの受け渡しが見えるようになると、新しい言語を見たときの怖さはだいぶ薄まります。

未経験者がプログラマーを目指すなら、求人では「使用言語」だけでなく、「新規開発」「保守開発」「改修」「テスト」の比率を見てください。
コードを書く仕事でも、既存画面の修正が中心なのか、機能追加まで任されるのかで、3ヵ月後に積める経験が変わります。

・システムエンジニア｜要件定義・設計・開発をつなぐ役割

システムエンジニアは、ユーザーや顧客の要望を整理し、設計、開発、テストへつなぐ役割です。
会社によってはSEと呼ばれ、プログラマーよりも上流工程（作る前に仕様や設計を決める工程）に関わる時間が増えます。

というのも、システム開発では「何を作るか」が曖昧なままだと、後工程でズレが大きくなるからです。
たとえば「検索機能がほしい」と言われても、検索対象、表示順、権限、処理速度、エラー時の表示まで決めないと、開発者は手を動かしにくいんですよね。
SEは、その曖昧な要望を、作れる単位に変換します。

具体的には、要件定義（必要な機能や条件を整理する作業）、基本設計、詳細設計、レビュー、テスト計画、顧客説明などに関わります。
現場によっては、設計だけでなく自分でJavaやC#を書いたり、SQLを確認したりすることもあります。
「話す人」と「作る人」が完全に分かれているとは限りません。

私自身、設計を任された当初は、設計書に何をどこまで書けばよいのか迷いました。
プロジェクトごとのフォーマットに合わせつつ、あとから読む人が処理の流れを追えるかを意識する。
コードより日本語の整理で詰まる日もあり、SEは文章力も使う仕事だと実感しました。

未経験からSE職を見るなら、最初から要件定義だけを任されると思わないほうが現実的です。
まずはテスト、議事録、仕様変更のメモ、簡単な設計書修正から入り、開発工程を覚えながら上流へ近づくケースもあります。
求人では、担当工程が「詳細設計以降」なのか「要件定義から」なのかを見てみてください。

・Webエンジニア｜WebサイトやWebサービスを作る人気職

Webエンジニアは、ブラウザで使うWebサイトやWebサービスを開発する職種です。
未経験者から人気がありますが、実際には画面、裏側の処理、データベース、運用改善まで幅が広い仕事でもあります。

それは、Webサービスがユーザーの操作からデータ保存までを一連の流れで扱うからです。
たとえば、ログイン、商品検索、予約、投稿、決済、マイページ表示などは、画面だけで完結しません。
裏側ではAPI、データベース、セッション（ログイン状態などを管理する仕組み）、セキュリティ対策も動いています。

具体的には、HTML/CSS、JavaScript、TypeScript、PHP、Ruby、Python、Java、SQL、GitHubなどに触れることがあります。
フロントエンド寄りのWebエンジニアもいれば、バックエンド寄りのWebエンジニアもいるため、求人の中身はかなり違います。
「Web」と書いてあるだけで、全部同じ仕事だと思わないほうがよいです。

米国労働統計局の職業情報でも、ソフトウェア開発者はアプリケーションやプログラムを設計・開発し、QAやテスターは問題を見つけて欠陥を報告する職種として整理されています。
また、同職業群の雇用は2024年から2034年にかけて15％増加すると見込まれています。
※参考: https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

未経験者がWebエンジニアを目指すなら、ポートフォリオ（自分で作った成果物）では見た目だけでなく、ログイン、投稿、編集、削除、検索などを1つ入れておくと説明しやすいです。
求人では、SES（客先常駐などで技術支援を行う働き方）・受託開発・自社開発の違いも押さえ、自分が応募する会社がどの働き方に近いか確認してください。

・フロントエンドエンジニア｜画面の見た目や操作性を作り込む仕事

フロントエンドエンジニアは、ユーザーが直接触る画面や操作性を作り込む仕事です。
ボタン、入力フォーム、メニュー、アニメーション、スマホ表示など、目に見える部分を担当します。

Webサービスでは「動く」だけでなく「使いやすい」ことも求められますよね。
同じ検索画面でも、入力欄の位置、エラー文の出し方、読み込み中の表示、スマホでの押しやすさが違うだけで、使う側のストレスは変わります。
見た目を整える仕事に見えて、ユーザーの行動をかなり細かく考える職種なんです。

具体的には、HTML、CSS、JavaScript、TypeScript、React、Vue、Next.jsなどを使う現場があります。
デザイナーが作ったFigma（画面デザインを作るツール）の内容をもとに、ブラウザで動く形へ実装することもあります。
APIから受け取ったデータを画面に表示したり、入力値をバックエンドへ送ったりする作業も出てきます。

未経験者がフロントエンドを狙うなら、ただきれいなページを作るだけでは弱くなりがちです。
入力フォーム、バリデーション（入力内容のチェック）、レスポンシブ対応（画面幅に合わせて表示を変えること）、API連携まで触れると、実務に近い説明がしやすくなります。

求人では、HTML/CSS中心のコーダー寄りなのか、ReactやTypeScriptを使うアプリ開発寄りなのかを確認してみてください。
同じ「フロントエンド」でも、デザイン再現が中心の現場と、状態管理や画面設計まで扱う現場では、学ぶ内容が変わります。

・バックエンドエンジニア｜ログイン・決済・データ処理など裏側を担う仕事

バックエンドエンジニアは、画面の裏側で動く処理やデータの流れを作る仕事です。
ログイン、決済、検索、投稿保存、通知、権限管理など、ユーザーには見えにくい部分を支えます。

というのも、Webサービスやアプリが、画面だけでは成立しないからです。
ユーザーがボタンを押したあと、サーバー側でデータを確認し、必要な処理をして、結果を画面へ返します。
この裏側がうまく動かないと、画面がきれいでもサービスとして使えません。

具体的には、Java、PHP、Ruby、Python、Go、Node.js、SQL、MySQL、PostgreSQL、AWSなどに触れることがあります。
API（システム同士をつなぐ窓口）を作ったり、データベース設計を考えたり、処理速度やセキュリティを見直したりする場面もあります。
地味ですが、サービスの心臓部に近い仕事ですね。

未経験者がバックエンドを学ぶなら、最初は「データがどう流れるか」を意識してみてください。
フォームに入力された内容が、どのURLへ送られ、どのテーブルに保存され、どの条件で取り出されるのか。
ここが見えると、ログイン機能や投稿機能の理解が一気に進みます。

求人では、単なる保守修正だけでなく、API実装、DB設計、性能改善、バッチ処理（決まった時間にまとめて動かす処理）に触れるかを見てください。
バックエンドは学習範囲が広いぶん、経験が積み上がると開発系の中でも説明材料を作りやすい職種です。

・アプリケーションエンジニア｜スマホアプリや業務アプリを開発する仕事

アプリケーションエンジニアは、スマホアプリや業務アプリなど、特定の目的を持つアプリケーションを開発する仕事です。
Webだけに限らず、社内で使う販売管理システム、在庫管理システム、勤怠システムなども対象になります。

なぜなら、企業や利用者の課題に合わせて、使うアプリの形が変わるからです。
スマホアプリなら、iOS、Android、通知、カメラ、位置情報、ストア公開などを考えます。
業務アプリなら、入力画面、承認フロー、帳票出力、CSV連携、権限管理など、仕事の流れに合わせた機能が必要です。

具体的には、スマホアプリではSwift、Kotlin、Flutter、React Nativeなどが使われます。
業務アプリではJava、C#、VB.NET、SQL、クラウド上の開発基盤を使う現場もあります。
ユーザーが毎日使う画面を作るため、細かい入力ミスや操作ミスを想定する力も求められます。

未経験者がアプリケーションエンジニアを目指すなら、「何のアプリを作る仕事か」を具体的に見ると迷いにくいです。
スマホ向けなのか、企業向けの業務システムなのか、既存アプリの改修なのか、新規機能の追加なのか。
同じアプリ開発でも、求められる知識は変わります。

求人では、対象ユーザー、使用言語、担当工程、リリース後の保守有無を見てください。
業務アプリの場合は、プログラミングだけでなく、経理、在庫、販売、勤怠などの業務知識が武器になることもあります。

・開発系に向いている人は？黙々作業だけでは足りない理由

開発系に向いている人は、コードを書く時間が好きなだけでなく、仕様を読み、質問し、直しながら考え続けられる人です。
「黙々と作る仕事」というイメージだけで入ると、レビューや確認の多さに驚くかもしれません。

それは、開発が1人で完結しにくい仕事だからです。
仕様書を書いた人、画面を設計した人、コードを書く人、テストする人、運用する人がつながって、ようやく1つの機能が動きます。
自分の担当だけを見ていると、前後の工程とのズレに気づきにくいんですよね。

向いている人の特徴を挙げるなら、次のようなタイプです。

• エラー文を読んで、原因を1つずつ切り分けられる人
• 分からない点を、調べた内容と一緒に質問できる人
• 画面や処理の細かい違和感に気づける人
• 作ったあとに、もっと読みやすく直すことを嫌がらない人

一方で、「人と話したくないから開発系」という選び方は、少し危ういです。
コードレビュー、仕様確認、進捗報告、障害時の説明など、開発系でも人に伝える場面は普通にあります。
会議が好きである必要はありませんが、確認を避け続けると、手戻りが増えてしんどくなります。

開発系を目指すなら、最初は職種名よりも「どの作業なら続けて調べられそうか」を見てください。
画面を整えるのが好きならフロントエンド、データの流れに興味があるならバックエンド、業務の仕組みを形にしたいならアプリケーションエンジニアが候補になります。
次の章では、開発系とは別軸で、サービスの土台を支えるインフラ系エンジニアを整理していきます。

◆5. インフラ系エンジニア5職種｜安定需要を狙うなら知っておきたい分野

この章では、インフラ系エンジニアを5職種に分けて、担当範囲と未経験者が見落としやすい違いを整理します。
インフラ系は「裏方」という言葉でまとめられがちですが、サーバー、ネットワーク、クラウド、セキュリティでは見る場所が違います。
開発系とは別の角度でITを支える仕事なので、コード以外の技術に興味がある人はここで候補を広げてみてください。

・インフラエンジニア｜ITサービスの土台を支える総合職

インフラエンジニアは、システムやWebサービスが動くための土台を設計・構築・運用する総合職です。
サーバーだけ、ネットワークだけに限定されず、クラウド、監視、バックアップ、障害対応まで横断して関わることがあります。

それは、ITサービスが1つの部品だけでは動かないからです。
アプリケーションが正しく作られていても、サーバーの容量が足りない、通信が不安定、証明書が切れている、監視が抜けているとなれば、利用者には「使えないサービス」に見えてしまいます。
インフラエンジニアは、そうした見えにくい土台をまとめて支える役割なんですよね。

具体的には、Linux（サーバーでよく使われるOS）の操作、ネットワーク設定、ミドルウェア（OSとアプリの間で動くソフト）の導入、監視設定、バックアップ、障害時の一次調査などがあります。
未経験者の場合、最初は手順書に沿った確認、監視アラートの切り分け、サーバー情報の台帳更新から入るケースもあります。
地味に見えますが、土台の構成を知る入口としてはかなり実務に近いです。

インフラエンジニアを見るときは、担当範囲が広いぶん、何でも屋になりすぎないかも確認したいところです。
サーバー寄りなのか、ネットワーク寄りなのか、クラウド運用寄りなのかで、学ぶ内容が変わります。
「インフラ全般」と書かれている場合ほど、入社後3ヵ月で触る機器、OS、クラウド、監視ツールを具体的に見てください。

・サーバーエンジニア｜システムが動く環境を構築・管理する役割

サーバーエンジニアは、アプリケーションやWebサイトを動かすためのサーバー環境を構築・管理する仕事です。
サーバーは、利用者の画面からは見えませんが、ログイン、検索、予約、決済などの処理を受け止める場所になります。

というのも、サービスの安定性がサーバー環境に大きく左右されるからです。
CPU、メモリ、ディスク容量、OS、ミドルウェア、ログ保存、バックアップの設計が合っていないと、アクセスが増えたときに遅くなったり、障害時に復旧しにくくなったりします。
派手さはありませんが、止まった瞬間に一気に注目される分野です。

具体的には、Linux、Windows Server、Apache、Nginx、Tomcat、MySQL、PostgreSQLなどを扱うことがあります。
コマンドでログを確認したり、サービスの起動状態を見たり、パッチ適用（修正プログラムの適用）やバックアップ確認を行ったりします。
オンプレミス（自社やデータセンターに置く物理サーバー）とクラウドの両方に関わる現場もありますね。

未経験者がサーバーエンジニアを目指すなら、まずは「サーバー上で何が動いているか」を見る癖をつけると理解しやすいです。
Webサーバー、アプリケーションサーバー、データベースサーバーの役割が分かると、障害対応の説明も読みやすくなります。
募集要項では、Linuxコマンド、ログ調査、バックアップ、仮想化、クラウド移行の単語があるかを見てみてください。

・ネットワークエンジニア｜通信環境を設計・運用する専門職

ネットワークエンジニアは、システムや端末同士が通信できるように、ネットワーク環境を設計・構築・運用する専門職です。
インターネットにつながる、社内システムにアクセスできる、拠点間で通信できるという当たり前を支えています。

なぜなら、通信経路が止まると、サーバーやアプリが正常でも利用者はサービスに届けないからです。
たとえば、DNS（ドメイン名をIPアドレスに変換する仕組み）、ルーター、スイッチ、ファイアウォール、VPN（安全に社内ネットワークへ接続する仕組み）のどこかで問題が起きると、画面の前では「つながらない」だけに見えます。
原因の場所を切り分ける力が問われる仕事です。

具体的には、IPアドレス、サブネット、VLAN（ネットワークを論理的に分ける仕組み）、ルーティング、ポート番号、通信ログなどを扱います。
未経験者が最初に入る場合は、通信監視、機器の設定確認、構成図の更新、障害時の一次切り分けから始まることがあります。
Cisco、Yamaha、Fortinetなど、機器名が募集要項に出ることもありますよ。

ネットワーク系に向いているのは、「どこまでは通っていて、どこから先が通っていないか」を順番に見られる人です。
ping、traceroute、nslookupといった確認コマンドを使う場面も出てきます。
面談では、夜間作業や現地作業の有無、設計・構築まで進めるのか、運用監視中心なのかを確認しておくと働き方のズレを減らせます。

・クラウドエンジニア｜AWS・Azureなどを扱う将来性の高い分野

クラウドエンジニアは、AWS、Azure、Google Cloudなどのクラウドサービスを使って、インフラを設計・構築・運用する仕事です。
物理サーバーを直接触るというより、管理画面やコードでサーバー、ネットワーク、ストレージ、監視を組み合わせていきます。

そう言えるのは、クラウドでは必要なリソースを素早く増減でき、運用の自動化や標準化もしやすいからです。
一方で、簡単に作れるぶん、権限設定、ネットワーク公開範囲、コスト管理を誤るとリスクも大きくなります。
便利な工具箱ですが、どの工具をどこで使うかを知らないと、逆に散らかるんですよね。

デジタル庁のガバメントクラウドでも、迅速・柔軟・セキュアでコスト効率の高いシステム構築、クラウドサービスのセキュリティや可用性、スケーラビリティの活用が説明されています。
また、令和5年度の調達では、ガバメントクラウドに求める技術要件として305項目が示されています。
クラウドは単に「流行っている技術」ではなく、政府システムの基盤でも具体的な要件とセットで扱われている分野なんです。
※参考: https://www.digital.go.jp/policies/gov_cloud

具体的には、EC2、S3、VPC、IAM、CloudWatch、Azure Virtual Machines、Azure Monitorなどを扱う場面があります。
Terraform（インフラ構成をコードで管理するツール）やCI/CD（テストや反映を自動化する仕組み）に触れる現場もあります。
未経験からいきなり設計担当になるより、クラウド運用、監視、設定変更、構築補助から入るルートを見たほうが現実的です。

クラウドエンジニアを目指すなら、「AWSを勉強する」だけで止めないほうがよいです。
どのサービスを、何のために使うのかまで説明できると、学習が実務に近づきます。
募集要項では、運用中心なのか、構築補助まであるのか、IaC（Infrastructure as Code：インフラ構成をコード化する考え方）に触れるのかを確認してみてください。

・セキュリティエンジニア｜サイバー攻撃や情報漏えいを防ぐ高度職

セキュリティエンジニアは、サイバー攻撃、情報漏えい、不正アクセス、脆弱性（攻撃に悪用される弱点）からシステムや組織を守る仕事です。
インフラ系の中でも専門性が高く、未経験からは段階を踏んで近づくことが多い職種になります。

それは、セキュリティがサーバー、ネットワーク、クラウド、アプリ、運用ルールのすべてに関わるからです。
ファイアウォールを置けば終わりではなく、権限管理、ログ監視、脆弱性診断、パッチ適用、インシデント対応（事故発生時の調査・復旧対応）まで見ます。
技術だけでなく、どの情報を誰が見てよいかという業務理解も必要です。

具体的には、SOC（セキュリティ監視センター）、CSIRT（セキュリティ事故に対応する組織）、脆弱性診断、EDR（端末の不審な動きを検知する仕組み）、SIEM（ログを集めて分析する仕組み）などの領域があります。
未経験者の場合、最初はログ監視、アラート確認、脆弱性情報の整理、手順書に沿った一次対応から入ることもあります。
ここでサーバーやネットワークの基礎があると、通知の意味を理解しやすくなります。

セキュリティ職を見るなら、「守る仕事」という言葉だけで選ばず、何を守るのかを分けてください。
端末を守るのか、ネットワークを守るのか、クラウド設定を監査するのか、Webアプリの脆弱性を見るのかで、必要な知識が変わります。
基本情報技術者試験や情報セキュリティマネジメント試験の範囲を触っておくと、用語の地図を作りやすいですよ。

・なぜインフラ系は未経験者の入口になりやすいのか

インフラ系が未経験者の入口になりやすいのは、手順化しやすい作業と、段階的に任せやすい作業があるからです。
いきなり設計や構築を担当するのではなく、監視、運用、確認、記録から経験を積める現場があります。

というのも、インフラ業務には「正常か異常かを見る」「決められた手順で確認する」「変化を記録する」といった切り出しやすい作業が含まれるからです。
もちろん簡単という意味ではありません。
でも、最初の担当範囲を限定しやすいため、未経験者でも現場に入りながら土台の仕組みを学べるケースがあるんです。

具体的には、監視画面のアラート確認、ログの一次確認、バックアップ結果の確認、アカウント申請の処理、手順書の更新、機器構成表の入力などがあります。
最初は単純に見える作業でも、「なぜこのアラートが出るのか」「どのサーバーに影響するのか」まで追うと、サーバー、ネットワーク、クラウドの理解につながります。
ここを流れ作業にするか、仕組みを覚える入口にするかで差が出ます。

私が開発寄りのSEとして働いていても、環境、接続先、権限、ログの見方が分からないと、コード以前のところで手が止まる場面がありました。
インフラ担当者が用意した環境があるから、開発者はアプリを動かせます。
その意味では、インフラ系は裏方というより、開発や運用の足場を作る仕事だと感じています。

未経験からインフラ系を見るなら、最初の作業名だけで判断せず、半年後にどこまで広がるかを見てください。
監視だけで終わるのか、ログ調査、手順改善、構築補助、クラウド設定まで進めるのか。
次の章では、品質保証・サポート系の職種を見ながら、始めやすい仕事ほど将来設計が必要になる理由を整理していきます。

◆6. 品質保証・サポート系5職種｜未経験から始めやすいが、将来設計が重要

この章では、品質保証・サポート系の5職種を、仕事内容と将来の広げ方に分けて整理します。
未経験から入りやすいと言われる仕事ほど、最初の作業だけで判断すると道が細く見えやすいです。
テスト、問い合わせ、社内ITのどこで経験を積むのか、一緒に粒度をそろえて見ていきましょう。

・テストエンジニア｜不具合を見つけて品質を守る仕事

テストエンジニアは、システムやアプリが仕様どおりに動くかを確認し、不具合を見つける仕事です。
「画面をポチポチ触るだけ」と思われがちですが、実際には条件、手順、証跡をそろえて確認する職種なんですよね。

理由は、開発者が直せる形で不具合を伝えないと、品質改善につながりにくいからです。
同じ「ログインできない」でも、ブラウザ、OS、アカウント種別、入力値、操作手順、発生頻度が抜けていると、再現確認に時間がかかります。
テストエンジニアは、ただ失敗を見つける人ではなく、問題を再現できる情報に変換する人です。

具体的には、テストケース（確認する手順と期待結果をまとめたもの）に沿って、ログイン、検索、登録、編集、削除、CSV出力などを確認します。
不具合を見つけたら、実際の結果、期待結果、操作手順、スクリーンショット、ログ、端末情報を残します。
Jira、Redmine、Backlog、TestRailのような管理ツールに記録する現場もありますね。

未経験者がテストエンジニアを見るなら、テスト実行だけなのか、テスト観点づくりまで触れるのかを見てください。
回帰テスト（修正後に別の機能が壊れていないか確認すること）、ブラウザ別確認、スマホ実機確認まで経験できると、開発工程の見え方が変わります。

・QAエンジニア｜テストだけでなく品質改善まで担う仕事

QAエンジニアは、テスト実行だけでなく、開発プロセス全体の品質を上げる仕事です。
テストエンジニアが不具合を見つける役割に近いなら、QAは「なぜ不具合が出たのか」「次に減らすにはどうするか」まで見ます。

というのも、品質は最後のテストだけで作られるものではないからです。
要件が曖昧、設計レビューが浅い、テスト観点が偏っている、リリース判断が急ぎすぎている。
こうした前工程のズレが、あとから不具合として出てくることがあります。

私の経験でも、QAチームは開発者から見ると緊張感のある存在でした。
テストケースの指定に沿って確認し、指摘が入ると「どこを見落としたのか」と背筋が伸びるんです。
ただ、あれは責めるためではなく、利用者に届く前に問題を止めるための仕組みだったと今は感じています。

具体的には、テスト計画、テスト設計、品質基準、リリース判定、不具合分析、再発防止の提案などに関わります。
不具合の件数だけを見るのではなく、どの機能に集中しているのか、同じ原因が繰り返されていないかを見ることもあります。
品質を守るというより、品質が崩れる前のサインを拾う仕事に近いですね。

未経験からQAを目指すなら、いきなり品質改善を任されるより、テスト実行からテスト設計へ進むルートが現実的です。
求人では、JSTQB、テスト設計、自動テスト、品質分析、リリース判定といった単語があるかを見てください。
「テスター」と「QA」を同じ意味で使う会社もあるので、担当範囲の確認はかなり大事です。

・ヘルプデスク｜問い合わせ対応からIT知識を身につける入口

ヘルプデスクは、社内や顧客からの問い合わせを受け、ITトラブルを整理して解決へつなぐ仕事です。
未経験者の入口になりやすい一方で、ただ電話を取る仕事だと思うと、実際の切り分け作業で戸惑いやすかったりします。

それは、問い合わせの言葉と本当の原因が一致しないことが多いからです。
「パソコンが壊れた」と言われても、電源、ネットワーク、アカウント、ソフトの設定、権限、端末故障のどれかは聞いてみないと分かりません。
相手がITに詳しくないほど、こちらが質問を小さく分ける必要があります。

具体的には、パスワード再設定、アカウント申請、PCの初期設定、プリンター接続、VPN接続、Microsoft 365やGoogle Workspaceの問い合わせ対応などがあります。
チケット管理ツールに受付内容、対応履歴、原因、完了日時を残す現場も多いです。
この記録が雑だと、同じ問い合わせが来たときにチーム全体で再利用しにくくなります。

O*NET OnLineのComputer User Support Specialistsでも、コンピュータ利用者への技術支援、対面・電話・電子的な問い合わせ対応、ハードウェアやソフトウェア利用の支援が職務として整理されています。
また、同職種は2026年更新の職業情報として掲載され、タスクには日常的なシステム性能の確認、機器のセットアップ、技術マニュアル確認、問い合わせ対応などが含まれます。
※参考: https://www.onetonline.org/link/summary/15-1232.00

ヘルプデスクを見るなら、一次受付だけで完結するのか、原因調査や手順書改善まで触れるのかを確認してみてください。
社内SEやインフラ系へ広げたい人は、端末、アカウント、ネットワーク、SaaSのどれに多く触れるかで、次の経験が変わります。

・テクニカルサポート｜製品やサービスの技術的な問題を解決する役割

テクニカルサポートは、自社製品やITサービスについて、顧客の技術的な問題を解決する仕事です。
ヘルプデスクよりも、特定の製品、ログ、設定値、仕様への理解が求められやすい職種ですね。

というのも、問い合わせ内容が「使い方が分からない」だけで終わらないからです。
たとえば、SaaSの管理画面で権限が反映されない、API連携が失敗する、請求データが取り込めない、エラーコードが出るといった相談があります。
この場合、利用状況だけでなく、製品仕様やログの見方まで確認します。

具体的には、FAQ回答、管理画面の操作案内、ログ確認、設定値のチェック、再現手順の整理、開発チームへのエスカレーション（上位担当へ引き継ぐこと）などがあります。
製品によっては、SQL、API、ブラウザの開発者ツール、クラウド管理画面を使うこともあります。
サポート職でありながら、技術調査の比率が高い現場もあるんです。

未経験者がテクニカルサポートを見るなら、扱う製品の種類を必ず確認してください。
業務システムなのか、クラウドサービスなのか、ネットワーク機器なのか、Webサービスなのかで、必要な知識が大きく変わります。
将来、開発やプリセールスSE（導入前に技術説明を行う職種）へ進みたい人は、問い合わせを仕様改善に戻せる現場かどうかも見たいところです。

・社内SE｜社内システムやIT環境を支える人気ポジション

社内SEは、自社の社員が使うシステムやIT環境を整える仕事です。
人気がありますが、会社によって仕事内容の幅がかなり広く、未経験者ほど「何を担当する社内SEなのか」を分けて見る必要があります。

なぜなら、社内SEという名前の中に、ヘルプデスク、業務システム運用、ベンダー調整、アカウント管理、セキュリティ対応、システム企画が混ざることがあるからです。
小さな会社では1人が広く担当し、大きな会社では情報システム部の中で役割が細かく分かれるケースもあります。

具体的には、PCやスマホの管理、Microsoft 365やGoogle Workspaceの運用、社内システムのアカウント管理、IT資産管理、ワークフローシステムの設定、ベンダーとの調整などがあります。
業務部門から「承認フローを変えたい」「入力項目を追加したい」と相談される場面もありますね。
その場合、単に設定を変えるだけでなく、業務の流れを聞き取る力も必要になります。

社内SEを目指す人は、「楽そう」「安定していそう」だけで選ばないほうがよいです。
問い合わせ対応が中心なのか、業務改善に関われるのか、システム導入プロジェクトに入れるのかで、積める経験が変わります。
求人では、社内ヘルプデスク、情シス、業務システム運用、ベンダーコントロール、システム企画のどれに近いかを確認してみてください。

未経験から近づくなら、ヘルプデスクやテクニカルサポートで、端末、アカウント、SaaS、業務システムの扱いに慣れておくルートがあります。
社内SEは「社内の便利屋」になりやすい面もあるため、どこまで技術経験として残せるかを最初から見ておきたいです。

・始めやすい仕事ほど「次にどこへ進むか」を考えるべき理由

品質保証・サポート系は、未経験者の入口になりやすい一方で、次の進み方を考えずに入ると経験が横に広がりにくいことがあります。
最初の入りやすさと、1年後に説明できる経験は別物なんですよね。

そう言えるのは、作業が手順化されている現場ほど、担当範囲が固定されることもあるからです。
テスト実行だけ、一次受付だけ、FAQ回答だけ、アカウント申請だけで止まると、慣れるほど作業は速くなります。
でも、職務経歴書に書くときは「何を改善したか」「どこまで判断したか」が見えにくくなります。

次に広げる方向は、入口ごとに変わります。

• テスト実行から、テスト設計、自動テスト、QA分析へ進む
• ヘルプデスクから、社内SE、インフラ運用、SaaS管理へ進む
• テクニカルサポートから、開発チーム連携、プリセールスSE、カスタマーサクセスへ進む
• 社内ITから、業務改善、システム導入、セキュリティ運用へ進む

見るべきなのは、最初の職種名ではなく、3ヵ月後と6ヵ月後に増える作業です。
たとえば、テスト項目を実行するだけでなくテスト観点を出せるのか。
問い合わせを受けるだけでなく、ナレッジ（再利用できる対応メモ）を作れるのか。
この差が、次の職種へ移るときの説明材料になります。

品質保証・サポート系は、ITの現場に近いところで利用者や不具合に触れられる入口です。
次の章では、AI・データ・組み込み・ゲームなど、将来性は高いものの未経験からは距離が出やすい専門職を整理していきます。

◆7. 専門性が高いエンジニア5職種｜将来性は高いが未経験からは難しめ

この章では、AI、データ、組み込み、ゲームなど、専門性が高いエンジニア職種を整理します。
どれも魅力のある分野ですが、未経験からいきなり中心業務へ入るには、前提知識の厚さが必要になりやすいです。
「難しそう」で終わらせず、どの入口から近づけるのかまで一緒に見ていきましょう。

・AIエンジニア｜機械学習や生成AIを扱う注目分野

AIエンジニアは、機械学習や生成AIを使って、予測、分類、文章生成、画像認識、業務自動化などを実装する仕事です。
最近は生成AIの話題が多いので派手に見えますが、実務ではモデル、データ、評価、運用をセットで扱います。

それは、AIが「作って終わり」の機能ではないからです。
学習に使うデータが偏っていないか、出力結果が業務で使える精度なのか、誤回答したときに誰が確認するのかまで考えます。
特に生成AIでは、便利さだけでなく、情報漏えい、著作権、ハルシネーション（もっともらしい誤回答）、偏りへの注意も必要です。

NISTのAI Risk Management Frameworkでも、AIのリスク管理は、AI製品・サービス・システムの設計、開発、利用、評価に信頼性の観点を組み込むためのものとして説明されています。
また、生成AI向けのプロファイルも公開されており、生成AI特有のリスクを識別し、組織の目的に合うリスク管理行動を検討する資料として位置づけられています。
AIエンジニアは、モデルを動かすだけでなく、使ってよい状態に整える視点も求められる職種なんです。
※参考: https://www.nist.gov/itl/ai-risk-management-framework

具体的には、Python、機械学習ライブラリ、API連携、プロンプト設計、RAG（外部データを参照して回答を作る仕組み）、モデル評価、MLOps（機械学習モデルを運用する仕組み）などを扱います。
未経験からすぐ研究開発の中心に入るより、AIツール導入補助、データ整理、チャットボット運用、評価データ作成から近づくほうが現実に近いです。

AIエンジニアを目指すなら、「Pythonを学ぶ」だけでは足りません。
どの業務をAIで置き換えるのか、何を正解とするのか、誤回答をどう検知するのかまで見てください。
求人では、生成AI、機械学習、LLM、RAG、MLOps、モデル評価のどこを担当するのかを確認すると、必要な学習範囲が見えやすくなります。

・データエンジニア｜分析に使うデータ基盤を作る仕事

データエンジニアは、分析やAIで使えるように、データを集め、保存し、加工し、使いやすい形へ整える仕事です。
データサイエンティストが分析する前の、通り道を作る役割と言うとイメージしやすいかもしれません。

というのも、企業のデータが最初からきれいに並んでいるとは限らないからです。
売上、顧客、在庫、広告、問い合わせ、アプリの操作ログが別々のシステムにあり、形式も更新タイミングもバラバラなことがあります。
そのままでは、分析する前に集計結果がズレたり、古いデータを見て判断したりする危険が出てきます。

具体的には、SQL、Python、ETL（データを抽出・変換・格納する処理）、データウェアハウス（分析用データを蓄積する基盤）、BigQuery、Snowflake、Redshift、dbt、Airflowなどを扱う現場があります。
最近はクラウド上にデータ基盤を作り、BIツール（データを表やグラフで可視化するツール）へつなぐ構成も多いですね。
インフラとデータの中間に立つような仕事です。

未経験からデータエンジニアを目指す場合、最初はSQLでの抽出、CSV整形、レポート更新、データ連携の確認から入るルートがあります。
ここで「この数字はどのテーブルから来たのか」「いつ更新されたデータなのか」を追えると、基盤づくりに近づきます。
単なる集計作業で止まるか、データの流れまで見られるかで、1年後の説明材料はかなり変わります。

データエンジニアを見るなら、分析そのものよりも、データの入口と出口を確認してみてください。
入口は、業務システム、広告ツール、アプリログ、外部ファイル。
出口は、BI、AIモデル、レポート、社内ダッシュボードです。
この流れを説明できる現場なら、専門職への足場を作りやすくなります。

・データサイエンティスト｜データを分析して意思決定を支援する専門職

データサイエンティストは、データを分析し、事業や業務の意思決定を支援する専門職です。
AIエンジニアよりも、課題設定、仮説検証、統計、説明資料づくりに寄る場面が多くなります。

なぜなら、分析結果は「グラフがきれい」で終わらず、次の判断に使われるからです。
たとえば、解約しそうな顧客を予測するなら、どの指標を使うのか、予測が外れたときの損失はどれくらいか、営業やサポートがどう動くのかまで考えます。
数字を出すだけではなく、数字を使って人が動ける形にする仕事なんですよね。

具体的には、SQL、Python、R、統計、A/Bテスト（施策を比較して効果を見る方法）、機械学習、BIツール、プレゼン資料作成などを扱います。
分析テーマとしては、売上予測、顧客分類、広告効果測定、解約予測、在庫最適化、不正検知などがあります。
ドメイン知識（業界や業務の知識）がないと、数字の意味を読み違えることもあります。

未経験からいきなりデータサイエンティストを狙う場合は、求人との距離を感じやすいです。
そう言えるのは、統計、プログラミング、業務理解、説明力を同時に求められやすいからです。
近い入口としては、データアナリスト補助、BIレポート作成、SQL集計、マーケティング分析補助などがあります。

データサイエンティストを目指すなら、学習では「モデルを作った」だけで止めないほうがよいです。
たとえば、なぜその指標を選んだのか、欠損値をどう扱ったのか、分析結果からどの施策を提案するのかまで書けると、実務の説明に近づきます。
数字が好きな人ほど、最後は人に伝えるところまで意識しておきたいですね。

・組み込みエンジニア｜家電・自動車・IoT機器を動かす技術職

組み込みエンジニアは、家電、自動車、産業機器、医療機器、IoT機器などに入るソフトウェアを開発する仕事です。
Web画面ではなく、機械や装置の中で動くプログラムを作る分野ですね。

それは、組み込み開発では、ソフトウェアが現実の機器の動きに直結するからです。
ボタンを押したらモーターが動く、温度センサーの値で制御を変える、車載機器が通信する、といった処理では、遅延や誤作動がそのまま製品の品質に関わります。
画面の見た目より、限られたメモリ、処理速度、安全性を考える場面が増えます。

具体的には、C言語、C++、リアルタイムOS（決められた時間内に処理するためのOS）、マイコン（小型の制御用コンピューター）、センサー、通信規格、制御ロジックなどを扱います。
テストでは、実機、シミュレーター、計測器を使うこともあります。
Web系とは違い、手元のブラウザだけで完結しにくい仕事です。

未経験から組み込み系を目指すなら、プログラミングだけでなく、機器の制約に興味を持てるかを見てください。
C言語のポインタ（メモリ上の場所を扱う仕組み）、ビット演算（0と1の単位で値を操作する処理）、通信、電気の基礎が出てくることがあります。
ここに抵抗が少ない人は、Web系とは違う面白さを感じやすいです。

入口としては、組み込みテスト、評価業務、デバッグ補助、仕様書に沿った動作確認から始まるケースがあります。
求人では、対象製品、使用言語、実機評価の有無、C/C++の比率、車載・家電・IoTのどれに近いかを確認してみてください。
「何を動かすソフトなのか」を見ると、仕事内容がだいぶ具体的になります。

・ゲームエンジニア｜ゲームの機能や動作を開発する人気分野

ゲームエンジニアは、ゲームのキャラクター操作、画面描画、通信、UI、サウンド、バトル処理、ツール開発などを担当する職種です。
人気が高い分、未経験からの競争も強く、作品提出や技術理解を求められやすい分野になります。

というのも、ゲーム開発が「楽しいものを作る仕事」であると同時に、処理負荷、操作感、演出、バグ修正が細かく絡む仕事だからです。
キャラクターが1秒遅れて動く、当たり判定がズレる、オンライン対戦で通信が不安定になる。
こうした違和感は、プレイヤーにはすぐ伝わります。

具体的には、Unity、Unreal Engine、C#、C++、3D数学、物理演算、シェーダー（画面表示の質感を決める処理）、ネットワーク通信、ゲーム内ツールなどを扱います。
スマホゲームなら課金、ガチャ、イベント運用、ログ分析に関わる現場もあります。
コンシューマー、スマホ、PCオンライン、サーバーサイドで必要な技術はかなり変わりますね。

未経験者がゲームエンジニアを目指すなら、「ゲームが好き」だけでは説明が弱くなりがちです。
自作ゲーム、操作できるデモ、GitHub、プレイ動画、工夫した処理、直したバグのメモまで出せると、話が具体的になります。
採用側が見たいのは、好きなタイトルよりも、自分で作ったときにどこまで考えたかです。

近い入口としては、ゲームテスター、デバッグ、運用補助、ツール作成補助、サーバーサイド開発補助などがあります。
ただし、テスターから必ず開発へ進めるわけではないため、業務時間外にUnityやUnreal Engineで小さな作品を作り、開発職へ説明できる材料を別で持つほうが安全です。

・未経験から専門職を目指すなら、近い入口を選ぶのが現実的

未経験から専門職を目指すなら、いきなり肩書きそのものを狙うより、近い入口を選んで距離を縮めるほうが現実的です。
AI、データサイエンス、組み込み、ゲームは、どれも前提知識が厚いため、最初の一歩を間違えると学習が空回りしやすいんですよね。

なぜなら、専門職ほど「分からない範囲」が広くなりやすいからです。
AIなら統計とデータ、データ基盤ならSQLとクラウド、組み込みならC言語と機器制御、ゲームならエンジンと数学。
それぞれ必要な土台が違うため、同じ「専門職」でも学習ルートは一本ではありません。

私自身、作業に何日かかるかを見積もるのは、20年エンジニアを続けていても難しいと感じます。
作業内容をかなり把握していないと、簡単そうに見える作業ほど見落としが出るんです。
未経験者が専門職を選ぶときも同じで、職種名だけを見て距離感を決めると、必要な準備を読み違えやすくなります。

近い入口を選ぶなら、次のように分けると見やすいです。

• AIエンジニアに近づくなら、データ整理、AIツール導入補助、評価データ作成
• データエンジニアに近づくなら、SQL集計、BI更新、データ連携確認
• データサイエンティストに近づくなら、分析補助、レポート作成、A/Bテスト集計
• 組み込み・ゲームに近づくなら、評価、デバッグ、小さな成果物作成

専門職を目指すなら、「最初の会社でその肩書きになれるか」だけで判断しないでください。
半年後に触れる技術、1年後に作れる成果物、次に応募できる職種まで見える入口なら、遠回りに見えても経験が残ります。
次の章では、希望条件別に、どの職種が自分に合いやすいのかを診断形式で整理していきます。

◆8. あなたに合うのはどれ？希望条件別の職種診断

この章では、これまで紹介した職種を「自分の希望条件」から逆引きして整理します。
職種名を先に選ぶより、どんな作業なら続けて向き合えそうかを見るほうが、未経験者には判断しやすいです。
「結局、自分はどれを目指せばいいの？」と迷っているなら、ここで一度、希望を作業レベルに落としてみてください。

労働政策研究・研修機構（JILPT）の職業適性検査・職業興味検査ページでも、一般職業適性検査では9種の適性能、職業レディネス・テストでは6つの職業領域への興味・自信、キャリア・インサイト統合版では能力、興味、価値観、行動特性を扱うと説明されています。
つまり、職種選びは「何となくかっこいい」だけではなく、興味、得意さ、働き方、価値観を分けて見るほうが現実に近いんです。
※参考: https://www.jil.go.jp/institute/seika/tools/

・作ることが好きな人は、Web・アプリ・プログラマー系が候補

作ることが好きな人は、Webエンジニア、アプリケーションエンジニア、プログラマー系をまず候補に入れると方向を決めやすいです。
ただし、ここでいう「作る」は、ゼロから好きなものを自由に作るというより、仕様に合わせて機能を形にする作業に近いです。

なぜなら、開発系の仕事では、動くものを作る楽しさと同じくらい、細かい修正や確認が多いからです。
ボタンの表示を直す、入力チェックを追加する、一覧画面の項目を増やす、既存コードの動きを追う。
こういう小さな作業を積み上げて、ようやく1つの機能として動くんですよね。

具体的には、画面を作るのが楽しいならフロントエンド寄り、データ保存やログイン処理に興味があるならバックエンド寄り、業務の流れをアプリにしたいなら業務アプリ寄りが候補になります。
HTML/CSS、JavaScript、PHP、Java、SQL、GitHubなど、学ぶものも入口によって変わります。
求人を見るときは、「開発」と書かれているかではなく、画面、API、データベース、改修、テストのどこに触るのかを見てください。

私の周りにも、文系出身でもアプリ開発で活躍している同期がいました。
理系か文系かより、分からない仕様を読み、エラーを調べ、動くまで直す作業に向き合えるかのほうが、現場では差になりやすいです。
作ることが好きな人は、最初のポートフォリオでも「見た目」だけでなく、入力、保存、編集、削除まで入れてみると適性を試しやすくなります。

・安定した需要を重視する人は、インフラ・クラウド系を検討

安定した需要を重視する人は、インフラエンジニアやクラウドエンジニアを候補に入れてみてください。
新しい機能を作る仕事ではなく、システムが止まらず使える状態を支える仕事に近いです。

理由は、会社がITを使い続ける限り、サーバー、ネットワーク、クラウド、アカウント、監視の管理がなくならないからです。
アプリを作ったあとも、ログを見たり、容量を確認したり、障害時に原因を切り分けたりする人が必要になります。
派手なリリースよりも、毎日動き続ける状態を守ることに価値を感じる人と相性がよい分野ですね。

具体的には、Linux、AWS、Azure、ネットワーク、監視ツール、バックアップ、権限設定などを扱います。
未経験からの場合、最初は運用監視、ログ確認、手順書対応、クラウド設定変更の補助から入るケースがあります。
ここで「なぜこのアラートが出たのか」「どのサーバーに影響するのか」を追える人は、ただの監視で終わりにくいです。

ただし、安定需要だけで決めると働き方のギャップが出ることがあります。
夜勤、シフト、休日対応、障害対応の有無は、求人票や面談で必ず見たいところです。
インフラ・クラウド系を検討するなら、需要の安定性と一緒に、半年後に運用改善や構築補助へ進めるかも確認してみてください。

・細かい確認が得意な人は、テスト・QA系で強みを出しやすい

細かい確認が得意な人は、テストエンジニアやQAエンジニアで強みを出しやすいです。
画面の違和感、条件の抜け、説明の曖昧さに気づける人は、品質保証系で頼られやすくなります。

というのも、テスト・QA系では「何となく変」を、再現できる情報に変える力が求められるからです。
たとえば、エラーが出たときに「壊れています」で終わらせず、端末、ブラウザ、操作手順、入力値、期待結果、実際の結果をそろえる。
ここまで書けると、開発者が原因を追いやすくなります。

具体的には、ログイン、検索、登録、編集、削除、CSV出力などをテストケースに沿って確認します。
QA寄りになると、テスト設計、品質基準、不具合分析、自動テストにも広がります。
Selenium、Playwright、Jira、Backlog、TestRailなどの単語が求人に出てくる場合は、単純な確認作業より専門性へ伸びる余地がありますね。

細かい確認が得意な人は、求人の「テスト業務あり」だけで判断しないでください。
テスト実行だけなのか、テスト観点づくり、不具合分析、自動テストまで触れるのかで、1年後の経験が変わります。
ミス探しが好きというより、条件を分けて説明できる人に向いた職種です。

・人と話すのが苦ではない人は、社内SE・ヘルプデスク・SEも選択肢

人と話すのが苦ではない人は、社内SE、ヘルプデスク、システムエンジニアも選択肢に入ります。
「ずっと話す仕事」という意味ではなく、相手の困りごとを技術の言葉に変換する場面が多い職種です。

なぜなら、ITのトラブルや要望は、最初からきれいな文章で届くとは限らないからです。
「ログインできない」「この画面を使いやすくしたい」「請求データが合わない」と言われても、原因はアカウント、権限、仕様、通信、入力ルールなどに分かれます。
相手の言葉をそのまま受けるだけでは、解決に近づけないんですよね。

具体的には、ヘルプデスクなら問い合わせ対応、PC設定、アカウント管理、社内SEなら業務システム運用、ベンダー調整、SaaS管理、SEなら要件整理や設計書作成に関わります。
会話が多い分、相手がITに詳しくない前提で質問を分ける力が必要です。
「いつから起きたのか」「誰の環境で起きるのか」「何をした直後か」を聞けるだけでも、切り分けはかなり進みます。

人と話すのが苦ではない人は、対人スキルを「営業っぽい仕事」と決めつけないほうがよいです。
IT職の中でも、説明、確認、調整、記録が得意な人は、社内SEやSEで強みを出せます。
求人では、電話受付中心なのか、原因調査や業務改善まで関われるのかを分けて見てください。

・数字や分析が好きな人は、データ系キャリアを視野に入れる

数字や分析が好きな人は、データエンジニア、データアナリスト、データサイエンティスト系のキャリアを視野に入れてよいです。
ただし、未経験の段階では、AIモデルよりもSQL集計やレポート作成から近づくほうが現実的です。

というのも、データ系の仕事が、数字を見るだけではなく、数字が生まれた流れを確認する仕事でもあるからです。
売上が増えたのか、集計条件が変わったのか、欠損値が混ざったのか、対象期間がズレたのか。
数字の意味を読むには、表の裏側にある業務やデータ構造まで見る必要があります。

具体的には、Excel、SQL、Python、BIツール、ダッシュボード、CSV、データベースなどを扱います。
最初の入口としては、SQLでの抽出、レポート更新、BI画面の修正、データクレンジング（表記ゆれや欠損を整える作業）があります。
分析職に近づきたいなら、単にグラフを作るだけでなく、「この数字から何を判断できるか」まで書けると強いです。

数字や分析が好きな人は、求人の「データ分析」という言葉を細かく分けてみてください。
Excel集計中心なのか、SQLでデータを取り出すのか、Pythonを使うのか、事業部門へ説明するのかで仕事内容は変わります。
データ系を目指すなら、最初の学習でも、架空の売上データをSQLで集計し、グラフと一言コメントまで作ると向き不向きを試しやすいです。

・将来の副業・独立を考える人は、Web系スキルとの相性を確認

将来の副業・独立を考える人は、Web系スキルとの相性を早めに確認しておくと判断しやすいです。
Web制作、WordPress、フロントエンド、バックエンド、保守改修は、個人案件や小規模案件とつながりやすい分野です。

それは、企業や個人事業の現場で、Webサイト修正、問い合わせフォーム追加、表示崩れ対応、予約ページ改善、簡単な業務ツール作成の需要があるからです。
大規模なAI開発やクラウド設計より、小さく切り出しやすい作業が多いんですよね。
一方で、副業は「コードが書ける」だけでは回らず、見積もり、納期、修正対応、文章での説明も必要になります。

具体的には、HTML/CSS、JavaScript、WordPress、PHP、GitHub、フォーム実装、レスポンシブ対応、SEOの基本、保守運用などが候補です。
最初から高単価の開発案件を狙うより、既存サイトの修正、LP（1ページの販売・集客ページ）改善、WordPressの軽微な調整から経験を積むほうが入りやすいケースがあります。
ただし、案件獲得、契約、税金、顧客対応まで自分で見る必要があるため、楽な働き方とは言い切れません。

副業・独立を考える人は、会社員としての最初の職種でも、Web系の実務経験が残るかを見てください。
画面実装、フォーム、CMS（Webサイトを管理する仕組み）、保守、改修、顧客説明のどれかに触れる現場なら、あとで小さな案件へつなげやすくなります。
ここまでで希望条件別の向き不向きを整理できたので、次の章では、職種選びで失敗しやすい人の共通点を具体的に見ていきます。

◆9. 職種選びで失敗する人の共通点5つ

この章では、未経験者が職種を選ぶときにやりがちな失敗を、5つのパターンに分けて整理します。
ここまで職種ごとの違いを見てきましたが、最後に迷うのは「どれを選ぶと後悔しにくいか」ですよね。
職種名、技術名、働き方の響きに引っ張られず、配属後の作業まで想像できる形に落としていきます。

NISTのNICE Framework Resource Centerでは、サイバーセキュリティ業務を説明する共通言語として、仕事の内容と、それを完了するために必要な知識・スキルを整理すると説明されています。
また、職務記述書の作成、候補者スキルの評価、ロール別トレーニングやキャリア計画にも使われる枠組みとして紹介されています。
分野はサイバーセキュリティですが、「職種名」だけでなく、仕事・知識・スキルに分けて見る考え方は、未経験者の職種選びにもかなり使いやすいです。
※参考: https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center

・失敗1｜「未経験でも入りやすい」だけで決めてしまう

「未経験でも入りやすい」だけで職種を決めると、入社後に積み上がる経験が見えにくくなります。
入口が広い仕事と、自分が伸ばしたい技術に近い仕事は、必ずしも同じではありません。

というのも、未経験者向けの仕事ほど、最初の担当範囲が小さく切られていることがあるからです。
問い合わせの一次受付、テスト項目の実行、監視画面の確認、データ入力、手順書どおりのチェック。
これらはIT業界に入る入口にはなりますが、そこで止まると「慣れた作業」は増えても、次の職種へ説明しやすい経験が残りにくいんですよね。

具体的には、ヘルプデスクなら、受付だけで終わるのか、原因調査やナレッジ作成まで任されるのかを分けて見ます。
テスト系なら、テスト実行だけなのか、テスト観点や不具合分析まで触れるのか。
運用監視なら、アラート転送だけなのか、ログ確認、手順改善、クラウド設定の補助まで広がるのかで、半年後の見え方が変わります。

入りやすさを見るなら、同時に「3ヵ月後に増える作業」もセットで確認してみてください。
最初の業務が小さくても、その先に原因調査、設計補助、改善提案があるなら、入口としての価値は十分あります。
逆に、1年後も同じ画面・同じ手順・同じ受付だけなら、次の応募で語れる材料が少なくなりやすいです。

・失敗2｜「Pythonを学べば稼げる」と思い込む

「Pythonを学べば稼げる」と決め打ちするのも、未経験者がつまずきやすい選び方です。
Pythonは便利な言語ですが、Pythonという名前だけで、AI、データ分析、Web開発、自動化の仕事に直結するわけではありません。

なぜなら、評価されるのが言語名そのものではなく、何を作ったか、どのデータを扱ったか、どこまで業務に使える形にしたかだからです。
同じPythonでも、pandas（表データを扱うライブラリ）でCSVを集計する仕事、FastAPI（Web APIを作るフレームワーク）で裏側の処理を作る仕事、機械学習モデルを評価する仕事では、必要な前提がまるで違います。
「Pythonできます」と言っても、相手が知りたいのは、その中身なんですよね。

具体的には、データ系ならSQL、Excel、BIツール、統計の基礎が一緒に出てきます。
AI寄りなら、モデル評価、学習データ、プロンプト設計、RAG（外部データを参照して回答を作る仕組み）なども関わります。
Web寄りなら、HTTP（Web通信の仕組み）、API、データベース、認証処理まで見ないと、実務の会話に乗りにくいです。

Pythonを学ぶなら、言語名ではなく、作業の種類まで決めてください。
たとえば「売上CSVを読み込み、商品別に集計し、グラフとコメントを出す」「ログイン付きの簡単なAPIを作る」のように、成果物を具体化する。
技術名に期待を乗せすぎず、職種で使う作業へ落とすと、学習の空回りを減らせます。

・失敗3｜「リモートワークしたい」だけでWeb系を選ぶ

リモートワークをしたいという理由だけでWeb系を選ぶと、仕事内容との相性を見落としやすいです。
Web系は在宅と相性がよい場面もありますが、未経験の最初から完全リモートで進むとは限りません。

それは、リモート可否が職種名ではなく、作業の切り出し方、教育体制、セキュリティ、チームの運用で決まるからです。
コードを書くだけでなく、仕様確認、レビュー、環境構築、エラー相談、進捗共有が発生します。
未経験のうちは、このやりとりをオンラインだけで回すのが難しい現場もあるんです。

具体的には、GitHub、Backlog、Jira、Slack、Teams、Google Meetなどで作業が管理され、設計書やチケットが整っている現場は、リモートへ移りやすい傾向があります。
一方で、PCの受け渡し、社内ネットワーク接続、顧客先での説明、研修中の横並びサポートが多い現場では、週数回の出社が残りやすいです。
「Web系だから在宅」と見るより、作業がクラウド上で完結するかを見たほうが現実に近いですよ。

Web系を選ぶなら、リモートの有無だけでなく、最初の30日で誰に質問するのか、レビューはどう返ってくるのか、仕様変更はどこに記録されるのかを見てください。
オンラインで働きたい人ほど、文章で質問する力、作業ログを残す力、途中経過を共有する力が問われます。
場所の自由だけを先に見ると、仕事の進め方でしんどくなることがあります。

・失敗4｜夜勤や監視業務を確認せずインフラ系に進む

インフラ系を選ぶときに、夜勤や監視業務の有無を確認しないまま進むと、働き方のギャップが出やすいです。
インフラ系は安定した需要を狙いやすい一方で、サービスを止めないための運用体制まで含めて見る必要があります。

それは、システムの障害が平日の昼だけに起きるとは限らないからです。
サーバー、ネットワーク、クラウド、監視ツールが関わる現場では、夜間シフト、休日対応、障害時の呼び出し、定期メンテナンスが組まれていることがあります。
もちろん、すべてのインフラ職が夜勤ありという話ではありません。

私の経験でも、インフラチームがシステムに何か起きたとき、夜中に対応していることがありました。
開発側から見ると、翌朝には何事もなかったように環境が戻っていることもあります。
でも、その裏ではログ確認、影響範囲の切り分け、関係者への連絡が動いているわけです。

インフラ系を見るなら、仕事内容と同じくらい運用体制を確認してみてください。
見るポイントは、24時間365日監視なのか、夜勤は交代制なのか、一次対応だけなのか、ログ調査や復旧作業まで担当するのか。
監視業務そのものが悪いのではなく、自分の生活リズムと、半年後に増える技術経験が合うかを見る必要があります。

・失敗5｜仕事内容を知らないまま社内SEやAIエンジニアを目指す

社内SEやAIエンジニアのような人気職を、仕事内容を知らないまま目指すのも危うい選び方です。
名前の印象がよい職種ほど、実際の作業範囲が広かったり、前提知識が厚かったりします。

というのも、どちらも「聞こえのよさ」と「実務の中身」に差が出やすいからです。
社内SEは、社内で落ち着いて働ける仕事に見えますが、実際にはヘルプデスク、アカウント管理、SaaS運用、ベンダー調整、業務部門へのヒアリングまで混ざることがあります。
AIエンジニアも、モデルを作る前に、データ整理、評価、セキュリティ、利用ルールの整理が入ります。

具体的には、社内SEを目指すなら、情シス（情報システム部門）でPC管理中心なのか、業務システム改善まで触れるのかを分けて見ます。
AIエンジニアなら、Pythonを書くのか、AIツールを導入するのか、評価データを作るのか、生成AIの回答を検証するのかを確認したいところです。
同じ職種名でも、毎日の作業はかなり違います。

人気職を目指すなら、「その職種名になりたい」よりも、最初に任される周辺作業を受け入れられるかを見てください。
社内SEなら問い合わせ整理や業務ヒアリング、AI系ならデータ整備や評価作業。
華やかに見える仕事ほど、地味な前処理や調整が支えていることを知っておくと、入社後の落差を小さくできます。

・迷ったら「最初の業務内容」と「3年後のキャリア」をセットで見る

職種選びで迷ったら、「最初の業務内容」と「3年後のキャリア」を1枚のメモに並べると判断しやすくなります。
頭の中だけで比べると、職種名、年収、リモート、人気度が混ざって、優先順位がぼやけやすいんですよね。

なぜなら、未経験者の職種選びでは、入口と出口を分けて見る必要があるからです。
最初に任される作業が自分に合っていても、3年後に進みたい方向とズレているなら、途中で迷いやすくなります。
逆に、最初の作業が地味でも、3年後の方向につながるなら、経験として積み上げやすいです。

具体的には、候補職種を3つまでに絞り、次の項目を横並びで書きます。

確認項目	見る内容
最初の30日	問い合わせ、テスト実行、画面修正、監視確認など何をするか
半年後	原因調査、設計補助、テスト設計、クラウド設定などに広がるか
3年後	開発、QA、インフラ、社内SE、データ系のどこへ進みたいか
避けたい条件	夜勤、電話中心、出社多め、単純作業固定などは何か

このメモを作ると、「入りやすいけれど進みたい方向と違う職種」と、「最初は地味でも次に広がる職種」が分かれます。
職種選びは一発で正解を当てる作業ではなく、最初の配属で何を経験し、次に何を説明できるようにするかの設計に近いです。
次の章では、ここまでの内容を比較表にして、未経験者が見るべき判断基準を5つに整理していきます。

◆10. 職種別比較表｜未経験者が見るべき判断基準は5つ

この章では、未経験者が職種を比べるときに見るべき5つの判断基準を整理します。
ここまで読んでも「結局、どれを候補に残せばいいの？」と迷いますよね。
職種名だけで比べるのではなく、入りやすさ、学習難易度、年収の伸び方、リモート相性、AI時代の需要で横並びにして見ていきます。

欧州委員会が運営するESCOでは、European e-Competence Framework（e-CF）がICT専門職向けの40のコンピテンシーを分類し、能力・スキル・熟達度レベルを表す共通言語を提供すると説明されています。
職種を比較するときも、「名前」ではなく、必要なスキル、担当する業務領域、どの段階まで任されるかに分けて見ると、判断がかなり落ち着きます。
※参考: https://esco.ec.europa.eu/en/about-esco/escopedia/escopedia/european-e-competence-framework-e-cf

・比較1｜未経験から入りやすいか

未経験からの入りやすさを見るなら、最初に任される作業が小さく切り出されているかを確認すると判断しやすいです。
入口の広さだけで見ると、ヘルプデスク、テスト実行、運用監視、サポート系は候補に入りやすくなります。

なぜなら、これらの職種では、手順書、問い合わせ分類、テストケース、監視アラートのように、未経験者でも担当範囲を区切りやすい作業があるからです。
一方で、AIエンジニア、データサイエンティスト、セキュリティエンジニア、ゲームエンジニアは、前提知識や成果物を求められやすく、最初から中心業務へ入るには距離があります。

比較すると、こんな見方になります。

入りやすさ	職種例
入りやすい傾向	ヘルプデスク、テストエンジニア、運用監視、サポート系
中間	プログラマー、Webエンジニア、社内SE、インフラエンジニア
難しめ	AI、データサイエンティスト、セキュリティ、ゲーム、組み込み

私の経験でも、未経験向けの求人では「Excelの基本操作」「ITに興味がある」といった条件を見ることがあります。
ただ、それだけで楽に入れるという意味ではなく、最初の作業が受付、確認、記録、補助に寄っている可能性があるという見方が近いです。
入りやすさを見るときは、採用条件よりも、入社後30日で何を触るかまで確認してみてください。

・比較2｜学習難易度は高いか低いか

学習難易度は、覚える技術の量だけでなく、実務で使う前提知識の幅で見たほうがよいです。
「簡単そう」「難しそう」という印象より、最初の3ヵ月で何を理解する必要があるかを分けると見えやすくなります。

それは、職種によって学ぶ対象がまったく違うからです。
Web系ならHTML/CSS、JavaScript、Git、API、SQL。
インフラ系ならLinux、ネットワーク、クラウド、監視、権限管理。
データ系ならSQL、Excel、Python、BIツール、統計の基礎が出てきます。

ざっくり分けるなら、ヘルプデスクやテスト実行は、IT基礎と業務理解から入りやすいです。
開発系は、文法だけでなくエラー調査や既存コードの読み方が壁になります。
AI、データサイエンス、セキュリティ、組み込みは、数学、統計、OS、通信、ハードウェア、リスク管理など、周辺知識の厚さが増えます。

学習難易度を見るときは、教材の量ではなく、現場で最初に使うツール名を見てください。
たとえば、GitHub、SQL、Linux、AWS、Jira、Excel、BIツールのどれが出てくるのか。
最初の学習対象を3つまでに絞れる職種は、未経験者でも進め方を組み立てやすいです。

・比較3｜年収はどのタイミングで伸びやすいか

年収の伸びやすさは、最初の給与よりも、2年後・3年後に担当範囲が広がるかで見たほうが現実的です。
未経験の初年度だけで比べると、職種ごとの差より、会社、勤務地、雇用形態、配属先の影響も大きくなります。

というのも、エンジニアの評価が「作業をこなせる」から「判断して任せられる」へ変わるタイミングで上がりやすいからです。
テスト実行だけなら入口の経験ですが、テスト設計、自動テスト、不具合分析まで広がると評価材料が増えます。
インフラでも、監視からログ調査、手順改善、構築補助、クラウド運用へ進めると説明しやすくなります。

職種別に見るなら、伸びるタイミングは少し違います。

職種分類	年収が伸びやすいタイミング
開発系	改修から設計、API実装、DB設計へ広がると伸ばしやすい
インフラ系	監視から構築、クラウド、セキュリティへ広がると強い
QA系	テスト実行から設計、自動化、品質分析へ進むと差が出る
データ系	集計から基盤、分析、意思決定支援へ進むと評価されやすい

年収を見たい人は、求人の想定年収だけでなく、昇給時に評価される作業を確認してみてください。
コード行数や対応件数より、任された工程、改善した手順、作った仕組み、説明できる成果物のほうが、3年後の比較材料になります。
「今いくらか」だけでなく、「何を任されると上がるのか」まで見ると、職種選びが少し冷静になります。

・比較4｜リモートワークとの相性はよいか

リモートワークとの相性は、職種名ではなく、作業がオンラインで完結するかで判断するほうが正確です。
Webエンジニアだから必ず在宅、インフラだから必ず出社、という分け方は少し粗いです。

理由は、リモートのしやすさが、端末作業、セキュリティ、教育体制、顧客対応、チームの情報共有で変わるからです。
ソースコード、設計書、チケット、レビュー、テスト結果がクラウド上で管理されている職場は、リモートへ移りやすい傾向があります。
一方で、PCキッティング（初期設定）、ネットワーク機器確認、顧客先作業、実機評価が多い職種は、出社や現地対応が入りやすくなります。

相性で見るなら、Web開発、バックエンド開発、クラウド運用、データ集計・分析補助、QAの一部はリモート候補に入りやすいです。
ヘルプデスク、社内SE、ネットワーク、組み込み、オンサイト保守は、扱う機器や相手によって出社比率が変わります。
未経験の場合は、最初の1ヵ月〜3ヵ月だけ出社し、その後に在宅が混ざるケースもありますね。

リモート重視なら、求人の「リモート可」だけではなく、週の出社日数、研修期間、端末作業、障害時対応、連絡ツールを確認してください。
Slack、Teams、Jira、GitHub、Google Workspaceなどで作業が見える化されているかも判断材料になります。
場所より先に、仕事の進め方がリモート向きかを見てみるとズレを減らせます。

・比較5｜AI時代でも需要が残りやすいか

AI時代でも需要が残りやすい職種は、単純作業だけでなく、判断、設計、調整、品質確認、運用改善に関われる職種です。
AIに置き換わるかどうかを怖がるより、AIを使っても最後に人が見る部分がどこかを考えたほうが現実に近いです。

というのも、AIがコード生成、文章作成、集計、問い合わせ文の下書きを助けても、業務要件、セキュリティ、品質、責任の判断までは現場側に残るからです。
たとえば、AIがコードを書いても、仕様に合っているか、既存システムを壊さないか、個人情報を扱っていないかは確認が必要です。
生成された答えをそのまま使うより、検証できる人の価値が上がりやすいんですよね。

需要が残りやすい方向としては、次のように見られます。

職種分類	AI時代でも残りやすい需要
開発系	AIを使っても、設計、レビュー、既存コード理解が必要
インフラ系	クラウド、セキュリティ、障害対応は運用判断が残る
QA系	AI出力や自動生成コードを検証する品質目線が使える
データ系	分析結果を業務判断へつなぐ説明力が残りやすい

AI時代を意識するなら、「AIに奪われにくい職種」を探すより、AIを使ったあとに何を確認できる人になるかを見てください。
テスト、レビュー、ログ調査、要件整理、データ品質確認、セキュリティ確認のような仕事は、AIの出力が増えるほど必要性が見えやすくなります。
職種名より、判断を含む作業へ近づけるかが分かれ目です。

・一覧表で整理｜気になる職種を3つまで絞ろう

最後に、ここまでの比較軸を使って、気になる職種を3つまで絞ってみてください。
候補が多すぎると、JavaScriptもLinuxもPythonもAWSも少しずつ触って、どれも浅いまま止まりやすいです。

まずは、職種群ごとに次のように整理すると見やすくなります。

職種分類	入りやすさ	学習難易度	年収の伸ばし方	働き方・注意点
開発系	中	中〜高	担当工程が広がると伸びやすい	リモート相性は高め
インフラ系	中	中	クラウド・設計・セキュリティで伸ばしやすい	夜勤・シフト・障害対応など働き方の確認が必要
テスト・QA系	高め	低〜中	テスト設計・自動化・品質分析へ進めるかで変わる	実行だけで終わらない現場か確認したい
サポート・社内IT系	高め	低〜中	社内SEやインフラへ広げられると伸ばしやすい	問い合わせ対応だけでなく、担当範囲の確認が必要
データ・AI系	低〜中	高め	SQL・データ基盤・分析説明まで広がると強い	最初は集計やデータ整理から始まることもある

絞り方は、単純なランキングではなく、自分の優先順位で決めるほうが合います。
早くIT業界に入りたいなら、テスト・QA、ヘルプデスク、運用監視。
コードを書きたいなら、Web、プログラマー、アプリケーションエンジニア。
安定運用やクラウドに興味があるなら、インフラ、サーバー、クラウド。
数字が好きなら、データ集計、データエンジニア補助、分析補助を候補にできます。

迷ったら、候補を3つだけ紙に書いてください。
その横に、最初の30日で触る作業、3ヵ月後に増える技術、3年後に進みたい方向を書きます。
この3つが埋まらない職種は、まだ情報が足りない状態です。
次の章では、最初の職種からどのキャリアへ移動できるのかを、入口別のルートとして整理していきます。

◆11. 最初の職種で将来は決まる？入口から考えるキャリア移動マップ

この章では、最初に選んだ職種から、次にどんなキャリアへ広げられるのかを入口別に整理します。
「最初の職種を間違えたら終わりなのかな」と不安になる人もいると思いますが、私はそこまで固定的に考えなくてよいと見ています。
ただ、入口で何を経験するかによって、次に説明しやすい方向は変わるんですよね。

IPAのスキル標準ページでは、DX推進のための人材確保・育成の指針であるデジタルスキル標準のほか、IT人材の育成や採用の際に参考となるスキル標準として、ITSS、UISS、ITSS+などが紹介されています。
つまり、IT職のキャリアは「肩書き」だけでなく、どの業務を担当し、どのスキルを増やしていくかで見たほうが整理しやすいです。
※参考: https://www.ipa.go.jp/jinzai/skill-standard/index.html

・ヘルプデスクから社内SE・インフラエンジニアへ進むルート

ヘルプデスクから進むなら、社内SEやインフラエンジニアへ広げるルートが考えやすいです。
問い合わせ対応で終わらせず、端末、アカウント、ネットワーク、業務システムのどれに触れたかを記録していくと、次の職種へつなげやすくなります。

それは、ヘルプデスクが利用者に近い場所で、IT環境の困りごとを広く見る仕事だからです。
「ログインできない」「VPNにつながらない」「社内システムが見られない」といった相談の裏には、アカウント権限、端末設定、ネットワーク、SaaS（インターネット経由で使う業務ソフト）の設定が絡むことがあります。
ここをただの受付で終わらせるか、原因の種類まで分けて見られるかで、次の一歩が変わります。

具体的には、社内SEへ進みたいなら、問い合わせの傾向をまとめ、よくあるトラブルをナレッジ（再利用できる対応メモ）にする経験が役立ちます。
インフラ系へ進みたいなら、IPアドレス、VPN、Wi-Fi、アカウント権限、端末キッティング（PCの初期設定）に触れた経験を残しておきたいところです。
チケット管理ツールで対応履歴を残しているなら、月ごとの問い合わせ件数や改善した手順も説明材料になります。

ヘルプデスクを入口にするなら、最初の1年で「何件対応したか」だけを積み上げないほうがよいです。
どのトラブルを自分で切り分けたのか、どの手順を改善したのか、どのシステムの運用に関わったのかまで書けると、社内SEやインフラ系への移動が見えやすくなります。

・監視・運用からクラウドエンジニアを目指すルート

監視・運用から進むなら、クラウドエンジニアやインフラ構築補助へ広げるルートがあります。
最初はアラート確認や手順書対応でも、ログ、構成、権限、バックアップまで見られるようになると、クラウド側の仕事に近づきます。

というのも、クラウドエンジニアの仕事も、いきなり派手な設計だけで成り立つわけではないからです。
AWSやAzureを使う現場でも、監視、ログ確認、障害時の一次切り分け、コスト確認、権限設定の見直しは日常的に出てきます。
監視・運用で「正常な状態」と「異常な状態」を見分ける経験は、クラウド運用でも使いやすいんですよね。

具体的には、監視ツールの通知を見たら、どのサーバー、どのサービス、どの時間帯で起きたのかを追います。
AWSならCloudWatch、IAM（権限管理の仕組み）、EC2、S3、VPCなどの名前が出てくることがあります。
最初はボタン操作だけでも、設定の意味をメモしておくと、半年後に「なぜこの設定が必要なのか」を説明しやすくなります。

監視・運用からクラウドへ進みたい人は、資格名だけでなく、現場で触ったサービス名を残してください。
「AWSを勉強中」よりも、「CloudWatchのアラート確認」「EC2の状態確認」「IAM権限の申請確認」のほうが、実務との距離が伝わります。
運用を流れ作業にしない人ほど、構築補助やクラウド運用へ広げやすいです。

・テストエンジニアからQA・開発・PMへ広げるルート

テストエンジニアからは、QAエンジニア、開発職、PM（プロジェクトマネージャ）補助へ広げるルートがあります。
テスト実行で終わらず、仕様理解、不具合分析、テスト設計まで広げると、次の職種へ説明しやすくなります。

なぜなら、テストが開発工程の出口だけでなく、仕様、画面、データ、リリース判断を横断して見る仕事だからです。
不具合を見つけたときに、どの条件で起きるのか、仕様の抜けなのか、実装ミスなのか、データの問題なのかを考える場面があります。
この切り分け力は、QAにも開発にも使えるんです。

具体的には、QAへ進みたいなら、テスト観点、リリース前チェック、不具合の傾向分析を意識します。
開発へ近づきたいなら、エラーの再現手順だけでなく、該当画面、API（システム同士をつなぐ窓口）、データベースの関係を追ってみてください。
PM補助へ広げるなら、遅れているテスト項目、未解決バグ、影響範囲を一覧で整理する経験が役立ちます。

テスト系を入口にするなら、「テストをした」だけで職務経歴を終わらせないほうが安全です。
テストケースを何本実行したか、どんな不具合を見つけたか、再発防止のために何を提案したか。
この3つを残しておくと、QA、開発、PM補助のどこへ進むにも話が具体的になります。

・プログラマーからSE・バックエンド・フリーランスへ進むルート

プログラマーから進むなら、SE、バックエンドエンジニア、フリーランス寄りの働き方へ広げるルートがあります。
ただコードを書けるだけでなく、仕様を読み、データの流れを理解し、修正内容を説明できるようになると選択肢が増えます。

それは、プログラマーの経験が、実装範囲の広がりによってキャリアの方向を変えやすいからです。
画面修正だけでなく、API、データベース、認証、バッチ処理（決まった時間にまとめて動く処理）まで触れると、バックエンド寄りの説明がしやすくなります。
設計書や要件確認に関わる時間が増えると、SE寄りの仕事にも近づきます。

具体的には、SEへ進みたいなら、仕様変更の理由、画面項目の意味、業務フローをメモしておくとよいです。
バックエンドへ進みたいなら、SQL、API、ログ、エラー処理、権限管理を意識して触ります。
将来フリーランスを考えるなら、技術だけでなく、見積もり、納期、修正依頼への返し方、保守対応の経験も見ておきたいですね。

私自身、面接では変にできるふりをしないほうがよいと感じています。
次の職種へ移るときも同じで、「Javaができます」だけではなく、「どの画面のどんな改修を担当し、どこまで自分で調べたか」を話せるほうが強いです。
プログラマーを入口にするなら、書いたコードの量より、任された範囲の変化を残してみてください。

・データ集計からデータエンジニア・分析職へ近づくルート

データ集計から進むなら、データエンジニア、データアナリスト、分析補助へ近づくルートがあります。
Excel作業で止まるか、データの入口・加工・出口まで見られるかで、次の職種への距離が変わります。

それは、データ系の仕事が、集計結果だけでなく、どこから来たデータを、どの条件で加工し、誰が使うのかまで見る仕事だからです。
同じ売上集計でも、対象期間、除外条件、更新タイミング、部門別の見方がズレると、判断に使えない数字になります。
数字が出れば終わりではなく、数字の作られ方を説明できるかが問われるんですよね。

具体的には、データエンジニアへ近づきたいなら、SQL、CSV連携、データベース、ETL（データを抽出・変換・格納する処理）に触れる経験を増やします。
分析職へ近づきたいなら、集計後に「どの商品が伸びたのか」「どの期間で変化したのか」「次に何を確認すべきか」までコメントできると強いです。
BIツール（データを表やグラフで見える化するツール）を使うなら、ダッシュボードの更新理由も残しておきたいところです。

データ集計を入口にするなら、Excelの操作だけで終わらせないでください。
どのテーブルから取り出したのか、どの条件で絞ったのか、誰がその結果を見るのかを書いておく。
この3点を説明できると、データエンジニアや分析職へ近づく足場になります。

・最初の職種で失敗しないために、次の移動先まで考えよう

最初の職種で失敗しないためには、入社時点の肩書きだけでなく、次の移動先までセットで考える必要があります。
ただし、3年後まで完璧に決める必要はありません。
最初の半年で何を覚え、1年後に何を説明できるようにするかを置いておくだけでも、求人を見る目は変わります。

というのも、未経験者の最初の職種が、ゴールではなく材料集めの場所になるからです。
ヘルプデスクなら問い合わせと社内IT、監視・運用ならログとクラウド、テストなら品質と仕様、プログラマーなら実装と設計、データ集計ならSQLと分析へ広げられます。
同じ入口でも、毎日の作業をどう記録するかで、次の移動先が変わるんです。

具体的には、候補職種を選ぶ前に、次の3行を書いてみてください。

• 最初の30日で担当しそうな作業
• 半年後に増やしたい技術や担当範囲
• 1年後に職務経歴書へ書きたい成果

この3行が書ける職種は、入口と次の移動先がつながっています。
逆に、「何となく入りやすそう」だけで3行が埋まらない職種は、まだ情報が足りない状態です。
次の章では、職種を選ぶ前に確認したいスキルや資格を、開発系・インフラ系・テスト系・サポート系に分けて整理していきます。

◆12. 職種を選ぶ前に確認したいスキル・資格一覧

この章では、職種を決める前に見ておきたいスキルと資格を、職種別に整理します。
「何を学べばいいのか」が曖昧なまま教材を開くと、HTMLもLinuxもPythonも少しずつ触って、結局どれも自信が持てない状態になりやすいです。
ここでは、資格名を先に選ぶのではなく、目指す入口で使う作業から逆算していきます。

IPAのITパスポート試験ページでは、ITパスポートを「ITに関する共通的な基礎知識」を持つ人材向けの国家試験として説明し、コンピュータシステム、データベース、ネットワーク、情報セキュリティなどの基礎知識が要求されるとしています。
また、基本情報技術者試験ページでは、基本情報を「ITエンジニアの登竜門」とし、ITを活用したサービス、製品、システム、ソフトウェアを作る人材に必要な基本的知識・技能を扱う試験として整理しています。
資格は職種を決める魔法の札ではありませんが、学習範囲を棚卸しする物差しとして使うと、迷いを減らしやすいです。
※参考: https://www.ipa.go.jp/shiken/kubun/ip.html
※参考: https://www.ipa.go.jp/shiken/kubun/fe.html

・開発系で学びたい基礎｜HTML・CSS・JavaScript・Java・PHP・Python

開発系を候補にするなら、最初に見るべきなのは「人気の言語」ではなく、どの種類のアプリを作るための基礎かです。
HTML・CSS・JavaScript、Java、PHP、Pythonはよく名前が出ますが、全部を同じ深さで学ぶ必要はありません。

なぜなら、開発系の中でも、画面を作る仕事、業務システムを直す仕事、データを処理する仕事で使う技術が変わるからです。
HTMLは画面の構造、CSSは見た目、JavaScriptはブラウザ上の動きに関わります。
JavaやPHPは、業務システムやWebサービスの裏側で使われることが多く、Pythonは自動化、データ処理、AI周辺でも見かけます。

具体的には、フロントエンド寄りなら、まずHTML/CSS、JavaScript、GitHubを組み合わせて、小さな画面を作ると判断しやすいです。
バックエンド寄りなら、Java、PHP、Pythonのどれか1つに加えて、SQL（データベースから情報を取り出す言語）とAPI（システム同士をつなぐ窓口）を見ます。
業務アプリ寄りなら、一覧画面、登録画面、編集画面、CSV出力のように、仕事の流れをどうシステム化するかを考える力も必要です。

ここで全部を一気にやろうとすると、教材だけが増えて手が止まりやすいです。
最初の1ヵ月は「画面を作る」「データを保存する」「一覧で表示する」のどれか1つに絞ってください。
開発系の基礎は、言語名のコレクションではなく、1つの機能を最後まで動かす経験から見えてきます。

・インフラ系で押さえたい基礎｜Linux・ネットワーク・クラウド

インフラ系を候補にするなら、Linux、ネットワーク、クラウドの3つを入口として見ておくと整理しやすいです。
この3つは別々に見えますが、現場では「サーバーに入る」「通信できるか確認する」「クラウド上の設定を見る」という形でつながります。

なぜなら、インフラ系の仕事が、システムを動かす土台を扱うからです。
Linuxはサーバーを操作するための基礎、ネットワークは通信の通り道を理解するための基礎、クラウドはサーバーやネットワークを画面や設定で管理するための基礎になります。
どれか1つだけ知っていても、障害時にはつながりを追う場面が出てくるんですよね。

具体的には、Linuxならcd、ls、pwd、cat、grep、tailなどの基本コマンドから始めます。
ネットワークなら、IPアドレス、DNS（ドメイン名をIPアドレスに変換する仕組み）、ポート番号、ping、tracerouteを押さえると会話に入りやすいです。
クラウドなら、AWSやAzureの名前だけでなく、仮想サーバー、ストレージ、ネットワーク、権限、監視の役割を分けて見ます。

インフラ系の学習では、いきなり難しい構築手順を暗記するより、異常を確認する流れを作るほうが実務に近いです。
たとえば、Webページが見られないときに、端末、DNS、ネットワーク、サーバー、アプリのどこで止まっていそうかを順番に考える。
この切り分けの癖がある人は、監視・運用からクラウド運用へ広げるときにも強みを出しやすいです。

・テスト・QA系で役立つ知識｜テスト設計・品質管理・仕様理解

テスト・QA系を候補にするなら、ツール名より先に、テスト設計、品質管理、仕様理解の3つを押さえてください。
テスト実行だけなら入口に入りやすいですが、次に広げるには「何を、なぜ確認するのか」を説明できる必要があります。

それは、テスト・QA系の価値が、不具合を見つけるだけではなく、不具合が起きやすい条件を先に考えるところにあるからです。
仕様理解が浅いまま画面を触ると、表示された結果が正しいのか、たまたま動いているだけなのか判断しにくくなります。
品質管理では、件数だけでなく、どの機能に不具合が集中しているか、リリース前に何を止めるべきかまで見ます。

具体的には、テスト設計では、正常系（想定どおりに動く確認）と異常系（エラーや例外を確認するパターン）を分けます。
仕様理解では、画面項目、入力条件、権限、データの流れを読み、期待結果を言葉にします。
品質管理では、Jira、Backlog、TestRailなどで、不具合の状態、優先度、再現手順、修正確認の履歴を残すことがあります。

テスト・QA系を目指すなら、最初の学習でも「ログインできるか」だけで終わらせないでください。
空欄、文字数上限、存在しないユーザー、権限違い、スマホ表示まで条件を分けると、テストの仕事に近い視点になります。
テストは作業の速さより、条件を分けて説明する力が残る分野です。

・サポート系で評価されやすい力｜IT基礎・説明力・トラブル対応力

サポート系を候補にするなら、IT基礎、説明力、トラブル対応力の3つを先に見てください。
ヘルプデスクやテクニカルサポートは、人と話す仕事に見えますが、実際には情報を整理して原因に近づく仕事です。

というのも、問い合わせが最初から技術的に正しい言葉で届くとは限らないからです。
「ネットが遅い」「ログインできない」「ファイルが開けない」と言われても、端末、アカウント、ネットワーク、権限、ソフトの設定など原因は分かれます。
相手の言葉を、確認できる項目に変換する力が必要なんです。

具体的には、IT基礎では、OS、ブラウザ、アカウント、メール、Wi-Fi、VPN、プリンター、Microsoft 365やGoogle Workspaceの基本を見ます。
説明力では、専門用語をそのまま投げず、「何を押すか」「どの画面を見るか」「次に何が表示されるか」を短く伝える練習が役立ちます。
トラブル対応力では、いつから起きたのか、誰の環境で起きるのか、再起動や別ブラウザで再現するのかを順番に聞きます。

サポート系で評価されたいなら、対応件数だけでなく、対応後に何を残したかを意識してみてください。
ナレッジ（再利用できる対応メモ）、FAQ、手順書、問い合わせ分類を作れる人は、社内SEやインフラ運用へ進むときにも説明材料を作りやすいです。
技術を深める入口として見るなら、電話対応の量より、原因調査まで触れるかを見たいところです。

・資格はどれを取るべき？ITパスポート・基本情報・CCNA・AWSの選び方

資格を選ぶなら、「有名だから取る」ではなく、目指す職種で不足している基礎を補う目的で選んだほうがよいです。
ITパスポート、基本情報技術者試験、CCNA、AWS認定は名前を聞く機会が多いですが、向いている職種と学習範囲は違います。

なぜなら、資格ごとに証明しやすい知識が違うからです。
ITパスポートはIT全般の共通知識を確認しやすく、サポート系や社内ITの入口で用語の地図を作るのに向いています。
基本情報技術者試験は、開発・運用・設計に関わるITエンジニアの基礎を広く見られるため、開発系やSE志望と相性があります。
CCNAはネットワーク基礎、AWS認定はクラウド基礎やAWSサービス理解を示しやすい資格です。

ざっくり選ぶなら、次のように分けると迷いにくいです。

目的・状況	おすすめ資格
IT未経験で用語から不安	ITパスポート
開発系やSEを目指す	基本情報技術者試験
ネットワークやインフラ寄り	CCNA
クラウド運用やAWS案件を見たい	AWS Certified Cloud Practitioner、またはAWS Certified Solutions Architect – Associate

私の場合、SEとして働く中で、プログラマーの延長のように設計や上流工程へ担当が広がっていきました。
そのときに感じたのは、資格そのものよりも、設計、開発、運用、セキュリティの言葉を同じ地図の上で見られることの助けです。
資格は内定を保証するものではありませんが、学習範囲を区切り、求人に出てくる単語を読める状態に近づける道具にはなります。

資格を取るなら、合格だけをゴールにしないでください。
ITパスポートなら社内ITの問い合わせ例、基本情報なら小さなプログラムやSQL、CCNAならpingやDNS確認、AWSならEC2やS3の役割まで、手を動かす材料とセットにします。
次の章では、ここまで整理した職種選びについて、未経験者がよく迷う質問に短く答えていきます。

◆13. よくある質問｜未経験者の職種選びに関する疑問

この章では、未経験者がエンジニア職種を選ぶときによく迷う質問に、短く答えていきます。
ここまで読んでも、最後は「自分の場合はどうなの？」が残りますよね。
長い説明に戻りすぎず、職種を絞る直前の確認メモとして使える形にします。

経済産業省とIPAが運営するマナビDXは、デジタル知識・スキルが身につく学びの場として公開されています。
学習できるスキルから探す欄には、データ活用、ソフトウェア開発、デジタルテクノロジー、セキュリティなどがあり、目指すロールから探す欄には、フロントエンドエンジニア、バックエンドエンジニア、クラウドエンジニア/SREなども並んでいます。
職種選びでも、肩書きだけでなく「どのスキルを使う入口なのか」を見たほうが、学習の迷子になりにくいです。
※参考: https://manabi-dx.ipa.go.jp/

・Q1. 未経験から一番なりやすいエンジニア職種はどれ？

未経験から入りやすい候補は、ヘルプデスク、テストエンジニア、運用監視、サポート系です。
それは、最初の作業を手順書、問い合わせ対応、テスト項目、監視アラートのように切り出しやすいからです。

具体的には、ヘルプデスクならPC設定やアカウント対応、テスト系なら画面操作と不具合報告、運用監視ならアラート確認から始まることがあります。
ただし、「なりやすい」と「伸びやすい」は別です。
最初の3ヵ月で何を覚え、半年後に原因調査や改善まで広がるかを見てください。

・Q2. プログラミングが苦手でも選べる仕事はある？

プログラミングが苦手でも、選べるIT職はあります。
候補になるのは、ヘルプデスク、テスト・QA、社内IT、インフラ運用、テクニカルサポートです。

理由は、ITの仕事がコードを書く作業だけで成り立っているわけではないからです。
問い合わせを整理する、テスト結果を記録する、ログを見る、手順書を直す、SaaS（インターネット経由で使う業務ソフト）を管理する仕事もあります。

とはいえ、プログラミングを完全に避けるより、ITの仕組みを理解するために少し触っておくほうが安心です。
HTMLの画面、SQLの簡単な検索、Linuxコマンドの確認くらいでも、会話についていきやすくなります。
「コードを書く職種」ではなくても、技術の言葉を読める状態は作っておきたいですね。

・Q3. 文系ならどのエンジニア職種が向いている？

文系なら、社内SE、ヘルプデスク、QA、SE、業務アプリ系が候補に入りやすいです。
というのも、これらの職種で、業務理解、文章力、説明力、調整力を使う場面が多いからです。

具体的には、社内SEなら社内の困りごとを聞き取り、SEなら要望を仕様に整理し、QAなら不具合を再現できる文章にします。
業務アプリ系では、販売、在庫、勤怠、経理などの流れを理解する力が役立つこともあります。

文系か理系かだけで職種を決める必要はありません。
見るべきなのは、1ヵ月後に触る作業が、画面作成なのか、問い合わせ整理なのか、仕様確認なのかです。
学歴より、作業を言葉にして説明できるかが差になりやすいですよ。

・Q4. 30代未経験なら、開発系とインフラ系のどちらを選ぶべき？

30代未経験なら、開発系かインフラ系かを年齢だけで決めるより、前職経験と生活リズムで分けるほうが現実的です。
コードを書く時間を増やしたいなら開発系、安定運用やクラウドに興味があるならインフラ系が候補になります。

なぜなら、30代では「何を学べるか」だけでなく、勤務時間、夜勤、質問しやすさ、前職で得た説明力や調整力をどう使うかも効いてくるからです。
私の経験でも、忙しいプロジェクトでは終電近くまで残業したことがありました。
職種名より、配属先の働き方を見ないと、学習以前に体力面でしんどくなることがあります。

具体的には、開発系ならJavaScript、Java、PHP、SQL、GitHubを触る時間を確保できるか。
インフラ系ならLinux、ネットワーク、クラウド、監視、シフト勤務の有無を確認します。
30代は「入りやすさ」より、1年後に続けられる働き方と説明できる経験を優先して見てください。

・Q5. インフラエンジニアとWebエンジニアはどちらが始めやすい？

始めやすさだけで見るなら、インフラ系の運用監視やサポート寄りの仕事のほうが入口を見つけやすい場合があります。
ただし、Webエンジニアも、改修、テスト、保守から入る求人なら未経験の入口になります。

というのも、インフラ系には監視、手順書対応、ログ確認のように作業を切り出しやすい領域があるからです。
一方でWeb系は、ポートフォリオ（自分で作った成果物）やGitHub、画面実装の経験を求められることがあります。

選ぶときは、どちらが簡単かではなく、最初に何を触るかで見てください。
Linuxやネットワークに抵抗が少ないならインフラ系。
画面や機能を作るのが好きならWeb系。
迷ったら、Linuxの基本操作とHTML/CSSの小さなページ作成を両方1週間ずつ触ると、相性が見えやすいです。

・Q6. テストエンジニアから開発職に移ることはできる？

テストエンジニアから開発職に移ることはできます。
ただし、テスト実行だけで止まらず、仕様理解、エラー調査、SQL、簡単なコード修正へ近づく必要があります。

それは、開発職で見られるのが「テスト経験があるか」ではなく、システムの動きをどこまで理解しているかだからです。
不具合の再現手順、画面とAPIの関係、データベースの値、ログの内容まで見られると、開発側の会話に入りやすくなります。

具体的には、テスト中に見つけた不具合について、どの入力で起きたのか、どの画面で起きたのか、どのデータが関係しそうかをメモします。
余力があれば、JavaScriptやSQLで小さな成果物を作って、開発職に移る材料を別で用意しておくと安心です。
テストは入口になりますが、開発へ移るには作る経験も足したいところです。

・Q7. ヘルプデスクから始めるのは遠回り？

ヘルプデスクから始めるのは、目的によっては遠回りではありません。
社内SE、インフラ運用、SaaS管理、テクニカルサポートへ進みたい人には、かなり近い入口になります。

というのも、ヘルプデスクで端末、アカウント、ネットワーク、業務システム、問い合わせ記録に触れられるからです。
利用者が何に困るのかを知っている人は、社内ITやサポート系で強みを出しやすいんですよね。

ただし、開発職を最短で目指すなら、ヘルプデスクだけではコードを書く経験が不足しやすいです。
遠回りにしないためには、問い合わせ対応だけで終わらせず、ナレッジ作成、原因調査、SaaS設定、簡単な自動化に触れる機会を見てください。
同じヘルプデスクでも、担当範囲で次の行き先はかなり変わります。

・Q8. AIエンジニアは未経験からいきなり目指せる？

AIエンジニアを未経験からいきなり目指すのは、難しめです。
なぜなら、Pythonだけでなく、データ整理、統計、機械学習、モデル評価、セキュリティ、業務理解まで関わるからです。

具体的には、生成AIを使う仕事でも、プロンプトを書くだけでなく、回答の正確性、社内データの扱い、個人情報、誤回答の確認が出てきます。
機械学習なら、学習データ、評価指標、前処理（分析前にデータを整える作業）も必要です。

未経験から近づくなら、AIエンジニアの肩書きだけを狙うより、データ集計、SQL、PythonでのCSV処理、AIツール導入補助、評価データ作成から見るほうが現実的です。
「AIを作る人」より先に、「AIで使うデータを整え、結果を確認できる人」を目指すと距離を縮めやすいです。

・Q9. リモートワークしやすい職種はどれ？

リモートワークしやすいのは、作業がオンラインで完結しやすい職種です。
候補は、Web開発、バックエンド開発、クラウド運用、データ集計・分析補助、QAの一部になります。

なぜなら、コード、設計書、チケット、レビュー、テスト結果、ダッシュボードをクラウド上で扱える仕事ほど、場所に縛られにくいからです。
一方で、PCキッティング（初期設定）、ネットワーク機器作業、オンサイト保守、社内端末対応は出社が残りやすくなります。

未経験者の場合、最初の1ヵ月〜3ヵ月は研修や質問のために出社するケースもあります。
「リモート可」だけで判断せず、週の出社日数、研修期間、端末作業、障害時対応、使用ツールを見てください。
リモート向きかどうかは、職種名より作業の管理方法で決まります。

・Q10. 将来性が高いエンジニア職種を選ぶなら何を見るべき？

将来性を見るなら、職種名の流行より、AIやクラウドを使っても残る判断業務に近づけるかを見てください。
開発、インフラ、QA、データ、セキュリティのどれでも、設計、改善、品質確認、運用判断に関われるほど経験が残りやすいです。

それは、技術名そのものより、現場で「何を任されるか」がキャリアの材料になるからです。
たとえば、開発ならレビューや設計、インフラならクラウド運用と障害対応、QAなら品質分析、データ系なら集計結果の説明が評価されやすくなります。

見るポイントは、次の3つです。

• 半年後に増える担当範囲
• 1年後に説明できる成果物
• 3年後に移れる職種や工程

将来性が高い職種を一発で当てるより、将来性のある作業へ近づける入口を選ぶほうが現実的です。
次の章では、ここまでの内容をまとめ、未経験者が職種一覧をどう使って最初の候補を絞ればよいかを整理します。

◆まとめ｜未経験者は「職種一覧」を見るだけでなく、自分に合う入口を選ぼう

この記事では、未経験者がエンジニア職種を選ぶときに見るべき仕事内容、初期業務、学習内容、働き方、将来ルートを整理してきました。
ここまで読んだなら、もう「なんとなくWeb系」「とりあえずAI」のまま選ぶ段階ではありません。
職種一覧は眺めるための表ではなく、最初の入口を絞るための地図として使ってみてください。

厚生労働省のハロートレーニングでは、希望する仕事に就くために必要な職業スキルや知識などを習得できる公的制度として、公共職業訓練や求職者支援訓練などが紹介されています。
職種を選ぶときも同じで、先に肩書きを決めるより、「その仕事で必要になる知識やスキルをどう身につけるか」まで見たほうが、次の行動に移しやすいです。
※参考: https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/jinzaikaihatsu/hellotraining_top.html

・この記事の要点｜仕事内容・初期業務・将来性をセットで比較する

この記事の要点は、エンジニア職種を「仕事内容」だけで選ばないことです。
未経験者が見るなら、仕事内容、最初に任されやすい業務、将来どこへ広げられるかをセットで比べたほうが、入社後のズレを減らしやすくなります。

というのも、同じエンジニアでも、入口の作業がかなり違うからです。
Webエンジニアなら画面改修やテストから入ることがありますし、インフラ系なら監視や手順書対応、QAならテスト実行や不具合報告から始まるケースがあります。
職種名だけを見ると似ていても、最初の30日で触るものは、コード、ログ、テストケース、問い合わせ、Excel、SQLのように分かれます。

具体的には、候補職種を見るときに次の3点を並べてください。

• 最初に担当しそうな作業
• 3ヵ月後に増えそうな技術やツール
• 1年後に説明できそうな成果物

この3つが見える職種は、学習の順番も作りやすいです。
逆に、名前はかっこよく見えても、最初に何を触るか分からない職種は、まだ判断材料が足りません。
職種一覧はランキングではなく、自分が次に触る作業を見つけるための確認表として使うと迷いにくいですよ。

・迷ったときは「入りやすさ」と「伸ばしたいキャリア」を分けて考える

迷ったときは、入りやすさと伸ばしたいキャリアを分けて考えるのがおすすめです。
入りやすい職種が悪いわけではありませんし、難しい職種を最初から諦める必要もありません。
でも、この2つをごちゃ混ぜにすると、「入れそうだから選ぶ」「稼げそうだから選ぶ」のどちらかに寄りやすいです。

なぜなら、入口で求められる力と、2年後・3年後に評価される力が違うからです。
ヘルプデスクなら最初は問い合わせ整理が中心でも、社内SEへ進むなら端末管理やSaaS設定の経験が効きます。
テスト系ならテスト実行から入りやすい一方で、QAへ広げるならテスト設計や不具合分析まで見たいところです。

私自身、長くSEとして働いてきて、肩書きよりも「どの工程を任されたか」「どこまで自分で説明できるか」のほうが、キャリアを話すときに効くと感じています。
同じ開発寄りの仕事でも、改修だけなのか、設計まで触ったのか、他チームとの確認まで任されたのかで、次に話せる内容は変わるんですよね。

だから、候補を選ぶときは次のように分けてください。

分類	内容
早くIT業界に入る入口	ヘルプデスク、テスト、運用監視、サポート
伸ばしたい方向	開発、クラウド、QA、社内SE、データ、セキュリティ
つなぎ方	半年後に増やす作業、1年後に書ける成果、3年後に移れる職種

この分け方をすると、「最初の職種で全部決まる」という不安が少し薄まります。
最初の職種はゴールではなく、次の職種へ渡す材料を集める場所です。
入口の近さと、その後に伸ばしたい方向を別々に見るだけで、選び方はだいぶ落ち着きます。

・次にやること｜気になる職種を3つに絞り、必要スキルを確認しよう

次にやることは、気になる職種を3つに絞ることです。
多くても3つまでにしておくと、学ぶスキル、見る求人、作る成果物が散らばりにくくなります。
10職種を浅く追うより、3職種を深く比べるほうが、次の1週間の動きが決まりやすいです。

具体的には、紙でもメモアプリでもよいので、次のように書いてみてください。

候補	確認するポイント
第1候補	最初に触りたい作業
第2候補	働き方や学習量の相性
第3候補	将来広げたいキャリア

そのうえで、各職種に必要なスキルを1つずつ置きます。
Web系ならHTML/CSSやJavaScript、インフラ系ならLinuxやネットワーク、QAならテスト設計、サポート系ならIT基礎と説明力。
ここまで書けると、「何から勉強すればいいのか」が少し具体的になります。

最後に、候補ごとに求人を3件ずつ見て、最初の業務内容だけを抜き出してください。
給与やリモート条件より先に、研修後に何を任されるのか、どのツールを使うのか、誰とやりとりするのかを確認します。
その作業に抵抗が少ない職種から、学習を始めてみてください。
職種一覧を見終えたあとに必要なのは、全部を覚えることではなく、自分が最初に踏み出す入口を1つ決めることです。