ITコンサルからエンジニア転職、技術面接で実装力を問われる壁

「まず、この関数の一行目から書いてもらえますか」——画面共有の先でカーソルだけが点滅し、1分以上キーボードに手が乗らなかった。ITコンサルタントからエンジニアへの転職を目指す方から、技術面接の後にこんな話を聞くことがあります。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、要件定義や提案が仕事の中心だった方ほど、設計の意図は流れるように語れるのに、手を動かす場面で止まってしまう傾向があります。今回は、その「話せるが書けない」がなぜ起きるのか、面接官が具体的にどこを見ているのか、そして半年でどんな実装の証拠を作れば越えられるのかを、現場で見てきた実例を交えてお伝えします。

目次

1. ITコンサルからエンジニア転職で、技術面接の実装力が壁になる理由
2. 面接官は「書けない」をどこで見ているのか
3. エッジケースとエラー処理
4. 既存コードの読み書き
5. デバッグとつまずきの手順
6. 研究者の実装力不足とは、何が違うのか
7. 実例：実装課題で手が止まった、ITコンサル出身のRさん
8. 半年で作る最小の実装証拠
9. 題材は、自分が詳しい業務から選ぶ
10. 小さく、でも異常系まで入れる
11. 週の時間配分
12. 面接の形式ごとに、手が止まる場面は違う
13. 面接では「実装の途中経過」を語る
14. 狙う求人の選び方
15. 年収は下がる前提で、コンサルの価値を残す
16. よくある質問
17. まとめ

ITコンサルからエンジニア転職で、技術面接の実装力が壁になる理由

ITコンサルタントの仕事は、顧客の課題を整理し、要件を決め、システムの全体像を描くことです。IT業界の役割分担として、コンサルは上流を担い、実装はSEやエンジニアが担うという整理は一般的で、日々コードを書く職種ではありません。

ここに転職の落とし穴があります。コンサルとしての評価は「何を作るべきかを決められるか」で決まってきたのに、エンジニアの技術面接は「決まったものを自分の手で動く形にできるか」を確かめる場だからです。評価の軸がずれているので、経歴が立派であるほど、面接で露呈する落差も大きくなります。

もう一つ見落とされやすいのが、コンサル経験があること自体は、実装力の代わりにならないという点です。エンジニアtypeの記事で久松剛氏は、技術力が「十分条件」から「参加チケット」に変わり、そのうえで技術を事業課題の解決に活かす推進力が求められるという趣旨を述べています(出典：エンジニアtype「久松剛氏の記事」)。調査データではなく一人の方の見解ですが、私が面接のフィードバックを見ている実感とも近いものです。

つまり、コンサルの強みは「参加チケットを持った人」に上乗せされる価値であって、チケットの代わりにはなりません。この順番を取り違えて、面接で上流の話を厚く語るほど評価が伸びないという相談を、私はこれまで何度も受けてきました。

面接官は「書けない」をどこで見ているのか

「実装できない」と言われても、何が足りないのか自分では分かりにくいものです。面接官の側から見ると、判断の材料はかなり具体的です。設計の意図は語れても、次の3点が出てこないと「手を動かしていない人」と読まれます。

エッジケースとエラー処理

コンサルの設計の語りは、正常系の流れで完結しがちです。「ユーザーが申込みをして、承認が下りて、請求が走る」という筋は語れても、「承認者が不在のときはどうするか」「二重送信されたらどうなるか」まで自分の手で確かめたかを聞かれると、言葉が止まります。

面接官がこれを聞くのは、意地悪ではありません。実際にコードを書くと、正常系より異常系の処理の方がずっと多いと身をもって知るからです。そこを語れるかどうかは、書いた経験の有無をいちばん素直に映します。

既存コードの読み書き

エンジニアの仕事の多くは、ゼロから書くことではなく、既に動いているコードに手を入れることです。「このバグ報告を渡されたら、最初にどこを見ますか」という質問は、既存コードを読んだ経験の厚みを測っています。

コンサルは設計書やパワーポイントは読み慣れていても、他人が書いたコードを読んで挙動を追う経験が薄い。ここは経歴の言い換えでは埋まらず、実際に読んだ回数がそのまま答えの具体度になります。

