開発職の職務経歴書で落とされる人が知らない採用担当者の視点

この記事では、開発職の職務経歴書で採用担当者が実際に見ているポイントと、書類選考で落とされやすいNGパターンを解説します。プロジェクト記述・技術スタックの整理・自己PRの書き方から、SES経験者や経験が浅い方向けの書き方まで、例文をあわせて紹介します。

採用担当者が開発職の書類で最初にチェックする4つのポイント

書類選考の現場では、1件あたり平均30秒から1分程度しかかけていません。その短い時間で「読み進めるかどうか」を判断しているのが採用担当者の実態です。

多くのエンジニアが「スキルが伝わっているはず」と感じながら書類選考で落ちるのは、採用担当者が「読もうとする動機」を持てない書き方になっているからです。まずこの4つの着眼点を押さえてください。

「何をしたか」より「どんな規模で、どんな役割を担ったか」

採用担当者がまず知りたいのは、そのプロジェクトの規模とあなたの立ち位置です。「ECサイトの開発に携わりました」という記述は、何人のチームで・どのフェーズを担当し・どんな技術を使ったのかがまったく伝わらず、書類選考の足切り対象になりやすい。

チーム規模（何人中何名のエンジニアとして）、担当フェーズ（設計・実装・テストのどれか）、使用技術を一行でも明記することで、読み手が具体的な業務イメージを持てるようになります。

技術スタックは「書いた」だけでは評価されない

スキルシートに「Java、Python、AWS」と並べているだけの職務経歴書は、採用担当者には情報として機能しません。どの技術を・何年・どんな文脈で使ったのかがセットで書かれて初めて評価対象になります。

「JavaでのREST API開発3年」「PythonによるMLパイプライン構築経験あり」のように、技術名と実績を必ずセットで記述するのが通過率を上げる最短ルートです。

採用担当者はGitHubを開く

エンジニア採用の現場では、職務経歴書にGitHubのリンクが記載されている場合、採用担当者は必ず確認します。リポジトリのコミット頻度・READMEの丁寧さ・自分で書いたコードの質は、書類だけでは伝えられない実力の証明になります。

GitHubアカウントがある場合は職務経歴書に必ず記載し、できれば代表的なリポジトリのURLも添えてください。業務コードが公開できない場合は、個人開発や学習用のリポジトリでも問題ありません。

職務要約で読み進めるかどうかが決まる

職務経歴書の冒頭に置く「職務要約」は、採用担当者が「この人の書類を最後まで読む価値がある」と判断するための入口です。「〇〇業界で□年間、△△を中心に開発経験を積みました。現在は□□を得意とし、○○領域で即戦力として貢献できます」という構造で、3〜5行でまとめることが目標です。

職務経歴書の全体構成と各セクションの役割

開発職の職務経歴書は、大きく4つのセクションで構成されます。それぞれの役割を理解してから書き始めると、情報の抜け漏れと構成の迷いを防げます。

セクション	役割・目的	目安の分量
職務要約	全体像を伝えてすぐ読み進めてもらう	3〜5行
職務経歴	プロジェクト単位で実績を具体的に示す	1プロジェクトにつき10〜15行
技術スキル・資格	スキルの深さと広さを整理して伝える	表形式で1〜2ページ
自己PR	技術以外の価値・姿勢・今後の方向性を伝える	200〜300文字

職務要約（冒頭サマリー）の書き方

職務要約は採用担当者が最初に読む部分であり、最も差がつくセクションです。長すぎても短すぎても印象が薄くなります。以下の3要素を意識して書いてください。

• 経験の軸：何年・どの領域で開発してきたか（例：Webバックエンド開発を中心に5年）
• 得意分野：特に深く経験した技術・フェーズ（例：マイクロサービスアーキテクチャの設計・実装）
• 次のキャリアとの接続：転職先でどう貢献するか（例：チームリードとして開発生産性の向上に貢献したい）

職務経歴（プロジェクト単位での記述）

職務経歴は、在籍期間の長い会社から順に（または直近から逆順に）記載します。1プロジェクトにつき、後述する7項目を漏れなく書くことで採用担当者が具体的なイメージを持てる記述になります。

複数のプロジェクトを経験している場合は、主要なもの（規模が大きい・難易度が高い・スキルアップに繋がった）を優先し、小さなものはまとめて記述する方法もあります。質より量を選ばず、読み手に伝わる厳選した情報を書くことを意識してください。

技術スキル・開発環境の整理

