コードの品質を向上させたい。その一心で ESLint の厳格なルールを導入したものの、実際の開発現場では予想外の問題が次々と発生する。厳格すぎるルールが開発効率を下げ、チームメンバーとの軋轢を生み出すこともある。

この記事では、ESLint の厳格ルール運用で陥りがちな落とし穴と、現実的な運用方法について詳しく解説する。理想と現実のバランスを取りながら、チーム全体が納得できる ESLint 設定を構築する方法を学んでいこう。

ESLint 厳格ルールの魅力と現実

ESLint の厳格なルール設定は、確かに魅力的に見える。eslint:recommendedや@typescript-eslint​/​recommendedなどの推奨設定に加えて、追加のルールを適用することで、より高品質なコードを書けるようになる。

javascriptCopy code// .eslintrc.js - 厳格な設定例
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
    '@typescript-eslint/recommended-requiring-type-checking',
    'plugin:prettier/recommended',
  ],
  rules: {
    // 厳格なルールを追加
    '@typescript-eslint/no-explicit-any': 'error',
    '@typescript-eslint/no-unused-vars': 'error',
    '@typescript-eslint/explicit-function-return-type':
      'error',
    '@typescript-eslint/no-non-null-assertion': 'error',
    'prefer-const': 'error',
    'no-var': 'error',
  },
};

しかし、この厳格な設定を導入した瞬間から、現実の壁にぶつかることになる。既存のコードベースには大量のエラーが発生し、新機能の開発よりも既存コードの修正に時間を取られるようになる。

実際に発生するエラーの例を見てみよう：

bashCopy code# ESLint実行時のエラー例
$ yarn lint

/path/to/component.tsx
  15:10  error  '@typescript-eslint/no-explicit-any' Unexpected any. Specify a different type
  23:5   error  '@typescript-eslint/no-unused-vars' 'unusedVariable' is defined but never used
  45:12  error  '@typescript-eslint/explicit-function-return-type' Missing return type annotation
  67:8   error  '@typescript-eslint/no-non-null-assertion' Forbidden non-null assertion

✖ 4 problems (4 errors, 0 warnings)

このようなエラーが数百、数千件発生すると、開発者は途方に暮れてしまう。

厳格すぎるルールが引き起こす問題

厳格すぎる ESLint ルールは、開発現場に様々な問題を引き起こす。最も深刻なのは、開発効率の大幅な低下だ。

開発速度の低下

新機能の実装よりも、既存コードの修正に時間を取られるようになる。特に、以下のようなエラーが頻発する：

typescriptCopy code// よくあるエラー例1: any型の使用
function processData(data: any) {
  // ❌ any型は禁止
  return data.map((item) => item.value);
}

// 修正後
interface DataItem {
  value: string;
}

function processData(data: DataItem[]): string[] {
  // ✅ 型を明示
  return data.map((item) => item.value);
}

typescriptCopy code// よくあるエラー例2: 未使用変数
const unusedVariable = 'test'; // ❌ 未使用変数
const usedVariable = 'hello';
console.log(usedVariable);

// 修正後
const usedVariable = 'hello';
console.log(usedVariable);

チームメンバーのストレス増大

厳格すぎるルールは、特に経験の浅い開発者にとって大きなストレスになる。コードを書くたびにエラーが出て、本来の開発に集中できない状況が続く。

bashCopy code# 開発者の心理的負担を示すエラー例
$ yarn lint

src/components/UserProfile.tsx
  12:15  error  '@typescript-eslint/no-explicit-any' Unexpected any. Specify a different type
  18:7   error  '@typescript-eslint/no-unused-vars' 'temp' is defined but never used
  25:10  error  '@typescript-eslint/explicit-function-return-type' Missing return type annotation
  34:5   error  '@typescript-eslint/no-non-null-assertion' Forbidden non-null assertion
  41:8   error  'prefer-const' 'let' is preferred to be 'const'
  47:12  error  '@typescript-eslint/no-var' Unexpected var, use let or const instead

✖ 6 problems (6 errors, 0 warnings)

このような状況が続くと、開発者は「コードを書くのが怖い」という心理状態に陥ってしまう。

チーム開発での落とし穴

