早稲田大学を卒業後、三菱UFJ銀行に新卒入社。4年間の勤務期間でベンチャーから上場企業まで500社以上の法人を担当。また、オーナー社長の相続、事業承継提案や個人の資産形成提案等にも従事。その後、2020年4月にプルデンシャル生命保険に転職。2年半営業として社内表彰を受賞する等活躍。その後マネージャーに昇格し、新規の採用と育成に従事する中で、200名を超える転職相談を実施。現在はPEファンド・VC・投資銀行・M&A・戦略コンサルを中心に、プロフェッショナル人材の転職支援をサポート。2025年度下期MVP受賞。
ITコンサルの大手を調べる際は、企業の規模や知名度に加え、応募する職種でどの工程を担うかを見る必要があります。構想を考える仕事と、システムの設計・移行まで担う仕事では、使う経験も入社後に積める専門性も変わります。
本記事では、IT変革を支援する代表的な8社を事業領域で比べたうえで、求人票、職務経歴書、条件提示へどうつなげるかを説明します。8社は売上高による順位ではありません。
ITコンサル大手8社の主な領域
会社全体のサービスは、応募先を探す入口です。以下の「求人で見る点」まで進むと、同じ企業内にある職種の違いを捉えやすくなります。
| 企業 | 公式情報で確認できる領域 | 求人で見る点 |
|---|---|---|
| アクセンチュア | 幅広い業界の変革、テクノロジー | 応募職種とプラクティス、担当工程 |
| PwCコンサルティング | 業界別の知見、テクノロジー変革 | 所属組織と実装工程の範囲 |
| EYストラテジー・アンド・コンサルティング | 戦略、デジタル、アナリティクス、リスク | 専門領域と成果物 |
| KPMGコンサルティング | 事業変革、リスク、テクノロジー | 職種固有の必須要件と実装の有無 |
| IBM Consulting | AI、クラウド、データと業務変革 | 技術専門性と業務領域の比重 |
| NTTデータグループ | コンサルティングから構築・運用 | 構想から運用までの担当範囲 |
| 野村総合研究所 | コンサルティング、金融IT、産業IT、IT基盤 | 雇用職種とシステム責任の範囲 |
| ベイカレント | 複数産業とデジタル領域のサービス | 所属・アサイン方法と期待される専門性 |
ITコンサルに公的な「大手」の認定はありません。この表は、構想から運用までの提供領域、専門組織、顧客との仕事の接点を比べるためのものです。社員数や会社平均年収を一列に並べても、雇用法人や対象職種が違えば応募者への提示条件は読み取れません。
企業タイプで変わる仕事の入口
総合系は業務と技術の接点が広い
アクセンチュア、PwC、EY、KPMGには、業界別・機能別・技術別の仕事があります。たとえば同じDX案件でも、業務改革の方針を作る職種と、データ基盤の設計・導入を担う職種では成果物が異なります。求人の法人名、部門名、職務内容を一緒に読むと、希望する仕事との接点が見えてきます。
アクセンチュアの公式サイトには、戦略コンサルティング、AI・データ、クラウド、テクノロジー変革、マネージドサービスなどが並びます。業務改革を志望する人がクラウドの求人を見るときは、現行業務を描き直す仕事か、移行方式と運用を設計する仕事かで、過去の実績との接点が変わります。会社名だけで「上流」「開発」のどちらかに決めつけず、募集部門と職務記述を先に読めます。
PwCのサービス紹介には、コンサルティングのほか、データ・AI、サイバーセキュリティ、リスク・ガバナンス、マネージドサービスへの入口があります。たとえばデータ活用を希望する場合、分析環境の構築、業務部門の利用定着、管理態勢づくりでは必要な経験が違います。応募時には「データ」という語だけで選ばず、募集要項の成果物を見て候補を絞ります。
EYストラテジー・アンド・コンサルティングは、戦略、デジタル戦略、アナリティクス、テクノロジー、リスクなどのサービスを掲げています。KPMGコンサルティングも公式説明で、事業・業務・ITの改革とリスク対応を扱っています。同じ「テクノロジーコンサルタント」という名称でも、システム構想とリスク管理とでは面接で示す案件が異なります。求人に書かれた専門領域を、会社の広いサービス一覧から一段細かく特定すると、志望理由にも具体性が出ます。
IBM、NTTデータ、NRIは技術と業務の分担を見る
IBM ConsultingはAI、クラウド、データなどを扱い、NTTデータグループはコンサルティングからシステム構築・運用までを提供します。NRIはコンサルティング、金融IT、産業IT、IT基盤を事業として分けています。応募者が関わるのは構想、技術選定、開発統括、移行、運用改善のどこか。企業のサービス範囲をそのまま一人の担当範囲と考えず、募集職種の成果物で見分けます。
IBMのコンサルティング職採用ページは、ハイブリッドクラウドとAI変革を仕事の入口として紹介しています。クラウド経験者なら、製品知識に加えて、既存システムの制約を調べ、移行先の方式を選び、運用に引き渡した範囲まで示すと職務の接点が明確になります。反対に業務企画が中心なら、技術導入の前に業務要件や投資判断をどこまで担ったかが手掛かりです。
NTTデータグループの会社紹介は、コンサルティングからシステムづくり、運用までのサービスを明示しています。中途採用では持株会社と国内・海外の事業会社を区別し、実際の雇用法人と配属先を読む必要があります。金融の基幹システム刷新なら、制度・業務を踏まえた要件整理と、安定稼働を守る設計・移行は隣り合うものの別の役割です。自分が次に担いたい工程を、応募職種の責任範囲と照らします。
NRIの事業概要には、コンサルティング、金融ITソリューション、産業ITソリューション、IT基盤サービスが並びます。金融機関向けのIT経験は金融IT職との接点になり得ますが、経営コンサルティング職と同じ要件とは限りません。案件の業界知識が生きる職種か、共通基盤の技術を磨く職種かを分けると、同じ企業の中で応募先を選びやすくなります。
日系総合と追加候補は所属・配属を読む
ベイカレントには複数産業とデジタル領域のサービスがあります。候補を広げるなら、デロイト、アビームコンサルティング、フューチャーアーキテクトも同じ軸で見られます。大規模案件では専門家との協働機会がある反面、本人の役割が細かく分かれることもあります。応募部門とアサイン方法が、会社全体の紹介より実際の仕事に近い情報です。
ベイカレントの公式サイトは、産業別の入口に加えてAI、クラウド、デジタルテクノロジー、マネージドサービスなどを示しています。たとえばPMO経験を生かすなら、進捗会議の運営にとどまらず、複数部門の判断をどう前に進めたかを見直します。技術専門職を志望するなら、使った製品名だけでなく、方式選定や導入後の成果物を軸に求人を選べます。
追加候補のデロイトはEngineering、AI、Dataなどのサービスを示し、アビームも業務変革、AI、クラウドの入口を設けています。フューチャーアーキテクトはIT・戦略コンサルティングとソリューションを案内しています。8社で候補が決まらない場合には、会社数を増やすより、希望する業界、担当工程、技術領域が重なる職種をこの3社にも広げて探す方が比較しやすくなります。
転職のご相談では、アクセンチュア、アビーム、ベイカレントなどを比べる際に、上流工程へ関わりたいという希望だけでなく、実装までどこを担うのか、どの領域で専門性を積むのかを確認したいという方が多くいます。
求人票の職務内容から担当工程を読む
公式サービスページが示すのは会社の提供領域です。個別求人では、雇用法人・部門、職務を表す動詞、成果物、必須要件を続けて読みます。「DX支援」だけでは業務構想から導入後の運用まで幅があるため、同じ社名の求人でも役割を分けて考えます。
| 求人で使われる語 | 担う仕事・成果物の例 | 経験として示す材料 |
|---|---|---|
| 戦略・構想 | 調査、課題設定、投資や施策の選択肢 | 比較した案、意思決定者へ示した資料 |
| 業務改革・要件定義 | 業務プロセス、要求、承認された要件 | 現場の課題と部門間で合意した変更 |
| アーキテクチャ | 方式・製品の選定、非機能要件 | 性能・可用性・コストの判断理由 |
| 導入・移行 | 設計、開発会社の統括、テスト、切替 | 移行計画、品質・リスクへの対応 |
| 運用・改善 | 運用設計、障害対応、継続改善 | サービス水準や再発防止で変えたこと |
たとえば「クラウドを活用した変革」でも、方式を決める仕事と、移行後の安定稼働を担う仕事では求められる実績が違います。面接では、顧客、社内専門家、協力会社の間で本人が下した判断を示すと、チーム全体の成果と本人の責任を分けて説明できます。
同じクラウド案件でも募集職務は分かれる
クラウド移行の求人を二つ読む場面を考えます。一つ目に「現行システムの調査、移行先の構想、経営層への提案」とあれば、現状の制約を整理し、投資効果と実行順序を説明した経験が接点になります。二つ目が「移行方式の設計、テスト計画、切替の統括」なら、データ移行、障害時の復旧、利用部門の業務停止時間などを調整した実績が近いでしょう。どちらもクラウドの求人ですが、面接で最初に示す案件は変わります。
「戦略策定から実行まで」と書かれた求人は少なくありません。その際は、応募する職位が全工程を統括するのか、特定の工程を担当するのかを、募集要項の具体的な業務と必須要件から読み取ります。たとえば「提案」「要件定義」「ベンダー管理」が並ぶ職種なら、それぞれを自分で行ったのか、専門家へ依頼して判断したのかで、伝える経験は異なります。
募集要項で先に読む四つの欄
最初は雇用法人と部門です。複数の法人や事業部を持つ企業では、同じ社名の紹介から業務を推測できません。次に職務内容の動詞を読みます。「分析する」「設計する」「導入を統括する」「運用する」は、それぞれ成果物と責任範囲が違います。三つ目は必須要件と歓迎要件。必須の経験年数や技術領域に届かない求人を、職務経歴書の表現だけで埋めることはできません。四つ目は職位と評価対象です。リーダー職なら、本人の専門作業に加えてチームや顧客への責任が含まれる場合があります。
前職の経験と応募職種の接点
未経験からの応募でも、近い仕事をしてきた事実は材料になります。求人の必須要件に届かない部分は、経歴の言い換えで埋まりません。自分が担った工程と募集要件の重なりを探します。
| 現在の経験 | 応募書類で具体化する実務 | 求人要件との境界 |
|---|---|---|
| SIer・エンジニア | 要件、方式、品質、移行、運用で本人が決めたこと | 顧客課題の整理や提案を担うか |
| 社内SE・事業企画 | 利用部門の要求、投資判断、部門間合意 | 外部顧客への提案や技術専門家との協働 |
| 法人営業 | 課題仮説、複数案の提案、導入までの関与 | 分析・設計など職種固有の要件 |
| PM・PMO | 意思決定、リスク、品質、関係者の統括 | 進捗管理に加え業務・技術を判断するか |
SIerのPMなら「大規模案件を管理した」で止めず、仕様変更時に何を優先し、誰の承認を得て、移行計画をどう変えたかを記します。事業会社の企画職なら、業務部門の要求を整理してシステム要件へつないだ場面が応募先との接点になります。経験した事実を、求人に書かれた職務へ対応させることが先です。
社内SEには、利用部門から相反する要望が届く場面があります。たとえば短い納期を求める営業部門と、監査上の統制を重視する管理部門の間で、導入範囲を段階化した経験です。その際、要求を列挙しただけか、影響と費用を比較して意思決定者へ提案したかで、応募できる職種の幅が変わります。コンサルティング職を志望するなら、判断の材料を作った過程まで書く方が、単なる調整役という印象を避けられます。
法人営業からの転職では、システム導入前の課題分析や、顧客の複数部署を巻き込んだ提案が手掛かりです。ただし、技術設計や移行の実務を要する求人では、営業成果だけでは要件を満たしません。顧客の業務をどこまで理解し、実装担当者とどの論点を詰めたかを分けて記すと、業務側のコンサルティング職と技術専門職のどちらが近いか判断できます。
PMO経験者は、会議運営や進捗管理だけでなく、遅延の要因を見つけ、選択肢を提示し、責任者が決めた後に計画へ反映した場面が材料になります。全体を統括する職位を志望する場合には、予算、品質、スコープのどこに責任を持ったかも欠かせません。PMOという肩書だけで管理職の経験と同一視せず、役割と権限を職務経歴に明記します。
職務経歴書と面接で伝える実務
職務経歴書では応募職種の成果物に近い案件を選び、課題、制約、比較した案、本人の判断、結果を一続きで書きます。要件定義書、移行計画、ロードマップ、運用設計など、資料の名称だけでなく作成や承認にどこまで関わったかが伝わる記述にします。
面接では、成功した理由を本人の行動と周囲の協力に分けて話します。たとえば移行遅延に対応した案件なら、遅れの原因、優先順位の変更、関係部門との合意、稼働後の結果という順に説明できます。結果だけを強調するより、次の案件でも使える判断を示せます。
職務経歴書の一案件は、「目的」「制約」「自分が担当した工程」「検討した選択肢」「決定の根拠」「結果」の順にまとめると読み手が追いやすくなります。たとえば基幹システムの更新であれば、単に「移行を完了」と書くより、対象となる業務、停止可能な時間、並行稼働の判断、切替後に改善した運用を簡潔に示します。数値を使う場合は、自分が把握している案件の実績と担当範囲に限定します。
面接で問われる点も職種ごとに違います。構想・企画の職種なら「なぜその選択肢を推したか」、導入統括なら「関係部門が反対したとき何を変えたか」、技術専門職なら「方式の制約をどう検証したか」が問われる可能性があります。一つの案件について、目的を決めた人、判断材料を作った人、実装した人を混同せず話せるようにしておくと、経験の深さを示せます。
同じ企業でも、応募した部門と面接官の所属が異なる場合があります。選考が進むにつれ得た部門・職務の情報は求人票の記載と照らし、面接で聞く内容を具体化します。
大手で積む経験と次の職種
大手を選ぶ利点の一つは、業務、技術、業界の専門家が協働する案件に出会えることです。ただし、会社が広いサービスを持つことと、一人のコンサルタントがすべての工程を経験することは別です。最初の配属と担当案件で何を自分の専門として積むかによって、次の職位や転職先で示せる実績が変わります。
たとえば業務改革から入り、次にシステム導入の要件定義を担えば、業務部門と技術部門の橋渡しが強みになります。クラウド設計から入った人が、次に顧客の投資計画を担うには、技術案の比較だけでなく費用、リスク、実行順序を顧客と決めた経験が必要です。希望するキャリアパスを決める際は、現在の案件で得られる経験と、次の職種が求める実務をつなげて考えます。
専門性を深める方向もあります。金融ITであれば決済や勘定系などの業務理解、クラウドであれば非機能要件や移行設計、サイバー領域であれば統制と実装の接点が軸になります。汎用的な「DX経験」を積むことより、どの業界で何を変え、本人がどの判断を担ったかを積み重ねる方が、職務経歴書に残る実績になります。
案件の規模と担当範囲の関係
大規模な変革では、構想、要件定義、アーキテクチャ、開発、運用の担当が分かれることがあります。複数の専門家と協働できる半面、一人が見る範囲は限定される場合もあります。小規模な案件では一人が多くの工程を受け持つことがありますが、専門家に相談できる体制や顧客との距離は会社・部署によって違います。規模だけで良し悪しを決めるより、本人が責任を持てる範囲と、次に伸ばしたい技能を対応させます。
応募先を比べるときは「大きい案件を担当できるか」だけでなく、「本人の成果物は何か」「顧客の意思決定にどこまで関わるか」「導入後の結果まで追うか」を一続きで聞くと仕事の輪郭が明確になります。求人に『プライム案件』『グローバル案件』とあっても、それだけでは応募者の担当工程は決まりません。面接で話すプロジェクト例から、職位に期待される役割を掘り下げると判断しやすくなります。
年収・配属・働き方を比べるときの条件
報酬は提示年収の総額だけで比べず、固定給、変動賞与、初年度の一時金、職位を並べます。同じ総額でも、受け取り方と翌年以降の条件は変わります。一時金の支給時期や在籍条件が違えば、初年度に受け取れる額も変わります。企業平均給与は対象法人や職種・会計年度がそろわないため、個別のオファー判断には求人票と条件通知を使います。
提示条件の比較例として、固定給だけで提示する求人と、固定給に目標賞与を加えて想定年収を示す求人を考えます。目標賞与は支給が決まった金額ではありません。見かけの年収総額が同じでも、初年度に受け取る金額と翌年以降の安定性は異なります。入社一時金が加わる場合も、その支給時期、在籍条件、退職時の返還条件を固定給から分けて読みます。候補ごとに条件通知の内訳を一行ずつ書き出すと、何が保証され、何が実績や在籍期間に左右されるかが明確になります。
賞与の算定期間と入社月の関係も、初年度の金額を左右します。昇給や昇格の時期は制度上の評価サイクルと、入社後に最初の評価対象となる時期を分けて聞くと具体的です。現職の退職時期を決める前に、内定先で確定した条件と、入社後の評価で変わり得る条件を区別しておきます。
入社後の仕事は、配属先とアサインの決まり方で変わります。求人の担当工程、面接で説明された役割、条件通知に記された所属を照らし、確定している事項と配属後に決まる事項を分けます。勤務地、出社、出張も制度の説明と所属先の運用を区別しておくと、働き方の誤解を減らせます。
選考工程、リファレンス確認、別部門への再応募の扱いは会社・求人によって異なります。応募日と条件提示時点で分かる情報を使い、公開されていない条件を業界共通の制度として扱わないようにします。
応募前に複数社を並べるなら、求人票に明記された「所属組織」「担当工程」「必須経験」「想定職位」「勤務地」を同じ順序で記録します。選考で新しく分かった事実だけ追記すれば、会社紹介ページと面接時の説明が混ざりません。業務改革を希望する人が技術導入職を候補に入れた場合も、実装経験の不足を先に見つけられます。
年収交渉では、他社の平均給与より、応募職位で求められる責任と自分の実績が判断材料になります。たとえば現職で複数ベンダーの移行を統括した経験を提示するなら、対象業務、予算への関与、切替判断の権限、稼働後の成果を並べます。採用側が提示した職位の期待と食い違う場合、職位と担当範囲を先にすり合わせ、そのうえで条件を話す方が論点が明確です。
大手ITコンサルについてよくある疑問
大手なら上流工程を担当できるか
企業名だけでは決まりません。構想と要件定義を主に担う求人も、設計・移行・運用改善まで責任を持つ求人もあります。応募先の部門と成果物が、希望する工程に合うかを見ます。上流工程へ移りたいエンジニアなら、これまでの要件整理や技術案の比較が必須要件と重なる求人を起点にし、構想専任の求人との差も読んでおくと応募先を選びやすくなります。
エンジニア経験はITコンサルへ生かせるか
要件を整理し、技術案を比較し、品質・コスト・移行の制約の中で選んだ経験は応募材料になります。製品名や使用言語の一覧だけでは役割が伝わりにくいため、本人が判断した範囲まで書きます。実装経験を評価する職種では、コードを書いた期間だけでなく、設計の理由や障害への対応を伝えます。業務改革寄りの職種では、顧客の業務課題から要件を定めた過程を重視して案件を選びます。
8社の平均年収を比べればよいか
各社の公表値は連結・単体、職種、会計年度がそろいません。年収は職位と報酬構成が明らかな求人・オファーで比べます。各社の制度や働き方は、表の会社別記事からたどれます。
同時に何社へ応募するか
まず同じ担当工程の求人を複数並べ、仕事の違いをつかむと応募先を選びやすくなります。たとえば業務改革を希望する場合、業務要件の策定を担う求人と、導入後の定着支援を担う求人を並べると、経験の重なりと不足が見えます。同時応募の数だけを先に決める必要はありません。面接準備にかけられる時間と、各社で志望する職務を説明できるかを基準にします。
同じ会社の複数部門に関心がある場合、募集職種ごとの必須要件と選考の扱いを採用窓口へ伝える方が確実です。会社によって応募手続きは異なりますが、関心領域を広く挙げるだけでは、どの職務に本人の実績が合うのか採用側に伝わりません。第一希望の職種と、その理由になる案件経験を先に用意すると、別部門の提案を受けた際にも仕事内容を比べられます。
応募先を絞るための求人の使い方
まず希望する工程を一つ決め、同じ工程を扱う複数の求人を並べます。雇用法人、部門、成果物、必須要件の四つがそろえば、社名の印象から一歩進んで仕事内容を比べられます。選考で部門や条件が明らかになった後も、この四つと提示された職位・報酬を同じ候補に追記します。
応募前には、希望する仕事に最も近い求人と、現職の経験が最も生かせる求人を一件ずつ並べると、足りない実務が見えてきます。応募先を絞りきれない場合は、職種ごとの担当工程や職位を転職支援の相談で具体的にすり合わせる方法もあります。希望企業の名前だけを伝えるより、担当したい工程とこれまでの案件を示した方が、紹介可能な求人との接点を探しやすくなります。
下の求人検索では、企業名に加えて業界や職種の条件を変えながら募集を探せます。興味を持った求人は、募集要項にある担当工程と必須要件を読み、自身の経験が重なる部分を確かめてください。