採用側10年の本音：職務経歴書で落ちる人の共通点は経歴じゃない

先日、うちのチームで今年の採用が一区切りついた。100件以上の面接をしてきた僕が気づいたのは、職務経歴書で落ちてる人の理由は、経歴の派手さじゃなく、その書き方そのものだってことなんですよね。

テンプレートを完璧に埋めてるのに引っかかる人、むしろ雑な見た目なのに絶対面接したくなる人。その差がどこにあるのか、正直に語ります。

落ちる職務経歴書の共通点：「何ができるのか」が見えない

正直、うちが受け取る職務経歴書の7割くらいは「やってたこと」しか書いてない。例えばこんな感じです：

■ プロジェクト名：ECサイト構築
期間：2023年4月～2024年6月（14ヶ月）
規模：チーム8名
プロジェクト概要：Next.jsとAWSを使用したEC機能の開発
担当範囲：フロントエンド開発
使用技術：Next.js, TypeScript, React, PostgreSQL

これね、採用側からすると「で、お前は何ができるんだ？」ってなるんですよ。プロジェクトの説明であって、その人の価値が全く見えない。

うちのチームで「この人なら一緒に働きたい」って思わせる職務経歴書は、このタイプです：

■ プロジェクト名：レガシーNextアプリの性能改善
期間：2023年4月～2024年6月（14ヶ月）
規模：チーム8名（フロント5名）
ビジネス背景：ページ読み込みが平均3秒で、カゴ落ち率が業界平均の1.5倍

【自分の役割】
・Core Web Vitals分析と改善計画策定
・Next.js 13 App Routerへの段階的移行リード
・Image最適化でLCP 45%削減、CLS 0.2→0.05に改善
・チーム内でパフォーマンス測定の自動化を導入（PageSpeed Insights API連携）

【結果】
・セッション中の離脱率を18%削減
・新規ユーザーのコンバージョン率が12%上昇
・デプロイ後3日で効果測定できる体制を構築

使用技術：Next.js 13 App Router, TypeScript, Web Vitals API, Vercel Analytics

ね、全然違うでしょ。後者を読むと、「この人はビジネスインパクトまで考えてコード書く人だ」ってわかる。

経歴書で「嘘をついてないのに落ちる」という地獄

ここからが本当に大事な話なんですけど、僕がチーム面接で見てきた失敗パターンって、ほぼ100%これです。

「自分がやったこと」と「自分が理解してること」のズレが採用を落とす最大の要因なんですよ。

例えば「AWS ECSでマイクロサービス設計」って書いてある人に、「ECSタスク定義で本番環境でハマったことあります？」って聞くと、「あ、うーん、チームの設定を参考にしたので詳しくはちょっと…」みたいな返答が返ってくる。嘘ついてないんです。でも「参加しただけの人」なんですよね。

これ、採用側にとっては最悪なんですよ。だって一緒に働き始めて、3ヶ月後に「あ、この人ECSについて何も理解してない」って気づくんですから。

職務経歴書で落ちないためにやるべきことは実はシンプルで、「その技術で、自分が実装判断した経験があるかどうか」を明確に書く。これに尽きます。

書き方	例文	評価
避けるべき	「PostgreSQLでのデータベース設計」	何をしたか不明瞭
推奨	「PostgreSQLのインデックス戦略（複合キー・部分インデックス）でクエリ応答時間を平均1.2秒→180msに短縮した経験（Explain Analyzeを使った実測ベース）」	実装判断が見える

職務経歴書が「選考を通す文書」じゃなく「面接の入り口」だと理解する

転職サイトのテンプレート見てると、「職務経歴書で自分の全スキルを証明する」みたいな説明がありますけど、これは半分ウソなんですよ。

うちが職務経歴書に期待してるのは、「この人と1時間話す価値があるかどうかを判断する材料」だけです。全スキル証明じゃなくて。

正直、完璧に整形された経歴書より、「この3ヶ月の課題解決が面白い」って思える自分ごととして書かれたものの方が評価高いんですよ。

