ガチャ外れエンジニアの職務経歴書術

「配属先がずっと客先常駐で、自分の会社に帰属している感じがしない」「スキルが積み上がっているのか、よく分からない」——そんなもやもやを抱えたまま働いている20代エンジニアは、けっして少なくありません。

いわゆる"配属ガチャ"に外れたと感じているあなたでも、職務経歴書の書き方を工夫するだけで、自社開発企業や社内SEへの転職は十分に狙えます。この記事では、現場経験をどう整理し、どう伝えれば採用担当者の目に留まるのかを、ステップごとに解説していきます。

---

なぜ職務経歴書の書き方が合否を左右するのか

転職活動では書類選考が最初の関門です。面接にたどり着く前に、多くの候補者が職務経歴書の段階で落とされています。

特に自社開発企業や社内SE職は、スキルの中身よりも「どう働いてきたか」を重視する傾向があります。派遣・常駐型の経歴でも、書き方次第で「こういう人と一緒に働きたい」と思わせることができます。

反対に、技術スタックを羅列しただけの職務経歴書は、読み手に何も刺さりません。大切なのは「あなたがどんな問題をどう解決してきたか」という物語を、簡潔に届けることです。

採用担当者が職務経歴書で見ているもの

採用担当者が職務経歴書を読む時間は、最初の一読で30秒前後と言われています。その短い時間に「この人は使える」と感じてもらうには、次の3点が伝わっている必要があります。

• 何をしてきたか（業務内容・担当領域）
• どんな成果・変化を生んだか（定量・定性を問わず）
• 自分で考えて動けるか（主体性・成長意欲）

客先常駐やSES(エンジニアを企業に派遣する働き方)の経験は、一見「自社開発とは遠い」と思われがちです。しかし、書き方を変えるだけで印象は大きく変わります。

---

ステップ1 — 経験を棚卸しする

職務経歴書を書く前に、まず頭の中を整理しましょう。「何をやったか」を思い出すだけでなく、「なぜその判断をしたか」「どんな工夫をしたか」まで掘り下げるのがポイントです。

棚卸しに使える問いかけ

自分に問いかける形で経験を引き出してみてください。

• 参画したプロジェクトで、一番大変だったことは何か？
• チーム内で自分が担当した範囲はどこまでか？
• 自分から提案したこと、改善したことはあるか？
• プロジェクトの前後で、何かが変わったことはあるか？

常駐先での業務は「言われたことをこなしていただけ」と感じやすいですが、よく振り返ると「コードレビューのルールを提案した」「テスト工数を減らす仕組みを作った」など、小さな主体的な行動が見つかることが多いです。それがそのまま職務経歴書の武器になります。

---

ステップ2 — 経歴の構成を組み立てる

棚卸しが終わったら、職務経歴書の構成を決めます。基本的な骨格はシンプルです。

1. 職務要約（全体の経験を3〜5行でまとめる）
2. 職務経歴（プロジェクトごとに詳細を書く）
3. 保有スキル（言語・ツール・資格など）
4. 自己PR（転職の動機と、入社後に何をしたいか）

職務要約で最初の印象を決める

職務要約は、採用担当者が最初に読む部分です。ここで「ちゃんと読もう」と思わせられるかどうかが、書類通過率に直結します。

よくある失敗は「○○株式会社にてシステム開発に従事してきました」という、のっぺりした書き出しです。そうではなく、自分の得意領域と経験の厚みをひと言で示すことを意識してください。

たとえば「Webアプリケーションのバックエンド開発を中心に、要件整理から結合テストまでを一気通貫で担当してきました」のように書くと、読み手に具体的なイメージが湧きます。

---

ステップ3 — プロジェクト経歴を「成果」で語る

職務経歴の本体部分は、ただの業務日報にならないよう注意が必要です。「何をしたか」だけでなく、「どうなったか」まで書くことで、一気に説得力が増します。

数字がなくても成果は書ける

「成果を書きましょう」と言うと「数字で示せる成果なんてない」と感じる方が多いです。でも、成果は数字だけではありません。

