技術的負債の転職理由、伝え方はSIerと自社開発で真逆に

「レガシーシステムの保守運用に疲れました」——この転職理由を口にした瞬間に、面接官の反応が真っ二つに割れる場面を、私は何度も見てきました。

IT・Web業界を中心に800名以上の転職支援に携わる中で、同じひとことがSIer出身の面接官には強い共感を呼ぶ一方、自社開発企業の面接官には「モダン化を推進する側に回れなかったのでは」という逆の受け取られ方をすることがあります。今回は、この受け取られ方の逆転がなぜ起きるのか、技術的負債と向き合ってきた経験を面接官のタイプ別にどう語り直せばいいのかを、実際の相談例を交えてお伝えします。

目次

1. 技術的負債とレガシー、転職理由の伝え方はなぜSIerと自社開発で分かれるのか
2. 面接官が転職理由を掘り下げて聞く、本当の意図
3. 自社開発企業の面接官が抱く「モダン化を推進する側に回れなかったのでは」という懸念
4. 「技術的負債と戦った経験」への言い換え、現場エンジニア面接官向け
5. 同じ経験を、人事・役員面接官向けにはこう翻訳する
6. 転職理由の回答例文、NGパターンとOKパターン
7. 現場エンジニア面接官向け
8. 人事・役員面接官向け
9. 面接官が複数人同席する場面での話し方
10. Kさんのその後、逆質問への切り返しまで含めた実践例
11. SES・受託出身で自社開発を目指す場合に気をつけたいこと
12. 求人票・カジュアル面談の段階から、伝え方を意識しておく
13. よくある疑問に答えます
14. まとめ、技術的負債は「疲れた話」ではなく「動いた話」として語る

技術的負債とレガシー、転職理由の伝え方はなぜSIerと自社開発で分かれるのか

長年同じ基幹システムの保守を任され、追加改修のたびに継ぎ足されたコードと格闘してきた——。SIer出身のエンジニアから転職理由を聞くとき、この手の話は本当によく出てきます。技術選定の裁量がなく、保守フェーズの案件に長期間アサインされ続けたことへの疲労感は、SIer業界特有の構造的な問題として広く共有されています。

経済産業省がかつて公表したDXレポート由来の数字として紹介されることが多いのですが、レガシーシステムを21年以上使い続ける企業は6割を超え、IT予算の9割以上が保守運用に振り向けられているという指摘があります(Schoo「2025年の崖」を分かりやすく解説)。この数字が今のIT予算配分をそのまま表しているかは議論の余地がありますが、少なくとも私が担当してきたSIer出身の候補者の実感とは、驚くほど近いものがあります。

こうした背景があるからこそ、SIer出身の面接官——特に同じくSIerや受託開発を経て自社開発企業に転じたマネージャー層——は、「レガシー保守に疲れた」という理由に素直に共感してくれることが多いです。自分自身が通ってきた道だからこそ、疑う理由がない。むしろ「よく分かる、うちも似たようなものだった」と場が和むことすらあります。

補足すると、「技術的負債」という言葉が指す中身も、SIerと自社開発では微妙にずれています。SIerでの技術的負債は、多くの場合「顧客都合で選定されたレガシーな言語・フレームワーク」や「ドキュメント不足のまま引き継がれた仕様」を指し、自分たちで選んだわけではない負債です。一方、自社開発企業での技術的負債は「スピード優先で自分たちが作った借金」であることが多く、当事者意識の持ち方そのものが違います。この前提のズレを知らずに話すと、自社開発の面接官には「他人事のように聞こえる」という印象を与えかねません。

面接官が転職理由を掘り下げて聞く、本当の意図

そもそも面接官が転職理由を深掘りするのは、意地悪でも興味本位でもありません。見ているのは大きく二つ、入社後に同じ理由で早期に辞めないかという定着リスクと、うちの環境でどう活躍してくれるかという具体的なイメージです。

「レガシー保守に疲れた」という理由だけを聞くと、この二つのどちらにも答えが出ません。辞めた理由は分かっても、次の職場で何を求め、どう動くつもりなのかが見えないからです。面接官が重ねて質問してくるのは、たいてい情報が足りないというサインで、深掘りされること自体をネガティブに捉える必要はありません。

私が候補者に伝えているのは、転職理由は「過去に何があったか」だけでなく「次の職場で何を再現・改善したいか」までワンセットで語る、という原則です。この後の項目で扱う技術的負債の言い換えも、根っこにあるのはこの原則です。

