※本記事にはプロモーション(アフィリエイト広告)が含まれます。
「転職サービスに登録しようとして、職務経歴書の入力欄で手が止まった」。SIer 5 年目の私がそうでした。何を書けば評価されるのか分からないし、そもそも書くのが面倒くさい。先に結論を書くと、私の書き方は携わった案件ごとに「役割・プロジェクト規模・使用技術」の 3 点をセットで書く、これだけです。この形式で書いた職務経歴書をスカウト型サービスに置いたところ、スカウトが毎日数十件届くようになり、最終的に年収 +200 万の転職につながりました。なぜこの 3 点なのか、面倒くささをどう乗り越えるかを、実体験ベースで書きます。
この記事を書いた人
- 現役エンジニア(SIer 5 年 → 事業会社 → 外資系。転職 2 回で現在年収 1,500 万)
- 本記事の型で書いた職務経歴書で、スカウト毎日数十件 → 年収 +200 万の転職を経験
- 詳しい経歴: 運営者情報
職務経歴書は「読まれる」前に「検索される」
書き方の前に、職務経歴書が誰にどう使われるかを押さえておくと、何を書くべきかが逆算できます。
スカウト型サービスでは、企業やヘッドハンターは登録者のデータベースを検索条件で絞り込んで候補者を探します。あなたの職務経歴書は、人事の目に触れる前に、まず検索にかけられるデータなのです。使用技術の具体名が書かれていなければ、その技術で検索する企業からは存在しないのと同じになります。
名文は要りません。検索にヒットして、読んだ企業が評価できる情報が揃っていれば十分。ここから逆算したのが、次の 3 点セットです。

職務経歴書は自己紹介文ではなく、検索にヒットするためのデータです。
私が書いた型:案件ごとに「役割・規模・使用技術」の 3 点セット
私の職務経歴書の本体は、携わった案件ごとに次の 3 点を繰り返すだけの構造です。
1. 役割:「何をやった人か」を伝える
その案件で自分が何を担当したか。設計・開発・運用のどの工程か、リーダー経験はあるか。同じ案件に入っていても、要件を決めた人と手を動かした人では企業側の評価が変わるので、ここを曖昧にしないことが大事です。
2. プロジェクト規模:SIer の強みはここでしか伝わらない
チームの人数、システムの大きさ。転職してみると、SIer での「大規模で堅い経験」は事業会社から想像以上に高く評価されました(実録はこちら)。ただし、その価値は規模の数字を書かない限り相手に届きません。「大規模基幹システムの開発を担当」とだけ書いても伝わらないのです。チーム何名、全体何名規模、と数字で書く。SIer 出身者の職務経歴書で一番もったいないのは、この強みの書き漏らしだと思います。
3. 使用技術:企業の検索条件になる
言語・DB・ミドルウェア・クラウドを具体名で。前述のとおりここが検索条件になるので、省略した技術の分だけスカウトの入口が減ります。「Java 等」の「等」に畳み込んだ技術は、検索には一切引っかかりません。触った技術は漏れなく、盛らずに書いてください。
形式のイメージはこうです。
■ 案件名(業種・システム種別)
- 役割: 詳細設計〜結合テストを担当(開発メンバー 、後半はチームリーダー)
- 規模: チーム ◯名 / 全体 ◯名規模
- 使用技術: Java, Oracle, (触ったものを具体名で漏れなく)
これを案件の数だけ繰り返す。構造としてはこれだけです。
【コピペOK】SIerエンジニアの職務経歴書の例文3パターン
空欄の型だけ見せられても書き出しにくいと思うので、実際に埋めた状態の例文を用意しました。SIer で多い 3 つの立ち位置(開発担当・リーダー/PM・運用保守)を並べているので、自分に近いものを選んで、案件名・数字・技術名を置き換えてお使いください。
なお、私自身の経歴に近いのはパターン 1(詳細設計〜結合テストの開発担当)です。2・3 は同じ 3 点セットの型を別の立ち位置に当てはめた書き方の例です。
例文1. 開発担当(詳細設計〜テスト)
■ 金融機関向け勘定系システムの更改(2022年4月〜2024年3月)
– 役割: 詳細設計〜結合テストを担当。後半は開発チームのリーダーとしてメンバー4名の進捗管理・レビューを実施
– 規模: 開発チーム4名 / プロジェクト全体約60名
– 使用技術: Java 8, Spring Framework, Oracle 19c, SQL, Linux (RHEL), Jenkins, Subversion, JUnit
– 成果: 担当機能の結合テストを納期内に完了。共通処理の部品化により同種機能の実装工数を削減
例文2. リーダー/PM寄り(要件定義・進捗管理あり)
■ 製造業向け生産管理システムの新規構築(2021年10月〜2023年3月)
– 役割: サブリーダー。顧客との要件定義、基本設計、進捗・課題管理を担当。開発工程では設計レビューと結合テストの計画策定を実施
– 規模: 担当チーム8名 / プロジェクト全体約120名 / 顧客拠点3サイト
– 使用技術: Java, Spring Boot, PostgreSQL, AWS (EC2, RDS, S3), Docker, Git, Redmine
– 成果: 顧客との仕様調整を主担当として推進し、要件定義工程を計画どおり完了。課題管理の運用を整備し、結合テストでの手戻りを抑制
例文3. 運用保守・インフラ寄り
■ 通信事業者向け基幹システムの運用保守(2020年4月〜2022年3月)
– 役割: 障害一次対応、定常運用(バッチ監視・ジョブ運用)、性能改善対応を担当。手順書の整備と、後任メンバー2名への引き継ぎも実施
– 規模: 運用チーム6名 / 対象サーバー約40台 / 月間バッチジョブ約500本
– 使用技術: Linux (RHEL), Shell Script, Oracle, JP1, Zabbix, VMware
– 成果: 頻発していた障害の原因を切り分けて恒久対応を実施し、同一障害の再発を解消。運用手順の文書化により属人化を解消
この 3 つを見比べると分かるとおり、変わるのは中身だけで、構造は完全に同じです。役割・規模・使用技術の 3 行が並んでいるだけ。凝った文章はどこにもありません。
職務要約(冒頭のサマリー)の例文
案件の一覧の前に、3〜4 行の職務要約を置くと読み手が全体像をつかみやすくなります。ここも凝る必要はなく、「何年・何の領域・何ができる人か」が分かれば十分です。
SIer にて5年間、金融・製造業向けの業務システム開発に従事してきました。詳細設計から結合テストまでを一貫して担当し、直近2年はチームリーダーとしてメンバー4名の進捗管理・レビューを行っています。使用技術は Java / Spring / Oracle が中心で、直近の案件では AWS 上での構築も経験しました。今後は自社サービスの開発に携わり、当事者として機能の企画から運用まで関わることを希望しています。