• 改善系：「リリース後のバグ件数が減った」「デプロイ作業の手順を整備して属人化を解消した」
• 推進系：「ドキュメントが整備されていなかったので、自分で仕様書を作成しチームで共有した」
• 学習系：「新しい技術を自習してプロジェクトに取り入れた」

これらはすべて、自社開発企業や社内SEが「採用したい人材像」に直結するエピソードです。小さいことでも、具体的に書くほど印象に残ります。

技術スタックの書き方

スキルセットを書く際は、ただ言語名を並べるのではなく、実務でどのレベルで使ったかを添えると誠実さが伝わります。

たとえば「Java(3年。業務ロジックの設計・実装を担当)」「SQL(2年。パフォーマンスチューニング経験あり)」のように書くと、採用担当者が「どんな仕事を任せられるか」をイメージしやすくなります。

---

ステップ4 — 自社開発・社内SEに刺さる自己PRを書く

自己PRは、職務経歴書の中で唯一「あなたの言葉」で未来を語れる場所です。ここでなぜ今の環境を変えたいのか、転職先で何をしたいのかを、正直に・ポジティブに書きましょう。

「逃げ」に見えない転職理由の表現

客先常駐から転職する場合、「常駐が嫌だから転職する」という本音を、そのまま書くのは避けた方が無難です。採用担当者には「問題から逃げている」と映りやすいからです。

代わりに、前向きな欲求に言い換えることが大切です。

• ✕「客先常駐ではスキルが積みにくいと感じた」

• ○「自社プロダクトの成長に継続的に関わる経験を積みたい」

• ✕「自分の会社に帰属感がなかった」

• ○「チームとして一つのサービスを育てる仕事にチャレンジしたい」

本音は同じでも、表現の方向性を変えるだけで、受け取られ方がまるで違います。

社内SEを目指す場合に伝えたいこと

社内SEへの転職では、**「業務側の視点に興味があること」**を伝えると好印象につながりやすいです。

たとえば「常駐先の業務プロセスを観察する中で、システムと現場の橋渡しをする仕事に関心を持った」という経験は、社内SEにとって非常に価値ある資質です。技術力だけでなく、現場理解やコミュニケーション力をアピールできます。

---

応募先ごとに職務経歴書を調整する

一枚の職務経歴書を全社に使い回すのは、もったいないやり方です。応募先の事業・開発スタイルに合わせて、強調するポイントを微調整するだけで、書類通過率は大きく変わります。

自社開発企業に合わせる場合

自社開発企業では、サービスへのオーナーシップ(当事者意識)を重視します。職務要約や自己PRに「ユーザーの課題を解決することに関心がある」「リリース後の反応を意識しながら開発したい」といった表現を入れると、文化的な親和性をアピールできます。

社内SEポジションに合わせる場合

社内SEでは、技術力よりも「社内のひとと連携しながら問題を解決する力」が求められます。過去の経験から、要件ヒアリングや調整を行った場面があれば積極的に盛り込みましょう。「エンドユーザーと直接やり取りした経験」も、大きな強みになります。

---

よくある質問（FAQ）

Q. 常駐先のプロジェクト名や企業名は職務経歴書に書いていいですか？

守秘義務の観点から、具体的な社名やシステム名はぼかして書くのが一般的です。「大手流通業向けの在庫管理システム」「金融機関向けWebアプリケーション」のように業種と規模感がわかる程度の表現にとどめましょう。採用担当者もその慣習を理解しています。

Q. 経歴が浅い(1〜2年)でも自社開発に転職できますか？

経験年数だけで判断されることはほとんどありません。それより「何をどう考えて仕事してきたか」が重視されます。経験が浅い分は、自己学習の内容や個人開発・勉強会への参加など、能動的に動いてきた姿勢でカバーできます。GitHubなどに自分のコードを公開しておくと、書類以上の説得力になることもあります。

Q. 職務経歴書は何枚が適切ですか？

A4用紙で2〜3枚が目安です。経験が1〜2年程度であれば2枚にすっきりまとめる方が読みやすく、むしろ好印象になることが多いです。枚数を増やすよりも、一文一文の密度を上げることを意識してみてください。