チーム開発において、厳格すぎる ESLint ルールは特に深刻な問題を引き起こす。

コードレビューの質の低下

厳格なルールにより、レビュアーは ESLint エラーの修正に集中し、本来チェックすべきロジックや設計の観点がおろそかになる。

typescriptCopy code// レビュー時に見落としがちな問題例
function calculateDiscount(
  price: number,
  discountRate: number
): number {
  // ロジックエラー: 割引率が100%を超える場合の処理がない
  return price * (1 - discountRate); // ❌ 設計上の問題
}

// 修正後
function calculateDiscount(
  price: number,
  discountRate: number
): number {
  const clampedRate = Math.max(
    0,
    Math.min(1, discountRate)
  ); // ✅ 範囲チェック
  return price * (1 - clampedRate);
}

チーム内での意見対立

厳格なルールの導入は、チーム内で意見の対立を生むことがある。経験豊富な開発者は厳格なルールを好むが、経験の浅い開発者は苦戦する。

javascriptCopy code// チーム内で意見が分かれる設定例
// .eslintrc.js
module.exports = {
  rules: {
    // 上級者向けの厳格ルール
    '@typescript-eslint/no-explicit-any': 'error',
    '@typescript-eslint/explicit-function-return-type':
      'error',

    // 初心者には厳しすぎる可能性
    '@typescript-eslint/no-non-null-assertion': 'error',
    '@typescript-eslint/prefer-nullish-coalescing': 'error',
  },
};

プロジェクト進行の遅延

厳格なルールにより、リリース予定の機能が遅れることがある。特に、既存の大きなコードベースに厳格なルールを適用する場合、修正作業に膨大な時間がかかる。

現実的な ESLint 運用のベストプラクティス

厳格すぎるルールの問題を避けながら、コード品質を向上させる現実的なアプローチを紹介する。

段階的なルール導入

一度にすべての厳格ルールを適用するのではなく、段階的に導入することが重要だ。

javascriptCopy code// 段階的導入の設定例
// .eslintrc.js - Phase 1: 基本的なルール
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
  ],
  rules: {
    // 最初は基本的なルールのみ
    'no-console': 'warn',
    'no-debugger': 'error',
    'prefer-const': 'warn',
  },
};

javascriptCopy code// .eslintrc.js - Phase 2: 中級ルール
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
  ],
  rules: {
    // 基本的なルール
    'no-console': 'warn',
    'no-debugger': 'error',
    'prefer-const': 'error',

    // 中級ルールを追加
    '@typescript-eslint/no-unused-vars': 'error',
    '@typescript-eslint/no-explicit-any': 'warn',
  },
};

プロジェクトの状況に応じた設定

新規プロジェクトと既存プロジェクトでは、異なるアプローチが必要だ。

javascriptCopy code// 新規プロジェクト用の設定
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
    '@typescript-eslint/recommended-requiring-type-checking',
  ],
  rules: {
    // 新規プロジェクトでは厳格なルールを適用可能
    '@typescript-eslint/no-explicit-any': 'error',
    '@typescript-eslint/explicit-function-return-type':
      'error',
    '@typescript-eslint/no-non-null-assertion': 'error',
  },
};

javascriptCopy code// 既存プロジェクト用の設定
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
  ],
  rules: {
    // 既存コードへの影響を最小限に
    '@typescript-eslint/no-explicit-any': 'warn',
    '@typescript-eslint/explicit-function-return-type':
      'off',
    '@typescript-eslint/no-non-null-assertion': 'warn',
  },
};

チーム合意の形成

ESLint ルールの設定は、チーム全体で合意を形成することが重要だ。

javascriptCopy code// チーム投票で決めた設定例
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
  ],
  rules: {
    // チーム全員が同意したルール
    'no-console': 'warn',
    'no-debugger': 'error',
    'prefer-const': 'error',

    // 議論の結果、警告レベルにしたルール
    '@typescript-eslint/no-explicit-any': 'warn',
    '@typescript-eslint/no-unused-vars': 'warn',
  },
};

段階的なルール導入戦略

効果的な ESLint 運用のためには、段階的な導入戦略が不可欠だ。

Phase 1: 基本的な品質向上

