エンジニアの職務経歴書の書き方｜習得スキルと意識したことを足して伝える

エンジニアの職務経歴書は、項目そのものは定番の並びで構いません。差がつくのは、プロジェクトごとの経歴に「習得スキル」と「意識したこと」まで書けているかどうかです。

先に、書いている僕の立場をお伝えします。僕は2009年に新卒でSIerに入り、2016年にフリーランスのエンジニアとして独立しました。転職はしていません。この記事で僕の経験として書くのは、業務委託の案件に応募するときにエージェントに出す経歴書（スキルシート）のことです。業務委託のエンジニアを受け入れる面談に、面談する側の一人として入ることもあります。

ただし、正社員の採用面接に関わったことはありません。この記事では、業務委託の経歴書で僕が実際に足した項目と、面談する側として見ていることを紹介します。そのうえで、転職用の職務経歴書にどう生かせるかを考えます。項目別の書き方や雛形は、一般的な形に沿ってまとめました。

職務経歴書とスキルシートは、似ているようで出し先と決まることが違います。

職務経歴書は、採用する会社に出して雇用されるための書類です。一般には、これまでの経験に加えて入社後に活躍できるかも見られるといわれます。スキルシートは、エージェント経由で案件の現場に渡り、業務委託の契約を結ぶかを決める書類です。こちらは、いま何ができるかが重く見られます。この記事は転職用の職務経歴書に絞っています。独立して業務委託の案件を探す方は、エンジニアのスキルシートの書き方を読んでください。

職務経歴書を出す先から考えたい方は、SIerの転職エージェントの選び方にまとめています。

職務経歴書は「やったこと」に「習得スキル」と「意識したこと」を足す

エンジニアの職務経歴書で一番伝えたいのは、やったことだけで終わらせず「習得スキル」と「意識したこと」を足すという点です。僕が業務委託の経歴書に途中から足すようにした2つの欄で、職務経歴書のプロジェクト欄にもそのまま足せます。

やったことの羅列では伝わらない

業務内容・規模・役割・言語だけを並べた職務経歴書は、事実として正しくても書いた人の中身までは伝わりません。同じ工程を同じ言語で経験した人は、ほかにもたくさんいるからです。

僕が業務委託の案件に応募するときの経歴書も、最初は事実の項目だけでした。書いていたのは、業務の概要・開発システム概要・開発規模・役割・言語・使用ツール・OSあたりだったはずです。この並びは、職務経歴書のプロジェクト欄とほぼ同じです。

項目が埋まっていても、読む側にとっては「何をやったか」までしか分かりません。その人がどう仕事をする人なのかは、事実の項目だけでは見えにくいものです。

習得スキルを書く

習得スキルの欄には、そのプロジェクトに入ってから新しく身についたことを書きます。対象は技術に限りません。担当して初めて経験した工程や、そのプロジェクトで覚えた業務の流れも立派な習得スキルです。

書き方の例です（架空の例です）。

• 技術：「TypeScriptでのフロントエンド開発を、このプロジェクトで初めて経験」
• 工程：「基本設計から結合テストまでを一人で担当」
• 業務知識：「宿泊予約の空室管理と料金計算の流れ」
• 進め方：「コードレビューの観点表を作り、レビューの手戻りを減らした」

どのプロジェクトにも同じことを書いているなら、それはそのプロジェクトで身についたことではありません。もともと持っていたスキルなので、後で書くテクニカルスキルの欄に移します。

意識したことを書く

意識したことの欄には、そのプロジェクトで気をつけていたことや工夫したことを書きます。習得スキルが身についた中身を示す欄だとすると、こちらは仕事の進め方を示す欄です。

たとえば次のような書き方があります（架空の例です）。

• 「仕様の質問は、自分の理解を一文にまとめてから確認した」
• 「改修の前に影響範囲を一覧にして、テストの漏れを防いだ」
• 「後から入る人のために、手順書を作業のたびに更新した」

ここで書くのは、立派な成果である必要はありません。毎日の仕事で気をつけていたことを具体的に書くほうが、その人の仕事の進め方は伝わります。

書き方を変えて面談の話も変わった

2つの欄を足してから、面談で話す中身も変わりました。経歴をなぞって説明するだけで終わらせず、そのとき意識したことなどのプラスアルファも話すようになったのです。

年を重ねて経験が増えたこともあります。それだけではなく、話す内容を変えたことが案件獲得のプラスになっていると僕は感じています。数字で確かめたものではなく、あくまで僕の実感です。

一般に、職務経歴書に書いたことは面接で質問されるきっかけになります。意識したことが書いてあれば、そこを入り口に「どう仕事をする人か」を話す流れを作りやすくなります。

