DXコンサルタントの職務経歴書の書き方｜構想・導入・定着の工程別記載例とNG例を解説

相談してみる→

監修リメディ株式会社 ヘッドハンター清 龍一

東京大学を卒業後、株式会社クニエに入社。ヘルスケアチームにて、医療機関向けの業務改革およびDX支援に従事。製薬企業と医療機関の治験リクルートメント領域における新規サービス立ち上げプロジェクトでは、病院現場の業務プロセス整理やシステム要件の検証を担当。また、医療機関を対象とした医療DX推進プロジェクトに参画し、診療記録や問診票・同意書などの電子化を通じて、業務効率化と情報共有基盤の整備を支援。現在はこれまでのバックグラウンドを活かし、プロフェッショナルファームに在籍する / 志望する方向けの転職支援を行う。

事業会社のDX推進やSIerでの導入経験をDXコンサルタント向けの職務経歴書に書くときは、1つの案件を「構想・導入・定着」の3工程に分け、工程ごとに自分の役割、関わった部門や人数、業務がどう変わったかを書くのが基本です。KPMGコンサルティング、PwCコンサルティング、野村総合研究所、Ridgelinezの公式募集要項（4社6件）を読むと、システムを入れた経験に加えて、業務改革の経験年数、チームを率いた経験、導入後の定着や内製化を担う力が要件として並びます。

本記事は、事業会社のDX推進部門、業務改革・経営企画、SIerやITベンダーでの導入のいずれかを経験し、DXコンサルへの応募書類をこれから書く人を対象にしています。システムの担当範囲と業務の成果のどちらを前に出すかで迷っている人に向けて、工程別の書き方と盛らない示し方を、求人の原文と照らしながら示します。

本記事のポイント

DXコンサルの職務経歴書で評価の対象になるのは、「何のシステムを入れたか」よりも業務がどう変わり、定着したかです。要点を先に表にまとめます。

項目	内容
書く単位	1案件を構想・導入・定着の3工程に分け、工程ごとに役割・規模・成果を書く
先に示す経験	応募先の必須要件に当たる工程（業務分析・構想策定、導入の推進、定着・内製化のいずれか）
成果欄の中心	業務の指標、利用の状況、運用体制の変化。システムの機能や技術名は前提として短く書く
避けたい書き方	「導入を担当」で終える、チームの成果を自分の成果に見せる、見込みの数値を実績として書く
面接への備え	書いた数値の算出方法と、自分が判断した場面を説明できるようにしておく
相談のタイミング	応募先の要件に経歴がどう当たるか判断できないとき、書き直した実績欄を出す前

最初に決めたいのは「書く単位」です。案件を工程で区切っておけば、応募先ごとに先頭へ出す工程を入れ替えるだけで済み、職務経歴書を一から作り直す必要がなくなります。

次に、自分の経歴が求人のどの要件に当たりやすいかを確かめます。下の表は、本記事が対象とする3つの経歴を、確認した募集要項の記載と結び付けたものです。

現在の経歴	当たりやすい求人要件	職務経歴書で先に示す経験	補いたい経験
事業会社のDX推進部門	PwC：事業会社でDXに関わるプロジェクトの実務経験（必須要件の選択肢の一つ）／Ridgelinez：DX推進部門での職務経験（歓迎）	社内の関係部門を動かし、導入後の利用を定着させた工程	社外の相手に提案・報告した経験（KPMGは「クライアントサービス経験」を必須に挙げる）
業務改革・BPR・経営企画	KPMG：業務改革における業務分析/構想策定（2年以上、技術を活用した業務プロセス改善との選択）／NRI：組織改革や業務改革を完了まで遂行した経験（歓迎）	現状業務の分析と、変革の目的・指標を決めた構想の工程	デジタル技術を使って業務を変えた工程
SIer・ITベンダーで導入	PwC：システム導入に関わるプロジェクトデリバリ経験（必須要件の選択肢の一つ）／Ridgelinez：SIプロジェクトのPM経験（コンサル案件のリード経験に加える1項目の選択肢）	要件定義、推進体制づくり、関係部門との調整	業務側の成果（NRIの求人は主な顧客をビジネス部門と注記）

どの行に当たるかで、書き始める工程が変わります。複数の行に当てはまる人は、応募先の必須要件に近い行を優先してください。

募集要項から見る、DXコンサルの職務経歴書で見られる4つの点

