エンジニアの職務経歴書（スキルシート）、転職エージェントに出す前に整理したいこと

更新日: 2026年10月14日

日曜の夜、転職エージェントから届いた「スキルシートをお送りください」というメールを開いたまま、Excelの空欄を眺めている。 案件の名前は思い出せるのに、「何を使って、どこまでを自分が担当したのか」を一行にしようとして、カーソルが同じ場所で点滅し続けています。 この記事は、その点滅を止めるための、材料集めの順番です。

最初に確かめるのは、出す書類の「形式」

民間の転職関連サイトの解説では、スキルシートは、保有資格、使える言語、携わった案件など、技術面に絞って示す書類で、 「技術経歴書」と呼ばれることもあると説明されています(2026年10月14日に検索結果の要約で確認。ページ本文は未確認です)。 派遣や客先常駐の場合は、所属企業が取引先に提出することもあるとされ、提出先によって様式が変わる場合があります。

自社サービスの開発など、幅広い業務に関わってきた人には、案件で区切るスキルシートより、自由な形式の職務経歴書のほうが 経験を伝えやすいことがある、という見方もあります。どちらを求められているかは、エージェントや応募先によって違います。 手を動かす前に、担当者へ「スキルシートの様式ですか、職務経歴書の様式ですか」と一言聞いておくと、作り直しを避けられます。

書類全体の組み立ては職務経歴書の書き方の基本に任せ、この記事では、どちらの様式にも使い回せる案件のメモと、 エンジニアに固有の技術・工程・規模の書き方に絞ります。

案件1件につき、8つの欄を先に作る

空欄に向かって文章を組み立てるより、まず案件1件ごとに、次の8つの欄だけ作ってみてください。 文章に直すのは、欄が埋まってからで間に合います。

1. 期間: 参画した開始年月から終了年月まで。
2. 所属の立場: 自社の開発か、客先に常駐していたか、受託開発か。立場を書いておくと、役割の読み違いを防げます。
3. 何のシステムか: 業種の区分と目的を一行で。顧客名や製品名を出すかどうかは、あとで決めます。
4. チームの規模と自分の立場: 全体で何人のうち、メンバーだったか、サブリーダーやリーダーだったか。
5. 担当した工程: 要件定義、設計、実装、テスト、リリース、運用保守のどこか。
6. 使った技術: 言語、フレームワーク、データベース、OSやクラウド、バージョン管理や開発支援のツール。
7. 自分で決めたこと、変えたこと: 設計上の選択、作業の手順化、不具合の原因の切り分けなど。
8. 数字で言えること: 手元の記録から拾えるものだけ。

民間の転職関連サイトの解説でも、先に職歴を時系列で並べ、どの経験を前に出すかを決めてから書式に移す進め方が紹介されていました (検索結果の要約で確認)。期間やチームの人数は、課題管理のチケット、設計書の更新履歴、自分の作業メモに残っていることがあります。 思い出せない欄は、空けたまま次へ進んで構いません。見返すときは、会社の決まりに沿って、社内で行ってください。

技術名の横に、使い方の深さを一言添える

言語やツールの名前を一覧にしただけでは、読む人はその経験がどの程度のものか分かりません。名前の横に、次の3つの区分を添える方法があります。 区分の名前と基準は、編集部が整理したもので、公的な基準ではありません。

• 設計から自分で書いた: 構成を考え、実装まで自分で進めた。
• 既存のコードを読んで、修正・追加した: 他の人が作ったものに手を入れた。
• 手順に沿って使った: 検証や運用の中で操作した。

使用期間は言語ごとの通算で書きます。複数の案件で同じ言語を並行して使っていた月は、二重に数えません。 載せる順番は、応募先の募集要項にある技術名を先頭に寄せておくと、読む側が見比べやすくなります。 触ったことがない技術や、名前を知っているだけのものは載せません。載せた技術は、面接で一つずつ尋ねられる前提で選んでください。

担当した工程と、チームでの立ち位置は別々の行に

「設計から実装まで担当」と一言で書いても、設計書を白紙から起こしたのか、できあがった設計書をもとに画面を作ったのかで、中身は別物です。 どの工程を担当したかと、チームの中でどう動いたかは、行を分けて書くと伝わりやすくなります(編集部の整理です)。

書式の例です。◯は仮置きの記号なので、自分の記録にある値で置き換えてください。

• 「実装を担当」とだけ書く代わりに:
  「◯人のチームで、◯◯機能の詳細設計と実装を担当。他のメンバーのコードのレビューも行った。」
