ITコンサルが一番「炎上」しやすい理由──戦略コンサルとの違いを元採用責任者が解説

「コンサルは激務」という話をすると、たいていの人は一括りにして頷く。戦略だろうがITだろうが、どうせ深夜まで働くんでしょう、という理解だ。しかし採用責任者として何百人もの職務経歴書を見て、面接で「なぜ炎上したのか」を聞き続けてきた立場から言うと、この一括りには大きな見落としがある。

激務の”質”がまったく違うのだ。戦略ファームの激務は基本的に「頭を使い続ける」タイプの負荷であり、プロジェクトが炎上して現場が崩壊するケースは相対的に少ない。一方でITコンサルの現場は、構造的に炎上しやすい仕組みを抱えている。これは個人の能力や運の問題ではなく、ビジネスモデルそのものに組み込まれたリスクだ。

採用会議でよく議論になったのも、この点だった。「戦略もITも同じコンサルとして見ている候補者」は、入社後のギャップで離職する確率が高い。逆に、この違いを事前に理解した上で志望してくる候補者は、面接での質問の質が明らかに違った。

今日は、なぜITコンサルが最も炎上しやすいのか、その構造的な理由と、採用側から見て「炎上に強い人」と「弱い人」の違いがどこにあったのかを、具体的なパターンとともに解説する。

「コンサル=激務」という括り方がそもそも危うい

戦略コンサルの負荷は、基本的に頭脳労働の密度から来ている。クライアントの経営課題を分析し、仮説を立て、検証し、資料に落とし込む。この工程は苦しいが、破綻の仕方が比較的静かだ。分析が甘ければやり直せばいいし、最終報告の質が低くても「次のプロジェクトで挽回する」という形で収束することが多い。

これに対してITコンサル、特にシステム導入・刷新プロジェクトのPMOや実装フェーズを担うポジションは、負荷の性質がまったく異なる。ここでの炎上とは、頭が疲れるという話ではなく、納期・予算・品質のどれかが崩れて外部から見える形で失敗が露呈するということだ。クライアントの基幹システムが予定通り稼働しなければ、業務そのものが止まる。これは資料の質が低いという話とは重みが違う。

ITコンサルで炎上が起きやすい構造的な理由

面接で「前職でどんなプロジェクトが炎上したか」を聞くと、パターンはかなり似通ってくる。個人の力量の問題というより、プロジェクトの構造そのものに炎上因子が埋め込まれているケースがほとんどだった。

• カットオーバー日(システム稼働日)が経営判断や規制対応など外部要因で固定されており、動かせない
• 要件定義の段階で業務部門とIT部門の利害が一致しておらず、後工程で仕様が二転三転する
• テスト工程の終盤になって初めて、既存システムとの連携不具合や想定外のデータパターンが表面化する
• ベンダーが複数入っている場合、責任範囲の境界線が曖昧なまま進み、問題発生時に押し付け合いが起きる

特に厄介なのは3つ目だ。設計段階では見えなかった問題が、統合テストという最終盤で一気に噴出する。ここで発覚した不具合は、後工程で修正するほどコストと時間がかかる。だからこそ、炎上は「終盤に一気に来る」という特徴を持つ。戦略プロジェクトのように途中で軌道修正しながら進める余地が、構造的に小さいのだ。

採用面接で見えた「炎上に強い人」と「弱い人」の違い

ここまで書くと、ITコンサル自体を避けるべきだと言っているように聞こえるかもしれないが、そうではない。炎上プロジェクトを経験しても評価が下がらない人と、同じ経験をしても評価が伸び悩む人がいた。その違いは、炎上を経験したかどうかではなく、炎上の中で何を担っていたかにあった。

評価が上がった人の共通点

炎上プロジェクトの経験を強みとして語れる候補者は、たいてい「誰が何に困っていて、なぜその優先順位で対応したか」を具体的に説明できた。関係部署の利害調整に自分がどう関わったか、スケジュールの遅延をどう可視化してクライアントに報告したか、といった内容だ。炎上そのものより、炎上の中での立ち回りを語れるかどうかが評価の分かれ目だった。

