業務経歴書の書き方｜職務経歴書との違い・記載項目とIT/施工管理の例文

業務経歴書とは、担当した案件・プロジェクトを単位として経歴を一覧化する書類です。会社単位で職歴を語る職務経歴書とは、目的も構成も異なります。

「業務経歴書を提出してください」と言われて、職務経歴書と同じものだと思って出してしまう。これは、IT業界や建設業界への転職・商談でよくあるつまずきです。

両者の違いを一言でいうと、職務経歴書が「どの会社で何をして、どんな強みがあるか」を語る書類なのに対し、業務経歴書は「どんな案件を、どの立場で、どんな環境でやってきたか」を一覧で示す書類です。読み手も違います。職務経歴書の主な読み手は人事ですが、業務経歴書の読み手は現場のリーダーや技術責任者、つまり一緒に働く実務者であることが多いのです。

そのため、評価のポイントも変わります。

• 職務経歴書：強み・成果・人柄が伝わるか。自己PRの完成度
• 業務経歴書：経験の中身が正確に分かるか。案件の網羅性と項目の精度

業務経歴書という呼び方は、特にIT業界（SES・受託開発）や建設業界で根付いています。「スキルシート」「技術経歴書」と呼ばれる書類も、おおむね同じ性格のものです。呼び方は会社や現場によって揺れがあるため、求められたら「案件単位の経歴一覧」を指していると理解すればほぼ間違いありません。

業務経歴書が登場するのは、主に「商談・提案・手続き」の場面です。提出先によって見られるポイントが変わります。

具体的には、次の4つの場面が代表的です。

1. SESの商談（客先面談）：SES企業のエンジニアが新しい常駐先に入る際、営業が業務経歴書を先方に提示し、面談で深掘りされます。経歴書の精度が単価や案件の質に直結する、もっとも実利的な使われ方です
2. 派遣の就業先提案：派遣会社が就業先に人材を提案する際の資料になります。個人を特定する情報を伏せた形で使われることが一般的です
3. フリーランスの案件獲得：エージェント経由でも直接契約でも、発注側はまず経歴書で実力を判断します。フリーランスにとって業務経歴書は営業資料そのものです
4. 資格・許可関係の手続き：建設業などでは、資格の受験申請や許可関係の手続きで実務経験を証明する書類が求められることがあります。この用途では様式や要件が申請先ごとに定められているため、必ず公式の案内を確認してください

加えて、IT業界や建設業界の転職活動では、職務経歴書とあわせて案件一覧形式の経歴書を求められることがあります。

あなたがこれから書こうとしている業務経歴書は、どの場面で使うものでしょうか。商談用なら直近案件の説得力、手続き用なら様式と正確さ、というように力点が変わります。目的を先に決めてから書き始めると、迷いが減ります。

業務経歴書の基本は、どの案件にも「案件名・期間・工程・役割・規模・環境」の6項目をそろえることです。

様式の指定がない場合、全体の構成は次のとおりです。

1. タイトル（業務経歴書）と作成日・氏名（提出先によりイニシャル等）
2. 経歴の要約（2〜3行。経験年数と得意領域）
3. 保有資格・スキル一覧（言語・ツール・経験年数の表など）
4. 案件単位の経歴一覧（新しい案件から並べる）

中心となる案件一覧では、各案件に次の6項目を記載します。

• 案件名：内容が分かる名称にします。顧客名は「大手金融機関」「食品メーカー」のようにぼかすのが原則です
• 期間：開始と終了の年月。何カ月かも添えると親切です
• 工程：要件定義〜運用保守のうち、自分が担当した範囲（次のセクションで詳述します）
• 役割：リーダー・サブリーダー・メンバーなどの立場と、任されていた仕事の一言説明
• 規模：チーム人数やプロジェクト全体の人数。施工管理なら請負金額や延床面積など
• 環境・技術：言語、フレームワーク、データベース、クラウド、OS、ツールなど。実際に手を動かしたものだけを書きます

この6点がそろっていると、読み手は一覧を眺めるだけで「どのレベルの仕事を任せられるか」を判断できます。逆に、どれかが欠けた案件が混ざると、その都度確認が必要になり、書類全体の信頼感が下がります。

工程は自己流の呼び方ではなく、業界で通じる標準表記で書きます。どの工程を担当したかは、スキルレベルの判断材料そのものです。

