「古いコード」がチームの足枷になる前に。ESLintカスタムルールで技術的負債を自動防衛する技術
こんにちは。開発環境アーキテクトとして、これまで数多くの大規模プロジェクトを渡り歩いてきましたが、プロジェクトが長期化するにつれて必ず直面する「悪夢」があります。それは、「昔書かれた非推奨APIが、コードベースのあちこちに生き残り続け、誰も消せなくなる現象」です。
新しく入ったメンバーが古い実装をコピペし、負債が雪だるま式に増えていく……。これを人力のコードレビューだけで防ごうとするのは、もはや不可能です。
今回は、ESLintの「静的解析」という強力な武器を使い、チームの技術スタック更新を強制し、負債を自動的に追放する「門番」の作り方を伝授します。これをマスターすれば、あなたのチームは「過去のしがらみ」から解放され、常に最新のベストプラクティスで戦えるようになります。
—
1. なぜ「設定」でコードを強制する必要があるのか？
多くのチームが「コード規約」というドキュメントを作りますが、残念ながら誰も読みません。エンジニアは「動くコード」を書くことに集中しているからです。
私たちがやるべきは、ドキュメントを書くことではありません。「間違ったコードを書いた瞬間に、エディタ上で赤波線を出して止める」こと。これが最強の教育であり、最強の負債管理です。ESLintは単なるスタイルチェッカーではなく、チームの「規律を自動化するエンジン」なのです。
—
2. 実践：非推奨パッケージを追放する（no-restricted-imports）
まずは最も手軽で強力な `no-restricted-imports` を使って、古いライブラリの使用を禁止します。例えば、`moment.js` を禁止し、`date-fns` への移行を強制したい場合を考えましょう。
`.eslintrc.json` を開き、以下の設定を追加してください。
{
“rules”: {
// 特定のパッケージのインポートを物理的に禁止する
“no-restricted-imports”: [
“error”,
{
“paths”: [
{
“name”: “moment”,
“message”: “moment.jsは非推奨です。軽量なdate-fnsまたはdayjsを使用してください。”
}
]
}
]
}
}
ここがポイント:
単にエラーを出すだけでなく、`message` を入れるのが重要です。開発者は「なぜダメなのか」を一瞬で理解でき、次に何をすべきかの指針（date-fnsを使う、など）を提示されることで、学習コストを最小化できます。
—
3. 応用：特定の「構文」そのものを禁止する（no-restricted-syntax）
ライブラリのインポートだけでなく、特定の関数呼び出しや古い書き方（例：`new Date()` の直書き禁止など）を制限したい場合は `no-restricted-syntax` を使います。これはESLintがコードを解析する際に生成する「AST（抽象構文木）」を直接指定する高度な手法です。
例えば、「`alert()` を絶対に使わせない」というルールを作る場合：
{
“rules”: {
“no-restricted-syntax”: [
“error”,
{
“selector”: “CallExpression[callee.name=’alert’]”,
“message”: “デバッグ用のalertは禁止です。console.logを使用するか、適切なUIコンポーネントを導入してください。”
}
]
}
}
解説:
`selector` には「ASTクエリ」という言語を使っています。これは「関数呼び出し（CallExpression）の中で、名前がalertであるもの」という条件を抽出しています。この手法を覚えれば、プロジェクト固有の「やってはいけない実装パターン」を自由自在に禁止できます。
—
4. チームへの導入とCI連携のベストプラクティス
ローカルで警告を出すだけでは不十分です。CI/CDパイプライン（GitHub Actionsなど）で、このルールを強制しましょう。
.github/workflows/lint.yml の一例
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Dependencies
run: npm ci
- name: Run ESLint
# 警告をエラーとして扱い、ビルドを強制終了させる
run: npx eslint . –max-warnings 0
`–max-warnings 0` を付与するのが、アーキテクトのこだわりです。警告すら許さない。この厳格さが、チームの規律を維持し、結果として「レビューでの指摘事項」を劇的に減らします。
—
終わりに：ツールに任せて、エンジニアは「思考」に集中しよう
今回紹介した手法は、最初は少し手間がかかるように感じるかもしれません。しかし、一度設定してしまえば、「古いコードをレビュアーが指摘する」という、非常に生産性の低い精神的コストからあなたを解放します。
「ルールを強制する」ことは「仲間を縛る」ことではありません。むしろ、「誰もが常に最新の技術スタックを選択できる安全な環境を作ること」であり、それこそがチームが長期的に成長し続けるための鍵です。
皆さんの開発環境が、より知的で、よりクリーンな場所になることを心から願っています。何か詰まったら、いつでもASTの構造を覗いてみてください。そこには、コードの本質を理解するための新しい世界が広がっていますよ。