4社6件の募集要項を要件ごとに並べると、職務経歴書で見られやすいのは「業務改革の経験」「関係者を動かした経験」「定着まで担った経験」「チームを率いた経験」の4つに整理できます。

求人で求められる経験	職務経歴書で書く項目	成果指標の例	NG表現	改善の方向
業務改革・業務分析/構想策定（KPMGのDXコンサルタントは2年以上）	対象業務、現状の課題、変革の目的、自分が担った分析・構想の範囲と期間	処理時間、手戻りの件数、承認にかかる日数など対象業務の指標	「業務改革を推進」	対象業務・担当範囲・期間を書く
関係者を巻き込む力（NRIは企画を社内外の関係者へ説明し巻き込む力、Ridgelinezは部門責任者との関係構築を挙げる）	合意を取った相手の部門・役職、論点、合意までの進め方	意思決定までの期間、巻き込んだ部門の範囲	「関係者と調整」	誰と、何を決めたかを書く
定着・内製化（NRIは変革の定着化まで、PwCは人材育成と内製化、KPMGはDXを永続化させる組織/人材変革を掲げる）	導入後の利用状況、業務ルールの変更、社内で運用できる体制づくり	利用者の割合、問い合わせ件数の推移、社内で運用を担う人数	「稼働後も保守を担当」	稼働後に何を変え、誰へ運用を引き継いだかを書く
チームを率いた経験（KPMGは3名以上のスタッフを指揮した経験。マネージャー以上は提案・プロジェクトマネジメント経験が必須）	指揮した人数、役割分担、自分が下した判断	期限・品質・予算に対する結果	「リーダーとして推進」	人数・期間・自分が決めたことを書く

IT導入を中心に経験してきた人が意識したいのは、3つめの定着です。NRIのDXコンサルタントの募集要項は、主たる顧客はビジネス部門であり、情報システム部門ではないと注記しています。PwCのデジタルプロセス＆プラットフォーム変革コンサルタントでも、役割の一つは業務とITが一体となってKPIを共有するチームづくりです。NRIの記載は業務側を相手にすること、PwCの記載は業務とITが同じ指標で動くチームをつくることを示しています。どちらも、システムを入れた後に業務側で使われ続ける状態まで担った経験、つまり定着の工程と結び付けやすい要件です。

ここはリメディの見解ですが、こうした求人に応募するなら、システムの担当範囲は前提として短くまとめ、成果欄には業務の指標や利用状況の変化を置くほうが要件と結び付けやすくなります。

IPAの役割定義でいえば「ビジネスアーキテクト」に近い

書く順番の手がかりになる公的な基準が、IPA（情報処理推進機構）の「DX推進スキル標準」です。DXの推進に必要な主な役割を6つの類型に分けて定義しています。

そのうちビジネスアーキテクトは、変革で実現したい目的を定義し、ビジネスモデルと業務プロセスを設計して、関係者をコーディネートしながら成果を生み出す役割です。DXコンサルと同じ職種の定義ではありませんが、目的、設計、関係者、成果の順に経験を並べると、求人の4つの点とも重なります。

4つの点に自分の経歴を当てはめていくと、職務要約の冒頭で示す経験は1つに絞れてきます。どれを先頭に置くか決めかねるなら、応募を考えている求人と経歴を並べ、担当者と一緒に選ぶこともできます。

1案件を構想・導入・定着の工程に分けて書く

DXの案件を書くときの基本形は、1案件を「構想」「導入」「定着」に分けることです。工程ごとに求められる役割が違うため、分けて書くと自分がどこを担ったかが一読で伝わります。

工程で分けて考えるのは、求人の側も同じです。NRIの経営DX推進コンサルタントは、構想策定から業務・組織改革、テクノロジーの導入、変革の定着化までを一気通貫でやり遂げる役割を掲げています。KPMGのDXコンサルタントの応募資格も、業務分析/構想策定と、技術を活用した業務プロセス改善を別々の経験として挙げています。

リメディの見解では、職務経歴書も求人と同じく工程で区切っておくと、採用側が要件と照らし合わせやすくなります。担った工程だけを正確に書けば足り、全工程を担っている必要はありません。

構想：課題の定義と変革の目的を書く

構想の工程で書くのは、対象業務と課題を何で把握したか、変革の目的と指標をどう決めたかです。業務量の調査、現場へのヒアリング、データの分析など、課題をつかんだ手段まで書くと、分析の深さが伝わります。

