技術的負債を「自動消滅」させる：ESLintカスタムルールによるレガシーAPI撲滅戦略
大規模なフロントエンド開発において、最も生産性を阻害するのは「仕様変更」そのものではなく、「過去の遺産（レガシーな実装）」への対処です。新メンバーが既存コードを参考に古いAPIを使い、それをレビューで指摘し、修正させる……この「負のループ」に工数を溶かすのは、テックリードとして最も避けるべき事態です。
本稿では、ESLintを単なる構文チェッカーとしてではなく、「チームの技術的ガードレール」として機能させるための、一歩踏み込んだカスタム戦略を伝授します。
—
1. なぜ「設定」ではなく「ルール」で戦うのか
多くのチームが `no-restricted-imports` を使っていますが、多くの場合「なんとなく」禁止しているに留まります。真のアーキテクトは、「なぜそのAPIが禁止なのか」という文脈を開発プロセスに組み込みます。
ASTを読み解く：no-restricted-syntax の真価
単なるパッケージ禁止を超え、特定のメソッド呼び出しやプロパティアクセスをピンポイントで潰すには `no-restricted-syntax` を使います。これには「ESTree」の構造理解が必要です。
例えば、Reactの `componentWillMount` を完全に追放する場合、単なる禁止ではなく「ESLintルール自体を動的に注入する」アプローチを取ります。
// .eslintrc.json
{
“rules”: {
“no-restricted-syntax”: [
“error”,
{
“selector”: “MemberExpression[property.name=’componentWillMount’]”,
“message”: “componentWillMountは非推奨です。useEffectへの移行をお願いします。詳細は社内Wiki(内部リンク)を参照。”
}
]
}
}
この設定の肝は、`message` に「なぜダメなのか」「どう修正すべきか」を明記することです。IDE（VS Codeなど）でホバーした際にこのメッセージが出るだけで、ジュニアエンジニアはレビューを待たずに自己解決が可能になります。
—
2. チーム開発を加速させる「設定共有」の神髄
個人の `.eslintrc` を各々が管理するのは、崩壊の始まりです。設定は必ず `eslint-config-custom` のようなモノレポ内のパッケージとして切り出し、npm/yarnのワークスペース経由で配布してください。
構成のベストプラクティス
`package.json` で `main` を指定し、設定をNode.jsモジュールとして読み込ませます。
// packages/eslint-config-custom/index.js
module.exports = {
extends: [“eslint:recommended”, “plugin:@typescript-eslint/recommended”],
rules: {
// チーム共通の「絶対ルール」をここに集約
“no-console”: “warn”,
“@typescript-eslint/no-explicit-any”: “error”
},
overrides: [
{
// 特定のディレクトリだけルールを厳格化する
“files”: [“/features/auth//.ts”],
“rules”: { “no-restricted-imports”: [“error”, { “paths”: [“…”] }] }
}
]
};
これにより、ルール変更が必要な際は1箇所の変更が全プロジェクトに波及します。「ルール変更のコスト」を極限まで下げることこそが、技術スタックを最新に保つ唯一の鍵です。
—
3. 生産性を極限まで高める「神プラグイン」とツールチェーン
ESLintとPrettierの統合は、既に前提条件です。しかし、そこからもう一歩進んだ「開発体験」を構築します。
必須プラグイン
- eslint-plugin-import: 循環参照の検知。大規模プロジェクトの依存関係爆発を防ぐ防波堤です。
- eslint-plugin-unused-imports: 未使用のインポートを自動削除。`no-unused-vars` のイライラを解消します。
- lint-staged: Gitのコミットフックで「変更したファイルだけ」を高速検査。CI/CDの時間を劇的に短縮します。
現場で震えるほど役立つ「lint-staged」設定
`package.json` に記述するこの設定は、開発効率の要です。
“lint-staged”: {
“.{js,ts,tsx}”: [
“eslint –fix”,
“prettier –write”
]
}
なぜこれが重要か？
CI環境で全ファイルをチェックすると数分かかりますが、これなら「今作業している数ファイル」だけが数秒でクリーンアップされます。「開発者は、コードを書いている最中にフィードバックを得るべき」という原則を体現する構成です。
—
4. チームへの導入・定着の極意
どんなに優れたルールを作っても、チームに「強制」だけでは反発を生みます。
1. 「猶予期間」を設ける: 新しいルールを追加する際は、一度 `”warn”` としてリリースし、チーム全体に認知させます。翌週に `”error”` に昇格させることで、突発的なビルド失敗による混乱を防ぎます。
2. 自動修正を徹底する: `eslint –fix` で直せるものは全てルールに組み込みます。人間が手作業でコードを整形するのは、コンピュータに対する最大の冒涜です。
3. CIでの「警告」を可視化する: CIの結果をSlack通知し、誰が・どのファイルで・どんなルール違反を犯したかを見える化します。これは責めるためではなく、「何がチームのボトルネックになっているか」を分析するためのデータです。
—
最後に：負債を溜めないチームの条件
ESLintのカスタムルールを使いこなすことは、単なるコードの品質向上ではありません。それは、「チームの集合知をコードベースに刻み込む」という行為です。
「このAPIは使うな」というテックリードの口頭注意は、一週間後には忘れ去られます。しかし、ESLintのエラーメッセージとして記述されたルールは、半年後の新入社員にも同じ熱量で「なぜそうすべきか」を語りかけます。
この環境構築にかけた時間は、数ヶ月後の「レガシーの墓場」を整理するための数週間の残業を、ゼロへと変換する投資です。さあ、今すぐあなたのプロジェクトの `eslintrc` を開き、チームを縛るのではなく、「チームが迷わず最速で走れる道」を設計してください。