例文はあくまで型です。数字と技術名を自分の実際のものに置き換えるところが本番です。
社内でしか通じない言葉を消す
3 点セットを書くときの注意点がひとつあります。SIer の現場は社内用語・案件コード・顧客名の略称で会話が回っているので、それをそのまま書くと社外の読み手には何も伝わりません。書き換えのイメージはこうです。
| 社内でしか通じない書き方 | 社外に伝わる書き方 |
|---|---|
| ◯◯銀行次期システム更改PJ(社内略称そのまま) | 金融機関の勘定系システム更改 |
| 自社FW「◯◯」を用いた開発 | Java(自社フレームワーク。Spring ベース)での開発 |
| PT〜ITb を担当 | 単体テスト〜結合テストを担当 |
読み手は社外の人事とヘッドハンターです。「この会社の人にしか分からない単語が残っていないか」を最後に見直すだけで、伝わり方が変わります。
書くのが面倒くさい問題:今なら AI で下書きできる
正直に書くと、この 3 点セットは書き出すのがそれなりに面倒でした。案件を思い出し、規模の数字を確かめ、使った技術を列挙する。私はこれを手作業でやりましたが、市場価値の記事にも書いたとおり、職務経歴書を書くことが転職活動全体で一番大変な作業だったと思っています。
ただ、これは当時の話です。今なら AI に下書きさせるのが現実的です。案件ごとの情報(何のシステム・自分の担当・チーム人数・使った技術)を箇条書きでラフに渡し、職務経歴書の形式に整形させる。ゼロから文章を書く苦痛はこれでほぼ消えます。
ただし 2 つだけ、自分の仕事が残ります。
- 数字(規模・期間)は自分で正確に埋める。AI は知らない数字をそれらしく補うことがあります
- 面接で話せない内容は消す。職務経歴書に書いたことは面接で深掘りされます。AI が膨らませた表現が自分の実感より大きくなっていないか、自分の言葉で読み直してください

