テクニカルサポートの開発職転職はなぜ未経験扱いか

「SQLで原因を特定して、直接データを補正したこともあります」——そう面接で説明しても、書類選考の結果はいつも「開発未経験」のまま動かない。テクニカルサポートを担当してきた方から、こういう相談をよく受けます。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、同じ経験年数でも、テクニカルサポート出身者は開発職出身者に比べて書類選考の通過率が明らかに低い傾向があります。今回は、なぜ書類選考の段階で一律「未経験」扱いされてしまうのか、その構造と、SQL・ログ解析・スクリプト修正の実務を職務経歴書上の開発経験としてどう翻訳し直すかを、相談事例をもとにお伝えします。

目次

1. テクニカルサポートが開発職の書類選考で未経験扱いされる理由
2. 相談事例、Mさんが書類で落ち続けた理由
3. 職務経歴書のBefore、実績が「対応」で止まっていた
4. 開発経験として翻訳し直す、Before/Afterの実例
5. 書き直した後、Mさんの書類選考はどう変わったか
6. 面接で「本当に未経験じゃないですよね」と念押しされたときの答え方
7. データで見る、テクニカルサポート経験者はどの開発職に転身しているか
8. 書類選考を通過させるための職務経歴書の書き方
9. テクニカルサポートから開発職へ、狙い目の求人の見極め方
10. よくある質問に答えます
11. まとめ、未経験扱いは職種名ではなく書き方の問題

テクニカルサポートが開発職の書類選考で未経験扱いされる理由

書類選考の一次仕分けは、必ずしも人が一件ずつ丁寧に読んで判断しているわけではありません。応募が集まる求人ほど、まず職種名や必須要件のキーワードで機械的にふるいにかけられ、そこを通った分だけ担当者が中身を読みます。「開発実務経験3年以上」という応募資格は、字面通りにこの一次仕分けの基準として使われることが多いのが実情です。

肩書きが「テクニカルサポート」であるというだけで、実際の業務にコードやSQLがどれだけ含まれていても、キーワードマッチの網には引っかかりません。エージェントの初期仕分けでも同じことが起きます。職種欄が「サポート」となっている経歴を見た瞬間に、開発経験ゼロの候補者として扱う担当者は少なくありません。

もう一つの理由は、職務経歴書の書き方そのものにあります。テクニカルサポートの実績は「顧客対応」「問い合わせ対応件数」「対応満足度」といった顧客接点の成果を中心に書かれがちで、その中に埋もれているSQLやログ解析の技術的な中身が、読み手に伝わる形で言語化されていません。

ポイント： 求人票の「開発実務経験◯年以上」は機械的なキーワードマッチで足切りされやすく、実務の中身がどれだけ開発的でも、職種名と職務経歴書の書き方が変わらなければ「未経験」の箱から出られません。

この二つが重なると、実務としては開発に近い仕事をしていても、書類の上では一律「未経験」として処理されてしまいます。テクニカルサポート出身者の転職で見落とされがちなのはここで、選考担当者が読んでいるのは職務経歴書に書かれた言葉であって、実際にやってきた業務そのものではありません。

求人票の応募資格欄を見ると、「開発実務経験3年以上(言語不問)」「Web系企業での開発経験がある方」のように、経験年数と業界の組み合わせで足切りラインが引かれているケースが目立ちます。この文言は、応募が集中する人気企業ほど機械的な仕分けの基準として厳密に運用されやすく、担当者が経歴の中身まで読み込む前に、職種名だけで対象外に分類されてしまう場面が実際にあります。

エージェント経由の応募でも構造は同じです。担当者が一日に何十件もの経歴書に目を通す中で、「テクニカルサポート」という肩書きを見た瞬間に開発未経験カテゴリへ振り分ける判断は、悪意があってのことではなく、時間の制約の中で効率よく仕分けるための実務的な習慣です。この習慣を崩すには、応募者側が先回りして「これは開発経験です」と読み取れる書き方をしておくしかありません。

相談事例、Mさんが書類で落ち続けた理由

Mさん(31歳・経験7年)は、独立系SIerのサポートセンターで、業務システムパッケージの導入後サポートを担当していました。顧客からの問い合わせに一次対応するだけでなく、SQLで会員データベースを直接参照して不整合の原因を特定したり、アプリケーションログを解析して障害の切り分けを行ったり、パッケージのカスタマイズ部分にあたるPythonスクリプトの軽微な修正まで任されていました。

