タイトル

エンジニアの職務経歴書|下請・常駐の経歴をどう書くか

エンジニアの職務経歴書で評価が分かれるのは、**使った言語ではなく「担当した工程の中で自分が何を決めたか」**です。ここが書けていないと、経験年数をどれだけ重ねても「言われたものを作る人」としか読まれません。

そして下請・常駐で働く人には、固有の詰まりどころが3つあります。要件定義の経験が薄い/常駐先の社名やシステム名を書いてよいか分からない/案件が多すぎて束ねられないの3つです。

この記事は、その3つを含めてエンジニアの職務経歴書の全体像を一枚の地図にします。「上流の経験がない」のは個人の怠慢ではなく構造の問題であることを、公正取引委員会の実態調査の実数から先に示します。書式そのものの配布はしません。何を書くかの判断だけを扱います。

エンジニアの職務経歴書は「担当工程 × 判断」で読まれる

職務経歴書とは、これまでの業務内容と成果を、応募先が判断できる粒度で示す書類です。 エンジニアの場合、読み手が最初に探すのは「どの工程を、どの規模で、どんな役割で担当したか」の3点になります。

言語やフレームワークの一覧は、その3点を裏づける材料にすぎません。言語の経験年数を並べても、工程と役割が書かれていなければ、読み手はあなたの担当範囲を再現できません。

この記事は次の順に進みます。読みたい項目だけ拾い読みしても分かるように書いています。

1. 職務経歴書・履歴書・スキルシートの役割の違い
2. 「上流の経験が薄い」を構造として扱う(公取委の実数)
3. 下請・常駐のキャリアを書く5つの手順
4. 常駐先の社名・システム名は書いてよいのか
5. 「盛る」ことと「具体的に書く」ことの境界
6. 十数年分をどう束ねるか(分量と並び順)
7. 書き終えたあとにやること

なお、当サイトが何を根拠に勧め・何を勧めないかは編集方針にすべて公開しています。

職務経歴書・履歴書・スキルシートは役割が違う

3つは提出先も目的も別です。 混ぜて考えると、職務経歴書がスキルの羅列になったり、逆に案件表が抜け落ちたりします。

スキルシートは、SES・常駐の現場では営業が常駐先へ提出する資料として使われることが多く、転職の応募書類とは読み手が違います。同じ内容を貼り付けると、転職の場では役割と判断の記述が足りない書類になります。

「上流の経験が薄い」のは、個人ではなく構造の問題です

下請の現場で要件定義に関われる人は、そもそも多数派ではありません。 公正取引委員会が2022年に公表したソフトウェア業の実態調査に、その分布が実数で載っています。

(出典:公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書」2022年6月29日公表。主に担当する工程を1つ選ぶ設問への回答で、回答者は受注側の事業者です)

同じ調査では、回答企業の取引上の位置付けが元請40.4%・中間下請38.2%・最終下請21.3%(n=4,589)と示されています。そして公取委は、多重下請構造では再委託の都度、中間マージン等が差し引かれるため、下層に行くほど受注金額が低くならざるを得ないと記述しています。

つまり、下層に置かれた会社ほど担当できる工程が開発側に寄り、受注金額も下がるという2つの傾向が、同じ調査の中に並んでいます。これは個人の努力の話ではありません。

だから職務経歴書では、「要件定義の経験がない」を欠落として詫びる必要はありません。 代わりに、担当した工程の中で自分が何を判断したかを書きます。書き方は次のセクションで手順にします。

編集部が同じキーワードの検索上位10件を確認したところ、見出しを取得できた7件・計104件の見出しに「商流」「下請」「常駐」を含むものは1件もありませんでした(2026年8月時点)。書き方の解説では扱われてこなかった論点だということです。

商流そのものの仕組み——何次請けか、単価がどこで削られるか——はSESの仕組みと商流の解剖で扱っています。自分の会社の位置が分からない状態では、経歴の翻訳も難しくなります。