評価が伸びなかった人の共通点

逆に「炎上して大変でした、深夜まで働きました」という苦労話に終始する候補者は、採用会議での評価が上がりにくい。苦労の量ではなく、その状況でどう構造を理解し、どう関与したかが見られているからだ。特に、原因を「クライアントが悪かった」「上流の設計が悪かった」と他責的に語る候補者は、次の職場でも同じ構造にぶつかったときに同じ反応をするだろうと判断されやすい。

戦略とITの違いを理解しないまま志望する人の共通点

面接をしていて感じるのは、「コンサル業界に転職したい」という漠然とした志望動機のまま、戦略ファームとITコンサルの両方に併願している候補者が一定数いるということだ。それ自体は悪いことではないが、両者の負荷の質の違いを言語化できていない候補者は、志望動機の説得力が弱くなる。

典型的なのは、「クライアントの経営課題を解決したい」という動機だけでITコンサルのポジションに応募してくるケースだ。もちろんITコンサルにも経営課題への貢献はあるが、実際の日々の業務は要件定義書のレビューや進捗管理、ベンダーとの調整といった、地に足のついた実務が中心になる。この解像度のギャップが大きいまま入社すると、早期離職につながりやすい。採用側としても、このギャップを面接で埋められないまま採用してしまうと、オンボーディング後のミスマッチという形で跳ね返ってくる。

転職前に見極めるべきポイント

ITコンサルへの転職を検討している人に、面接の場で確認してほしいことがいくつかある。

• 自分が担当するのはPMO(進行管理・調整)なのか、実装・設計そのものなのか。役割によって炎上時の負荷のかかり方が大きく異なる
• 案件がプロジェクトのどのフェーズから始まるのか。要件定義からなのか、すでに炎上が始まっている火消しフェーズからのアサインなのか
• 直近1〜2年で担当した案件のカットオーバー実績はどうだったか。延期や炎上の頻度は、面接官の口ぶりからもある程度読み取れる
• クライアントの業界特性。金融・インフラ系は規制対応で納期が動かせないことが多く、炎上リスクが相対的に高い

これらを面接で自然に聞ける候補者は、それだけで「現場を分かっている」という印象を採用側に与える。逆に一切触れずに待遇面だけを質問してくる候補者は、入社後のギャップに気づいていないと判断されやすい。

ある候補者の話──SIer出身者が有利に見えて実は差がつくポイント

採用会議で印象に残っている候補者がいる。SIerで5年ほどPMOを経験し、大型の基幹システム刷新プロジェクトで炎上の渦中にいたという人だった。面接では「炎上した」という事実そのものより、炎上の兆候をいつ、どの数字から察知したかを聞いた。彼はテスト工程での不具合検出件数の推移をExcelで追っていて、通常のペースより減少カーブが緩やかになった時点で「これは収束しない」と判断し、上司にエスカレーションしていたと答えた。

この回答が評価されたのは、炎上を経験した回数や規模ではなく、炎上を定量的なシグナルとして先読みできていた点だった。SIer出身者はITコンサルへの転職で有利に見られがちだが、実際に差がつくのは「現場にいた年数」ではなく「現場で何を計測し、どう判断材料にしていたか」だ。同じ炎上プロジェクトを経験していても、感覚的に「大変だった」としか語れない候補者と、数字や兆候をベースに語れる候補者とでは、面接での評価が大きく分かれる。

まとめ

ITコンサルが炎上しやすいのは、個人の能力の問題ではなく、システム導入という仕事の構造そのものに起因している。だからこそ、志望する側に求められるのは「炎上を避ける」ことではなく、「炎上が起きる構造を理解した上で、自分がどこにどう関与するかを見極める」ことだ。この解像度を持って転職活動に臨めるかどうかが、入社後のミスマッチを防ぐ最大のポイントになる。