最初の段階では、最も基本的で効果的なルールから始める。

javascriptCopy code// Phase 1: 基本的なルール
// .eslintrc.js
module.exports = {
  extends: ['eslint:recommended'],
  rules: {
    // 即座に効果が現れるルール
    'no-console': 'warn',
    'no-debugger': 'error',
    'no-unused-vars': 'warn',
    'prefer-const': 'warn',
  },
};

この段階では、開発者に ESLint の存在を認識させ、基本的な品質向上を図る。

Phase 2: TypeScript 対応

TypeScript プロジェクトでは、型安全性の向上を目指す。

javascriptCopy code// Phase 2: TypeScript対応
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
  ],
  rules: {
    // 基本的なルール
    'no-console': 'warn',
    'no-debugger': 'error',
    'prefer-const': 'error',

    // TypeScript固有のルール
    '@typescript-eslint/no-unused-vars': 'error',
    '@typescript-eslint/no-explicit-any': 'warn',
  },
};

Phase 3: 高度な品質向上

チームが慣れてきたら、より高度なルールを導入する。

javascriptCopy code// Phase 3: 高度なルール
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
    '@typescript-eslint/recommended-requiring-type-checking',
  ],
  rules: {
    // 基本的なルール
    'no-console': 'warn',
    'no-debugger': 'error',
    'prefer-const': 'error',

    // TypeScriptルール
    '@typescript-eslint/no-unused-vars': 'error',
    '@typescript-eslint/no-explicit-any': 'error',

    // 高度なルール
    '@typescript-eslint/explicit-function-return-type':
      'warn',
    '@typescript-eslint/no-non-null-assertion': 'warn',
  },
};

プロジェクト別の設定例

プロジェクトの特性に応じて、適切な ESLint 設定を選択することが重要だ。

スタートアップ向け設定

迅速な開発が求められるスタートアップでは、厳格すぎるルールは避ける。

javascriptCopy code// スタートアップ向け設定
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
  ],
  rules: {
    // 開発速度を重視した設定
    'no-console': 'off', // デバッグ用に許可
    'no-debugger': 'error',
    'prefer-const': 'warn',
    '@typescript-eslint/no-explicit-any': 'warn',
    '@typescript-eslint/no-unused-vars': 'warn',
  },
};

エンタープライズ向け設定

大規模なエンタープライズプロジェクトでは、より厳格なルールが求められる。

javascriptCopy code// エンタープライズ向け設定
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
    '@typescript-eslint/recommended-requiring-type-checking',
  ],
  rules: {
    // 品質重視の設定
    'no-console': 'error',
    'no-debugger': 'error',
    'prefer-const': 'error',
    '@typescript-eslint/no-explicit-any': 'error',
    '@typescript-eslint/explicit-function-return-type':
      'error',
    '@typescript-eslint/no-non-null-assertion': 'error',
  },
};

オープンソース向け設定

オープンソースプロジェクトでは、コントリビューターの参加を促す設定が重要だ。

javascriptCopy code// オープンソース向け設定
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
  ],
  rules: {
    // コントリビューターに優しい設定
    'no-console': 'warn',
    'no-debugger': 'error',
    'prefer-const': 'warn',
    '@typescript-eslint/no-explicit-any': 'warn',
    '@typescript-eslint/no-unused-vars': 'warn',
  },
};

まとめ

ESLint の厳格なルール運用は、確かにコード品質の向上に寄与する。しかし、現実の開発現場では、厳格すぎるルールが開発効率の低下やチームメンバーのストレスを引き起こすことがある。

重要なのは、理想と現実のバランスを取ることだ。段階的なルール導入、チーム合意の形成、プロジェクト特性に応じた設定選択が、成功の鍵となる。

厳格なルールを一度に適用するのではなく、チームの成長に合わせて徐々にレベルアップしていくアプローチが、長期的な成功につながる。ESLint は開発を助けるツールであり、開発を阻害するものではないことを忘れないでほしい。

最終的に、チーム全体が納得し、継続的に運用できる ESLint 設定こそが、真に価値のある設定なのだ。

関連リンク

• ESLint 公式ドキュメント
• TypeScript ESLint
• ESLint 設定のベストプラクティス
• Prettier との連携