システム開発の工程は、上流から下流へ、おおむね次の流れで表記するのが標準です。

1. 要件定義：顧客や業務部門の要望を整理し、システムで実現することを決める
2. 基本設計（外部設計）：画面・帳票・機能の全体像を設計する
3. 詳細設計（内部設計）：プログラムの内部構造を設計する
4. 実装（製造・開発）：プログラミングを行う
5. 単体テスト：プログラム単位の動作を確認する
6. 結合テスト：機能やシステム間のつながりを確認する
7. 総合テスト（システムテスト）：システム全体を本番同様に確認する
8. 運用・保守：稼働後の維持管理、障害対応、機能改修を行う

読み手は、担当工程の範囲から経験のレベルを読み取ります。一般に、要件定義や基本設計といった上流工程の経験は、顧客折衝や全体設計の力を示すものとして重視される傾向があります。だからこそ、上流を担当した案件では「要件定義（顧客ヒアリング・要件取りまとめを担当）」のように、関与の中身まで書くと説得力が増します。

逆に、少しでも関わったからと「要件定義〜運用保守」とすべての案件に書いてしまうと、面談で深掘りされた際に答えられず、かえって信頼を失います。会議に同席しただけの工程は「要件定義（一部参画）」のように正直に表記しましょう。

ITエンジニアの案件記載は、6項目＋担当業務・貢献の構成で書きます。直近案件を最も詳しく書きましょう。

以下は、案件1件分の記載サンプルです。数値や内容は書き方を示すための架空の例なので、自分の経験に置き換えてください。

例文（ITエンジニア・案件記載のサンプル）：

• 案件名：大手小売業向けECサイトのリニューアル開発
• 期間：20XX年4月〜20XX年3月（12カ月）
• 工程：基本設計、詳細設計、実装、結合テスト
• 役割：サブリーダー（実装チーム5名の進捗管理と設計レビューを担当）
• 規模：プロジェクト全体約20名／開発チーム8名
• 環境・技術：TypeScript、React、Node.js、PostgreSQL、AWS、GitHub
• 担当業務と貢献：商品検索機能の基本設計から実装までを担当。レビュー観点の標準化を提案・運用し、結合テストでの手戻りを減らした

このレベルの記載を直近2〜3案件に施し、それ以前の案件は次のように圧縮します。

例文（古い案件の圧縮記載）：

• 20XX年〜20XX年：製造業向け生産管理システムの保守開発（Java、Oracle）。詳細設計〜テストをメンバーとして担当

冒頭に置くスキル一覧は、「言語・フレームワーク・DB・クラウド・ツール」のカテゴリ別に、経験年数を添えて整理すると読みやすくなります。ここに書いてよいのは、実務で手を動かした技術だけです。学習中のものは「学習中」と明記して分けましょう。商談の面談では、経歴書に書いた技術は必ず質問されると考えてください。

施工管理では、工事名・工期・工事種別・規模・立場・担当業務の構成で書きます。規模と立場が力量の物差しになります。

建設業界の業務経歴書（工事経歴・実務経験の一覧）は、ITの案件一覧と発想は同じで、項目が工事仕様に置き換わります。以下は記載サンプルです。数値は架空の例です。

例文（施工管理・工事記載のサンプル）：

• 工事名：○○市内オフィスビル新築工事（発注者名は伏せ字で可）
• 工期：20XX年4月〜20XX年9月（18カ月）
• 工事種別：建築一式工事（鉄骨造・地上8階建て）
• 規模：延床面積約6,000平方メートル／請負金額は概算帯で記載（例：10億円規模）
• 立場：現場代理人補佐（職人約30名規模の工程調整を担当）
• 担当業務と貢献：工程管理・品質管理・安全管理を担当。週次工程会議の運営と是正指示の記録化を徹底し、手戻りの削減と無事故での竣工に貢献

施工管理で特に見られるのは、次の3点です。

1. 工事の規模（延床面積・請負金額の帯・構造種別）：任された現場の大きさを示します
2. 立場（現場代理人・主任技術者・工事主任など）：責任の重さを示します。資格が前提となる立場は、保有資格とセットで書きます
3. 管理項目（工程・品質・安全・原価のどこまで担当したか）：4大管理のカバー範囲が経験の幅を表します

指定がなければ、前半に職務経歴書の要素、後半に案件一覧を置く2部構成が実用的です。