下請・常駐のキャリアを書く5つの手順

やることは、現場の言い方を採用の言葉に翻訳する作業です。 順番に進めれば、要件定義の経験がなくても書く材料は出てきます。

手順1|案件を全部書き出す(評価はまだしない)

まず、在籍中に参画した案件を時系列で全部書き出します。期間・常駐先の業種・システムの種類・チーム人数・自分の担当範囲の5項目だけで構いません。

この段階で「これは書くほどのことではない」と削らないでください。削る判断は、材料が全部出てからにします。 案件数が多い人ほど、後の工程で束ね方が効いてきます。

手順2|現場の言い方を工程名に翻訳する

次に、担当範囲を工程名に置き換えます。現場の口語のままでは、応募先の読み手が範囲を再現できないためです。

保守・改修が中心の経歴は、書き方によって印象が大きく変わる領域です。既存システムの影響範囲を特定できる力は、新規開発では身につきません。 そこを工程として明示するかどうかで、読み手の受け取りは変わります。

手順3|工程の中で「自分が決めたこと」を書く

ここが本記事の中心です。工程名だけでは、あなたが担当したという事実しか伝わりません。

同じ実装作業でも、決めたことは必ずあります。 例として、次のような記述に置き換えます。

• 「◯◯機能を実装」→「既存の共通処理を再利用する方針を提案し、改修範囲を◯本から◯本に削減」
• 「テストを担当」→「過去の不具合傾向から観点を追加し、結合テストでの検出漏れを削減」
• 「問い合わせ対応」→「同一原因の問い合わせを集計し、恒久対策を起票して月◯件の再発を停止」

判断・提案・改善の3語のどれかで書けるものを、案件ごとに最低1つ探します。要件定義に関われなかった人でも、この3語は必ず発生しています。

手順4|規模と数字を、出せる範囲で出す

規模が書かれていない経歴は、読み手が難易度を測れません。人数・期間・本数・件数・データ量のうち、手元の記憶で確実に言えるものだけを書きます。

覚えていない数字を推測で埋めないでください。面接で説明できない数字は、書かないほうが安全だというのが編集部の考えです。

手順5|書けない情報を抽象化する

常駐先の企業名やシステムの固有名称は、そのまま書けない場合があります。判断の基準は次のセクションで扱いますが、書けないときは抽象化して残すのが原則です。伏せると経歴自体が消えてしまいます。

常駐先の社名・システム名は書いてよいのか

編集部が確認した範囲では、書いてよい・悪いを一律に決める公的な基準は見当たりません。 判断は、自社と常駐先の間の契約(基本契約書などに置かれる秘密保持の定め)と、自社との労働契約・就業規則によって変わります。

ここで押さえておきたいのは、その契約の当事者はあなたではなく会社同士だという点です。常駐先との取り決めがどうなっているかは、本人の手元にある書面だけでは確認できないことがあります。契約が3枚に分かれている構造はSES契約の仕組みで詳しく扱っています。

したがって編集部は、次の順で扱うことを勧めます。断定できない論点だからこそ、確認の相手を間違えないことが実利になります。

1. 迷ったら書かない——固有名詞は、抽象化しても評価材料が残る
2. 自社の営業・管理部門に確認する——常駐先との取り決めを把握しているのは会社側です
3. 応募先のエージェント経由で提出する場合は、その旨も伝える——提出先が増えるほど扱いは慎重になります

抽象化の実例は次のとおりです。業種・規模・担当工程が残っていれば、読み手は難易度を判断できます。

常駐という働き方そのもの——契約や勤務地、キャリアへの影響——は客先常駐とは何かにまとめています。自分の立場を説明する言葉が整理されていると、書類でも面接でも迷いが減ります。

「盛る」ことと「具体的に書く」ことの境界

当サイトは、事実と異なる自己申告のテクニックを一切扱いません。 担当していない工程を担当したと書く、在籍期間を変える、保有していない資格を書く——これらは書き方の工夫ではなく、別の問題です。

