採用側が見てる職務経歴書の落とし穴｜100件面接して気づいたこと

採用側と応募側、両方見えてきた話

先日うちのチームで新卒者3名を採用したんですが、その時に100件以上の職務経歴書を見てて気づいたことがある。エンジニアってなぜか技術スキルは細かく書くのに、実務でのインパクトは全く伝わってない履歴書 がめちゃくちゃ多いんですよね。

かくいう自分も、最初の転職の時は採用を落ちまくった。当時は「Pythonで株価分析ツール開発」とか「AWSでインフラ構築」みたいに、やったことだけ書いてた。採用側の視点を持つようになって初めて気づいたんですが、それ企業側には全く価値に見えてない んです。

この記事は、過去の自分に伝えたかったこと、そしてうちのチームで面接する時に「おっ、これは本気度高いな」と感じた職務経歴書の特徴をまとめた話です。

実務インパクトを定量化することの圧倒的な差

実際の例で説明した方が分かりやすいと思うんで、見比べてもらえます？

NGパターン:

2023年4月〜2024年6月 | 決済システム開発
担当: Python、FastAPI、PostgreSQL、AWS(EC2, RDS, Lambda)
・マイクロサービスアーキテクチャの設計と実装
・APIの開発と運用
・データベース最適化

採用がビビる書き方:

2023年4月〜2024年6月 | 決済システムパフォーマンス改善
背景: 決済処理が前月比で遅延が20%増加し、利用者満足度が低下
施策: FastAPI非同期処理最適化 + PostgreSQL接続プール導入
インパクト: 
  - API応答時間: 平均1.2秒 → 0.4秒に短縮（約66%改善）
  - 月間エラー率: 2.1% → 0.3%に削減
  - インフラコスト: AWS月額45万円 → 28万円に削減（月17万円の削減）
関連: SRE的な取り組み。監視・アラート設計も担当

これね、見た瞬間に「あ、この人は単なるコード書き手じゃなくて、ビジネスへの貢献を意識してる人だ」という評価が変わるんですよ。採用面接で次に質問する時のレベルも上がるし。

うちのチームで見た「刺さった職務経歴書」の共通点は、かならず 「Before → After」 のパターンが組み込まれてた。何をやったか、じゃなくて「何が困ってて、お前さんが何をして、結果どうなったか」が3行で分かる。それだけで他の候補者と圧倒的に差が付きます。

技術スタックの書き方で正直気になるところ

転職市場で「使った技術は何か」はもちろん大事なんですが、2026年の今は 「その技術でどんな判断をしたか」まで 書けるかで全然違うんですね。

たとえば、自分の前職で決済チームから移動した時、こう書きました：

2024年7月〜 | 検索基盤の再設計
選定: Elasticsearch → OpenSearchへの移行

判断根拠:
- 費用: Elasticsearch年間210万円 → OpenSearch年間85万円（年間125万円削減）
- スケーラビリティ: ノード追加時の設定時間が40分 → 8分に短縮
- チーム側: OSSの方が内製化しやすいという判断

実装詳細:
- インデックス設計の見直し: クエリレイテンシ450ms → 120msに改善
- 検索精度: Recall 0.91 → 0.96に向上

これは「何を選んだか」だけじゃなく、「なぜそれを選んだのか、どんなトレードオフを考えたのか」まで見えるんです。採用側は「この人はいきあたりばったりじゃなくて、ちゃんと判断してる」と感じます。

自分で経験を整理するプロセスが実は重要

正直、職務経歴書って最初から完璧に書く必要はないと思うんですよ。自分がやったことを定量化して、それを文章化する プロセス自体 が面接で役立つからです。

たとえば、前職での「バッチ処理の最適化」を職務経歴書に書く時、こんな流れで整理してみるんですよ：

