こんにちは、フロントエンドエンジニアのてりーです。
僕の詳しいプロフィールはこちら
はじめに
エンジニアの職務経歴書と、正社員転職の書類・面接の話を書きます。
僕は2022年ごろ、エンジニア歴4年くらいのタイミングで、SESからメガベンチャーの正社員に転職しました。
フリーランス → SES → 正社員、と雇用形態がけっこう動いている経歴です。
そのときの数字はこれでした。
書類を出した : 15社ほど
面接に進んだ : 7社前後
内定 : 2社
期間 : 登録から内定先を決めるまで 2ヶ月ほど
半分以上は書類で落ちています。
面接でも「すぐ辞めない？」と普通に疑われました、、
なので「書類が全部通る職務経歴書の書き方！」みたいな話ではないです。
どこで落ちて、どこで通ったかを、社名は伏せて正直に書きます。
前回の記事（エンジニア副業、月40時間で手取りがバイト以下だった）で「単価は棚卸しの解像度で決まる」と書いたんですが、今回はその棚卸しを正社員転職の書類と面接に使った話です。
実務経験があって、転職するかどうか迷っている人向けです。
先に結論：書類で見られていたのは「スキル × 経験年数 × ロール」だった
書類で問われるのは、純粋にスキル（技術スタック）と経験年数、そしてロールだと思っています。
で、15社出してみて分かったのは、落ちる・通るを分けていたのはロールの方でした。
- 通ったところ：メンバーで手を動かしたことも、少人数のチームをリードしたこともある、というロールの幅を書けた求人
- 落ちたところ：求人が求めるロールと、僕がやってきたロールがズレていた求人
技術スタックの数より、「その現場で何の役をやっていたか」の方がずっと見られていた印象です。
書類で落ちたのは、ロールが合っていない求人だった
まず落ちた方から書きます。
振り返ると、落ちた求人ははっきり2パターンでした。
完全なフロントエンドアーキテクトを求めている求人
当時の僕は、5人規模のチームのリーダーはやっていました。
でも、本当に上流のアーキテクチャレベルの設計をした経験はまだ浅かったです。
「リーダー」と「アーキテクト」は別のロールなんですよね。
アーキテクチャ設計でリードしていく人を求める求人は、書類で落ちていた印象があります。
フロントもバックも（何ならインフラも）一気通貫でリードするプロダクトエンジニアの求人
SES時代に、フロントエンドもバックエンドも技術としては触って開発していました。
ただ、バックエンドはメンバーレベルでの開発だけです。
フロント・バック・インフラを一気通貫で「リードする」ところまでは求人の水準に届いていなくて、ここも書類で落ちていました。
「触ったことがある」と「その範囲をリードした」は、書類の上では全然違う情報です。
これは1本目で書いた「React 2年」と同じ構図で、期間や技術名だけでは、相手は僕のロールを判断できないんですよね。
書類で評価されたのは「ロールの幅」と「エンジニアリング以外の協業」
逆に、通ったところで評価されたのはこのあたりでした。
メンバーもリードも、両方やったことがある
メンバーとして手を動かしたこともあるし、少人数のチームでリードしたこともある。
そのリードのときに、上流の設計をしたうえでメンバーと協業していたこと。
これを書いていました。
デザイナーとのデザインシステム構築
フロントエンドエンジニアという職種だったので、デザイナーと一緒にデザインシステムを作った経歴も書きました。
スクラムチームを現場の正社員さんと一緒に作った
SES時代、少人数のチームのときに、当時の現場の正社員さんと一緒にスクラムチームの構築をやりました。
そのあとスクラムマスターの資格も取っていて、それも書いています。
技術発信（Qiita・Zenn）
フリーランス時代に、QiitaやZennで技術ブログを結構書いていました。
ここで技術的な探究心とか将来性を期待してもらえた部分も、大きかったと思います。
エンジニアリング以外の部分も、やったなら書く
デザイナーとの協業とか、チーム全体の活動の共有とか。
正社員として協業していくときに大事にされる部分を、エンジニアリング以外でもやったことがあるなら、職務経歴書に書いておくのがいいと思います。
まだやったことがないなら、そういう経験を取りに行く、というのもアリかなと。
ただしそれが自分の志向性と合っていれば、です。
あと、多くの現場・言語・技術スタック・ロールを経験しておくのは、SESやフリーランスの強みだと思っています。
今だったら、生成AIの経験もそこに入ってくるかもしれないです。
「フリーランス → SES → 正社員」の経歴は、どう書いたか
雇用形態が動いている経歴なので、書き方はけっこう気にしました。
実際、面接では「すぐ辞めない？」と疑問視されています。
で、結局どう書いたかというと、雇用形態は「補足」にしました。
現場ごとに書いたこと
- どんな現場だったか
- どんなロール・期待役割で動いていたか
- やったこと・実績
- 技術スタック
- 雇用形態（業務委託として参画／SESとして参画）← ここは1欄で補足するだけ
正社員だろうとSESだろうとフリーランスだろうと、**職務経歴書なので結局「現場で何をしたか」**です。
そこを多く書いて、雇用形態は欄を1つ足して補足した、くらいでした。
「すぐ辞めない？」にはこう返した
面接で聞かれたときは、シンプルにこう答えています。
正社員として今後のキャリアを歩みたいので、辞めないです。
中長期で正社員としての転職が絶対ゼロとは言いませんが、フリーランスやSESに戻ることは考えていません。
正社員として合う会社で、キャリアを進めたいです。
実際、SES時代から数えると、もう6年以上ずっと正社員を続けています。
職務経歴書は、1から自分で書いていない
ここは意外かもしれないんですが、僕の職務経歴書は1から自分で作ったものじゃないです。
SESで現場に入るときに営業さんが作ってくれたもの、フリーランスのときにエージェントさんが作ってくれたもの。
それを踏襲して、追加の経歴を書き足していくスタイルです。今も基本はこの方式です。
当時やってもらったのは、30分くらいの面談で経歴をヒアリングしてもらっただけでした。
それで形になったものが出てきた。
よかったのは、転職業界に詳しい第三者を一度通していることです。
- 職務経歴書のフォーマット
- 「ここはこういう書きっぷりの方がいいよ」という指摘
- その修正
を、最初の段階でやってもらえていました。
自分ひとりで1から書いていたら、たぶん技術名と期間を並べただけのものになっていたと思います、、
棚卸しのやり方：3列で書き出す
ここからが実用パートです。
1本目でやったのと同じ3列を、職務経歴書にも使います。
何を | どんな制約の中で | 結果どうなったか
実例：医療系の受託開発
僕の経歴でいちばん3列にしやすいのがこれでした。
■ 何を
医療系の会員向けサービスを、フロントエンド・バックエンド一気通貫で開発
（エンジニア全体で15人ほど／僕がいたのは1年ほど）
技術: JavaScript・Vue.js ／ PHP・Laravel ／ MySQL
お医者さんたちの協会から来る要件を、正社員のエンジニアさんがシステム要件に落としてくれる
→ それが本当に期待通りにできるのか、という大きい技術的な設計の部分を担当
■ どんな制約の中で
- 受託なので、明確な納期とシステム要件がある
- 間にビジネス側のエンジニアがいるわけではない（協会の要件を直接システムに落とす）
- 人員の問題：
メンバーはいろいろなSES会社から来ている人たち
フロントエンドを熟知している人もいれば、エンジニア経験の浅いジュニアの人もいる
→ 誰に基幹部分を触ってもらって、誰に作業部分を触ってもらうか
フロントの経験しかない人にも、必要なときはバックエンドの作業をお願いする
納期の中で、どこに濃淡をつけるかの「人振り」をかなり気にした
■ 結果どうなったか
受託の納期には間に合った
ただ一発目でうまくいったわけではなく、最初の納期で一旦のものを出して、
追加の要望に応えていく運用フェーズへ
→ そこでまた、人の整理・やることの整理・優先順位付けが発生していった
実例：SESの縦割りを、スクラムで混ぜた
同じ医療系の現場の話です。
人振りの話の続きで、途中からチームの組み方そのものを変えました。
■ 何を
SES会社ごとの縦割りチームを、全員まぜこぜのスクラムチームに組み直した
（現場の正社員さんと一緒に。そのあとスクラムマスターの資格も取った）
■ どんな制約の中で
- SES会社ごとに、リーダーっぽい人＋メンバーで4〜5人のチームが3つほどあった
僕のところも、僕を合わせて4〜5人
- フロントが得意な人、バックが得意な人、いろいろいる
- 会社をまたいでチームにするので、コミュニケーションが制約になる
- 誰が何時まで働けるか、家庭の事情、現場を離れたがっている・変えたがっている人
- 新しくどんなスキルの人が来るか分からない、人の入れ替わり
→ それでも、SES会社の枠を超えて「現場レベルで一致団結する」必要があった
■ 結果どうなったか
- ウォーターフォールっぽい受託開発に、スクラムの考え方を入れた
- 全体の進捗を、SES会社ごとではなく全員で共有できるようになった
- できる人・手が空いている人・お互いの息遣いを見ながら、
重要なところに人数を割ける柔軟な体制になった
- 納期より余裕を持って一旦終えて、受託先の人に見てもらう
→ フィードバックでブラッシュアップ、という良いサイクルで開発ペースが乗った
ウォーターフォールのままだと、納期までにバーッと作りきって、バグを潰して、どうだ！って出す一発勝負になっちゃうんですよね。
それを避けられたのが、いちばん大きかったです。
Before / After
同じ経験でも、書き方でこれくらい情報量が変わります。
Before
医療系会員サービス開発（1年） Vue.js / Laravel / MySQL
After
医療系会員サービス（受託・エンジニア15人規模）の開発で、フロントエンド・バックエンドの技術設計を担当。
複数社のSESメンバーによる縦割りチームを、現場の正社員と一緒にスクラムチームに再編。
スキルの違うメンバーに基幹部分と作業部分を割り振り、納期より余裕を持って初回リリース。
その後は受託先のフィードバックを受けてブラッシュアップするサイクルで運用。
Before だと、相手は「何年やったか」しか分かりません。
After なら、「リーダーとして人を振れる人なんだな」「でもアーキテクトかどうかはまだ分からないな」まで判断できる。
この「相手が判断できる」が、書類で落ちる・通るの差だったと思っています。
面接で「なぜ正社員に？」と聞かれたときの答え
面接でいちばん聞かれたのはこれでした。
フリーランス → SES → 正社員なので、当然といえば当然です。
僕が伝えたのは4つです。
- マネジメントに挑戦したい
- スクラムの経験
- 勉強会・技術ブログ
- エンジニア文化への貢献
背景としては、SES時代に新卒を含む5人ほどのリーダーをやっていて、ビジネスの観点を育てたい、グロースのためのマネジメントと育成に力を入れたい、と思ってリーダー職を目指していました。
ここで楽だったのは、職務経歴書の棚卸しと、面接の答えが揃っていたことです。
書類に書いたスクラムチームの構築や技術発信が、そのまま「なぜ正社員に？」の答えの根拠になります。
うまく答えられなかった質問：「将来どうなりたい？」
逆に、全然うまく答えられなかったのがこれです。
「エンジニアとして将来どうなりたいか、どういうキャリアパスを歩みたいか」
SESやフリーランスの時代に、正社員のエンジニアが30、40、50歳になっていく中でどういうキャリアパスを歩むのか、インプットも、背中を見てきた事例も少なかったんですよね。
当時は技術でより上に行きたかったので、テックリードは視野に入っていました。
でも、
「それってテックリードでやらないといけないの？」
「EM（エンジニアリングマネージャー）とかって目指さないの？」
と聞かれて、そもそもEMって何をする人なのか、あんまり分かってない、という状態でした、、
EMやVPoEみたいに、正社員として組織やエンジニアカルチャーの中にいるからこそ価値や役割が見えてくる職種には、当時は理解が追いついていなかったです。
そういう視座を持っていなかった。
もし今SESやフリーランスから正社員を考えている人がいたら、テックリード・EM・VPoE が何をしている人なのかは、面接の前に一度調べておくのをおすすめします。
技術面接とコーディングテストは、ほとんどの会社であった
技術面接は、本当に技術的な課題とか、「こういうときってどうしますか？」というケーススタディ寄りのものが多かったです。
その場で、自分の知っている知識・できることを出して、本当にその立場になって考えてみる、という感じでした。
コーディングテストは文字どおりコーディングのテストで、30分とか時間を取って、休みの日にグッと集中してやりました。
あと、GitHubのプルリクエストを見て、その場でレビューしてくださいという試験もありました。
技術的な深さや、どこが気になるかを見るという意味では、いい形式だなと思います。
正直、事前にコーディングテストの対策をしたかというと、そこまではしていないです。
うまくできなかったな、ここ気になったな、というのをその都度キャッチアップして、「こういうことを答えられたらいいんだな」というチップスや慣れを積み上げていった感じでした。
書類15社 → 面接7社 → 内定2社の内訳
流れはこんな感じでした。
登録
↓ 2〜3日
エージェントとの最初の会話
↓ 10日ほど
面接が組まれ始める
↓
内定2社
↓
1社に決める（登録からここまで 2ヶ月ほど）
内定2社から、提示年収が低い方を選んだ
ここは正直に書くと、2社のうち、提示年収が低い方を選びました。
それでも決めたのは、やれること・自分の伸びしろ・キャリアパスで見て、こっちがいいなと思ったからです。
- 選んだ会社の方が規模が少し小さめ
- ビジネス志向が強くて、エンジニアとビジネスが分断されていない印象があった
短期の目標は、1エンジニアとしてチームをリードして、エンジニア組織をリードすること。
中長期では、ビジネス側のPOやアナリスト、営業部隊、経営層と近い距離で、ビジネスの判断とエンジニアリングの判断の両輪を追いかけられる筋力をつけたかった。
なので、年収より環境を取りました。
結果として、短期目標だったテックリードは今達成できていて、エンジニア組織をより良くする動きができています。
プラスアルファで、会社の中長期のマイルストーンに沿って「どの開発を、どの手順で、どういうスケールを考えた技術設計にするか」を年度単位で考えるのが今求められていることで、まさにこういう経験が欲しかったんですよね。
自社開発である限り、開発はビジネスと紐づいています。
デザインシステムひとつ取っても、どのタイミングで、どの規模感のものを作って、どうスケールさせるか。
それを会社のステップに合わせて見極めながら技術と向き合えているのは、いい学びになっています。
ちなみに年収は、SES時代から150万ほど上がっています。
（なので「低い方」と言っても、下がったわけではないです）
提示年収が高い方なら、200万円以上上がっていました。
でも150万上がるだけで十分満足していたので、経験の方を取りました。
もうひとつ理由があって、高すぎる年収は、入ったあとの期待値とのギャップが怖かったんですよね。
期待値がそこまで高くなくて、入ったあとに期待以上の活躍をして、社内でどんどん昇進していける余白が残っている会社の方が、正社員として続けやすいなと思いました。
エージェントは「自分の潜在ニーズを言葉にする相手」として使った
転職活動は、レバテックキャリアで本格的にやりました。
転職ドラフトとFindyは、事前に登録して情報収集に使っていました。
エージェントにやってもらって一番よかったのは、書類の添削より自分が何を大事にしているかの深掘りでした。
同じような条件の求人が来たときに、「どっちの方がいいですか？」と聞かれて、僕は直感で答えるわけです。
その直感が何から来ているのかを、一緒に深掘りしてもらいました。
- こういう要素を自分は大事にしてるんだな
- こういう会社、こういう経験を積みたいんだな
と、自分でも気づいていなかった潜在ニーズを引き出してもらいつつ、
- そういう会社に引っかかりやすくなるには、どういう経験を書くといいか
- 面接のときにどういう表現を気にするといいか
を、面接やカジュアル面談のあとのヒアリングを通して、毎回アジャストしていく感じでした。
それで、自分の志向性に合っていて、入って3、4年経った今も「ここからもまだ長くいたいな」と思える会社を見つけられました。
年収については、MUST（現年収か＋50万）とWANTの2つに分けて伝えたくらいです。
使ったエージェントの良かった点・合わなかった点は、こちらにまとめています。
👉 レバテックキャリアの評判
転職しなくても、1〜2年に1回は棚卸しする
最後に、転職を勧めたいわけではないです。
僕は今、1〜2年に1回は市場に出て棚卸しするのを年間行事にしています。
転職しなくても、棚卸しをすると「今の会社でまだやれること」の再確認になります。
ロールの幅が足りないなら今の現場で取りに行けばいいし、足りているなら今の職務経歴書を更新しておけばいい。
どっちに転んでも損はしないかなーと個人的には思っています。
まとめ
- 書類で見られていたのは「スキル × 年数 × ロール」。落ちたのはロールがズレていた求人だった
- 雇用形態は補足でいい。書くのは「その現場で何の役をやったか」
- 職務経歴書は「何を／どんな制約の中で／結果どうなったか」の3列で棚卸しすると、相手が判断できる粒度になる
- 棚卸しが揃っていると、面接の「なぜ正社員に？」もそのまま答えられる
- テックリード・EM・VPoE が何をする人なのかは、面接の前に調べておく
もう少し細かく書いたもの
- エンジニア副業、月40時間で手取りがバイト以下だった。4年やってわかった案件の選び方と単価の決まり方 — 副業の単価と棚卸し
- フリーランスから正社員に戻った体験談｜年収は下がった？手残りの差は月5万円だった — フリーランスをやめて正社員に戻った理由とお金
- レバテックキャリアの評判 — 使ったエージェントの良かった点・合わなかった点
質問があれば、コメントください！