デバッグとつまずきの手順

三つ目は、詰まったときの動き方です。優秀な方ほど「調べて解決しました」の一言で済ませてしまいますが、面接官が聞きたいのは、エラーメッセージのどこを見て、何を仮説にして、どう切り分けたかという手順です。

この手順が語れると、仮にコードの総量が少なくても「手を動かして悩んだ人」だと伝わります。逆に言えば、悩んだ記録がない人は、語りようがない。ここが、設計の意図は語れるのに実装の話になると失速する方の、いちばん多いパターンです。

研究者の実装力不足とは、何が違うのか

同じ「実装力が足りない」でも、研究者とITコンサルでは中身が逆です。研究者は日常的にコードを書いているので、足りないのは保守性・再現性・テストといった「書き方の作法」です。この翻訳については、別の記事で詳しく書いています(機械学習研究者がMLエンジニアに転身するときの、研究経験から実装力への翻訳)。

一方、ITコンサルの場合は、翻訳の元になるコードがそもそも少ない。作法を直せばよいのではなく、「小さくても動くものを自分で書いた」という証拠そのものを、ゼロから作る必要があります。

ここを混同すると、対策がずれます。研究者向けの「コードを整える」助言をコンサル出身者が受けても、整える対象がありません。私は、コンサル出身の方には最初に「まず書く量を増やす」という、地味なことを伝えています。

実例：実装課題で手が止まった、ITコンサル出身のRさん

実際にあった例を一つ挙げます。32歳・ITコンサル経験8年で、総合系ファームの基幹システム刷新案件を中心に、要件定義や業務設計を担当してきたRさんです。「もう資料を作る仕事より、自分でプロダクトを作る側に回りたい」と、自社開発のWebサービス企業のエンジニア職を受けました。

一次面接は順調でした。要件をどう整理し、関係者の利害をどう調整したかを語ると、面接官は何度もうなずいたそうです。ところが二次面接で、冒頭の場面が起きます。簡単な在庫引き当ての関数を、その場で書くよう求められ、一行目から手が止まりました。

Rさんは後日、「頭の中に設計図はあるのに、それをどの順で文字にすればいいか分からなかった」と話していました。フィードバックには「設計の考え方は十分。ただ実装の手触りが確認できなかった」とありました。

私が最初にしたのは、応募を止めることでした。Rさんは一刻も早く次の選考を受けたがっていましたが、数社重ねても同じ場面で止まるだけです。そこで、半年かけて小さなものを一本作ると決めてもらいました。次の節で書く内容がそのとき決めた中身です。

半年後、Rさんは別の自社開発企業の技術面接で、自作した在庫管理の小さなアプリを題材に、エラー処理とデバッグの経緯を語り、内定を得ました。年収は現職より100万円ほど下がりましたが、本人は納得して承諾しています。

半年で作る最小の実装証拠

コンサル出身者が作るべきものは、立派なポートフォリオではありません。面接官に「手を動かした」と伝わる、最小の証拠です。ポートフォリオ全般の考え方はフロントエンドエンジニアのポートフォリオ設計の記事にも書いていますが、ここでは未経験寄りの方に絞って整理します。

題材は、自分が詳しい業務から選ぶ

何を作るかで迷う時間がいちばんもったいないので、題材は「自分が要件定義した経験のある業務」に決めてしまいます。Rさんなら在庫管理でした。仕様を知っているので、技術的な悩みだけに集中できます。

この選び方には、もう一つ効用があります。面接で「なぜこの機能にしたのですか」と聞かれたとき、業務の理由から語れるので、コンサル経験が自然に活きるのです。作る物の価値は、技術の新しさではなく、「業務を知っている人が自分で作った」という点にあります。

小さく、でも異常系まで入れる

規模は、画面が3〜4つ程度で十分です。ただし、入力エラー、通信失敗、データが空のときの表示だけは必ず作ってください。面接官が見るのはここだからです。

ポイント： 機能を増やすより、異常系を1つでも多く自分の手で作る。半年かけるなら、機能数より「悩んだ回数」を増やす方が、面接では効きます。