1. まず思い出す → どんな問題があった？毎晩3時間かかってた日次集計がネック
2. 定量化する → どのくらい改善した？3時間 → 40分（約87%削減）
3. 背景を考える → なんでそんなに遅かった？SQLがN+1問題で、複数回クエリしてた
4. 実装を書く → 何をした？Batch処理設計で複数処理を並列化、非同期処理導入
5. 副次効果を拾う → 他になった？メモリ使用量が減ってAWS費用も下げられた

このプロセスで整理することで、実は 面接で「なぜそうしたんですか？」って聞かれた時、スラスラ答える ことができるようになるんです。

自分の職務経歴書、AI使って添削してもらった

ここ最近、ChatGPTやCursorを使って自分の職務経歴書をブラッシュアップするって手法がマジで効くんですよね。個人的には、プロンプトはこんな感じで投げてます：

以下は、SRE職を目指すエンジニアの職務経歴書です。
採用側の視点で、以下の3点を評価してください：
1. インパクトの定量化ができているか
2. 技術選定の理由が明確か
3. スケーラビリティ・コスト効率など、実務的な視点が入ってるか

改善案があれば、具体的に指摘してください。

---
[職務経歴書本文]

こうやって回してもらうと、自分が「当たり前だと思ってた」ことが実は「全く伝わってない」ってことに気づくんですよ。特に「技術的には正しいんだけど、ビジネス視点がない」というダメ出しは何度も喰らいました。

職務経歴書のテンプレート（実践版）

実際に自分が使ってる様式を貼っときます。これをベースに自分の経歴を埋めると、採用がちゃんと見える書き方になると思う：

## 期間 | プロジェクト名（または所属・役割）

### 背景・課題
ビジネス側の困りごと、または技術的な制約。数字があるなら入れる。
Ex: "APIレイテンシが1秒以上あり、UX上の問題になってた"

### 施策・実装
やったこと。技術スタックと、その選定理由を1行添える。
Ex: "非同期処理導入。同期処理だとDB接続数がボトルネックになるため"

### 結果
Before/After。可能な限り数字で。
Ex: "API応答時間: 1.2秒 → 0.35秒（約71%改善）"

### 学んだこと・次への活かし方
面接で聞かれそうなことを先に答えておく。
Ex: "スケーラビリティと開発コストのバランスを重視するようになった"

このテンプレートで書くと、面接官は「あ、この人は過去の経験を言語化してる」と感じるんですよ。当たり前に見えるかもしれませんが、実際にはめちゃくちゃ少ないです。

キャリアチェンジを書く時のコツ

エンジニアって異業種から来たり、バックエンド→フロントエンド、SRE→データエンジニアみたいに職種が変わることもありますよね。その時の職務経歴書の書き方が難しいんですが、正直なところ 「なぜ変わったのか」を堂々と書く 方が好感度高いです。

自分の場合、決済チームからSRE寄りの仕事にシフトした時は：

2024年7月以降、インフラ信頼性向上に軸足を移しました。
理由: 決済システムの可用性が0.1%の改善で月額100万円のビジネスインパクトになることに気づき、
      この領域を深掘りしたいと考えたため。

具体的には：
- 監視アラート設計: False Positive率を35%削減
- インシデント対応の自動化: 平均MTTR（復旧時間）が45分短縮

こう書くと「あ、キャリアチェンジじゃなくて、ちゃんと理由がある人なんだな」という評価になるんです。正直さがあると、面接でも「なんで変わったんですか？」という質問がポジティブになります。

最近感じる、職務経歴書の傾向

2026年の今、面接してて気づくのは GitHub が実績代わりになってるエンジニア が増えてるってこと。OSS貢献多いとか、個人プロジェクトのリポジトリが充実してる人は、職務経歴書よりGitHubの方が説得力あるんですよね。

ただし、OSS活動がある場合は職務経歴書に1行書く ことを強く推奨します。採用は「あ、この人のGitHub見てみよう」というきっかけが欲しいんですよ。具体的には「主要OSS：Apache Beam（クエリ最適化で○○件PR merged）」みたいに、貢献の粒度が分かるように書くといいです。

職務経歴書と面接の親和性