Ridgelinezの戦略コンサルタントの求人は、必須スキルに課題定義、原因分析、解決策の提案と実行支援を含む問題解決を挙げています。経営層や部門長に何を提案し、どこまで採用されたかも、この工程に入れてください。

導入：要件定義・推進体制・関係部門の調整を書く

導入の工程で中心になるのは、推進体制の中での自分の位置と、要件の優先順位を誰とどう決めたかです。ベンダーの管理、移行計画、テストへの業務部門の巻き込みなど、業務側と技術側の間で決めたことを具体的に書きます。

PwCの求人は、コンサルティングファーム・SIer・クラウドベンダーでのシステム導入に関わるプロジェクトデリバリ経験を、必須要件の選択肢の一つに挙げています。導入工程の経験は、それ自体が応募の根拠になる場合があります。

定着：利用の定着・運用体制・内製化を書く

定着の工程で書くのは、稼働後に業務ルールや教育をどう変え、社内の誰が運用を担う体制にしたかです。稼働した時点で終わらせないことが、この工程の書き方の要点です。

PwCの求人は差別化領域での人材育成と内製化を、KPMGの求人はDXを永続化させるための組織/人材変革を、それぞれ仕事の柱に置いています。Ridgelinezのテクノロジーコンサルタントもチェンジマネジメント（OCM：組織的変革管理）の経験を歓迎要件に挙げており、定着の工程を書ける人は応募先の幅が広がります。

工程	職務経歴書に書く項目	規模の示し方	成果指標の例	当たる求人要件の例
構想	対象業務、課題の把握手段、変革の目的、提案と採否	対象部門・業務の範囲、提案した相手の役職	目標に置いた業務指標、承認された施策	KPMG：業務分析/構想策定／Ridgelinez：課題定義・原因分析・解決策の提案
導入	推進体制と自分の役割、要件の優先順位づけ、部門間の調整	体制の人数、関わった部門、期間	計画に対する進み具合、移行の結果	PwC：システム導入に関わるプロジェクトデリバリ経験／Ridgelinez：SIプロジェクトのPM経験
定着	業務ルールの変更、教育、運用の引き継ぎ	利用者の範囲、引き継いだ部門	利用状況、問い合わせの推移、社内で運用を担う人数	NRI：変革の定着化／PwC：人材育成と内製化／KPMG：組織/人材変革

表の「規模の示し方」は、金額やシステムの規模よりも、関わった部門と人の範囲で書くと業務変革の大きさが伝わります。1案件を書く順番の例は次のとおりです。

1. 案件名：業界と対象業務（社名やクライアント名は伏せてよい）
2. 期間・体制：全体の人数と自分の役割
3. 構想：課題、目的、自分が担った分析と提案
4. 導入：推進体制、調整した部門、自分が決めたこと
5. 定着：稼働後に変えたこと、運用の引き継ぎ先
6. 成果：指標、時点、算出の方法

担っていない工程の行は削ってかまいません。空欄を埋めるために他のメンバーの仕事を書くより、自分の行を厚く書くほうが、面接での説明とも食い違いません。

経歴別に強調すべき実績とBefore／After

同じDX案件でも、経歴によって職務経歴書で先に出すべき工程は変わります。以下のBefore／Afterは記載の例で、Afterの「○」は自分の実績の値に置き換える前提の空欄です。

事業会社のDX推進部門にいた人

DX推進部門の経験は、Ridgelinezの戦略コンサルタントの求人で歓迎要件に挙がっています。社内の関係部門を動かし、導入後の利用を根付かせた経験は、支援する側に移っても使える強みです。

一方で、KPMGのDXコンサルタントの求人はクライアントサービス経験を必須に挙げています。社内の他部門を相手にした提案や報告を、相手・論点・結果の順で書いておくと、社外の顧客を支援する仕事との接点を示せます。

Before	After
全社DX推進プロジェクトに参画し、RPAやクラウドツールの導入を推進。業務効率化に貢献。	経理部門の請求処理を対象に、現状業務の調査から稼働後の定着までを担当（期間○か月、推進チーム○名のうち業務側の取りまとめ役）。部門長との月次報告で自動化する業務の優先順位を決め、稼働後は利用手順を改訂し、問い合わせの一次対応を情報システム部門から経理部門へ移した。請求処理の時間は導入前の月○時間から月○時間に減少（○年○月時点、業務ログから算出）。