うちのチームで内定出した人の職務経歴書を見返すと、共通点は三つあります。

1. 「なぜこうしたのか」という判断基準が見える

「GitHubActionsを選んだ理由は、チームのGitHub使用率が90%で…」みたいに、テンプレートには書かれない判断軸が垣間見えるんですよね。これって「ちゃんと考えて選んだ人だ」って伝わる。

2. 失敗経験を堂々と書いてる

「Terraformで本番構成を一気に移行したら、状態ファイル競合で6時間止まった」とか、こういう話を素直に書いてる人ってむしろ信頼度高いんです。失敗からの学習が見える人は、実務経験が濃い証拠。

3. 数字がざっくり、でも根拠がある

「レスポンス時間を3秒→800msに改善」（Lighthouse測定）とか「オンコール対応時間を平均4時間→45分に削減」（PagerDuty実績）みたいに、測定根拠があると「実際にそこにいた人」って伝わるんですよ。

正直、2026年は「職務経歴書 + GitHub」で判断される

ここは2026年だから言っておくと、職務経歴書だけで判断するチームはもう少数派ですよ。うちも面接に進む人には、絶対GitHub見ます。転職活動中のOSS参加ってアホみたいに評価高いんです。なぜなら、誰かに強制されてない、純粋な技術判断が見えるから。

職務経歴書で「Rust5年運用」って書いてある人と、「Rustは業務経験1年だけど、OSS 3ヶ月で10個マージされた」って書いてある人、後者の方が「あ、この人は本当にRustが好きなんだ」って伝わるんですよね。

職務経歴書を書く時の、本当にやるべきこと

うちのチームで使ってるチェックリストを正直に書きます。テンプレートじゃなくて、**「採用側が実務レベルで判断するために必要な情報」**です。

1. プロジェクト説明は「誰に、どの問題を」を先に

❌ 「Next.jsのパフォーマンス改善」
✅ 「新規ユーザーの離脱率が18%と高かったため、
    ページロード時間がネックと分析→改善」

ビジネス背景があるだけで、「この人はビジネスを見てるな」ってわかるんですよ。

2. 使用技術は「選んだ理由」まで書く

❌ 「Next.js 13, TypeScript, PostgreSQL, Docker」
✅ 「Next.js 13 App Router（段階移行で本番停止リスク最小化）
    PostgreSQL（既存DB移行コスト考慮）
    Docker（ローカル開発環境統一、マシンスペック格差対策）」

単なる羅列じゃなくて、「なぜそれを選んだのか」という判断軸があると、その人のエンジニアとしての思考が見える。

3. 結果は「ビジネスメトリクス」で

❌ 「クエリ応答時間が改善した」
✅ 「クエリ応答時間 1.2秒→180ms（PageSpeed Insightsで測定）
    結果、セッション中の離脱率が18%削減、
    コンバージョン率が12%上昇」

技術面での改善も大事ですけど、それがビジネスにどう効いたのかを書くと、採用側は「あ、この人は全体像で考える人だ」って判断します。

4. チーム規模は「自分の立場」まで明記

❌ 「チーム 10名」
✅ 「チーム 10名（フロント5名）、自分はインフラ改善リード
    他チームのバックエンド2名と連携」

自分がどのポジションで、誰と協力したのかが見えると、組織での貢献度が伝わりやすいんですよ。

よくある「職務経歴書あるある」の落とし穴

あるある1：「カジュアルすぎて敬意が足りない」

これ、意外とハマる。「〜〜が得意です！」みたいなキャラクターづけは転職活動では逆効果なんですよ。採用面接官からすると「仕事に対する姿勢がちょっと軽い？」って見えるんですから。

職務経歴書は**「対クライアント資料」くらいの気持ちで**書いた方が無難。プロフェッショナルと親しみやすさのバランスが大事ですね。

あるある2：「技術スタックの羅列合戦」

見た目はすごくなるんですよ。「React, Vue, Angular, Next.js, Nuxt, Remix…」みたいに20個も30個も書いてる人いますけど、採用側からすると「あ、これは『いろんなプロジェクト回された人』だな」ってわかっちゃうんですよね。で、結局のところ「何を深掘りしたのか」が見えなくて、面接しづらい。

