未経験でヘルプデスクから開発へ進めるか｜道筋の作り方

応募を続けても書類が通るのはヘルプデスクや運用保守ばかり。そんな状態が続くと、「ここに入ったら開発には戻れないのでは」という不安が出てきます。SNSでは「ヘルプデスクは避けろ」という声も流れてきます。迷って当然だと思います。

ここでは、ヘルプデスクに入るべきかどうかより、入ったあとに何をすれば開発やインフラの仕事に移れるのかを書きます。

ヘルプデスクから開発・インフラには進めるのか

進めます。移れるかどうかは、ヘルプデスクを何年やったかより、在籍中に担当外のどんな業務まで引き受け、それをどう説明できるかで決まります。

代表の米田は、未経験からだといきなり開発に入りたいと思いがちだけれど、最初にヘルプデスクを1年しっかりこなすのも立派なキャリアだと言っています。大事なのは、そこからステップアップできるかどうかです。最初の職種名より、入ったあとに何をするかで、その後に選べる仕事が変わります。

「未経験→ヘルプデスク→詰み」と言われる理由

詰むとしたら、それは職種名のせいではありません。問い合わせの一次対応だけを何年も繰り返し、その記録も残っていない状態が続くからです。同じ作業を反復すると、経験年数は増えても説明できる材料が増えません。だから次の選考で語れることが去年と同じになります。

インフラや開発と重なる業務

ヘルプデスクの仕事には、インフラ職と重なる領域がいくつもあります。PCやサーバのOS設定、社内ネットワーク、ADなどの認証基盤、資産管理、ログの確認。このあたりは、インフラ職が最初に任される範囲とほぼ同じです。問い合わせ対応の仕組み化や、手順の自動化・スクリプト化は、開発の仕事に近い作業です。

開発とインフラのどちらに進むかについて、米田はどちらでも行けるという見方です。個人開発をしっかりやっていれば、それがアピールポイントになって開発に進むこともできる、と。開発とインフラのどちらかを選んだら、もう一方には進めなくなるというわけではありません。

なぜ未経験の開発職はこれほど狭き門なのか

応募する人の能力より、未経験者を育てる余力がある会社が限られていることが理由です。

開発の現場で未経験者を受け入れるには、レビューや質問対応に先輩の時間が要ります。その余力を確保できる会社は多くありません。だから求人の総数に対して、未経験可の開発職は少なくなります。ここで落ちても、それはあなたの評価が確定したという意味ではないんです。

求人票の職種名と、実際の業務の幅はずれることがある

「ヘルプデスク」と書かれていても、実務では社内システムの設定変更や簡単な構築補助まで含む職場があります。逆に「インフラエンジニア」の名前で、実態は監視画面のアラート一次対応だけという場合もある。職種名は目安にして、実際に担当する業務を確かめてください。

拾ってくれる入口から入るという選択

米田は、経験が浅いうちのSESについて「個人的な意見として」おすすめだと言っています。理由は、会社や先輩たちの信頼で仕事をもらえることと、経験が浅い人を拾ってくれる場所が他に少ないこと。経験を積んでからSESを選ぶよりは良い、という立場です。

ヘルプデスクも同じように、経験の浅い人を受け入れてくれる職場です。問題になるのは、入ったまま新しい業務を覚えずに年数だけが過ぎることです。

ヘルプデスクの1年で何が積み上がるのか

ITの現場でしか身につかない知識と経験が得られます。ただし、それを説明できる形で残しておかないと、選考では使えません。

技術面では、OSの挙動、ネットワークのつながり方、認証やアカウント管理、資産の管理方法、ログの読み方。これらは書籍だけで理解するのが難しい領域で、実際のトラブルに対応した人のほうが理解が早い分野です。

もうひとつがポータブルスキルです。ENFIのBE-DO-HAVE棚卸しでは、未経験の方のHaveに「ポータブルスキル」の欄を置いています。障害が起きたときにどこから切り分けるか、非エンジニアに分かる言葉で説明できるか、対応の記録を後から読める形で残せるか。どれも、職種が変わっても使えるスキルです。

一方で、職務経歴書に「月間◯件対応」とだけ書いて終わってしまう人は多いです。件数より、どんな症状をどう切り分け、何で解決し、再発防止に何をしたかを書いてください。ここまで書くと技術的な思考の跡が読み取れます。

米田は、個人開発で使っている技術があればスキルシートに書くべきだとも言っています。立派なアピールポイントになるし、面接でも必ず聞かれるからです。

ステップアップできる人がやっていること

差がつくのは環境の当たり外れよりも、業務時間の外で何を続けているかです。