ここ大事なんですが、職務経歴書がいい人ほど 面接で自信を持って答えられる んですよね。なぜなら、すでに「こういう背景で、こういう判断をして、こういう結果が出た」という筋が立ってるから。

逆に職務経歴書が曖昧な人は、面接で「あの、それでいくつか質問なんですが…」と掘り下げられ始めると、答えられなくなることが多い。職務経歴書を「面接の予習」だと思って、細部まで自分で理解しておくのが大事です。面接官も「あ、この人は深く考えてるな」って感じるし。

「得意分野」と「経験分野」を分けて書く

これ個人的に気づいたことなんですが、職務経歴書って「やったこと」だけ書きがちなんですよ。でも採用側は「これから何をやってくれるのか」も見てるんです。

だから、経歴の最後に「強み・今後の方向性」をまとめるセクションを入れるのおすすめです：

### 強み
- スケーラビリティ設計（大規模トラフィック対応経験あり）
- インフラコスト最適化（AWS年間1000万以上のコスト削減実績）
- チーム育成（3名の後進者を育成、全員昇進）

### 今後の興味・方向性
AIOps・自動化による運用負荷削減に興味があり、Bedrock・LLMを使った
インシデント対応の自動化に取り組みたい。

採用する側からすると、これがあると「あ、この人はこれからも成長する気があるんだな」という期待感が生まれるんですよ。

職務経歴書のNG例と改善版

実際のチームで「これはないな」と感じた例を見てみましょう。

NG例	理由	改善版
”システム全体の改善に関わった”	何がどう改善されたか不明瞭	”データベースのクエリ最適化により、バッチ処理が3時間から40分に短縮（87%削減）"
"AWS・Python・データベース設計”	技術の羅列。判断根拠がない	”PostgreSQLではなくDynamoDBを選択。スケーラビリティと運用コストの観点から、年間125万円のコスト削減を実現"
"チームリーダーとして統括”	何を管理したのか不明	”5名のバックエンド開発チームをリード。スプリント計画から本番デプロイまで責任を持ち、バグ0運用を実現（過去12ヶ月）”

見比べるとわかるんですが、改善版は「数字」と「判断根拠」が入るだけで、ぐっと説得力が上がるんですよね。

最後に、正直な話

これまで色々書いてきましたが、正直言うと職務経歴書だけで採用が決まることはなくて、面接での対話が一番大事なんですよ。だから職務経歴書は「面接で説得力のある話をするための武器」くらいの気持ちで、完璧に整える必要はないと思ってます。

ただし、「自分の経歴を数字で説明できるか」という訓練になるので、転職気だけじゃなく普段からやっておくと良いかも。会社で企画提案する時とか、昇進面談の時とか、同じスキルセットが使えますから。個人的には、年1回くらいは自分の職務経歴書をアップデートする習慣がおすすめですね。

まとめ

1. 定量化が全て 「何をしたか」より「結果どうなったか」を数字で伝える。応答時間○秒改善、コスト○○万円削減、エラー率が○%下がった、みたいに。

2. 判断根拠を残す なぜそのツール・技術を選んだのか、1行でいいので理由を書く。スケーラビリティ、コスト、内製化の容易さなど、選択背景が見えると強い。

3. Before/After形式 課題 → 施策 → 結果の3ステップで、誰が読んでもわかる文章に。この流れを意識するだけで、職務経歴書の説得力がガラッと変わります。

4. 職務経歴書は面接の予習 完璧さより「自分がしっかり説明できるか」が重要。細部まで理解しておくことで、面接での対答にも力が入ります。

5. 今後の方向性も込める やったことだけじゃなく「次は何をやりたいのか」を書くと、採用側の期待度が変わります。成長意欲が見える人とそうでない人の評価は、地味に大きく違うんですよ。

正直、職務経歴書の完璧な型に当てはめるより、自分の実績を「ビジネスへのインパクト」で語れるようになることが一番の武器になると思ってます。皆さんはどうしてます？職務経歴書で工夫してることあれば、意見聞きたいですね。