この原則を知らないまま面接に臨んで苦戦した候補者を、私は何人も見てきました。ある候補者は「レガシー環境がつらかった」という説明を三社連続で繰り返し、いずれも一次面接止まりで終わりました。本人はスキル不足を疑っていましたが、実際に選考記録を見返すと、面接官が求めていたのは技術力の証明ではなく「同じことを繰り返さない見込みがあるか」という一点でした。過去の説明だけで終わる回答は、面接官の側からすると判断材料が半分しかない状態です。

自社開発企業の面接官が抱く「モダン化を推進する側に回れなかったのでは」という懸念

ところが、生え抜きで自社開発企業しか経験していない面接官の反応は違います。エンジニアが技術選定に一定の裁量を持つのが当たり前の環境で育ってきた人からすると、「レガシーがつらかった」という話は、裏を返せば「その環境を変える動きを取れなかった」というシグナルにも読めてしまうのです。

この傾向は、募集要項に「レガシー刷新」「モダン化推進」といった言葉を掲げている企業ほど強くなります。そうした企業は、これから技術的負債と正面から向き合う人材を採ろうとしているので、面接官も「負債と向き合った経験があるか」を通常より深く確認してきます。同じ転職理由でも、応募先が技術的負債の解消を採用の前面に出しているかどうかで、聞かれる深さが変わると考えておいた方がいいでしょう。

35歳、金融系の基幹システム保守を12年担当してきたKさんの話です。一次面接は現場のエンジニアが面接官で、COBOLと.NETが混在するシステムの保守で味わった苦労を率直に話したところ、深く共感してもらえた手応えがあったといいます。

ところが二次面接、人事と開発部長が同席する場で、開発部長からこう聞かれた瞬間に言葉に詰まりました。「保守が大変だったのは分かりました。では、その中でモダン化や改善を提案したことはありますか」。数秒の沈黙のあと、Kさんが答えたのは「提案できる立場ではなかった」という一言で、これが決め手になって見送りとなりました。

自社開発企業、特にプロダクトの技術的意思決定にエンジニア自身が関与するカルチャーの企業ほど、「疲れた」という理由を環境を変える力がなかった証拠として読み替えてしまう傾向があります。SIerの面接官なら同情してくれる話が、自社開発の面接官には逆質問の材料に変わる。これが今回のテーマの核心です。

ポイント： 自社開発の面接官が本当に知りたいのは「レガシーが嫌だったかどうか」ではなく、「レガシーの中で何をしようとしたか」です。感情の描写だけで終える回答は、この問いへの答えになっていません。

「技術的負債と戦った経験」への言い換え、現場エンジニア面接官向け

とはいえ、保守フェーズの案件で何の改善アクションも取っていないエンジニアは、実際にはそう多くありません。予算や権限の制約で日の目を見なかっただけで、掘り起こせば材料はあるケースがほとんどです。私が面談で必ず聞くのは、次のような質問です。

現場エンジニア面接官には、この種のエピソードを技術的な具体性を持って話すのが効きます。「デプロイ作業を自動化しました」で終わらせず、「月次リリースで8時間かかっていた手動デプロイ手順を、CIパイプラインの整備で40分まで圧縮した」というように、対象・手段・数値をセットで語る。技術の話が分かる相手ほど、抽象的な感想より具体的な変化量の方が刺さります。

権限がなく実現できなかった提案も、材料として無駄にはなりません。「承認は下りなかったが、影響範囲の小さい夜間バッチの一部で検証用のパイロットを組み、処理時間を3割短縮できる見込みを示した」という話は、実現できなかった事実よりも、動いた事実の方が評価されます。現場のエンジニアは、提案が通らなかった経験そのものに共感してくれることも多いものです。

現場エンジニア面接官は、技術的負債を「なんとなく感じるもの」ではなく「測れるもの」として扱えるかどうかも見ています。障害チケットの件数、テストカバレッジ、コードレビューでの指摘件数、特定モジュールの改修頻度といった指標を一つでも持ち出せると、感覚的な話から一段踏み込んだ印象を与えられます。数値を正確に覚えていなくても、「◯件から◯件に減らした」というような概算で十分で、無理に細かく作り込む必要はありません。

同じ経験を、人事・役員面接官向けにはこう翻訳する