米田にこの質問をしたとき、答えは「個人開発や資格勉強を続けているかどうか」でした。通勤時間や昼休み、寝る前など、1日のうち少しでも学習に充てているかが大きな違いになる、と話します。まとまった時間を作ろうとして何も始まらない、というのが一番もったいないパターンです。

もうひとつは、業務での動き方です。依頼が来たら処理して終わる人もいれば、同じ依頼が3回来たら手順書にまとめたり、スクリプトにしたりする人もいます。後者は、問い合わせに対応するだけでなく、対応の仕組みを作る仕事を始めています。手順書やスクリプトを作った経験は、そのまま職務経歴書に書けます。

記録が残っているかどうかでも差がつきます。ENFIのQUESTでは、作ったものと、作る過程・運用の記録をGitHubに残し、面接で説明できるようにしています。ヘルプデスクの仕事でも、作った手順書や書いたスクリプト、切り分けの記録を残しておけば、選考で話す材料になります。

入社前・在籍中に見るべきチェックポイント

見るのは職種名より、その会社がどんなビジネスで稼いでいるかです。米田は年収について「その会社がどんなビジネスをしているかが大事」「年収はスキルより環境で決まる」と言っています。担当できる業務の幅も、同じように会社のビジネス構造で決まります。

見る観点	次につながりやすい兆候	止まりやすい兆候
業務範囲	構築補助や運用自動化に触れる機会がある	問い合わせ一次対応で固定されている
異動・担当変更	実際に領域を変えた人の話が聞ける	前例を聞いても出てこない
社内の人材構成	技術選定や運用設計をしている人が社内にいる	設計は発注元、社内は対応のみ
記録の文化	ナレッジや手順が共有・更新されている	属人的で口頭中心

面接で聞くなら、「入社1年後、この役割の人はどんな業務まで担当していますか」という一問が使いやすいです。抽象的な回答しか返ってこないなら、それも情報になります。

転職だけが選択肢ではない

今の環境を辞める以外にも打ち手はあります。社内で担当を広げていくこと、社内異動、学び直し、転職。この4つを並べたうえで選ぶほうが、後悔は少なくなります。

一番早く試せるのは、今の場所で担当を広げていくことです。今の職場で手順の自動化や構築補助に手を挙げてみる。動かないなら異動の可否を確認する。並行して学び直しを進める。そのうえで環境そのものを変える必要があると判断したときに、転職を選ぶ。順番としてはこれが現実的だと思います。

ENFIは転職ありきで話をしません。スキルや年収の話の前に、自分が何を大事にしたいかと、今どこまでできるかを整理して、進む方向を決めます。その結果として今の場所に残るなら、それも立派な選択です。米田自身も、SESでスキルをつけたら転職でキャリアアップも考えよう、という言い方をしています。先にスキルと説明できる実績をつけておかないと、環境を変えても同じ悩みが続きます。

代表・米田の視点 今は開発職に就くための準備期間と捉えます。実務で学べるスピードも案件によりますから、個人開発や資格学習でそれ以上の知識や経験を身につけることって、無理な話じゃないんです。マインド次第でいくらでも逆転は可能だと思っています。

BE-DO-HAVEで今の自分とありたい姿を書き出す

整理の順番はHave（今持っているもの）、Be（5年後の理想）、Do（今すべきこと）です。スキルや年収の話は、この後に来ます。

多くの人はDoから考え始めます。何を勉強するか、どの資格を取るか。でもHaveとBeが埋まっていないと、Doが他人のロードマップのコピーになります。

未経験の方向けの設問はこうなっています。Haveには現在の学習状況と成果物、前職から持ち込めるポータブルスキル、自分の資質。Beには目指す技術領域（フロント、バック、AI、インフラ）、働き方、なりたい人物像。Doには3ヶ月以内の行動、入社1年目の動き、自走力をどう証明するか。

ヘルプデスクの方がHaveを書くときのコツは、件数ではなく中身を書くことです。「プリンタ不具合30件」ではなく「印刷できない症状で、ドライバとネットワーク経路を切り分けた」。こう書くと、自分でも何ができるようになったかが見えてきます。Haveに書けるものがない、と思い込んでいる人ほど、書き出すと出てきます。

今日からできる次の一歩

1. Haveを1問だけ書く。直近1ヶ月で対応した案件を3件挙げて、何を調べて何で解決したかまで書く
2. Beを1行で書く。5年後、どの領域の人と呼ばれたいか

そのうえで、現職の上司か応募先に対して「1年後、この役割はどこまで業務範囲が広がりますか」と聞く質問をひとつ用意しておいてください。答えを聞くまでは、判断材料が足りていない状態です。