エンジニアの職務経歴書の書き方｜スキルシートとの違い・テンプレート付き

エンジニアの職務経歴書で一番もったいないのは、「触った技術の一覧」で終わっているものです。 技術名の羅列はスキルシートの仕事。職務経歴書が語るべきは「その技術で、何を、なぜ、どう判断して作ったか」——つまり技術の一覧ではなく、技術判断の記録です。書類の通過率も、その後の技術面接のしやすさも、ここで決まります。

🛠 職務経歴書作成ツール（エンジニア用フォーマット）（※公開時はここに作成ツールが埋め込まれます。プロジェクト単位の入力フォームで、この記事の型に沿った経歴書がPDFで完成します）

スキルシートと職務経歴書の違い

スキルシート：技術要素×経験年数×習熟度の表。SES・案件マッチングの世界の書類で、「検索に引っかかる」ための構造化データ
職務経歴書：プロジェクトの物語。「環境→課題→自分の判断→結果」を語る書類

両方求められたら両方出す、が答えです。ただし転職の選考で読み込まれるのは職務経歴書のほう——スキルシートをコピペして職務経歴書と呼ばないことが、この職種の第一ルールです。

プロジェクト実績の型：4点セット

プロジェクトごとに、この4点で書きます。

環境：何のシステムか・規模（チーム人数・期間）・自分の立場（メンバー/リード）・主要技術スタック
課題：そのプロジェクト（または自分の担当）で何が難しかったか
自分の判断と実装：「なぜその技術・設計を選んだか」まで書く。「◯◯を導入」ではなく「△△の課題に対し、□□との比較で◯◯を選定し導入」
結果：性能・工数・品質・運用の数字（「応答時間を◯割改善」「デプロイ頻度を週◯回に」「障害件数を◯→◯に」）

この型で書かれた経歴書は、そのまま技術面接の深掘り（なぜその技術を？他の選択肢は？）への回答台本になります。書類と面接対策が同時に終わるのが、この型の実利です。

職務要約3行：スカウト検索を意識する

冒頭の職務要約は、スカウト型サイトの検索対象でもあります。「経験年数×主要領域×規模感×一番の実績」を、技術キーワードを自然に含めて3行で。

例：「Webアプリケーション開発◯年。バックエンド（言語・フレームワーク名）を中心に、直近は◯名規模のチームリードとして△△の設計・技術選定を担当。□□の改善で応答時間を◯割短縮した実績があります」

GitHub・ポートフォリオ・技術記事の載せ方

載せる場所：職務要約の直下か、スキル欄に「公開リンク」の項を作る
載せる基準：見られて困らないものだけ。整理された（READMEのある）リポジトリ1〜2個は、雑多な10個より強い
業務コードは載せない：守秘義務違反です。業務の実績は文章で、公開できる腕前はGitHubで、という分担
技術記事・登壇資料があれば強力な補強材です。なければ無理に作る必要はありません——空欄より「経歴書本文の技術判断の記述」のほうがずっと重要です

経験帯別のポイント

未経験〜1年：実務の代わりに「制作物の4点セット」（何を・なぜその技術で・どこで詰まり・どう解決したか）。スクール課題そのままではなく、自分の課題設定を1つ
2〜5年：担当モジュールの「自分の判断」を発掘して書く。チーム決定に従った技術も「◯◯の理由で採用された△△で実装し、□□を学んだ」と正直に書けば材料になります
リード以上：技術の詳細より「選定・設計・育成・障害対応の判断」に紙面を割く。市場基準の交渉の土台になるのはこの層の記述です

よくある質問

Q. 使用技術はバージョンまで書くべきですか？ A. 主要なものはバージョン帯まで書くと解像度が伝わります（特にバージョン差が大きい技術）。全部に書く必要はなく、「ちゃんと分かっている人」のシグナルとして要所だけで十分です。

Q. 関わったプロジェクトが多すぎて2枚に収まりません。 A. 直近・代表の3〜4件を4点セットで厚く書き、古いものは1〜2行に圧縮します。全部を均等に書いた経歴書は、全部が薄く見えます。応募先に近いプロジェクトを上に並べ替えるのはツールの得意技です。

まとめ

エンジニアの経歴書は技術判断の記録。「なぜその技術か」まで書けばスキルシートと差がつく
型は環境→課題→判断→結果の4点セット。そのまま技術面接の台本になる
GitHubは整理された1〜2個、業務コードは載せない。要約3行はスカウト検索を意識して

エンジニア向けの記事一覧はengineerハブへ。書き方の全般論は職務経歴書の完全ガイドを参照してください。

最終更新：2026年7月5日／project転職編集部