あわせて、コミットは小分けにして、つまずいた原因と直した方法をREADMEやメモに残してください。コミットの見せ方についてはGitHubのコミットが少ないときの面接対策が参考になります。ただ、今回の場面ではコミットが少ない以前に、書いた記録がない状態なので、まずは記録を作る段階です。

週の時間配分

私がRさんに勧めたのは、平日は1日1時間、週末は4時間を2回という配分です。無理をしない範囲で、とにかく途切れさせないことを優先してもらいました。

最初の1か月は、動くものを作るより、他人が書いた小さなコードを読んで直す練習に使います。オープンソースの簡単な不具合修正や、教材のサンプルコードを改造する程度で十分です。既存コードを読む経験が積めれば、前節の2つ目の材料を埋められます。

全体の流れは、Rさんの場合はおおむね次のようになりました。

あくまでRさんのペースで、人によって前後して構いません。大事なのは、5か月目の異常系を後回しにしないことです。ここを飛ばして機能を増やす方が多いのですが、面接で聞かれるのは正にそこです。

面接の形式ごとに、手が止まる場面は違う

技術面接と一口に言っても、形式で止まる場所が変わります。ライブコーディングなら「最初の一行」、口頭の技術質問なら「異常系やデバッグの手順」、持ち帰り課題なら「READMEで判断を説明できるか」です。

Rさんが止まったのは、いちばん即興性が求められるライブコーディングでした。この形式は慣れの要素が大きく、実装経験があっても最初は緊張で手が止まる方もいます。だからこそ、日頃から小さな関数を声に出しながら書く練習を入れておくと、本番の落差が小さくなります。私は面接前の週に、10〜15分で書ける小問を数題、声に出しながら解くことを勧めています。

選考が始まる前に、応募先がどの形式を採るかを確認しておくのも手です。エージェント経由なら、私たちが企業側から形式を聞けることが多いので、遠慮なく聞いてください。

面接では「実装の途中経過」を語る

作ったものがあっても、語り方が上流の癖のままだと、評価は伸びません。コンサル出身者は、完成した設計や結論から語りがちで、そのせいで「本当に自分で書いたのか」と疑われることがあります。

効くのは、結論より途中経過を話すことです。次のように、順番を変えてみてください。

私はこの順番を、Rさんと模擬面接で何度も練習しました。たとえば「在庫が負の数になる不具合が出て、原因は同時更新だと仮説を立て、更新処理にロックをかけた」のような具体が一つあるだけで、面接官の質問の深さが変わります。

ここで大切なのは、うまく解決した話である必要がないことです。解決しきれなかった部分も、正直に「ここは未解決で、次にこう調べます」と言える方が、手を動かした人の語りとして信用されます。設計の意図を語るのは得意なはずなので、その力を「なぜその実装にしたか」の説明にそのまま使えるのも強みです。

課題が出題されたときの手の止まり方についても触れておきます。分量や進め方は持ち帰り課題の分量の見極め方、落ち方の典型はコーディングテストで落ちる人の共通点で書いています。ライブコーディングで手が止まったときは、黙らずに「まず入力と出力を決めます」と声に出して、要件の分解から始めれば、コンサルの得意技がそのまま時間稼ぎではなく思考の見える化になります。

狙う求人の選び方

もう一つの判断軸は、どんな求人を狙うかです。ITコンサル出身者が、いきなり実装力を厳しく問う自社開発の求人だけを受けると、苦戦が長引きます。求められる実装の水準は、職種によってかなり違うからです。

IPAのITスキル標準では、IT人材を職種と専門分野、レベルで整理しています(参考：IPA ITスキル標準 キャリアフレームワーク)。職種ごとにスキルの中身が違うという前提に立てば、「エンジニア」と一括りにせず、自分が入れる入口を選ぶ発想が持てます。

どれを選ぶかは、本人が何に価値を感じるかで決まります。「手を動かしたい」という動機が強いのであれば、PdMやプリセールスは本人の望みとずれますし、逆に実装水準の高い求人をいきなり狙うのも遠回りです。