自社開発企業のアプリケーションエンジニア職に絞って応募したところ、8社に出して7社が書類選考で見送りになりました。唯一通過した1社の一次面接でも、面接官から「開発は未経験ですよね」と念押しされ、Mさんは「実務でSQLもログ解析もやっているのに、なぜ未経験だと判断されるのか」と相談に来ました。

職務経歴書を見せてもらうと、原因はすぐに分かりました。業務内容の記述が「各種システム対応」「顧客からの不具合報告への対応」という、サポート業務の枠組みでしかまとめられていなかったのです。SQLやログ解析、スクリプト修正という開発的な要素は、文章のどこにも固有名詞として出てきていませんでした。

Mさん自身は、面接に呼ばれれば技術的な話をきちんと説明できる自信がありました。実際、唯一通過した1社の一次面接では、口頭でSQLのJOIN句を使った調査手順まで具体的に話しています。ところが面接官の反応は「なるほど、サポート業務の中でそこまでやっていたんですね」という驚きの反応で、事前に職務経歴書からその情報を読み取ってもらえていなかったことが、そのやり取りからも分かりました。

職務経歴書のBefore、実績が「対応」で止まっていた

書き直す前のMさんの職務経歴書には、次のような記述が並んでいました。

すべての項目が「対応した」という動詞で終わっており、何を使って、どういう手順で、どこまで踏み込んで作業したのかが読み取れません。SQLでどんなクエリを書いたのか、ログのどこを見て何を判断したのか、スクリプトのどの部分をどう直したのかという、開発職の選考担当者が本当に知りたい情報が、すべて「対応」の一言に圧縮されてしまっていました。

これでは、選考担当者が「開発経験あり」と読み替える手がかりがありません。書けることを書いていないだけで書類選考に落ちているケースは、テクニカルサポート出身者に限らず珍しくありませんが、Mさんの場合は特にその落差が大きい事例でした。

開発経験として翻訳し直す、Before/Afterの実例

Mさんと一緒に、日々の業務を一つずつ分解し、開発職の選考担当者が読んで技術的な中身が伝わる言葉に書き直しました。JACの職務経歴書サンプルでも、テクニカルサポートの技術業務を「環境/対応レベル」欄で使用言語や対応区分まで具体的に書く例が紹介されていますが、Mさんの職務経歴書にはこの粒度が丸ごと欠けていました(参考：JAC Recruitment「テクニカルサポートの職務経歴書サンプルと書き方」)。

自己PR欄の書き換えも見落とせないポイントでした。Beforeの「両立に自信があります」という表現は、何が強みなのかが具体的に伝わらず、どの職種にも使い回せる汎用的な文章になっていました。Afterでは「顧客の一次情報」から「技術的な原因特定」までの流れを一つの強みとして言語化し、開発チームだけでは気づきにくい顧客側の文脈を補える人材だという打ち出し方に変えています。

同じ業務でも、使用した技術・作業の手順・関わった範囲を固有名詞と数字で書き出すと、読み手に伝わる情報量がまったく違います。この書き換えを通じて改めて感じたのは、開発未経験と経験ありを分けているのは、業務内容そのものより言語化の解像度だという手応えでした。

書き直す過程で、Mさん自身も「自分がここまでコードやDBに触れていたことを、今まで言葉にしていなかった」と話していました。日々の業務の中では当たり前すぎて、わざわざ説明する必要を感じていなかったのだと思います。

書き直した後、Mさんの書類選考はどう変わったか

職務経歴書を書き直した後、Mさんは応募する求人の絞り込み方も見直しました。社内SE求人を含めて手当たり次第に応募するのではなく、パッケージ導入後の保守開発を担うアプリケーションエンジニア職に対象を絞り、6社に応募し直しました。結果、4社が書類選考を通過し、最終的に2社から内定が出ました。

Mさんが選んだのは、現職より月給で言うと年収換算約27万円高いオファーを出した企業でした。決め手になったのは金額だけでなく、面接で職務経歴書に書いたスクリプト修正の内容について「どのくらいの規模の改修だったか」「レビューはどう受けていたか」と具体的に踏み込んで聞かれ、答えに詰まらずに済んだことだったとMさんは振り返っています。

書類選考の通過率が上がったこと以上に大きかったのは、面接で聞かれる質問の質そのものが変わったことです。書き直す前は「開発経験はどこまでありますか」という前提を疑う質問から始まっていましたが、書き直した後は「その改修の技術的な判断」を聞かれるようになりました。選考担当者がどこから話を始めるかは、職務経歴書の書き方一つで変わる——Mさんの転職活動は、それをそのまま体現していました。