技術スキルセクションは、採用担当者が「欲しいスキルを持っているか」を素早く確認するためのセクションです。カテゴリ別（言語/フレームワーク/データベース/インフラ/ツール）に整理し、表形式で見やすくまとめるのが最も伝わりやすいフォーマットです。

自己PR欄で伝えるべきこと

自己PRは「技術以外の価値」を伝える場所です。技術力はプロジェクト記述で伝え、自己PR欄では「どんな姿勢で仕事をしているか」「チームの中でどんな役割を担えるか」「どんな環境で力を発揮するか」を書きます。200〜300文字で具体的なエピソードをひとつ盛り込むと説得力が増します。

職務経歴書の下書き作成で時間がかかる場合は、職務経歴書の自動作成ツールを活用して構成の土台を作ることも有効です。

プロジェクト記述の正しい書き方（良い例・NG例）

書類選考で落とされる職務経歴書の多くは、プロジェクト記述の具体性が不足しています。ここでは「通過する記述」と「落とされる記述」を対比しながら、実際に使える例文と必要な7項目を解説します。

プロジェクト記述に必要な7項目

• ① プロジェクト名・期間：システムの名称（社外秘の場合は「社内業務管理システム」等の表現でOK）と在籍期間
• ② プロジェクト概要：何のシステムで・誰のためのもので・規模（ユーザー数・取引規模等）はどのくらいか
• ③ チーム構成と自分の役割：チーム全体の人数と自分のポジション（メンバー/リーダー/サブリーダー等）
• ④ 担当フェーズ：要件定義/基本設計/詳細設計/実装/単体テスト/結合テスト/リリース/運用保守のどれか
• ⑤ 使用技術・開発環境：言語・フレームワーク・DB・インフラ・ツールのバージョン含む具体的な記述
• ⑥ 担当業務の詳細：自分が具体的に何を作ったか・どう対応したか
• ⑦ 成果・工夫：定量的な成果（処理速度○%改善・障害件数○件削減）または定性的な工夫点

通過する例文とNG例の対比

同じ経験でも書き方によって評価は大きく変わります。以下のNG例と良い例を比べてください。

小規模プロジェクトしか経験がない場合の書き方

1〜3名程度のチームや社内ツール開発のみの経験でも、書き方次第で十分にアピールできます。小規模プロジェクトで採用担当者が評価するのは「主体性」と「判断力」です。

技術スタックの書き方と採用担当者が見ているポイント

技術スキルセクションは、採用担当者が求人要件と照合する場所です。「書きすぎ」も「書かなさすぎ」も評価を下げます。適切な粒度と整理の仕方を理解しておきましょう。

言語・フレームワーク別の整理方法

技術スキルはカテゴリ別に表形式で整理するのが最も読みやすいフォーマットです。以下のカテゴリに分けて記述してください。

カテゴリ	記述例
プログラミング言語	Java（5年）、Python（3年）、TypeScript（1年）
フレームワーク	Spring Boot、Django、React
データベース	MySQL、PostgreSQL、DynamoDB
インフラ・クラウド	AWS（EC2・RDS・S3・Lambda）、Docker、Terraform
開発ツール	Git、GitHub Actions、Jira、Confluence
資格	基本情報技術者（取得年）、AWS認定ソリューションアーキテクト – アソシエイト（取得年）

スキルレベルの表し方（習熟度の基準）

習熟度を記述する際は、採用担当者が解釈できる客観的な基準を使います。「実務経験3年」のように年数で示す方法が最も分かりやすく、主観的な「上級者」「得意」という表現は避けてください。

表現	目安
実務経験○年	最も客観的で推奨される表現
業務で使用可能	実務での使用経験がある（年数が短い場合）
個人開発レベル	業務経験はないが個人プロジェクトで使用
学習中	現在勉強中で実務経験なし（書くなら率直に）

「得意」「熟練」などの自己評価ワードは避け、年数と実績で示すのが採用担当者に最も伝わる表現です。習熟度の基準が曖昧だと、面接でギャップが生まれ選考に悪影響を与えることがあります。

状況別の書き方（担当フェーズ・キャリアタイプ別）

開発職の職務経歴書は、担当してきたフェーズやキャリアの経緯によって見せ方が変わります。自分の状況に合った書き方を選んでください。

実装中心のエンジニア

実装（コーディング）が主な業務だった場合、「何を・どう実装したか」の具体性が評価軸になります。コード品質への意識（テスト・リファクタリング）や、パフォーマンス改善の取り組みを書くと、技術力の高さをアピールできます。

SES・派遣経験が多い場合の整理