転職活動では、「職務経歴書を提出。ただし案件単位の経歴も知りたい」という場面が少なくありません。書類を2通に分けるより、1通の中で役割を分担させるほうが、読み手にも自分にも負担が軽くなります。

兼用する場合の構成例は次のとおりです。

1. 職務要約（3〜5行）：経験年数・得意領域・代表的な実績
2. 活かせる経験・スキル：技術や管理項目をカテゴリ別に整理
3. 職務経歴（会社単位）：在籍企業ごとに事業内容・所属・職位を簡潔に
4. 業務経歴（案件単位）：6項目をそろえた案件一覧。新しい案件から
5. 保有資格
6. 自己PR（2〜3段落）

この構成なら、人事は前半で人物と強みをつかみ、現場の技術責任者は後半でスキルの中身を確認できます。読み手によって読む場所が違う、という前提で設計するわけです。

分量の目安は全体でA4・3〜5枚程度です。案件数が多い人は、前述のとおり直近を詳しく、過去を圧縮して調整します。逆に、SESの商談など様式指定がある場面では、兼用版ではなく指定様式に転記して提出します。兼用版を「マスター」として手元に整備しておき、提出先に応じて削る運用にすると、毎回ゼロから書かずに済みます。

提出時の体裁にも気を配りましょう。ファイル形式は指定がなければPDFが無難です。ファイル名は「業務経歴書_氏名_日付」のように、受け取った側が管理しやすい名前にします。作成日（更新日）を書面の冒頭に入れておくと、情報の鮮度が伝わり、古い経歴書を使い回している印象を避けられます。表の列幅や文字サイズも、印刷した状態で読めるかを一度確認してください。中身が良くても、体裁の粗さは「仕事の粗さ」として受け取られかねません。

業務経歴書の失敗は「羅列だけで役割・成果がない」「古い案件から書く」の2つに集約されます。提出前に必ず点検しましょう。

選考や商談で評価を下げやすいパターンを整理します。

• 案件の羅列だけで役割・成果がない：案件名と期間が並んでいるだけでは、読み手は「その中であなたが何をしたのか」を判断できません。各案件に役割と貢献を一言添えるだけで、書類の価値は大きく変わります
• 古い案件から書いてしまう：時系列順（古い順）に書くと、最初のページが何年も前のスキルで埋まります。読み手が知りたいのは直近の実力です。新しい案件から並べる逆編年体を基本にしましょう
• 触っただけの技術を並べる：環境欄を盛ると、面談の深掘りで答えられず信頼を失います。実務で使った技術と学習中の技術は明確に分けます
• 工程の表記が自己流：社内だけで通じる呼び方では、スキルが正確に伝わりません。標準表記に合わせます
• 顧客名・現場名をそのまま書く：秘密保持の観点で問題になります。「大手金融機関」「○○市内の商業施設」のようにぼかすのが原則です
• 期間の空白や重複を放置する：一覧形式は時系列の矛盾が目立ちます。提出前に期間のつながりを確認しましょう
• 規模感がどこにもない：人数や金額帯が無いと、仕事のレベルを推定できません。書ける範囲で規模を示します

あなたの経歴書を初めて読む人が、3分で「何を任せられる人か」を言えるでしょうか。言えそうにない箇所が、直すべき箇所です。

業務経歴書は、案件単位・6項目・逆編年体の3原則を守れば、確実に伝わる書類になります。

この記事の要点を振り返ります。

1. 業務経歴書は案件単位の経歴一覧。職務経歴書とは目的・読み手・構成が違う
2. 使われる場面はSES商談・派遣提案・フリーランス商談・資格や許可関係の手続きなど
3. 各案件は案件名・期間・工程・役割・規模・環境の6項目＋貢献の一言でそろえる
4. 工程は要件定義〜運用保守の標準表記で、関与の実態どおりに書く
5. 並び順は新しい案件から。直近2〜3案件を詳しく、古い案件は圧縮する
6. 指定がなければ職務経歴書と兼用の2部構成が実用的

案件の棚卸しを手作業で進めるのが大変な場合は、キャリビーのAI職務経歴書作成が役立ちます。質問に答えるだけで経歴が構造化され、案件単位の整理にも応用できるたたき台が短時間で完成します。たたき台ができたら、この記事のサンプルと照らして6項目の抜けを埋めていきましょう。次の商談や応募の機会は、いつ来るか分かりません。マスター版の経歴書を、今のうちに仕上げておいてください。