人事や役員クラスの面接官は、技術的な詳細そのものにはあまり関心を持ちません。彼らが知りたいのは、その経験が事業や組織にどんな影響を与えたか、そして入社後に同じ動き方を再現できるかどうかです。

先ほどの「デプロイを40分まで圧縮した」という話は、人事・役員向けには「月次のリリース作業にかかっていた人件費と機会損失を実質的に削減し、リリース頻度を上げられる状態を作った」というように、コストや事業スピードの言葉に翻訳し直す必要があります。技術用語の羅列で終わる説明は、この層には刺さらないどころか記憶にも残りません。

面接官のタイプによって、響く語り方と避けたい言い方をまとめると次のようになります。

同じ経験の使い回しではなく、相手が評価軸として持っている言葉に合わせて訳し直すという発想が要ります。この作業を面接直前に初めて考えるのではなく、応募前の職務経歴書を書く段階で一度言語化しておくと、面接での言い換えがぶれません。

一口に自社開発企業といっても、規模によって温度差があります。数百人規模のメガベンチャーでは、技術的負債の解消自体が専門チームの役割として制度化されていることが多く、候補者に求めるのは「制度に乗って改善を進められる実行力」です。一方、数十人規模のスタートアップでは制度も専門チームもまだなく、技術的負債の解消は誰かが手を挙げて巻き取るしかありません。求められるのは「言われなくても気づいて動く姿勢」で、同じ経験でも強調するポイントを変えた方が伝わります。

転職理由の回答例文、NGパターンとOKパターン

言葉で説明するより、実際の回答例を並べた方が違いは分かりやすいはずです。SIerで基幹システムの保守を5年ほど担当し、自社開発企業に応募する場面を想定した例文を挙げます。

現場エンジニア面接官向け

NGパターンは「保守運用がメインで、新しい技術に触れる機会がなかったので転職を考えました」という説明です。事実の羅列で終わっており、面接官には「何もしていなかった期間」としか映りません。

OKパターンは次のようになります。「保守運用が中心の環境でしたが、月次リリースの手動デプロイ作業が属人化していたのが課題で、自分の裁量が及ぶ範囲でCIパイプラインを整備し、作業時間を8時間から40分に圧縮しました。この経験から、もっと裁量を持って技術選定に関われる環境で、同じような改善を積み重ねたいと考えています」。対象・課題・行動・結果・次への意欲まで一続きになっている点がNGパターンとの違いです。

人事・役員面接官向け

NGパターンは「レガシーな環境で成長が止まると感じたので、モダンな技術を使っている御社で挑戦したいです」という説明です。動機が「今の環境への不満」に寄りすぎていて、事業への貢献イメージにつながりません。

OKパターンは「保守運用の中でも、リリース作業の属人化はチームの生産性やリスクに直結する課題だと考え、自分の裁量でできる範囲から改善に取り組みました。裁量が広い環境であれば、同じ視点でより大きな範囲の課題に貢献できると考えています」というように、個人の不満ではなく組織への貢献に置き換えて話す形です。

一つ注意したいのは、この言い換えをやりすぎて「改善は全部自分の手柄」という語り口になると、今度は別の懸念を招くことです。保守フェーズの改善は一人で完結することが少なく、チームや上司の協力があって初めて動く場合がほとんどです。面接官、特にマネージャー経験のある面接官は、そのあたりの謙虚さも見ています。「自分が気づいて動いたが、チームの協力があって実現できた」という一言を添えるだけで、成果の見せ方と協調性のバランスが取れます。

面接官が複数人同席する場面での話し方

現場エンジニアと人事・役員が同席する最終面接では、どちらか一方に合わせるのではなく、技術的な具体性から入って事業インパクトで締めるという順番が扱いやすいです。最初に対象・課題・行動を具体的に話して現場側の関心を満たし、最後の一文で「この経験から、御社では◯◯という形で貢献したいと考えています」と事業側の言葉で結ぶ。話す順番を意識するだけで、片方の面接官だけに刺さって終わる事態を避けられます。

Kさんのその後、逆質問への切り返しまで含めた実践例

Kさんとは見送りの連絡を受けた後に面談を組み、3社分の面接内容を一つずつ振り返りました。技術的負債と向き合った経験自体はいくつも出てきたのに、それを「疲れた」という感情の言葉でまとめてしまい、行動として語れていなかったことが最大の問題でした。