面接で「本当に未経験じゃないですよね」と念押しされたときの答え方

職務経歴書を書き直しても、面接で改めて開発経験の有無を確認されることはあります。Mさんが4社目の一次面接で聞かれたのは「職務経歴書には開発的な内容が書いてありますが、実際の役割としては開発チームのサポート側だったのでは」という質問でした。ここで曖昧に答えると、書類上の印象がひっくり返ってしまいます。

Mさんが実際に答えたのは、役割の境界線をそのまま説明することでした。「クエリの作成と原因特定までは自分で行い、実装方針が固まった後の本番コードへの反映は開発チームが担当していました。ただしスクリプト修正についてはPull Requestの作成まで自分で行い、レビューを受けて本番反映していました」という形で、どこまでが自分の作業でどこからが開発チームの作業だったかを、曖昧にせず線引きして話しています。

この答え方が効いたのは、開発経験を過大に見せようとしなかった点です。役割の境界線を正直に説明した方が、誇張した回答より信頼されるというのは、面接に限らず職務経歴書全体にも言えることだと私は考えています。境界線を隠さずに話せる人は、書類に書いた内容と面接での説明に矛盾が生まれにくく、結果的に技術力そのものより「話の一貫性」で評価が上がることがあります。

データで見る、テクニカルサポート経験者はどの開発職に転身しているか

doda「テクニカルサポート/ヘルプデスクとはどんな職種？」によると、テクニカルサポート・ヘルプデスク経験者の平均年収は383.8万円、年収分布では300万円台が最多の40%を占めています。転職後の職種内訳を見ると、社内SEが32.2%と最も多く、アプリケーションエンジニアが8.6%、サーバーエンジニアが6.8%と続いています(出典：doda「テクニカルサポート/ヘルプデスクとはどんな職種？」)。

一方でJAC Recruitmentの「テクニカルサポートの転職事情」では、想定平均年収734.7万円という数字が紹介されています。ただしこれはJACに登録しているハイクラス層を中心とした母集団の数字であり、doda(383.8万円)とは対象層がまったく異なるため、単純に比較して「転職すれば年収が倍になる」と読むのは早計です。JACの記事ではキャリアパスとしてSE・社内SE・プロダクトマネージャーへのルートが挙げられています(出典：JAC Recruitment「テクニカルサポートの転職事情」)。

このデータを見て私が気になるのは、転職後に社内SEを選ぶ人が突出して多いという点です。社内SEは「未経験可」を掲げる求人が相対的に多く、書類選考の入り口として通りやすい面があります。ただしMさんのように、職務経歴書の書き方さえ変えれば、アプリケーションエンジニア職を直接狙うルートも十分に通る余地があります。今回の事例は、その余地の広さを裏付けていると私は見ています。

書類選考を通過させるための職務経歴書の書き方

Mさんの書き換えを一般化すると、テクニカルサポート出身者が職務経歴書で意識すべき点は次の3つに集約できます。

Geeklyの職務経歴書ガイドには、同社の書類添削・代行サービスを使った場合に書類通過率が「3.4倍」に上がったという自社調査(2022年8月時点)が紹介されています。これはテクニカルサポート特有の数字ではなく同社のサービス全体の実績値なので、そのまま鵜呑みにはできませんが、書き方一つで通過率がそれだけ動きうるという方向性自体は、Mさんの事例で見た変化とも重なります(参考：Geekly「テクニカルサポートの職務経歴書の書き方」)。

数字を入れる際は、キリの良すぎる数字よりも、実際に数えた実感のある数字を使う方が説得力があります。Mさんの「月平均3件」「担当案件の約7割」という数字も、後から集計して出したものではなく、日々の業務の感覚に近い粒度でした。

テクニカルサポートから開発職へ、狙い目の求人の見極め方

「未経験可」と書かれた求人には、応募資格のキーワードマッチで漏れた人を拾うために用意されている枠と、本当に育成前提で採用している枠の二種類が混ざっています。この見分け方は「未経験可」求人票の言葉の温度差を読み解く記事で詳しく書きましたが、業務内容欄の解像度(担当する言語やツールまで具体的に書かれているか)を見ると判断しやすくなります。