職務経歴書の項目別の書き方

エンジニアの職務経歴書の項目は、職務要約・職務経歴（プロジェクトごと）・テクニカルスキル・自己PR・資格・その他が基本です。応募先によっては志望動機の欄を設けることもあります。ここからは、項目ごとに何をどこまで書くかを見ていきます。

職務要約

職務要約は、職務経歴書の冒頭で経歴の全体を3〜5行にまとめる欄です。読む側は最初にここを読むので、経験の年数・分野・役割・強みが一目で分かるようにします。

書き例を挙げます（架空の例です）。

新卒で独立系SIerに入社し、約8年にわたって宿泊・旅行業向けの業務Webシステムの受託開発に携わってきました。Java（Spring Boot）を使った設計からテストまでを担当し、直近3年は5名のチームのサブリーダーとして進捗管理とレビューを担当しています。要件の聞き取りから仕様に落とし込むまでを一人で進められることが強みです。

最後の一文のように、任せてもらえる範囲を一言で示すと伝わりやすくなります。僕が2016年に最初の案件が決まった面談でも、.NET系の経験が当時7年ほどあることと、基本的に一人称で仕事を進められることを伝えました。経験の年数と、どこまで一人で進められるか。職務要約でもこの2つを入れておくと、読む側は任せられる仕事を想像しやすくなります。

年齢や経験年数が気になる方は、SIerの転職は30代でも遅くないかやエンジニア35歳定年説も参考にしてください。

職務経歴（プロジェクトごと）

職務経歴は、職務経歴書の中心になる欄です。SIerのエンジニアは、在籍した会社と期間を書いたうえで、その中をプロジェクトごとに分けて書く形がよく使われます。

プロジェクトごとに書く項目は、次のとおりです。

• 期間
• 業務内容（どんな業務を支えるシステムか）
• 開発規模（チームの人数・期間）
• 役割と担当した工程
• 開発環境（言語・フレームワーク・データベース・OS・ツール）
• 習得スキル
• 意識したこと

並び順は、古いものから書く編年体と、新しいものを上に書く逆編年体があります。直近の経験を見てほしいなら、逆編年体のほうが応募先の知りたい情報が先に目に入ります。経験の分野がいくつかに分かれている人は、分野ごとにまとめるキャリア式という書き方もあります。

すべてのプロジェクトを同じ分量で書く必要はありません。応募先に近い経験と直近の経験は厚くします。古いものや応募先と関係の薄いものは、数行にまとめて構いません。

テクニカルスキル

テクニカルスキルは、使える言語・フレームワーク・データベース・OS・クラウドなどを一覧にする欄です。プロジェクトごとの経歴をまとめた「目次」のような役割を持ちます。

表にして、それぞれの経験年数とどの程度使えるかを添える形がよく見られます。

表の中身は説明のための架空の例です。「少し触った」と「一人で任せられる」を分けて書くと、読む側が判断しやすくなります。

AIを使った経験

AIを使った経験は、いまの職務経歴書ではテクニカルスキルか自己PRの近くに書いておきたい項目です。業務委託の面談で面談する側に入るとき、僕はAIの使い方も見ています。

面談する側として僕が見ているのは、AIの知識の量より使い方への意識です。コーディングだけでなく調査や資料作成も含めて、自分の仕事をどれだけAIに任せられるか考えて働いている人は「使える」と感じます。反対に、これだけAIが広まった今になって「最近使い始めました」という人はダメだと思っています。最新の動向ばかり追っていて、一緒に仕事をすると使いこなせていない人もいるので、そこも気をつけて見ています。

AIでコーディングした経験や、エージェント型のAIにゼロから任せて何かを作った経験をある程度話せるだけでも、意外と半分より上にいく気がします。これは僕の感覚で、数字で確かめたものではありません。業務委託の面談での話なので、転職の選考で同じとは限りません。

職務経歴書に書くなら、たとえば次のような形があります（架空の例です）。

• 職務経歴の習得スキル欄：「対話型AIを使ったテストコードの作成」
• 職務経歴の意識したこと欄：「AIが出したコードは、テストを通したうえで差分を自分で読んでから取り込んだ」
• 自己PR欄：個人でAIを使って作った仕組み

僕は仕事では対話型AIを使っていて、ソースを1から書くことはだいぶ減りました。やりたいことを文章にできれば、実装は任せられます。ただ伝え方があいまいだと、解釈違いが出ます。誰が見ても同じ成果物になるように言葉にする必要があります。職務経歴書に書くときも、こうした「どう任せてどう確かめたか」まで書けると具体的になります。

