採用担当者が見ているポイント
| 評価ポイント | 見ている内容 | 評価に占める割合 |
|---|---|---|
| 技術スタック | 求めるスキルとのマッチ度 | 30% |
| プロジェクト実績 | 規模・役割・成果の具体性 | 35% |
| 成長の軌跡 | キャリアの一貫性と成長方向 | 20% |
| 読みやすさ | 構造化されているか、冗長でないか | 15% |
最も重要なのは「プロジェクト実績」だ。 何を使って何を作ったかだけでなく、「なぜその技術を選んだか」「どのような課題をどう解決したか」まで書けると、技術的な判断力をアピールできる。
採用担当者は1日に数十件の職務経歴書を読む。 最初の30秒で「もっと読みたい」と思わせる構成が重要だ。
職務経歴書の基本構成
| セクション | 記載内容 | 分量目安 |
|---|---|---|
| 職務要約 | 経験年数、得意領域、キャリアの方向性 | 3〜5行 |
| 技術スタック | 言語・FW・DB・クラウド・ツール | 表形式で1ページ以内 |
| 職務経歴（各社ごと） | 在籍期間、ポジション、プロジェクト詳細 | 各社1〜2ページ |
| 自己PR | 強み、今後のキャリア志向 | 5〜10行 |
全体で3〜5ページが目安。 それ以上になると読まれない可能性が高い。 直近の経験を最も詳しく書き、古い経験は要約する。
職務要約の書き方
職務要約は「エレベーターピッチ」だ。30秒で自分の価値を伝える。
良い例： 「バックエンドエンジニアとして7年の経験。Go/TypeScriptを中心に、金融・EC領域でマイクロサービスアーキテクチャの設計・実装を担当。直近3年はテックリードとしてチームの技術方針策定、コードレビュー、メンバー育成にも従事。」
NGな例： 「2018年にエンジニアとしてキャリアをスタートし、さまざまなプロジェクトに参画してきました。Java、Python、Go、Ruby、PHPなど多くの言語を経験し、フロントエンドからバックエンドまで幅広く対応できます。」
NGの例は具体性がなく、「何でもできます」は「何も尖っていない」と同義だ。
技術スタックの書き方
| カテゴリ | 良い書き方 | NGな書き方 |
|---|---|---|
| 言語 | TypeScript（3年）、Go（2年）、Python（1年） | TypeScript, Go, Python, Java, Ruby... |
| フレームワーク | React 18 + Next.js 14（2年） | React, Vue, Angular, Svelte |
| DB | PostgreSQL（設計・チューニング経験あり） | MySQL, PostgreSQL, MongoDB, Redis |
| クラウド | AWS（EC2, ECS, RDS, S3, CloudFront） | AWS, GCP, Azure |
ポイントは「経験年数」と「深さ」を明示すること。 チュートリアルを触っただけの技術を列挙するのは逆効果だ。 「浅く広い」より「深く適切」な記述が評価される。
プロジェクト実績の書き方テンプレート
| 項目 | 記載例 |
|---|---|
| プロジェクト名 | ECサイトリプレイスプロジェクト |
| 期間 | 2024年4月〜2025年9月（18ヶ月） |
| チーム規模 | 8名（エンジニア5、デザイナー2、PM1） |
| 担当 | バックエンドリード（API設計、DB設計、コードレビュー） |
| 技術スタック | Go, PostgreSQL, Redis, AWS ECS, Terraform |
| 課題と解決策 | レガシーPHPシステムからGoへの段階的移行。API Gatewayパターンを採用し、既存システムと並行稼働させながら無停止で移行を完了 |
| 成果 | レスポンスタイム60%改善（平均800ms→320ms）、サーバーコスト40%削減 |
「成果」は可能な限り数値で示す。 「パフォーマンスを改善した」ではなく「レスポンスタイムを60%改善した」と書くことで、インパクトが明確になる。
GitHubとポートフォリオの活用
職務経歴書にGitHubアカウントやポートフォリオサイトのURLを記載するエンジニアが増えている。
| 種類 | 効果 | 注意点 |
|---|---|---|
| GitHub | コーディングスタイル、OSSへの貢献を可視化 | 草が生えていない場合は逆効果になりうる |
| 技術ブログ | 技術的な思考力、アウトプット力のアピール | 低品質な記事が多いと評価を下げる |
| 個人プロジェクト | 自発性と技術への情熱を示す | 完成度の低いものは載せない |
ポイントは「量より質」だ。 READMEが充実し、テストが書かれ、CIが回っているリポジトリが1つあれば十分だ。
自己PRの書き方
自己PRは「この人と一緒に働きたい」と思わせるセクションだ。 技術力だけでなく、チームへの貢献やコミュニケーション力もアピールできる。
良い例： 「技術選定においては、チームのスキルセットと保守性を重視した意思決定を行ってきました。直近のプロジェクトでは、流行のフレームワークではなくチームの習熟度が高いGoを選択し、開発速度を落とさずにリプレイスを完了させました。」
NGな例： 「新しい技術に常に興味を持ち、休日もプログラミングをしています。コミュニケーション能力が高く、チームワークを大切にしています。」
NGの例は抽象的で、誰にでも当てはまる内容だ。 具体的なエピソードに基づいた自己PRが説得力を持つ。
よくあるNG例と改善法
| NGパターン | 問題点 | 改善例 |
|---|---|---|
| 「Reactで画面を作成しました」 | 誰でも書ける、差別化がない | 「React + SWRでリアルタイムデータ表示を実装し、UX改善によりCV率が15%向上」 |
| 「チームメンバーとして参画」 | 役割が不明確 | 「5名チームのバックエンドリードとして技術選定〜レビューまで担当」 |
| 技術スタックを20個以上列挙 | 浅い印象を与える | メインスキル5〜8個に絞り、経験年数を添える |
| 古い経験を詳細に書く | 現在のスキルが見えない | 直近2〜3社を詳しく、それ以前は要約 |
職務経歴書は「過去の記録」ではなく「未来への提案」だ。 「私を採用すると、こんな価値を提供できます」というメッセージを伝えることが目的であり、そのためには過去の経験を「応募先企業にとっての価値」に翻訳する作業が必要だ。 あなたの職務経歴書は、その翻訳ができているだろうか。
経験年数別の書き方戦略
職務経歴書は、キャリアのステージによって力点を変えるべきだ。
1〜3年目（ジュニア）。 プロジェクト経験が少ないため、学習速度と技術への意欲を強調する。 「未経験の技術Xを2週間でキャッチアップし、機能実装を完了した」といった具体的なエピソードが有効だ。 個人プロジェクトやOSS貢献があれば積極的に記載する。
4〜7年目（ミドル）。 技術的な深さと幅のバランスを示す。 単なる実装者ではなく「技術的な判断ができる人材」であることを、具体的な意思決定のエピソードで示す。 「MongoDBとPostgreSQLで迷った際に、トランザクション整合性の要件からPostgreSQLを選定した」など。
8年以上（シニア / リード）。 技術力に加え、組織への影響力を示す。 「チーム全体のコードレビュー文化を構築した」「採用プロセスの技術面接を設計・運用した」など、個人の実装を超えた貢献を強調する。 マネジメント経験がある場合は、チーム規模と成果を明記する。
職務経歴書の最終チェックリスト
提出前に以下を確認しよう。
・誤字脱字がないか（技術名のスペルミスは致命的） ・全体が3〜5ページに収まっているか ・直近のプロジェクトが最も詳しく書かれているか ・成果に数値が含まれているか ・応募先企業の求めるスキルがスキルサマリーに反映されているか ・GitHubやポートフォリオのURLが正しくリンクされているか ・連絡先（メールアドレス・電話番号）が正しいか
導入5ステップ
ステップ1: 採用側の4評価軸に沿って骨組みを作る
技術スタック30%、プロジェクト実績35%、成長の軌跡20%、読みやすさ15%という配点を意識し、職務要約・技術スタック・職務経歴・自己PRの4セクションで全体3〜5ページに収める。
ステップ2: 職務要約を30秒のエレベーターピッチにする
経験年数、得意領域、キャリアの方向性を3〜5行で書く。「Go/TypeScriptでマイクロサービス設計、直近3年はテックリード」のように、尖った軸を一文目に出す。何でもできます系の表現は削る。
ステップ3: 技術スタックを「年数と深さ」で書く
TypeScript（3年）、Go（2年）のように経験年数を併記する。触っただけの言語は列挙しない。DBなら「PostgreSQL 設計・チューニング経験あり」、AWSなら使ったサービス名まで具体化する。
ステップ4: プロジェクト実績をテンプレートに流し込む
プロジェクト名、期間、チーム規模、担当範囲、技術スタック、課題と解決策、成果の7項目を統一フォーマットで記述する。成果は「レスポンスタイム60%改善（800ms→320ms）」のように数値化する。
ステップ5: GitHubと自己PRで厚みを足す
README・テスト・CIが整ったリポジトリのURL、質の高い技術ブログ、完成度の高い個人プロジェクトを厳選して載せる。自己PRでは技術力に加え、チーム貢献とコミュニケーション面の強みを具体的なエピソードで示す。
よくある質問（FAQ）
Q. 枚数は何枚が適切？
経験5年以下なら2枚、経験10年以上でも3枚以内が鉄則です。採用担当者は1件あたり3〜5分しか読みません。すべてを書くのではなく、**「応募先に刺さる情報」**を選抜して濃縮するのが正解です。
Q. GitHubリンクは必須？
自社開発・Web系なら実質必須と考えてください。公開リポジトリが1つもない状態では即戦力判定の材料が乏しく、書類段階で落ちるケースも珍しくありません。小さなTypeScriptプロジェクト+READMEが充実した状態が最低ライン。
Q. 職務経歴書とスキルシートの違いは？
職務経歴書は物語（どういう課題をどう解いたか）、スキルシートは**カタログ（何ができるか）**が役割です。自社開発・SaaS転職では職務経歴書が重視され、SES・フリーランスでは両方必須というのが実務上の使い分けです。
