経歴はあるのに書類選考で止まる理由の多くは、経験そのものではなく「書き方」にあります。企業が職務経歴書を読む際に探しているのは、過去の実績評価ではなく「入社後にどの案件でどんな役割を任せられるか」というアサイン仮説です。経験を時系列に並べるだけでは、読み手はあなたを入社後の具体的な場面に配置できません。
この記事では、人材紹介の現場で繰り返し出会う「経験は十分なのに役割が読み取れない経歴書」の具体パターンと、アサインイメージが立つ4つの要素（役割・動かしたもの・課題・転用）を軸に、自分の経歴書を見直す観点を整理します。
企業は職務経歴書で何を読もうとしているのか
Photo by Resume Genius on Unsplash
採用は「過去の評価」ではなく「入社後に任せる役割の仮説検証」です。特にIT・DX・コンサル領域では、企業は職務経歴書を読みながら手元の具体的な案件と照らし合わせています。「この人なら〇〇案件のPMを任せられそう」「△△領域の業務改革フェーズで動いてもらえそう」という像が立つかどうかが、書類選考の分かれ目になります。
逆に言えば、アサイン先が思い浮かばない経歴書は、良し悪し以前に検討の土俵に乗りにくいのです。経験年数が長く、プロジェクト数も多いのに書類で止まる場合、多くのケースで「何をした人か分からない」という読み手側の困りごとが起きています。
企業の採用担当者やコンサルファームのマネージャーは、経歴書を読みながら「最初の3か月で何を任せるか」を想像しています。その像が立たなければ、どれほど立派な経歴でも次に進みません。
経験の羅列が伝わらない理由
Photo by Dylan Gillis on Unsplash
プロジェクト名・規模・期間だけでは、本人が何をした人か分かりません。「大手製造業向け基幹システム刷新プロジェクト（300人月・2年間）に参画」という記述は、読み手にとっては情報の外枠だけが提示された状態です。あなたがPMだったのか、PLだったのか、設計担当だったのか、ベンダーコントロールを担ったのか、それとも要件定義フェーズの一部を担当したのか。これが読み取れなければ、企業はあなたを次の案件に配置できません。
「参画した」「担当した」で終わる記述は、役割の粒度が読み手に委ねられる書き方です。読み手は親切に解釈してくれません。曖昧な記述は「役割が薄かった」と受け取られることの方が多いのです。
同じ案件でも、PM・PL・設計・折衝のどこを担ったかで評価される職種が変わります。あなたがマネジメント寄りで見られたいのか、技術アーキテクト寄りで見られたいのか、業務改革の推進者として見られたいのか。その軸が経歴書から読み取れないと、企業は「どこで使える人か分からない」という理由で見送ることになります。
「マネジメント経験＝部下の人数」ではない｜企業が本当に見ている6つの軸と、経歴書での伝え方でも触れていますが、役割の粒度を伝えることは、自分がどの職種軸で評価されたいかを明示することでもあります。
アサインイメージが立つ4つの要素
Photo by Annie Spratt on Unsplash
経歴書を「入社後のアサインが想像できる状態」に書き換えるには、以下の4つの要素を補う必要があります。
役割: 誰に対して何の意思決定をしていたか
「PMを担当」ではなく、「誰と何を決めていたか」まで書きます。例えば「事業部長・IT部門・ベンダー3社の間で要件の優先順位を調整し、予算内でのスコープ合意を主導した」というように、意思決定の相手と内容を一文で表現すると、読み手はあなたの立ち位置を理解できます。
動かしたもの: 人・組織・顧客・意思決定のどれをどう動かしたか
「メンバー管理」「ステークホルダー調整」という言葉は、何も伝えていません。「何人のチームを率いたか」ではなく、「どんな状態のチームを、どんな状態にしたか」が重要です。例えば「SI経験のみのメンバー5名を、業務部門との直接対話ができる体制に育成し、要件のミスコミュニケーションを減らした」という書き方なら、あなたが何を動かせる人かが伝わります。
課題: 何が壁で、どう解いたか（成功だけでなく判断の過程）
プロジェクトがうまく進んだことだけを書く必要はありません。むしろ「何が壁だったか」を書くことで、あなたの判断力が伝わります。「要件が二転三転し、開発が遅延するリスクがあった。業務部門に週次で仮実装をデモし、早期に合意形成することで手戻りを防いだ」というように、課題と対処を書くと、あなたがどんな局面で力を発揮する人かが見えてきます。
転用: その経験を次の会社のどんな局面で再現できるか
これは経歴書の本文に「転用可能性」として書き込むのではなく、各案件の記述が「次の会社のどんな場面で使えるか」を想像させる書き方になっているかという観点です。例えば「製造業の業務改革」という記述を、「現場の業務フローを可視化し、IT導入前に業務プロセスの無駄を削減する改善を先行させた」と書けば、読み手は「この人は業務とITの両面で動ける人だ」と理解します。
技術経歴書の書き方完全ガイド｜採用側が最初に見る項目と強みの言語化戦略でも強みの言語化について触れていますが、経験を「次にどう使えるか」という視点で読み直すことが、転用可能性を伝える第一歩です。
書き分けの実例：同じ経験でも読まれ方が変わる
Photo by Vitaly Gariev on Unsplash
同じプロジェクト経験でも、書き方次第で読まれ方は大きく変わります。
「基幹システム刷新に参画」→ 誰と何を決めたかを一段落とす
Before:
「大手製造業向け基幹システム刷新プロジェクトにPMとして参画。要件定義からリリースまで担当。」
After:
「大手製造業向け基幹システム刷新プロジェクトにてPMを担当。事業部門・IT部門・ベンダー3社の要件調整を主導し、予算制約の中でスコープを絞り込む合意形成を行った。開発フェーズでは週次で進捗会議を設計し、遅延リスクを早期に可視化する体制を構築した。」
Afterでは、誰と何を決めたかが具体的に書かれているため、読み手は「この人は複数ステークホルダーの間で意思決定を回せる人だ」と理解できます。
「ベンダーコントロール」→ 何が揉め、どう合意形成したかまで書く
Before:
「ベンダーコントロールを担当。品質管理とスケジュール調整を実施。」
After:
「ベンダー側の開発遅延が頻発し、品質低下のリスクがあった。週次で実装物のレビュー会を設け、仕様の認識ズレを早期に検出する仕組みを導入。結果として大きな手戻りなくリリースまで進めた。」
Afterでは、何が問題で、どう対処したかが書かれているため、あなたがどんな局面で力を発揮する人かが伝わります。
「メンバー管理」→ 人数ではなく、どんな状態のチームを何にしたか
Before:
「5名のチームをマネジメント。」
After:
「SI経験のみのメンバー5名を、業務部門との直接対話ができる体制に育成。要件のミスコミュニケーションを減らし、手戻り工数を削減した。」
Afterでは、チームの状態変化が書かれているため、あなたがどんなマネジメントをする人かが見えてきます。
女性管理職×ITコンサルのリーダーシップ論｜自分らしいスタイルを確立する実践ガイドでも触れていますが、マネジメントは人数ではなく「何を変えたか」で伝わります。
書きすぎ・盛りすぎで逆効果になるケース
Photo by Scott Graham on Unsplash
アサインイメージを立てようとするあまり、逆効果になるパターンもあります。
定量表現の水増しは面接で必ず崩れる。確認できない数値は書かない
「コスト削減率30%」「生産性向上50%」といった数値は、面接で必ず「どうやって測ったのか」を聞かれます。答えられない数値を書くと、経歴書全体の信頼性が損なわれます。確認できない数値は書かず、「手戻り工数が減った」「残業時間が減った」という定性表現に留める方が、むしろ信頼されます。
全案件を同じ密度で書くと、何が主戦場か分からなくなる
10年分のプロジェクトを全て同じ分量で書くと、読み手はあなたの強みがどこにあるのか分かりません。直近3年の経験、または応募ポジションに最も関連する経験を厚く書き、それ以外は簡潔にまとめる方が、あなたの軸が伝わります。
応募ポジションごとに強調点を変える（テンプレの使い回しをしない）
PMポジションに応募するなら、意思決定とステークホルダー調整の経験を厚く書く。アーキテクトポジションなら、技術選定と設計判断の経験を厚く書く。同じ経歴でも、どこを強調するかで読まれ方は変わります。テンプレを使い回すのではなく、応募先ごとに強調点を調整することが、書類通過率を上げる最も確実な方法です。
『業界地図』2027年版をITコンサルの転職判断に使う｜AIの地殻変動から読むポジション選びでも触れていますが、応募先のポジションがどんな役割を求めているかを理解した上で、経歴書の強調点を調整することが重要です。
見直しのチェックリストと、書き直さないという判断
経歴書を見直す際のチェックリストを示します。
第三者が読んで「最初の3か月で任せる仕事」を言えるか
同僚や友人に経歴書を見せて、「この人にどんな仕事を任せられそうか」を聞いてみてください。具体的な答えが返ってこなければ、役割の粒度が足りていません。
職種軸（PM/アーキ/業務改革/データ）のどれで読ませたいかが一意か
あなたが「PMとして見られたい」のか「技術アーキテクトとして見られたい」のか、経歴書から明確に読み取れるかを確認してください。複数の軸を欲張ると、どれも中途半端に見えてしまいます。
経歴書を直しても届かない場合は、志望ポジション側のズレを疑う
経歴書を何度見直しても書類が通らない場合、書類の問題ではなく、志望ポジションと自分の経験のズレが大きい可能性があります。例えば、SIerでのPM経験を軸に、戦略コンサルのポジションに応募しても、求められる経験の種類が違うため書類で止まります。この場合、経歴書を直すのではなく、志望ポジションを見直す方が建設的です。
事業会社で活躍するエンジニア・ITコンサルの特徴 — 発注する側から見えるものやメーカー・研究職からITコンサルへ転職する方法｜強みの活かし方と準備ステップでも触れていますが、自分の経験がどんなポジションにフィットするかを見極めることは、経歴書の書き方と同じくらい重要です。
今は動かないという結論も含め、棚卸し自体は市場価値の確認になる
経歴書を見直した結果、「今は転職しない方がいい」という結論に至ることもあります。例えば、現職でもう少し経験を積んでから動く方が、次の選択肢が広がるケースは多くあります。経歴の棚卸し自体が、自分の市場価値を確認する機会になるため、結果として動かなくても無駄にはなりません。
ITコンサルの育休｜取得・復帰の現実と制度を使える環境の見極め方や30代エンジニアがITコンサルに転職して年収アップする方法【実例と戦略を解説】でも触れていますが、転職は「いつ動くか」のタイミングも含めて判断するものです。
職務経歴書は、過去の実績を評価してもらうための書類ではなく、入社後にどんな役割を任せられるかを想像してもらうための書類です。経験を時系列に並べるだけでは、読み手はあなたを次の案件に配置できません。
役割・動かしたもの・課題・転用という4つの要素を補うことで、経歴書は「入社後のアサインが想像できる状態」に変わります。自分の経歴書を見直し、第三者が読んで「最初の3か月で任せる仕事」を言える状態になっているかを確認してください。
もし経歴書を見直しても書類が通らない場合は、書類の問題ではなく、志望ポジション側のズレを疑う視点も持ってください。転職は「動く・動かない」の判断も含めて、自分のキャリアを棚卸しする機会です。
経歴の棚卸しや、自分の経験がどんなポジションにフィットするかを相談したい場合は、転職相談からお問い合わせください。
FAQ
職務経歴書は何枚くらいが適切ですか
IT・DX・コンサル領域では、A4で3〜5枚程度が一般的です。10年以上の経験があれば5枚を超えることもありますが、全てのプロジェクトを同じ密度で書く必要はありません。直近3年、または応募ポジションに最も関連する経験を厚く書き、それ以外は簡潔にまとめる方が、読み手はあなたの強みを理解しやすくなります。
全ての案件を書くべきですか
全ての案件を書く必要はありません。応募ポジションに関連する案件、または自分の強みが最も発揮された案件を中心に書いてください。古い案件や、役割が薄かった案件は、プロジェクト名と期間だけを列挙する形で十分です。
定量的な成果が書けない場合はどうすればよいですか
定量的な成果が書けない場合は、無理に数値を作る必要はありません。「何が壁で、どう解いたか」という課題と対処のプロセスを書く方が、あなたの判断力が伝わります。例えば「要件が二転三転し、開発が遅延するリスクがあった。業務部門に週次で仮実装をデモし、早期に合意形成することで手戻りを防いだ」というように、定性的な記述でも十分に伝わります。
応募先ごとに書き分ける必要はありますか
応募先ごとに、強調点を変える必要はあります。同じ経歴でも、PMポジションに応募するなら意思決定とステークホルダー調整の経験を厚く書き、アーキテクトポジションなら技術選定と設計判断の経験を厚く書く、というように調整してください。テンプレを使い回すのではなく、応募先が求める役割に合わせて経歴書を調整することが、書類通過率を上げる最も確実な方法です。
経歴書を直しても書類が通らない場合は何を疑うべきですか
経歴書を何度見直しても書類が通らない場合、書類の問題ではなく、志望ポジションと自分の経験のズレが大きい可能性があります。例えば、SIerでのPM経験を軸に、戦略コンサルのポジションに応募しても、求められる経験の種類が違うため書類で止まります。この場合、経歴書を直すのではなく、志望ポジションを見直す方が建設的です。自分の経験がどんなポジションにフィットするかを、第三者の視点で確認することをお勧めします。