次の応募先の一次面接では、先ほどの夜間バッチの検証エピソードを、対象システム・検証内容・処理時間の削減見込みまで具体的に話すよう準備しました。二次面接では、開発部長から同じ質問が来る前に、自分から「保守の中で提案した改善が通らなかった経験もあります」と先回りして触れ、その理由と、次はどう動きたいかまで話しきる構成に変えました。

準備のときに使ったのは、状況・課題・行動・結果を順に並べるだけの簡単なメモです。Kさんの場合、状況は「金融系基幹システムの夜間バッチ処理が肥大化していた」、課題は「処理時間の超過で翌朝の業務開始に影響が出かねなかった」、行動は「影響範囲の小さい部分だけ切り出して検証用の改修を自主的に試した」、結果は「処理時間を3割短縮できる見込みを示せたが、予算の都合で本採用には至らなかった」という4行です。感情から入らず状況から入るだけで、話の重心が自然と行動に移ることをKさん自身、面談の中で実感していました。

さらにKさんは、逆質問でも姿勢を示すことにしました。「御社では技術的負債をどう可視化し、優先順位をつけていますか」という質問です。逆質問で面接の通過率が変わる、IT・Web業界で評価される質問と評価を下げる質問でも触れていますが、逆質問は待遇確認の場ではなく、入社後の動き方を面接官にイメージさせる最後の機会です。この質問一つで、開発部長からは「うちも似た課題を抱えている、一緒に考えてほしい」という前向きな反応が返ってきたそうです。

結果として、Kさんはこの企業から内定を受け取りました。感情の描写を行動の描写に組み替え、逆質問まで一貫させたことで、「疲れた」だけの候補者から「変えようとした」候補者に印象が変わったというのが、私自身の受け止め方です。

SES・受託出身で自社開発を目指す場合に気をつけたいこと

SES企業から客先常駐で保守運用に携わってきた候補者にも、似た構造が起きます。むしろSESの場合は、客先の運用フィードバックを自分たちの開発プロセスに反映する権限そのものがないことが多く、「改善提案をしたくてもできる立場になかった」という説明が、SIer出身者以上に説得力を持ちやすい面もあります。

ただしその分、面接官からは「では次の職場で何を変えたいのか」という具体的な像をより強く求められます。単に「裁量のある環境で働きたい」で終わらせず、前職で権限がなくても気づいていた課題を、次の職場でどう解決したいかまで踏み込んで話す必要があります。

実際に、客先常駐で6年ほど保守運用を担当してきたエンジニアから、こんな相談を受けたことがあります。客先のシステムでエラーログが放置されていることに気づき、自分なりに原因を分類して報告書にまとめたものの、契約上の役割を超える提案だとして客先にも自社の営業にも取り合ってもらえなかったといいます。この話は「何もできなかった」というより「やろうとしたが構造上できなかった」という説明に組み直せる材料で、面接ではむしろ、権限の外側にある課題まで自分から拾いに行く姿勢として伝わりました。

求人票・カジュアル面談の段階から、伝え方を意識しておく

技術的負債への向き合い方を語る準備は、最終面接の直前ではなく、応募を検討する段階から始めておくと有利です。求人票や採用ページに「レガシー刷新」「技術的負債の解消」といった言葉が明記されている企業は、面接官もその話題を前提に質問してくるので、現場目線の具体的なエピソードを厚めに用意しておく価値があります。

反対に、そうした言葉が見当たらない企業では、面接官がそもそも技術的負債という概念に強い関心を持っていない可能性があります。この場合は無理に技術の深掘りへ持ち込まず、事業への貢献という切り口を先に置いた方が話がかみ合いやすくなります。カジュアル面談の段階で「今のプロダクトで技術的な課題として意識していることはありますか」と一つ尋ねておくだけでも、本選考での温度感を事前につかめます。

転職エージェントを使っている場合は、この見極めを自分だけで抱え込む必要はありません。担当のエージェントは同じ企業の過去の面接内容や、どのタイプの面接官が同席しやすいかを把握していることが多く、事前に共有してもらえれば準備の精度が上がります。私自身、面接直前に候補者から「今回の面接官は現場寄りですか、それとも事業寄りですか」と聞かれたら、分かる範囲で必ず答えるようにしています。

SIerから自社開発への転職では、技術的負債の伝え方以前に、最終面接特有の評価軸のズレでつまずくケースも少なくありません。SIerから自社開発への転職、最終面接で落ちる29歳SEの壁では、書類やコーディングテストは通るのに最終面接だけで評価がひっくり返る構造を扱っていますが、そちらも合わせて見ておくと、選考のどの段階でどんな軸が働いているかが立体的に見えてきます。

