概要
AI時代のIT企業が直面する人材課題のひとつが「中途で採用したベテランエンジニアをFDE型人材へ転換できない」という壁です。新卒は1年プログラムでゼロから育てられますが、中途は「すでに完成された実装思考」を持っています。彼らをコンサル化するには、新しいスキルを足す前に、既存の思考パターンを意識的に手放させる——アンラーニングが必要です。本稿では、コンサル業界が中途人材の入社後設計に使ってきた手法を、IT企業の中途エンジニアに転用する具体プロセスを解説します。
中途エンジニアのコンサル化が難しい構造的理由
「成功体験」が転換を阻む
新卒エンジニアは白紙です。教えれば吸収します。一方、中途エンジニアは5〜15年の実装経験のなかで、「こうやれば動く」「こう設計すれば後悔しない」という強い成功パターンを持っています。これは資産であると同時に、上流化を阻む足枷でもあります。
具体的には以下のような思考パターンが、コンサル化を阻みます。
- 「要件が固まらないと動けない」（業務発見の段階で動けない）
- 「とりあえず作ってみる」（仮説検証なしで実装に走る）
- 「顧客の言うとおりに作る」（本質課題を問い直さない）
- 「技術的に正しい解」を優先する（業務インパクトより技術的美しさ）
- 「コードで語る」（言語化・資料化を軽視する）
これらは実装の現場では機能してきました。しかしFDE型人材として顧客と対峙するときには、すべてが障害になります。
単純な研修では転換しない
「ロジカルシンキング研修を3日間受けさせれば変わるはずだ」——これがほとんどの場合うまくいかない理由です。中途エンジニアは座学で「分かりました」と頷きます。しかし実案件に戻ると、過去の成功パターンが優勢になり、研修内容は使われません。
アンラーニングは「知識の追加」ではなく「行動パターンの書き換え」です。意図的な設計が必要です。
コンサル業界の中途人材アンラーニング手法
コンサルファームは、毎年大量に中途人材を採用し、コンサル文化に馴染ませてきました。100年近い試行錯誤の末に確立された手法は以下の3つです。
手法1：自分の過去パターンを言語化させる
入社後すぐに「自分が今までどう仕事を進めてきたか」を、書面で詳細に振り返らせます。なぜ振り返るのか。自分の思考パターンを言語化できなければ、それを意識的に変えることはできないからです。
具体的には以下のような問いを与えます。
- 過去の典型的な案件で、最初に何をしたか
- どの段階で顧客に質問したか／しなかったか
- 課題発見と解決策提示のどちらに時間を使ってきたか
- 自分が「優秀」と評価された理由は何だったか
書き出すことで、本人が「これが自分のデフォルトモードだ」と気づきます。気づかせない限り、変えられません。
手法2：「強制的に違うやり方」を経験させる
過去パターンを言語化したら、次は「過去とは違うやり方」を強制的に経験させます。コンサルファームでは、新人にとって初めての案件で、わざと「最も苦手そうな役割」を割り当てることがあります。実装が得意な人には敢えてヒアリング主担当を、議論が得意な人にはモデリング担当を——という具合です。
中途エンジニアであれば、入社直後に「コードを書かない3か月」を作ります。要件定義、業務ヒアリング、PoC設計の検証——実装作業を意図的に外し、上流タスクに集中させます。これにより、「実装に逃げる」過去パターンが封じられ、新しい思考パターンを使わざるを得なくなります。
手法3：上司・メンターの強い介入
アンラーニング期間は、メンターが日常的に介入します。「なぜこのタイミングで実装に向かおうとした？」「顧客の本当の課題は何だと思う？」と問い続けます。本人が無意識に過去パターンに戻ろうとした瞬間に、その都度言語化させます。
最初の3か月、毎日のように介入し続けることで、新しい思考パターンが定着します。
中途エンジニア向け90日アンラーニングプログラム
Phase 1：自己認識（Day 1-15）
Day 1-5：オリエンテーションと過去棚卸し
- 入社オリエンテーション、FDE型人材像の共有
- 過去案件3〜5本の詳細振り返りシート作成
- 自分の「デフォルトの仕事の進め方」を言語化
Day 6-10：ベンチマーキング
- 社内シニアFDEの仕事ぶりを観察（顧客MTG・社内議論への陪席）
- 観察ノートを作成し、自分との差分を抽出
Day 11-15：個別アンラーニング計画
- メンターと1on1：手放すべき思考パターン3つを特定
- 同時に、新たに身につけるべきパターン3つを設定
- 90日後の到達点を合意
Phase 2：強制転換（Day 16-60）
Day 16-30：「実装しない」業務集中
- 顧客業務ヒアリングへの同行と議事化
- 業務フロー図作成、課題仮説の文書化
- ロジカルシンキング・仮説思考の集合研修（週1回半日）
Day 31-45：構造化と提案
- 担当業務領域での課題構造化
- 仮説検証プランの設計
- 顧客への中間提案を主担当（メンター伴走）
Day 46-60：上流主導の実装設計
- 仮説検証結果を踏まえたPoC設計
- AI活用を前提とした実装方針の作成
- 顧客との合意プロセスをリード
Phase 3：定着評価（Day 61-90）
Day 61-75：実案件統合
- 上流〜実装までを一気通貫で担当する小規模案件のリード
- 週次でメンターレビュー、パターン定着の確認
Day 76-90：総括と次フェーズ計画
- 90日間の総合評価（DSSビジネスアーキテクト類型での到達度判定）
- 次の半年の育成計画（FDE案件の本格化）
- 経営層との1on1：本人の納得度と次キャリアの方向づけ
アンラーニング成功の3つの条件
条件1：採用段階で覚悟を確認する
すべての中途エンジニアがアンラーニングに耐えられるわけではありません。採用面接の段階で、「3か月コードを書かない時期がある」「過去の自分のやり方を一旦手放してもらう」ことを明示し、本人の覚悟を確認します。覚悟がない人を入れると、双方が不幸になります。
条件2：環境の物理的な分離
過去パターンに戻りやすいのは、入社後すぐに「過去と同じ役割」の案件にアサインされた場合です。最低3か月は、過去とは異なる役割・チームに配置します。物理的に環境を変えることで、思考パターンの転換が促されます。
条件3：メンターの選定
メンターは「技術的に優れている人」ではなく「アンラーニングを言語化できる人」を選びます。自分自身が同じ転換を経験し、それを言語で説明できるシニアが最適です。場合によっては社外のコンサル経験者を一時的にメンターとして起用することも検討します。
まとめ——中途エンジニアこそ、IT企業の上流化を加速する
中途エンジニアは、新卒と比べて即戦力として期待されます。しかし「即戦力＝過去と同じ仕事」では、AI時代に通用しません。意図的なアンラーニング設計で「実装思考」から「課題解決思考」へ転換できれば、中途エンジニアこそ、IT企業の上流化を一気に加速する戦力になります。
経営者と育成責任者が判断すべきは、中途採用の入社後設計を「即戦力アサインで終わらせるか」「90日のアンラーニング期間を設けるか」です。後者を選ぶ会社にだけ、FDE型人材は育ちます。
Ballistaと相談する
ConStepでは、中途エンジニアのコンサル化アンラーニング・プログラムを各社向けにカスタマイズしてご提供しています。自社の中途人材の現状と転換計画について、個別相談（30分・無料）を承っています。