自己PR

自己PRは、職務経歴の中から応募先に一番効く強みを1〜2個選んで根拠と一緒に書く欄です。強みを並べすぎると、どれも印象に残りにくくなります。

書く順番は「強み → それを発揮した場面 → 応募先でどう生かすか」が分かりやすい形です。場面は、職務経歴に書いたプロジェクトと結びつけます。

強みの根拠には、うまくいった話だけでなく苦労した話も使えます。僕は業務委託の面談で困難だった経験を聞かれたとき、本番リリースのときのデータ移行で苦戦した話をしました。うまくいかずに詰まり、徹夜で対応したときの話です。困難の中身と、そこからどう抜け出したかを具体的に話せる経験は、自己PRの材料にもなります。

志望動機

志望動機は、職務経歴書ではなく履歴書や面接で伝えることも多い項目です。職務経歴書に書く場合は、3〜4行で収めます。

組み立ては「これまでの経験 → 応募先でどう生かせるか → 入社後にやりたいこと」の順にすると、職務経歴とのつながりが伝わります。行き先によって前に出す経験は変わるので、行き先ごとの考え方はSIerからの転職先の選び方を参考にしてください。社内SEを目指す方の志望動機の組み立て方は、SIerから社内SEへの転職で架空の例も載せています。

資格・その他

資格の欄には、取得した資格を取得年月と正式名称で書きます。勉強中の資格がある場合は、「〇〇を学習中（20XX年〇月受験予定）」のように書く人もいます。

その他の欄には、社外での活動を書けます。技術ブログ・登壇・個人で作ったツール・公開しているコードなどです。業務の外で手を動かしている人だと伝わります。

SIer出身のエンジニアが書くときの注意

SIer出身のエンジニアが職務経歴書を書くときの注意は、「社内の用語を直す」「役割と規模を数字で書く」「守秘義務の範囲で書く」の3つです。SIerの中では通じる書き方が、外の会社には伝わらないことがあります。

社内の用語を一般的な言葉にする

社内の用語は、社外の人が読んで分かる一般的な言葉に直します。SIerでは、社内だけで通じる呼び方が日常的に使われているからです。

直し方の例です。

書き終えたら、SIerで働いたことのない人が読んで分かるかを確かめます。家族や友人に読んでもらうのも一つの方法です。

役割と規模を数字で書く

役割と規模は、形容詞ではなく数字で書きます。「大規模な開発に携わった」だけでは、どのくらいの規模でどんな立場だったのかが伝わりません。

• 「大規模な開発に携わった」ではなく「チーム20名・期間1年半の開発で、帳票の機能を担当」
• 「リーダーとしてチームをまとめた」ではなく「5名のチームのサブリーダーとして、進捗管理とコードレビューを担当」
• 「業務を効率化した」ではなく「手作業だった月次の集計をバッチにして、作業を半日から10分に短縮」

例の数字は架空のものです。自分の数字が分からないときは、作らずに「数名」「約半年」のようにぼかして書くほうが安全です。盛った数字は、面接で深掘りされたときに答えに詰まります。

また、チームの人数と自分の担当範囲は分けて書きます。チームで要件定義をしていても、自分が関わったのが製造からなら「製造〜結合テストを担当」と書きます。

守秘義務の範囲で書く

職務経歴書には、顧客の社名やシステムの固有名詞を書かないのが基本です。前の職場との守秘義務があるうえに、情報の扱い方を応募先から見られることもあるからです。

固有名詞は種類に置き換えます。「〇〇電機の△△システム」なら、「大手製造業の生産管理システム（部品表・工程管理）」のように書く形です。業界まで伏せてしまうと業務の近さが応募先に伝わらないので、業界の種類は残して書くのが一般的です。

顧客の名前を伏せても、規模や業界の組み合わせで特定できてしまうことがあります。迷うときは一段ぼかして書いておくと安心です。

読まれない職務経歴書の特徴

読まれない職務経歴書の特徴は、「長すぎる」「誤字脱字がある」「強みの根拠が見えない」の3つです。どれも書いた本人は気づきにくいところです。

長すぎる

職務経歴書の長さは、A4で2枚前後、多くても3枚までを目安にする説明がよく見られます。読む側は多くの応募書類に目を通すので、枚数が多いほど応募先に近い経験が埋もれてしまいます。

経験が長いと、すべてのプロジェクトを書けば3枚を超えることもあります。そのときは、古いものや応募先と関係の薄いものを数行にまとめます。

僕が業務委託の面談で面談する側に入るとき、1対1なら30分ほどです。最近はオンラインで行っています。書類選考や面接でも、読む側が使える時間は限られています。要点を拾える分量に絞っておくのが無難です。