SES（システムエンジニアリングサービス）や派遣で複数の現場を経験している場合、職歴が多くなりがちです。この場合は「在籍した会社」と「担当したプロジェクト」を分けて整理するのが基本です。

注意が必要なのは、「この現場はあの現場と似ていた」という理由で記述を省略しないことです。採用担当者は各プロジェクトの経験の広さを評価するため、短期でも業種や技術が異なるプロジェクトは個別に書く方が有利です。

経験が浅い（1〜3年目）場合

経験年数が短い場合は「実績の量」ではなく「成長の姿勢と学習力」がアピールポイントになります。「任されたタスクをどう進め・何を学んだか」の記述に力を入れましょう。

• 業務外の学習（個人開発・資格取得・技術ブログ・OSS貢献）を職務経歴書内で触れる
• 「分からなかったことをどう調べ・解決したか」の姿勢を具体的に書く
• GitHub・Qiita・個人ブログのURLを添付する

経験が浅い段階では、職務経歴書を自分だけで完成させることが難しい場合もあります。職務経歴書の有料添削サービスを利用して第三者の視点をもらう方法も有効です。

自己PRで差をつける書き方

自己PRは採用担当者が「この人と一緒に働きたいか」を判断する場所です。優秀なエンジニアでも、この欄で「技術が得意です」だけを書いて落ちるケースは珍しくありません。

技術力だけでアピールする落とし穴

採用担当者は書類全体で技術力の評価をすでに終えています。自己PR欄で「Java歴5年で、Spring Bootを使ったAPI開発が得意です」と書いても、プロジェクト記述の繰り返しにしかなりません。

自己PR欄で伝えるべきは、技術を使って「何を達成したか」という問題解決力と、チームの中でどんな存在であるかです。「私は〇〇した結果、△△を達成しました」という構造で書くのが基本です。

採用担当者が評価する3つの視点

自己PR例文（良い例・NG例）

自己PR文の作成に行き詰まりを感じた場合は、職務経歴書の作成代行サービスを利用して、客観的な視点で整理してもらう方法もあります。

まとめ

• 採用担当者は書類を30秒〜1分で判断する。最初にチェックするのは「規模・役割・技術」の3点
• プロジェクト記述には7項目（概要・規模・チーム・フェーズ・技術・担当業務・成果）を必ず含める
• 技術スタックは羅列ではなく、実績と紐付けて書く。年数と使用場面を明記する
• SES経験が多い場合は、在籍会社とプロジェクトを分けて整理し、プロジェクトごとに個別に記述する
• 自己PRは技術の繰り返しではなく「問題解決力・チームへの貢献・成長意欲」を具体的なエピソードで伝える

職務経歴書は一度書いて終わりではありません。応募するポジションの要件に合わせて微調整しながら使うことで、書類通過率は上がっていきます。

開発職の職務経歴書に関するよくある質問

職務経歴書に守秘義務があってプロジェクト名や社名を書けない場合はどうすればいいですか？

機密情報に配慮しながら「大手小売業向け在庫管理システム」「金融機関の勘定系システム改修」など、業種とシステムの種類が分かる表現に置き換えて記述してください。企業名・システム名が不明でも、規模・担当フェーズ・使用技術・成果の記述は可能です。採用担当者は企業名よりも「何をどのくらいのスケールで経験したか」を重視しています。

GitHub・ポートフォリオは必ず記載すべきですか？

記載できる状態にあれば必ず記載してください。採用担当者がエンジニアを評価する際、GitHubの実績は書類の補強情報として高く評価されます。業務コードが公開できない場合でも、個人開発・学習用リポジトリで問題ありません。READMEを整備し、何を作ったか・なぜ作ったかが分かる状態にしてから記載するのが理想です。

職務経歴書のページ数はどのくらいが適切ですか？

一般的に2〜3ページが目安とされています。経験年数が5年以上であれば3ページ程度になることも自然ですが、4ページを超える場合は情報の取捨選択が必要です。直近3〜5年分の経験を厚く書き、古い経験は簡潔にまとめる構成にすると読みやすくなります。1ページにまとめようとして情報を削りすぎるのは避けてください。

フリーランスや副業の経験は職務経歴書に書くべきですか？

書くべきです。フリーランス・副業での開発経験は、自分で案件を取得・管理しながら成果物を納品したという主体性の証明になります。記述方法は会社員の場合と同様に、プロジェクト単位で担当業務・使用技術・成果を具体的に書いてください。契約上公開できない情報は「業種・規模・技術」のみの記述で代替できます。