プリセールスについてはエンジニアからプリセールスへ転身するときの面接、社内SEについては情報子会社・社内システム側の評価の記事で近い話をしています。求人票の読み方に迷う方は未経験でIT求人を探すときの実態も参考になります。

年収は下がる前提で、コンサルの価値を残す

職種を転換すると、年収が下がるのは珍しいことではありません。IPAのキャリアパスモデルの例示には、コンサルタント系などからアプリケーション開発系への職種転換の例があり、現実には転換後の職種でのレベルの位置付けは下がること、同じレベルを保つには必要な教育・訓練を経ることが前提になる、という趣旨の説明があります(参考：IPA ITスキル標準 キャリアパスモデルの例示)。年収ではなくスキルレベルの話ですが、職種を変えれば評価の起点が一度戻るという考え方は、公的な枠組みにも載っているわけです。

年収についての私の実感でも、一度下がるのは自然な動きだと思います。ここで焦って「前職の年収を維持したい」と交渉に力を入れると、実装力の弱さと条件の強気がぶつかって、選考がこじれることがあります。Rさんのように、100万円ほど下がっても納得できる理由(手を動かす仕事に就く)を先に決めておくと、判断がぶれません。

ただし、下がり幅を小さくする方法はあります。それは、コンサル経験を「実装力の穴埋め」ではなく、エンジニアとしての強みの上乗せとして語ることです。要件を正しく掴む力、関係者の調整、優先順位づけは、実装力を前提にすれば強い武器です。

年収交渉の場面では、実装の評価が固まってから、そうした周辺の価値を示すのが順序として効きます。先に上流の話で押し切ろうとしないでください。もう一つの方向性として、上流から意思決定の語りへ移る話はSIerのPMがPdMに挑むときの語り直しで扱っています。

よくある質問

どの程度書ければ、技術面接に受かりますか。 求人によって違いますが、自社開発のプロダクト開発職なら、簡単なAPIや画面を自分で組み、異常系まで自分の言葉で説明できる水準を、私は目安に伝えています。完璧なコードより、動かして直した経験の厚みが見られます。

30代でも、エンジニアとして未経験扱いされますか。 実装経験がなければ、年齢にかかわらず未経験に近い扱いになります。ただ、業務知識や調整力の価値は年齢とともに評価されやすいので、手を動かした証拠さえ作れれば、20代と同じ土俵で不利とは限りません。

どんなものを作れば、実装力の証拠になりますか。 自分が要件定義をした経験のある業務を、小さく作るのがおすすめです。機能の多さより、入力エラーや通信失敗といった異常系を自分の手で作り、つまずいた経緯をREADMEに残してください。

コンサル経歴は、年収交渉でどう扱われますか。 実装力が評価された後であれば、要件を掴む力や調整力として加点されることがあります。逆に、実装が弱いまま上流の話を前面に出すと、評価が上がりにくいというケースを私は見ています。

コンサルのまま、技術理解を深める道はないのですか。 あります。PdMやプリセールス寄りの技術職など、コンサル経験が活きる入口は存在します。ただし、どの職でも技術理解は求められるので、「手を動かしたい」のか「技術に近い上流にいたい」のかを、先に決めてください。

まとめ

ITコンサルからエンジニアへの転職で技術面接が難しくなるのは、能力が低いからではありません。評価の軸が「何を作るか決められるか」から「自分の手で動かせるか」に変わるのに、その証拠が手元にないからです。

面接官が見ているのは、エッジケースとエラー処理、既存コードの読解、つまずきとデバッグの手順でした。これは精神論ではなく、半年かけて小さなものを一本作り、その途中経過を語れるようにすれば、埋めていける差だと私は見ています。研究者のように作法を整えるのではなく、書いた事実そのものを作る。そこが出発点です。

求人は自分の動機に合う入口を選び、年収が一度下がることは前提に置いてください。そのうえで、要件を掴む力や調整力は、実装力に上乗せされる武器として残せます。「話せる人」から話せて書いたことのある人へ移るのに必要なのは、特別な才能ではなく、小さな実装を最後まで作り切った一本の記録だというのが、この記事で一番伝えたかったことです。