Afterで減らしたのはツール名、足したのは優先順位を決めた場面と運用を移した先です。自分が何を決めたかが抜けると、取りまとめをしただけの実績に読まれるおそれがあります。

業務改革・BPR・経営企画を担った人

業務改革の経験は、KPMGのDXコンサルタントの応募資格で年数とともに明記されている経験です。業務分析/構想策定を担った期間が2年以上あるなら、期間を職務経歴書に明記してください。年数の要件と、そのまま照らし合わせてもらえます。

NRIの経営DX推進コンサルタントの求人も、必須スキル・経験の欄に、事業会社の経営企画・経理財務・事業企画部門で経営管理制度の設計・導入を主導した経験を、コンサルティングファームやSIerでの経験と並べて挙げています。補いたいのはデジタルの要素です。業務を変える手段として、どのシステムやデータをどう使ったかを1文添えてください。

Before	After
経営企画部にて業務改革プロジェクトを担当。予算管理業務の効率化を実現。	予算編成プロセスの現状分析と改革方針の策定を担当（期間○か月、対象は○事業部）。各事業部の予算担当者への聞き取りから、同じ数値を複数の表計算ファイルに転記している工程を特定し、予算管理システムへの集約と承認ルールの見直しを経営会議に提案して採用された。導入後は事業部向けの説明会を開き、運用マニュアルを経営企画部から各事業部の担当者へ引き継いだ。予算編成にかかる期間は○日から○日に短縮（○年度の実績）。

Afterの要は、課題を見つけた手段と、提案が採用されたという事実です。「効率化を実現」の一言でまとめていた結果を、提案から定着までの流れに分けるだけで、構想の工程を担える人だと伝わります。

SIer・ITベンダーで導入を担った人

SIerでの導入経験は、PwCの求人で必須要件の選択肢の一つに挙がっています。Ridgelinezのテクノロジーコンサルタントの求人も、SIプロジェクトのPM経験やアーキテクチャ設計経験を選択肢に含めますが、こちらはコンサル案件のリード経験が別に必須です。

補いたいのは業務側の成果です。システムが予定どおり稼働したことに加え、利用部門の業務が稼働後にどう変わったかを1つでも書けると、ビジネス部門を顧客とする求人にも応募しやすくなります。

Before	After
販売管理システムの刷新プロジェクトにPLとして参画。要件定義から本番稼働まで担当し、納期どおりにリリース。	卸売業の販売管理システム刷新で、要件定義から稼働後の定着支援までをPLとして担当（期間○か月、自チーム○名）。営業・物流の両部門と受注ルールの例外処理を棚卸しし、システム化しない業務を○件決めて要件を絞った。稼働後○か月は利用部門の問い合わせを分類して運用手順の改訂を提案し、受注入力の差し戻し件数は月○件から月○件に減少（○年○月時点、顧客の運用記録から算出）。

「システム化しない業務を決めた」という一文は、技術の担当範囲を超えて業務の判断に関わったことを示します。業務側の判断に関わった場面が1つあるだけで、導入担当の経歴が変革支援の経歴として読まれます。

Afterの形に書き直したら、各行が応募先のどの要件に当たるかを見比べてください。当たる要件が見つからない行は削るか、別の求人向けの版に回します。要件との対応を自分では判断しにくいときは、提出前に担当者と確認できます。

書類で評価を落としやすい書き方と、成果を盛らない示し方

評価を落としやすいのは、技術名とシステム名で実績欄が埋まり、業務が変わったかが読み取れない書き方です。募集要項の要件と照らして伝わりにくい表現と、直し方を並べます。

NG表現	読み手に伝わらないこと	直し方
「○○システムの導入を担当」	担った工程と、業務への影響	担った工程と、業務の何が変わったかを足す
「DX推進に貢献」	貢献の中身と自分の役割	自分が決めたこと、動かした部門を書く
「業務効率を大幅に改善」	指標、時点、算出の方法	指標の名前と、いつ時点の何の値かを書く
「プロジェクトを成功に導いた」	全体の成果のうち自分が担った範囲	体制全体と自分の役割を分けて書く
「年間○時間の削減」（試算の値）	実績か見込みか	見込みは計画値と明記し、実績と分ける
技術用語を並べた実績欄	ビジネス部門の読み手にとっての意味	技術名は環境欄にまとめ、本文は業務の言葉で書く