誤字脱字がある

誤字脱字は、出す前に必ずなくしておきます。1つの誤字だけで落ちることは少ないにしても、細かいところまで気が回らない人という印象につながりかねません。

エンジニアの職務経歴書で特に気をつけたいのは、技術用語の表記です。

• 大文字と小文字（「Javascript」「Github」「Postgresql」など）
• 製品名やバージョンの書き間違い
• 同じ言葉の表記ゆれ（「データベース」と「DB」が混ざるなど）

毎日使っている言語の名前の表記ミスは、読む側に特に目立ちます。書き終えたら一晩おいてから読み直すと、気づきやすくなります。

資格が無いときは実務の成果で補う

強みの根拠が見えにくくなりやすいのが、資格の欄が空いている場合です。資格が無い場合は、実務の成果で補います。職務経歴の数字と習得スキル・意識したことの具体が、資格の代わりの根拠になります。

僕はIT系の資格を持っていません。基本情報と応用情報は受けたことがありますが、どちらも不合格でした。資格が無くても実務はうまくできていて、困ったことはありません。ただ、資格は要らないとは思っていません。取れるに越したことはなく、僕は取れなかっただけです。資格が評価される場面と、資格より先に見られることはエンジニアに資格はいらない？に書きました。

資格の欄が空くぶん、職務経歴の書き方で何ができるかを伝える必要があります。担当した工程を数字と一緒に書き、意識したことで仕事の進め方を見せる。資格が無い人ほど、この記事の最初に書いた2つの欄が効いてきます。

職務経歴書の雛形と提出前のチェック

職務経歴書の雛形は、ここまでの項目を上から並べれば作れます。転職サイトやエージェントから書式を渡されたときはそちらに合わせ、足りない項目だけを書き足すのが手堅いやり方です。

項目の並び

項目だけの雛形です。Word・Excelのどちらで作っても構いません。

職務経歴を1つ書いた記入例も載せます。これは説明のために作った架空の例で、僕自身の経歴ではありません。

業務委託の面談で面談する側に入るとき、僕がスキルシートで最初に確かめるのは、スキルが現場に合っているかどうかです。合っていなくても、それでもいいと思える観点があれば問題ありません。一方で、直近の経歴が数か月のものばかり続いていると、正直なところ不安に感じます。

僕自身も、数か月で終わる案件をいくつも重ねるより、同じ案件で何年も続けるほうが経歴書の見栄えは良くなると考えています。正社員の書類選考でも同じ見方をされるとは限りません。それでも、記入例のように応募先と重なる経験を上のほうに厚く書いておけば、読む側はその重なりを短い時間で見つけられます。

出す前に見直すこと

職務経歴書を出す前に、次の点を見直します。

• 職務要約とプロジェクトごとの経歴の中身が食い違っていないか
• プロジェクトごとに「習得スキル」と「意識したこと」が1行以上あるか
• 応募先に近い経験が、上のほうで目に入るか
• 顧客の社名・システム名・社内の用語が残っていないか
• 役割と規模が数字で書けているか（盛った数字はないか）
• AIを使った経験を、どこかに書いているか
• 技術用語の表記と誤字脱字
• 枚数が多すぎないか（A4で2枚前後が目安）

最後は声に出して読むのがおすすめです。面接では職務経歴書を見ながら質問されるので、書いたことを自分の言葉で説明できるかの確認にもなります。

エージェントに添削してもらう

職務経歴書は、転職エージェントに添削してもらうこともできます。自分では当たり前だと思っている経験が、応募先から見ると強みになることもあるからです。

エージェントによっては、企業ごとにどこを見られやすいかという視点で直してもらえます。「習得スキル」と「意識したこと」まで書いた状態で添削を頼むと、担当者も強みを拾いやすくなります。

社内SEを目指すなら、社内SE・情報システムの求人に特化した社内SE転職ナビも候補になります。公式サイトでは、カウンセリングから求人紹介・応募書類の添削・面接の日程調整・年収交渉まで無料でサポートするとしています。社内SE転職ナビは、エンジニアやコンサルタントとしての経験がない方・45歳以上の方・希望する勤務地が関東（東京・神奈川・千葉・埼玉）、関西（大阪・京都・兵庫）、北海道以外の方は、サポートの対象外になることがあります。僕自身は転職をしていないので、使ったことはありません。

エージェントの比べ方はSIerの転職エージェントの選び方に、転職全体の進め方はSIerからの転職にまとめています。そもそも転職か独立かで迷っている方は、キャリア診断で方向を確かめてから書き始めるのもおすすめです。