むしろ「React 5年（コンポーネント設計・パフォーマンス最適化中心）」みたいに、「浅く広い」より「深い一点」を書く方が評価高い。地味ですけど、これが本当に効きます。

あるある3：「期間計算がズレてる」

これマジでいるんですよ。2023年4月から2024年6月って、「14ヶ月」じゃなく「15ヶ月」です。細かいようですけど、採用面接官は「あ、この人は雑なんだな」って判断しちゃいます。

計算ツール使うか、エクセルで自動計算するかして、絶対にズレを作らない。こういう細部が信頼を作るんですよ。

職務経歴書を「自分の思考プロセスを見える化する文書」として書く

ここからが、うちが100件以上の面接から学んだ本当に大事な話です。職務経歴書で合格する人は、『何をしたか』じゃなく『なぜそうしたのか』という意思決定が見える人なんですよ。

実例を挙げますね。うちが実際に呼んだ人のエピソードです。

■ プロジェクト：社内ダッシュボード再構築
期間：2024年1月～6月（6ヶ月）
背景：既存のGoogle Sheetsベースのダッシュボードは
　　　スプレッドシートが重くなって毎日10分の更新待機

【実装判断】
・ツール選定：BIツール（Metabase vs Superset）を2週間で評価
　Metabase選定理由：
   - チーム全員SQLスキルあり（プロダクトスキル活かせる）
   - オンプレデプロイ可能（データセンシティビティ要件対応）
   - UI カスタマイズ比較でSuperset選定も検討したが、
     導入後3年の保守性を考慮してMetabaseに決定

・インフラ：ストレージをPostgreSQLから分析用DWに移行
　理由：OLTPクエリと分析クエリの干渉で本番遅延

【結果】
ダッシュボード更新時間 10分→30秒
クエリレスポンス 2秒→200ms
メンテナンスコスト 月5時間→月1時間

この人、面接で何聞いても答えられるんですよ。なぜなら、「なぜそこで判断したのか」という思考プロセス全部が書いてあるから。

対して、テンプレート埋めるタイプの人は、面接で「Supersetは検討しなかったんですか？」って聞くと、「あ、えっと、チームが決めてきたので…」みたいになっちゃう。実装判断してない人なんです。

転職活動で「職務経歴書が最初の営業資料」だと認識する

正直に言いますね。うちのチームで面接に呼ぶ/呼ばない分岐は、職務経歴書を読んで『この人と会いたい』って思うかどうかです。

そこに落ちる人の多くは、テンプレートを完璧に埋めてるのに、**「読む側の立場に立ってない」んですよ。採用面接官は毎日10～20個の職務経歴書を読みます。その中で「あ、面白い」って思わせるには、「業界標準的なキレイさ」より「その人の実装判断が見えるかどうか」**が全てなんですよ。

まとめ

うちが10年の採用面接で学んだ、職務経歴書で落ちない3つのポイント：

1. 「何をしたか」から「なぜそうしたのか」へ。実装判断が見える職務経歴書を書く

   • テンプレートの完璧さより、意思決定プロセスの透明性が評価される

2. 数字は測定根拠まで。「1.2秒→800ms」と書いたら、どうやって測ったか明記する

   • 具体的な測定方法があると「実際にそこにいた人」だって伝わる

3. 失敗経験を堂々と書く。むしろ「〜で失敗して、〜に変更した」の方が実務力が見える

   • 完璧な経歴書より、学習プロセスが見える方が採用側は安心する

正直、職務経歴書の書き方なんて本当にテンプレートだらけですけど、うちが実務で感じるのは**「自分の思考プロセスを武器にしてる人が面接に呼ばれる」**ってこと。テンプレートの完璧さなんて、実は誰でも作れるんですよ。

転職活動、頑張ってください。あと、転職決まったらいろいろ考えることあると思いますけど、まずは自分のスキルをちゃんと採用側に伝えることが第一歩ですよ。