SIerエンジニアの職務経歴書の書き方|スカウトが毎日数十件届いた型

SIerエンジニアの職務経歴書の書き方記事のアイキャッチ 技術とキャリア

「転職サービスに登録しようとして、職務経歴書の入力欄で手が止まった」。SIer 5 年目の私がそうでした。何を書けば評価されるのか分からないし、そもそも書くのが面倒くさい。先に結論を書くと、私の書き方は携わった案件ごとに「役割・プロジェクト規模・使用技術」の 3 点をセットで書く、これだけです。この形式で書いた職務経歴書をスカウト型サービスに置いたところ、スカウトが毎日数十件届くようになり、最終的に年収 +200 万の転職につながりました。なぜこの 3 点なのか、面倒くささをどう乗り越えるかを、実体験ベースで書きます。

この記事を書いた人

  • 現役エンジニア(SIer 5 年 → 事業会社 → 外資系。転職 2 回で現在年収 1,500 万)
  • 本記事の型で書いた職務経歴書で、スカウト毎日数十件 → 年収 +200 万の転職を経験
  • X: @detective_ai_en

職務経歴書は「読まれる」前に「検索される」

書き方の前に、職務経歴書が誰にどう使われるかを押さえておくと、何を書くべきかが逆算できます。

スカウト型サービスでは、企業やヘッドハンターは登録者のデータベースを検索条件で絞り込んで候補者を探します。あなたの職務経歴書は、人事の目に触れる前に、まず検索にかけられるデータなのです。使用技術の具体名が書かれていなければ、その技術で検索する企業からは存在しないのと同じになります。

名文は要りません。検索にヒットして、読んだ企業が評価できる情報が揃っていれば十分。ここから逆算したのが、次の 3 点セットです。

いぬ
いぬ

職務経歴書は自己紹介文ではなく、検索にヒットするためのデータです。

私が書いた型:案件ごとに「役割・規模・使用技術」の 3 点セット

私の職務経歴書の本体は、携わった案件ごとに次の 3 点を繰り返すだけの構造です。

1. 役割:「何をやった人か」を伝える

その案件で自分が何を担当したか。設計・開発・運用のどの工程か、リーダー経験はあるか。同じ案件に入っていても、要件を決めた人と手を動かした人では企業側の評価が変わるので、ここを曖昧にしないことが大事です。

2. プロジェクト規模:SIer の強みはここでしか伝わらない

チームの人数、システムの大きさ。転職してみると、SIer での「大規模で堅い経験」は事業会社から想像以上に高く評価されました(実録はこちら)。ただし、その価値は規模の数字を書かない限り相手に届きません。「大規模基幹システムの開発を担当」とだけ書いても伝わらないのです。チーム何名、全体何名規模、と数字で書く。SIer 出身者の職務経歴書で一番もったいないのは、この強みの書き漏らしだと思います。

3. 使用技術:企業の検索条件になる

言語・DB・ミドルウェア・クラウドを具体名で。前述のとおりここが検索条件になるので、省略した技術の分だけスカウトの入口が減ります。「Java 等」の「等」に畳み込んだ技術は、検索には一切引っかかりません。触った技術は漏れなく、盛らずに書いてください。

形式のイメージはこうです。

■ 案件名(業種・システム種別)
- 役割: 詳細設計〜結合テストを担当(開発メンバー 、後半はチームリーダー)
- 規模: チーム ◯名 / 全体 ◯名規模
- 使用技術: Java, Oracle, (触ったものを具体名で漏れなく)

これを案件の数だけ繰り返す。構造としてはこれだけです。

社内でしか通じない言葉を消す

3 点セットを書くときの注意点がひとつあります。SIer の現場は社内用語・案件コード・顧客名の略称で会話が回っているので、それをそのまま書くと社外の読み手には何も伝わりません。書き換えのイメージはこうです。

社内でしか通じない書き方 社外に伝わる書き方
◯◯銀行次期システム更改PJ(社内略称そのまま) 金融機関の勘定系システム更改
自社FW「◯◯」を用いた開発 Java(自社フレームワーク。Spring ベース)での開発
PT〜ITb を担当 単体テスト〜結合テストを担当

読み手は社外の人事とヘッドハンターです。「この会社の人にしか分からない単語が残っていないか」を最後に見直すだけで、伝わり方が変わります。

書くのが面倒くさい問題:今なら AI で下書きできる

正直に書くと、この 3 点セットは書き出すのがそれなりに面倒でした。案件を思い出し、規模の数字を確かめ、使った技術を列挙する。私はこれを手作業でやりましたが、市場価値の記事にも書いたとおり、職務経歴書を書くことが転職活動全体で一番大変な作業だったと思っています。

