レガシーコード保守に疲れた｜技術的負債が退職理由になるとき

レガシーコードの保守に疲弊し、退職を考えているエンジニアに向けて、社内での改善提案の方法と見切りをつける判断基準を解説します。

レガシーコード保守による疲弊の実態

IPAの「IT人材白書」やdoda・レバテックの転職理由調査によると、エンジニアの転職理由の上位に「技術的な成長が見込めない」「使用技術が古い」が挙がっています。

よくある疲弊パターン

• 10年以上前のフレームワーク（Struts、古いjQuery依存のUI）の保守が中心
• テストコードがなく、修正のたびにデグレが発生
• ドキュメントが存在せず、暗黙知に依存した開発
• 新しい技術を学んでも業務で使う機会がない
• 改善提案をしても「動いているものは触るな」と却下される

技術的負債が引き起こす問題

退職前に試すべき社内改善アプローチ

退職を決断する前に、以下の改善提案を試みることを推奨します。

1. 小さな改善から始める（ボーイスカウトルール）

一度に全てを刷新するのは現実的ではありません。以下のような小さな改善から始めましょう。

• 新規コードにはユニットテストを必ず書く
• 修正したファイルのコードフォーマットを整える
• 小さなモジュールから新しいフレームワークに移行する
• CIパイプラインを導入してテストを自動化する

2. 数値で経営層に説明する

技術的負債の解消を経営層に納得させるには、ビジネスへの影響を数値で示すことが重要です。

• 障害対応にかかっている月間工数（人月単位）
• 機能追加にかかる時間の推移（半年前との比較）
• セキュリティリスクの具体的な事例（同業他社の事故など）
• 採用コストの増加（技術スタックが原因で辞退された件数）

3. 20%ルールや技術研修の提案

• 業務時間の一定割合をリファクタリングに充てる制度の提案
• 社内勉強会の開催
• 技術カンファレンスへの参加費用補助の申請

見切りをつける判断基準

以下の状況が複数当てはまる場合、転職を真剣に検討すべきタイミングです。

環境面の判断基準

• 改善提案を繰り返しても経営層・上長が動かない（半年以上）
• 技術的負債の解消に予算が一切つかない
• チーム内に改善意欲のあるメンバーがいない
• EOLの技術を使い続ける方針が変わらない

キャリア面の判断基準

• 現在の技術スタックが市場で需要がない
• 同年代のエンジニアと比べてスキルセットに不安を感じる
• 3年後の自分のキャリアが想像できない
• 社外の勉強会やコミュニティで疎外感を感じる

健康面の判断基準

• 日曜の夜に強い憂鬱感がある
• コードを書くこと自体が苦痛になっている
• 慢性的な疲労感・不眠がある

健康面で問題がある場合は、退職だけでなく産業医への相談や休職も選択肢に入れてください。労働安全衛生法第66条の8により、長時間労働者は医師の面接指導を受けることができます。

退職届の書き方

レガシーコードの保守が退職理由であっても、退職届には「一身上の都合」と記載するのが一般的です。

退職届に具体的な不満は書かない

退職届はあくまで退職の意思表示をする公式文書です。技術的負債への不満や会社への批判は記載しません。

• ○: 「一身上の都合により」
• x: 「技術的負債の解消に取り組まない会社方針により」

退職面談・1on1での伝え方

退職理由を聞かれた場合は、前向きな表現を使いましょう。

• 「新しい技術領域にチャレンジしたい」
• 「キャリアの方向性を見直したい」
• 「違う環境で自分の力を試したい」

会社批判は避けるのが円満退職のポイントです。転職後も業界内で再会する可能性があります。

転職活動で注意すべきこと

在職中の転職活動のポイント

• 面接ではレガシーコード保守の経験をポジティブに伝える（大規模システムの安定運用経験）
• 個人開発やOSS活動でモダン技術のスキルを証明する
• 転職先がレガシーコードを抱えていないか事前に確認する（技術スタックの質問は面接で必ず行う）

競業避止義務の確認

転職先が同業他社の場合、雇用契約書の競業避止条項を確認してください。ただし、過度に広範な競業避止義務は公序良俗違反として無効とされる裁判例があります（東京地裁平成24年1月13日判決など）。