一方で、すでに起きた事実の解像度を上げることは、盛ることではありません。 手順3で挙げた「提案した」「削減した」は、実際にやったことに名前を付け直しているだけです。

区別の基準は1つで足ります。面接で「その具体を教えてください」と聞かれたとき、詰まらずに説明できるかどうかです。説明できない記述は、書き方の巧拙ではなく事実の問題として扱ってください。

なお編集部は、「この書き方なら書類が通る」という言い方をしません。選考の結果は応募先の要件・母集団・時期で変わり、書類の書き方だけで決まるものではないためです。

十数年分をどう束ねるか(分量と並び順)

編集部が確認した範囲では、職務経歴書の枚数を定めた公的な基準は見当たりません。 そのうえで、案件数の多い読者には次の構成を勧めます。

1. 職務要約を先頭に置く(5〜8行)——担当してきた工程・業種・技術の傾向を最初に伝える
2. 直近3〜5年の案件を詳述する——工程・役割・規模・判断まで書く
3. それ以前は一覧表に畳む——期間・業種・システム種類・担当工程の4列だけの表にする
4. 並び順は新しい順——読み手は直近の担当範囲から見ます

畳んだ案件を消さないのがポイントです。「同種の案件を繰り返し担当してきた」という事実自体が、経験17年の説明になります。 全案件を同じ密度で書くと、直近の担当範囲が埋もれます。

40代で経験年数が長い場合、書類の狙いは「若手と同じ土俵で技術の新しさを競うこと」ではありません。どの業種・どの規模のシステムで、何を判断してきたかの蓄積が読まれる部分です。

書き終えたあとにやること

職務経歴書は、書いて終わりではなく「測る道具」として使えます。 応募しなくても、書き上がった時点でできることが3つあります。

• 自分の担当工程の偏りが可視化される——開発と保守に偏っているなら、次に積むものが決まります
• 求人票の要件と突き合わせられる——足りない要件が何本あるかを数えられます
• スカウトや面談で、値札の反応を受け取れる——同じ書類に対してどんな提示が来るかが分かります

現職の単価や年収が妥当かどうかを先に知りたい場合は、SESの単価相場と給与の構造を先に読んでおくと、提示された金額の読み方が変わります。

そして編集部の立場として、書類を更新したからといって、いま転職する必要はありません。 更新した書類は、社内で条件を交渉するときの材料にもなります。

辞めるかどうかの判断そのものに迷いがある場合は、SESを辞めたいと感じたときの手順で、在職のまま進められる段取りを整理しています。

よくある質問

エンジニアの職務経歴書は何枚くらいが目安ですか?

編集部が確認した範囲では、枚数を定めた公的な基準は見当たりません。 実務的には、読み手が最初に見る職務要約で担当工程と役割が伝わることのほうが重要です。

案件数が多い場合は、直近を詳述して古い案件を一覧表に畳むと、密度を保ったまま枚数を抑えられます(→「十数年分をどう束ねるか(分量と並び順)」)。

エンジニアのスキルシートと職務経歴書は何が違いますか?

読み手と目的が違います。 スキルシートは技術要素と経験年数を一覧で照合するための資料で、SES・常駐の現場では営業が常駐先へ提出する用途で使われることが多い書類です。

職務経歴書は、応募先が担当範囲と判断の質を評価するための書類です。スキルシートをそのまま流用すると、役割と判断の記述が足りない書類になります。

エンジニアの履歴書と職務経歴書の違いは何ですか?

履歴書は事実確認、職務経歴書は内容の評価のための書類です。 履歴書は在籍企業・期間・学歴・資格といった基本情報を確認する用途で、職務経歴書は業務内容と成果を判断する用途で読まれます。

同じ職歴でも、履歴書には社名と期間だけ、職務経歴書には工程・役割・規模を書く、という書き分けになります。

職務経歴書はどこまで書けばいいですか?