ただ、これは当時の話です。今なら AI に下書きさせるのが現実的です。案件ごとの情報(何のシステム・自分の担当・チーム人数・使った技術)を箇条書きでラフに渡し、職務経歴書の形式に整形させる。ゼロから文章を書く苦痛はこれでほぼ消えます。

ただし 2 つだけ、自分の仕事が残ります。

  1. 数字(規模・期間)は自分で正確に埋める。AI は知らない数字をそれらしく補うことがあります
  2. 面接で話せない内容は消す。職務経歴書に書いたことは面接で深掘りされます。AI が膨らませた表現が自分の実感より大きくなっていないか、自分の言葉で読み直してください
いぬ
いぬ

書くのに疲れたら思い出してください。この面倒くささ自体が参入障壁で、書いた人から順に見つかります。

書いた結果:スカウトが毎日数十件届いた

この型で書いた職務経歴書をビズリーチに置いたところ、スカウトはすぐに届き始め、毎日数十件のペースになりました。「自分の市場価値なんて大したことない」と思っていた SIer 5 年目の自己認識は、ここで修正されました。

返ってくるのは量だけではありません。私の場合、SIer での大規模システムの経験を評価する事業会社からの声が多く、「自分の何が売れるのか」まで分かりました。職務経歴書を書いて置くことは、市場価値の実測そのものです。スカウトが少ない、欲しい方向と違う。そんなときに疑う順番も、まず規模の数字、次に使用技術の漏れです。

なお、私は転職活動の中でこの作成を最優先に時間をかけました。理由は単純で、スカウト型だろうとエージェント型だろうと、応募には職務経歴書が必須だからです。どのサービスを使うか迷う時間があるなら、先に職務経歴書を仕上げる。これさえあれば、あとはどこにでも出せます。

まとめ

  • 職務経歴書は検索されるデータ。案件ごとに「役割・規模・使用技術」の 3 点をセットで書く
  • SIer の強み(大規模で堅い経験)は規模の数字を書かないと伝わらない
  • 使用技術は検索条件。「等」に畳まず具体名で漏れなく
  • 下書きは AI に任せてよい。数字の正確さと「面接で話せるか」だけ自分で担保する
  • 書き上がったら、あとはスカウト型サービスに置いて反応を見るだけです。私が使ったサービスの実際の使用感はビズリーチの本音レビューに書いています

関連記事: エンジニアの市場価値の調べ方|転職しなくても測れる

よくある質問

Q. 職務経歴書はどれくらいの分量を書けばいいですか?
A. 私の職務経歴書は全体で 1,000 文字程度でした。長文の自己PRは書いておらず、案件ごとの 3 点セットが中心の箇条書きです。書ききれない詳細は面接で話せば伝わるので、文章の上手さや分量より「3 点が揃っているか」を優先するのが私の結論です。

Q. ビズリーチの職務経歴書には何を書けばいいですか?
A. 本記事の 3 点セット(役割・プロジェクト規模・使用技術)をそのまま使えます。私自身、この形式で書いた職務経歴書をビズリーチに登録して毎日数十件のスカウトを受けました。使用技術の具体名が企業側の検索条件になる点が特に重要です(ビズリーチの使用感はこちら)。

Q. スカウトを増やすにはどうすればいいですか?
A. 盛るより先に、漏れを無くしてください。触った技術を「等」に畳んでいないか、規模の数字を書き忘れていないか。検索にヒットする面を増やすほどスカウトの入口は増えます。それでも少ない場合は、今の仕事で書ける実績を増やす時期という測定結果だと捉えるのが健全だと思います。

Q. AI に職務経歴書を書かせるのはありですか?
A. 下書きはありだと思います。私が手作業で消耗した部分は今なら数分で済むはずです。ただし数字(規模・期間)は自分で正確に埋めること、面接で深掘りされて話せない表現を残さないこと。この 2 つを守れば、AI は「書き始められない」問題の良い解決策です。

Q. 実務経験が浅くて書ける案件がありません
A. 案件が 1〜2 件でも、3 点セットで具体的に書けばデータとしては成立します。それでもスカウトが少ない場合は、エージェント型で経験の言語化を手伝ってもらいながら実績を積む時期だと思います(エージェント型を使った記録)。

Q. 英語の職務経歴書も作るべきですか?
A. 外資を視野に入れるなら価値があります。私は LinkedIn に英語で職務経歴を登録していて、そこにヘッドハンターから声がかかったのが外資転職の入口でした(外資転職の実録)。内容は本記事の 3 点セットと同じ構造で書けます。

コメント

タイトルとURLをコピーしました