• 「不具合対応」とだけ書く代わりに:
  「本番で起きた◯◯の不具合について、ログから原因を切り分け、修正案を作って上長の承認を得た。」

リーダーに指示されて進めた作業と、自分で進め方を選んだ作業は、混ぜずに別の行へ置きます。補助に回った案件は、補助とそのまま書けます。 検索で見た解説では、概要だけでなく、役割と数字で表せる成果を具体的に書くと説得力が増すとされていました。 数字は記録があるものに限り、ないときは「何を、どう変えたか」を動詞で書けば足ります。

システムの大きさと、顧客名の伏せ方

システムの大きさは、利用者の数、データの量、サーバーの台数、1日あたりの処理件数などで表せます。手元の記録から言えるものを一つ選びます。 数字がないときは、「社内の約◯人が使う」「一般の利用者向け」「夜間のバッチ処理が中心」のように、幅や用途で示す方法があります。 数字の創作は避けてください。

顧客名やシステム名、数字を社外の書類に載せてよいかは、契約や社内の規程で決まっている場合があり、この記事では判断できません。 先に、社内の情報管理の窓口か上長へ聞いてください。そのうえで伏せるなら、「大手小売業向けの在庫管理システム」「金融系の社内システム」のように、 業種と用途の区分で書く方法があります。

運用保守・テスト中心・客先常駐で「書くことがない」と感じるとき

運用保守の経験が選考でどう見られるかは、確認できていません。ただ、「書くことがない」と感じていても、 案件ごとの8つの欄を埋めていくと、書ける事実が出てくることがあります。たとえば、次のようなものです。

• 監視やアラートへの対応で、一次対応までだったのか、原因の調査まで担当したのか。
• 手順書を作った、更新した。
• 繰り返していた作業を、スクリプトなどで省力化した。
• 問い合わせの受付から回答までの範囲。
• リリース作業での自分の持ち場。

小さく見える作業でも、「何を」「どこまで」を動詞で書くと、経験の輪郭が出ます。 客先に常駐している場合は、所属している会社と、参画先で担当した業務を分けて書くと、立場が伝わりやすくなります。 SESから社内SEを目指す場合の進め方は、客先常駐(SES)から社内SEへ|転職で失敗しないエージェントの選び方(広告を含む記事です)にまとめています。

完成の手前で、エージェントの担当者に見せる

仕上げてから出すのではなく、下書きの段階で担当者に見せると、直しが小さく済むことがあります。見せるときは、次の3点を聞いてみてください。

1. 提出の形式(Excel、Word、PDFなど)に、指定はあるか。
2. 応募先ごとに、強調する技術や案件の順番を変えてよいか。
3. 顧客名などの伏せ方が、足りているか、あるいは伏せすぎていないか。

書類を見てもらえる範囲は、サービスによって違う場合があります。登録の前後に、担当者へ直接聞いてください。 面談でエンジニアとしての経験をどう話すかは、ITエンジニアの転職に強いエージェントの選び方(広告を含む記事です)と、 初回面談で準備しておきたいことに整理しています。

エンジニア経験者向けの特化型を使うなら(広告提携先)

エンジニアの経験を持つ人に向けたサービスの一つに、株式会社明光キャリアパートナーズが手がける STRATEGY CAREERがあります。 運営会社の説明では、元エンジニアやIT業界出身のアドバイザーが在籍しているとされています(公式サイトでは照合できていません)。

対象条件があります。エンジニアとしての実務経験がある方が対象で、年齢層は20〜30代が主なターゲットです。 また、紹介される求人は東京・大阪エリアが中心です。それ以外の地域で働きたい方は、相談しても紹介できる求人がほとんどない可能性があります。 書類を見てもらえるかどうかは、確認できていません。

エンジニアの実務経験がない方、東京・大阪以外で働くと決めている方は、対象外になる可能性が高いため、総合型のエージェントを先に当たるほうが現実的です。 どの窓口から当たるか迷うときは、Kairosの無料診断(広告を含むページです)も使えます。

まとめ

スキルシートの材料は、案件1件につき8つの欄を作るところから集まります。技術名には使い方の深さを添え、工程とチーム内の動き方は別の行に置きます。 数字や顧客名を載せられないときは、幅や区分で示し、創作はしません。運用保守や客先常駐の経験も、「何を」「どこまで」を動詞にすれば輪郭が出ます。 下書きのうちに担当者へ見せる、という手も残しておいてください。 メールを返信する前に、案件の欄が半分でも埋まっていれば、何が足りないのかが見えている状態で、送る日を考えやすくなります。 いま手元に、期間と立場までなら言える案件は、いくつありますか。