求人票やカジュアル面談で拾える情報には限界があります。「レガシー刷新」「モダン化推進」といった言葉が採用ページに載っていても、それが経営陣の本気度なのか、採用のための言葉選びに過ぎないのかは、外からは判別しづらいところです。

こうした温度感を面談前に補う一例として、社員・退職者の口コミを集めた口コミサイトを情報収集に使う方法があります。転職会議はその一つで、企業ページには「社長と経営方針」という口コミカテゴリがあり、経営陣が技術的負債やモダン化にどれだけ本気で投資する姿勢を見せているかについて、在籍者・退職者の声が書き込まれていることがあります。

ただし、口コミの内容をそのまま鵜呑みにするのは避けた方がいいというのが私の見解です。口コミは在籍者・退職者の主観であり、特に経営方針や退職理由に関するカテゴリは、不満を抱えて辞めた側の声に偏りやすい傾向があります。あくまで面談で確認すべき論点の当たりをつける材料として使い、気になった記述はカジュアル面談や一次面接で本人に直接確かめる、というワンクッションを挟むのが実用的な使い方です。なお、口コミカテゴリの構成や掲載件数は公式サイト・公式発表に記載されている内容であり、私自身が閲覧して確かめた実感として書いているわけではない点は断っておきます。

よくある疑問に答えます

改善提案の経験がまったくない場合はどうすればいいですか。 提案という形でなくても構いません。ドキュメントを整備した、テストケースを追加した、レビューで気づいた点を指摘したなど、小さな行動でも「気づいて動いた」事実であれば材料になります。それすらない場合は無理に作らず、「次の職場ではこういう関わり方をしたい」という意欲を具体的に語ることに重心を置いた方が誠実です。

面接官がSIer出身か自社開発出身か、事前に見分ける方法はありますか。 面接案内のメールに面接官の役職や部署が書かれていれば、そこから推測できます。「開発部 ◯◯」であれば現場寄り、「人事部」「執行役員」であれば事業寄りの質問が来ると想定して準備するとよいでしょう。担当エージェントがいる場合は、過去の面接官情報を持っていることも多いので、面接前に確認する価値があります。

技術的負債への向き合い方は、職務経歴書にも書くべきですか。 書いた方がよいと考えています。面接で初めて語るより、職務経歴書の実績欄に「手動作業の自動化によりリリース時間を◯割短縮」のように一行入れておくと、面接官が事前にその話を深掘りする前提で質問を準備してくれます。結果として、面接本番で一から説明する負担も減ります。

逆に、自社開発企業からSIerや受託開発に転職する場合はどう伝えればいいですか。 方向が逆でも考え方は同じです。自社開発企業の面接官には「スピード優先で積み上がった負債を解消した経験」を、SIer・受託企業の面接官には「顧客都合の制約の中でも、品質や保守性を落とさない工夫をしてきた経験」として語り直すと伝わりやすくなります。どちらの業態でも、技術的負債との向き合い方そのものは同じスキルとして評価される、という前提を持っておくと言い換えがしやすいはずです。

まとめ、技術的負債は「疲れた話」ではなく「動いた話」として語る

レガシー保守の経験そのものは、決してマイナス材料ではありません。地雷を踏まないための土地勘を持ち、動かしながら壊さない開発の勘所を知っている人材とも言えます。ただしその経験を感情の言葉で止めて話すか、行動の言葉に変えて話すかで、面接官の受け取り方は真逆になります。

SIer出身の面接官には共感される話が、自社開発の面接官には懸念材料に変わる——この逆説を知らないまま同じ説明を使い回すと、通るはずの面接を落とすことになりかねません。面接官のタイプを見極め、同じ経験を違う言葉に訳し直せるかどうかが、技術的負債を語る上で一番効いてくるポイントだというのが、今回一番お伝えしたかったことです。

長くレガシー環境に身を置いてきた人ほど、自分の経験を過小評価しがちです。しかし技術的負債と付き合ってきた年数は、裏を返せば「壊さずに直す」という自社開発企業でも必ず求められる感覚を養ってきた年数でもあります。感情の言葉を行動の言葉に組み替える作業は、面接対策であると同時に、自分の経験を正しく棚卸しする作業でもあると私は考えています。