面接で説明できる範囲までが上限です。覚えていない数字や、担当していない工程を埋めるために推測を書くと、面接で整合が取れなくなります。

一方で、常駐先の固有名詞など書けない情報は、抽象化して残します(→「常駐先の社名・システム名は書いてよいのか」)。

webエンジニアの職務経歴書はどう書けばいいですか?

基本の骨格は同じで、強調する材料が変わります。 Web系・自社開発では、担当プロダクトと関わった機能、ユーザー数や負荷の規模が評価材料になりやすい領域です。公開されているアウトプット(GitHubのリポジトリ・技術記事・登壇)も同様に見られます。

一方、受託・常駐が中心の経歴では、公開できるアウトプットが手元にないことが普通です。その場合は、本記事の手順2〜手順4で担当工程と判断を厚く書くほうが現実的だと編集部は考えます。

エンジニアの職務経歴書の役割は何ですか?

応募先が「自社の案件を任せられるか」を判断するための材料を渡すことです。 そのため、技術の一覧よりも、どの工程をどの規模で担当し何を判断したかが読まれます。

同時に、書き上げた書類は自分の担当工程の偏りを可視化する道具にもなります(→「書き終えたあとにやること」)。

まとめ

• エンジニアの職務経歴書は、**言語の一覧ではなく「担当工程 × 判断」**で読まれます
• 下請事業者が主に担当する工程は開発56.6%で、提案・要件定義は5.5%(公正取引委員会・2022年・法人n=2,589・受注側の回答)。上流の経験が薄いことは、個人の欠落ではなく構造として扱ってよい論点です
• 書き方は5手順——①案件を全部出す ②現場の言い方を工程名に翻訳する ③工程の中で決めたことを書く ④規模と数字を出せる範囲で出す ⑤書けない情報を抽象化する
• 常駐先の企業名・システム名を書けるかは契約次第で、編集部が確認した範囲では一律の公的な基準は見当たりません。 迷ったら書かず、自社の営業・管理部門に確認してください
• 事実と異なる自己申告は扱いません。判断の基準は「面接で詰まらずに説明できるか」の1点です
• 案件数が多い場合は、直近を詳述して古い案件を一覧に畳みます
• 書き上げた書類は、応募しなくても自分の担当工程の偏りと値札を測る道具になります

なお、本記事の内容は一般的な情報の整理です。秘密保持の扱いなど個別の状況については、自社の担当部門や専門家に確認してください。

編集部の運営メンバーは、エンジニア職ではなくWebマーケティング領域の採用で、書類選考に関わってきました。そこで繰り返し感じたのは、担当範囲が具体的に書かれている書類は、経歴の派手さと関係なく読む時間が長くなるということです。工程の翻訳は、その時間を作るための作業だと考えています。

参考・出典

• 公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書」(2022年6月29日公表) https://www.jftc.go.jp/houdou/pressrelease/2022/jun/220629_sw_03.pdf (下請事業者が主に担当する工程=法人n=2,589で開発56.6%・設計20.6%・運用5.9%・提案・要件定義5.5%・システムインテグレーション5.4%・テスト1.3%〔主に担当する工程を1つ選ぶ設問への回答〕/取引上の位置付け=n=4,589で元請40.4%・中間下請38.2%・最終下請21.3%/「多重下請構造下では再委託の都度、中間マージン等が差し引かれるため、下層に行くほど受注金額が低くならざるを得ない」の記述。割合はいずれも受注者側がそう回答した数値です)
  • 報告書概要 https://www.jftc.go.jp/houdou/pressrelease/2022/jun/220629_02_sw.pdf /公表ページ https://www.jftc.go.jp/houdou/pressrelease/2022/jun/220629_software.html
• 編集部によるSERP調査(2026年8月16日実施):対策KWの検索上位10件の見出しを抽出し、見出しを取得できた7件・計104件の見出しに「商流」「下請」「常駐」を含む見出しがないことを確認