最後の行は、IT導入の経験が長い人に特に見直してほしい書き方です。技術名を消す必要はありません。置き場所を環境欄に分けるだけで、実績欄は業務の言葉で読めるようになります。

成果の数値に添える3つの条件

成果の数値には「誰の成果か」「いつ時点の値か」「どう算出したか」の3つを添えてください。チーム全体の成果なら全体の値と自分の担当範囲を分け、稼働前の試算は実績欄に入れないでください。

「誰の成果か」の示し方は、KPMGの応募資格が参考になります。マネジメント経験を「3名以上のスタッフをチームリーダーとして指揮した経験」のように、人数と役割で区切って書いています。

数値で示せない成果の書き方

効果を測る仕組みがなかった案件でも、成果は事実で示せます。たとえば、業務ルールを改訂した、運用の担当が別の部門に移った、新しい会議体ができて判断の場が決まった、といった変化です。誰の仕事がどう変わったかを書けば、数値がなくても定着の工程を担ったことが伝わります。

守秘義務とクライアント名の扱い

社名やクライアント名、未公表のシステム名は、守秘義務の範囲を確かめたうえで伏せて書きます。「卸売業・従業員規模○名程度」のように業界と規模に置き換えれば、案件の大きさは十分に伝えられます。

応募先のタイプ別に、職務経歴書の比重を変える

同じ「DXコンサル」の求人でも、主に相手にする部門や担う工程は求人ごとに違い、職務経歴書で厚く書く部分も同じではありません。確認した募集要項の記載から、4つのタイプに分けました。

求人のタイプ	募集要項の記載の例	先に置く工程・経験	短くしてよいもの
業務・経営改革型	NRI DXコンサルタント：主たる顧客はビジネス部門／NRI 経営DX推進コンサルタント：予算・実績管理プロセスの改革、KPIの設計・導入支援	構想と定着、業務指標の変化	開発や設定の細かな手順
全社変革・組織変革型	KPMG DXコンサルタント：全社規模・部門横断のDX、DXを永続化させる組織/人材変革	部門をまたいだ調整、定着と人材育成	単一部門だけの改善の積み重ね
IT・プラットフォーム寄り	PwC デジタルプロセス＆プラットフォーム変革：オペレーティングモデルとプラットフォームの変革／Ridgelinez テクノロジーコンサルタント：技術力とコンサルティング力の両面	導入工程のPM、設計、内製化の支援	技術と関係の薄い業務説明
業界別の戦略型	Ridgelinez 戦略コンサルタント：戦略・施策の立案、PoCの実施、業務プロセス設計・改革	業界の業務知識と構想の工程	業界と関係の薄い案件

ビジネス部門が主な顧客の求人に、技術の深さだけを前に出した職務経歴書で応募すると、要件とのずれが目立ちます。反対に、導入工程のマネジメントや設計を重く見るIT寄りの求人なら、SIerでのPM経験を先頭に置く書き方が合います。

IT寄りの求人に向けて技術経験の書き方を詰めたい人は、ITコンサルの職務経歴書の書き方で、技術の経験を成果として示す方法を扱っています。デジタルの比重が小さい業務改革の求人に寄せる場合の参考は、業務コンサルタントの職務経歴書の書き方です。

職務要約で先に置く経験を、応募先のタイプで選ぶ

職務要約は、応募先のタイプに合う工程を最初の文に置くと読み手の判断が早くなります。構成は「自分の経歴の要約」「応募先のタイプに合う代表案件と工程」「応募先で担いたい工程」の3つです。

• 業務・経営改革型に出す場合：経営企画として予算管理の改革を構想から定着まで担当した経験を最初に書き、システム導入は手段として後ろに置く
• IT・プラットフォーム寄りに出す場合：基幹システム刷新のPLとして要件定義から定着支援までを担った経験を最初に書き、業務側の成果を続ける

同じ経歴でも、最初の1文を入れ替えるだけで応募先に合わせた版が作れます。比重を決めるには、狙う求人の原文が手元に必要です。DXコンサルタントの求人を条件で絞り込み、必須・歓迎要件を読み比べてから版を分けると、書き直しの手間を減らせます。

コンサル未経験・隣接経験の人が書類で補う方法

コンサルティング業界の経験がなくても応募できる求人はあります。KPMGコンサルティングの応募・選考ガイドは、コンサル業界での経験は必須ではないと明記しています。補いたいのは、経験の種類ではなく書き方です。