書くのに疲れたら思い出してください。この面倒くささ自体が参入障壁で、書いた人から順に見つかります。
書いた結果:スカウトが毎日数十件届いた
この型で書いた職務経歴書をビズリーチに置いたところ、スカウトはすぐに届き始め、毎日数十件のペースになりました。「自分の市場価値なんて大したことない」と思っていた SIer 5 年目の自己認識は、ここで修正されました。
返ってくるのは量だけではありません。私の場合、SIer での大規模システムの経験を評価する事業会社からの声が多く、「自分の何が売れるのか」まで分かりました。職務経歴書を書いて置くことは、市場価値の実測そのものです。スカウトが少ない、欲しい方向と違う。そんなときに疑う順番も、まず規模の数字、次に使用技術の漏れです。
なお、私は転職活動の中でこの作成を最優先に時間をかけました。理由は単純で、スカウト型だろうとエージェント型だろうと、応募には職務経歴書が必須だからです。どのサービスを使うか迷う時間があるなら、先に職務経歴書を仕上げる。これさえあれば、あとはどこにでも出せます。
まとめ
- 職務経歴書は検索されるデータ。案件ごとに「役割・規模・使用技術」の 3 点をセットで書く
- 書き出せないときは、本文の例文3パターン(開発担当・リーダー/PM・運用保守)と職務要約の例文を土台にして、数字と技術名を自分のものに置き換える
- SIer の強み(大規模で堅い経験)は規模の数字を書かないと伝わらない
- 使用技術は検索条件。「等」に畳まず具体名で漏れなく
- 下書きは AI に任せてよい。数字の正確さと「面接で話せるか」だけ自分で担保する
- 書き上がったら、あとはスカウト型サービスに置いて反応を見るだけです。私が使ったサービスの実際の使用感はビズリーチの本音レビューに書いています
書いた職務経歴書は、どこに出すか
本文で書いたとおり、私は職務経歴書の作成を最優先にしました。これさえあれば、あとはどこにでも出せるからです。実際に私が置いたのはスカウト型(ビズリーチ)で、そこから毎日数十件のスカウトが届きました。
ここから先は私の体験談ではなく、情報として書きます。出し先はスカウト型だけではありません。エンジニア領域に特化したエージェントに持ち込むと、書いたものを他人の目で見てもらえます。
私が本文で「自分で担保しろ」と書いた部分を思い出してください。数字の正確さと、面接で話せるかの 2 つです。これは自分ひとりで読み返しても甘くなりがちなところで、特に「この規模の書き方で伝わるのか」は社外の人間に見てもらわないと分かりません。私はここを誰にも見せずに出しました。結果的にスカウトは来ましたが、添削を受けていたらどうだったかは分かりません。
ユニゾンキャリアは IT・Web に特化した転職エージェントです(運営は株式会社ユニゾン・テクノロジー、利用は無料)。公式の説明では、支援の中に履歴書・職務経歴書・スキルシートの添削が含まれており、アドバイザーが IT 業界・技術の知見を持つため技術面を含めた添削ができるとされています。本記事の 3 点セットで言えば、「使用技術」の書き方に効くのはここです。役割と規模は自分で書けても、その技術名がいま市場でどう検索されているかは、外の人間の方が知っています。
もうひとつ、Web 面談で市場価値・適正年収の提示を受けられるとあります。本文で「職務経歴書を書いて置くことは市場価値の実測」と書きましたが、それはスカウトという結果を見る間接的な測り方です。書いたものを渡して口頭で言ってもらう形は、それより早い。
FAQ に「実務経験が浅くて書ける案件がない」という質問を置きましたが、公式ではエンジニア経験・未経験のどちらも支援対象とされていて、実務経験の年数を条件として挙げる記載はありません。希望勤務地は申込フォームで全国転勤可・東京都(埼玉・神奈川・千葉)・大阪府(兵庫・京都・奈良)・愛知県(岐阜・三重)・福岡県・その他エリアから選ぶ形です(2026 年 9 月時点)。案件が 1〜2 件でも、3 点セットで書けていれば持ち込む先はあります。
添削を受ける前に確認したい対象条件と、申込フォームで何を入力するかは別記事に整理しました。
→ ユニゾンキャリアは誰が対象?面談の流れと登録前に訊くこと
私自身は、自分からエージェントに登録して添削や伴走を受ける形の転職はしていません。1 回目はビズリーチのスカウト、2 回目は LinkedIn 経由で声をかけてきた外資系エージェント(ヘイズ)のコンサルタントからの紹介でした(外資転職の実録)。なので使用感は語れず、ここまでは公式の記載にもとづく整理です。ただ、公式に職務経歴書が整っていない段階でも相談できるとされている点は補足しておきます。とはいえ、白紙で行くより 3 点セットを埋めてから行った方が話が早いのは間違いないので、順番は変わりません。
※申し込み先は求人検索サイトではなく、キャリアアドバイザーとの Web 面談の予約フォームです。職種・経験年数・希望年収・希望勤務地に加えて、氏名・生年月日・メールアドレス・電話番号の入力があります(2026 年 9 月時点)。添削してもらう前提なら、書いた職務経歴書を持って面談に臨むのが早いです。
関連記事: エンジニアの市場価値の調べ方|転職しなくても測れる
関連記事: ビズリーチのスカウトはどれに返信すべき?見分け方と返信例文
よくある質問
Q. SIerの職務経歴書の例文が見たいです。
A. 本文に「例文3パターン」として、開発担当・リーダー/PM・運用保守の 3 つの立ち位置で実際に埋めた記入例を載せています。加えて冒頭に置く職務要約の例文もあります。どれも「役割・プロジェクト規模・使用技術」の 3 点セットという同じ構造なので、案件名と数字、技術名を自分のものに置き換えれば形になります。
Q. 職務経歴書のテンプレートはどこで手に入りますか?
A. 私は転職サービスの入力欄にそのまま書いたので、専用のテンプレートファイルは使いませんでした。書式より中身(役割・規模・使用技術が揃っているか)で決まるので、本文の例文をコピーして書き換えるのが一番早いと思います。Word 形式などの雛形が必要な場合は、各転職サービスが配布しているものを使えば十分です。
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 点セットと同じ構造で書けます。




コメント