未経験可の求人を見分けたうえで、実際に応募する段になれば、今度は職務経歴書の書き方が結果を左右します。この点は職務経歴書が書類選考で通らない理由を扱った記事とも重なりますが、テクニカルサポート出身者の場合は特に、業務内容の記述が「対応」で止まっていないかを一つずつ点検する価値があります。

テクニカルサポートからの転身先としては、社内SE・アプリケーションエンジニア(保守開発)・QAエンジニアの3つが現実的な選択肢になります。社内SEは書類選考のハードルが比較的低い代わりに、開発そのものへの深入りは限定的になりがちです。アプリケーションエンジニアは書類選考のハードルは上がりますが、Mさんのように実務内容を翻訳し直せば十分に狙える範囲です。QAエンジニアは、ログ解析や不具合の切り分け経験をそのまま評価されやすく、開発職への足がかりとして選ぶ人もいます。

社内SEの求人票では「業務システムの運用・保守経験」が歓迎要件として書かれることが多く、テクニカルサポートで培った障害対応の経験がそのまま評価されます。ただし配属後の実務が運用寄りに偏り、コードを書く機会が想定より少ないという声も聞くので、求人票の「開発」の中身がどこまで手を動かす業務なのかを、面談段階で具体的に確認しておく必要があります。

アプリケーションエンジニア(保守開発)の求人は、既存システムの改修・不具合修正が中心になることが多く、ゼロから新規開発を任される求人よりも、Mさんが積んできたスクリプト修正やデータ調査の経験と地続きです。QAエンジニアは、テストの実行だけでなく不具合の原因切り分けまで担当する求人であれば、ログ解析の経験がそのまま強みになりますが、テスト実行のみに限定された求人だと開発への接続が薄くなる点には注意が必要です。

どのルートを選ぶにしても、職務経歴書に書く内容を「サポート業務としての実績」から「開発業務としての実績」に書き換える作業は避けて通れません。オンプレ環境しか経験のないインフラエンジニアがクラウド未経験のまま転職する際にも、経験を相手の言葉に翻訳し直す作業が通過率を左右しますが、これはテクニカルサポートから開発職への転身でもまったく同じ構造だと私は見ています。

よくある質問に答えます

テクニカルサポートの経験は何年あれば開発職に応募できますか。 年数そのものより、日々の業務にSQL・ログ解析・スクリプト修正といった技術要素がどれだけ含まれていたかが重要です。Mさんは経験7年でしたが、経験3年程度でも技術要素の比重が高ければ、書き方次第で開発経験として通用する場面を見てきました。逆に経験年数が長くても、顧客対応の窓口業務しかしていない場合は、開発経験として翻訳できる材料自体が乏しくなります。

ITILやベンダー資格は書類選考で有利になりますか。 ITILなどの資格は、運用プロセスの理解を示す材料としては評価されますが、開発経験の代わりにはなりません。資格欄に並べるだけでなく、その資格を使ってどんな業務改善や障害対応をしたかを、具体的なエピソードとして職務経歴書に落とし込む方が書類選考には効きます。

「未経験可」の求人ばかり受けた方がいいですか、経験者向け求人にも出すべきですか。 職務経歴書を書き直した後は、経験者向け求人にも出す価値があります。Mさんも「未経験可」表記のない求人に対して書き直した職務経歴書で応募し、通過しています。「未経験可」の表記の有無だけで応募先を絞り込むと、翻訳し直せば通る求人まで最初から除外してしまうことになりかねません。

エージェントに相談する場合、何をどう伝えればいいですか。 「テクニカルサポートをしていました」とだけ伝えると、担当者側も社内SE中心の求人しか紹介できません。SQLでどんな調査をしていたか、ログ解析でどこまで踏み込んでいたか、スクリプト修正にどう関わっていたかを、面談の最初の段階で具体的に話すことで、担当者が紹介できる求人の幅が変わります。

まとめ、未経験扱いは職種名ではなく書き方の問題

Mさんのケースが示しているのは、テクニカルサポートという職種名そのものが書類選考の壁になっているわけではないということです。壁になっているのは、SQLやログ解析、スクリプト修正という開発的な業務が、職務経歴書の中で「対応」という一言に圧縮されたまま埋もれている状態です。

書類選考の担当者は、応募者が実際にやってきたことではなく、職務経歴書に書かれた言葉だけを見て判断します。やってきたことを、相手が読み取れる言葉に翻訳し直せているかどうかが、未経験扱いされ続けるか、開発経験として認められるかの分かれ目だというのが、今回の相談事例を通じて一番伝えたかったことです。