現在の経験	書類での位置づけ	補い方
DX・業務改革の実務があり、コンサル経験はない	変革を内側で進めた当事者	社内の他部門を相手にした提案・報告を、相手・論点・結果の順で書く。クライアントサービス経験として扱われるかは求人ごとに違うため、応募前に確かめる
IT導入の実務が中心	導入工程の担い手	業務側の成果を1つでも事実で示し、業務の判断に関わった場面を足す
コンサル経験がある	変革支援の経験者	職位と、提案・プロジェクト管理の実績を明記する

面接で深掘りされやすい項目と、書類との一貫性

面接で見られるのは、職務経歴書に書いた成果を自分の言葉で説明できるかです。KPMGコンサルティングの場合、書類選考と適性検査（対象者のみ）の後に応募部署による面接が複数回あり、オファー面談を経て内定に至る流れです（ポジションにより異なる）。

書類の一行ごとに、続きうる質問を想定しておくと、準備の的を絞れます。下の表は、募集要項の要件から想定される深掘りをまとめたものです。

書類の記載	想定される深掘り	準備すること
成果の数値	誰の成果か、何と比べた値か、どう算出したか	算出に使ったデータと時点をメモにしておく
関係部門との調整	対立した論点と、どう合意に至ったか	反対した相手、譲った点と譲らなかった点
定着の取り組み	定着しなかった部分と、その後の対応	うまくいかなかった施策も1つ用意する
チームの指揮	役割の分け方と、自分が下した判断	判断の根拠と、その結果
転職の理由	なぜ事業会社やSIerから支援する側に移るのか	担いたい工程と、応募先の要件の結び付き

成果が出た部分だけでなく、定着しなかった部分の説明も用意しておくと、書類の数値と面接での話が食い違いにくくなります。定着の工程を書いた場合は、この質問への準備を特に厚くしておきたいところです。

応募職位の見立てにつながる実績の書き方

応募する職位によって、職務経歴書で先に示す実績は変わります。KPMGのDXコンサルタントの求人は、マネージャー以上にはプロジェクト提案とプロジェクトマネジメントの経験を必須としています。

応募する職位の目安	職務経歴書で示したい実績	根拠となる募集要項の記載
コンサルタント級	担った工程とその成果、チームを率いた人数と役割	KPMG：業務改革の経験年数と、チームリーダーとしてスタッフを指揮した経験を応募資格に挙げる
マネージャー級以上	誰に何を提案し採用されたか、体制・期間・予算のうち責任を持った範囲	KPMG：マネージャー以上はプロジェクト提案・プロジェクトマネジメント経験が必須／Ridgelinez テクノロジーコンサルタント：コンサル案件のリード経験が必須

事業会社で予算と体制の責任を持っていた人は、その範囲を数字で書いておくと、上の職位で応募できるかを採用側が判断しやすくなります。提案の実績は、提案した相手と採否まで書いてください。社内向けの提案でも、相手と採否まで書けば中身は伝わります。マネージャー級で応募する場合の書き方は、コンサルのマネージャー級の職務経歴書の書き方で詳しく扱っています。

DXコンサルの職務経歴書を相談すべきケース

自分で仕上げてよいか、相談してから出すかの分かれ目は、応募先の要件と経歴の対応を自分で説明できるかどうかです。

自分で進めてよいケース	相談した方が早いケース
応募先が決まり、必須要件に当たる工程がはっきりしている	業務寄りとIT寄りのどちらのタイプに出すか決めきれない
成果の数値と算出方法を自分で説明できる	成果が試算の値しかなく、実績欄に何を書くか迷う
コンサル経験があり、応募する職位も決まっている	コンサル未経験で、社内の調整経験がどう評価されるか判断できない
担った工程が1つに絞れている	複数の案件にまたがり、どれを代表案件にするか決められない

履歴書との書き分けや提出書類の様式で迷う場合は、コンサル転職の職務経歴書と履歴書で様式と提出書類を確認できます。不採用だった場合に同じポジションや別の部門へ再応募できる時期も、応募の順番を決めるために面談で聞いておきたい点です。

表の右側に当てはまる項目が多いなら、コンサル領域の転職を担当するエージェントに相談し、応募先のタイプと職務経歴書の比重を一緒に決める方法もあります。下の担当者から相談したい相手を選び、面談を予約できます。

DXコンサルの職務経歴書でよくある質問