ESLintを「ただの警告表示器」で終わらせるな：CIパイプラインを「品質改善ダッシュボード」に変える技術
多くの開発現場において、ESLintとPrettierは「保存時にコードを整形し、警告を表示してくれる便利ツール」として導入されています。しかし、テックリードの視点から言えば、それは氷山の一角に過ぎません。
ESLintの真価は、単なるLint結果の表示ではなく、`–format json`で出力される構造化データにあります。このデータを解析し、パイプラインに組み込むことで、チームのコード品質は「感覚」から「定量的指標」へと昇華されます。
本稿では、Lint結果を可視化し、技術的負債の蓄積を可視化する「攻めの品質管理」の極意を伝授します。
—
1. なぜ「JSON出力」なのか：データの透明性が生む生産性
標準のコンソール出力は人間の目には優しいですが、機械にとってはただのテキストです。JSONフォーマットを指定することで、Lint結果は「解析可能なデータセット」に変換されます。
JSONで出力し、ファイルに保存するコマンド
npx eslint . –format json –output-file ./lint-results.json
このファイルを活用すれば、以下のような「現場が震える」自動化が可能になります。
- 技術的負債の経年変化の可視化: 過去のデータと比較し、警告数が減っているか増えているかをグラフ化する。
- 「警告の温床」の特定: 特定のディレクトリやファイルに警告が集中していないかを検知し、リファクタリング対象を自動抽出する。
- PRへのスマートな通知: 全ての警告を出すのではなく、「今回修正した箇所」に紐付く警告のみをGitHubのコメントで指摘する（ノイズの低減）。
—
2. 現場で導入すべきベストプラクティス構成
設定ファイルは、複雑になればなるほど「魔法の箱」と化して誰も触れなくなります。「ルールは分離し、拡張は明示する」のが鉄則です。
.eslintrc.json の構成案
eslint-config-airbnb や plugin:import をベースにしつつ、チーム独自のルールを明確に分離します。
{
“extends”: [
“airbnb-base”, // 基本的なAirbnbスタイル
“plugin:@typescript-eslint/recommended”, // TS対応
“plugin:prettier/recommended” // Prettierとの競合を完全に排除する
],
“rules”: {
// チームの設計思想に反するルールはここで個別に制御
“no-console”: [“warn”, { “allow”: [“warn”, “error”] }],
“@typescript-eslint/explicit-function-return-type”: “error”
},
“settings”: {
“import/resolver”: {
“typescript”: {} // エイリアス解決に必須
}
}
}
—
3. CIでLint結果を「ダッシュボード化」するパイプライン設計
GitHub Actions上で実行し、結果をJSONから集計して「品質スコア」を算出するワークフローの例です。
jobs:
lint-analyze:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run ESLint
run: npx eslint . –format json –output-file lint-report.json || true
- name: Analyze Results
run: |
# jqを使用して警告総数とエラー総数を集計
TOTAL_ERRORS=$(cat lint-report.json | jq ‘[.[].messages[].severity] | map(select(.==2)) | length’)
echo “現在の技術的負債（エラー数）: $TOTAL_ERRORS”
# ここでAPIを叩いてダッシュボードやSlackに通知
—
4. 開発体験を極限まで引き上げる「神設定」と「隠し技」
VS Code 拡張機能の「絶対設定」
`settings.json`に以下を追加するだけで、チーム全員の開発スピードが底上げされます。
{
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: true // 保存時に自動修正を強制
},
“eslint.validate”: [“javascript”, “typescript”],
“eslint.workingDirectories”: [{ “mode”: “auto” }] // モノレポ構造でもルートを自動認識
}
必修キーボードショートカット
- `Cmd + .` (Mac) / `Ctrl + .` (Win): 「Quick Fix」はLintエラーを解決するための最速経路です。わざわざマウスで警告に合わせる必要はありません。
- `F8`: エラーからエラーへジャンプする。マウスを使わずにファイル内の全Lintエラーを解消するフローを身体に染み込ませてください。
—
5. テックリードとしての提言：なぜツールを「管理」するのか
Lintは、「コードを綺麗にするための道具」ではありません。「コードの品質に対するチームの合意形成を自動化する仕組み」です。
JSON出力を活用してダッシュボードを作ることは、単なる数値遊びではなく、「何が原因で開発が遅れているのか」を可視化する経営判断の材料を手に入れる行為です。警告の数が増えればリファクタリングの時間を確保する根拠になり、ルール違反が多ければペアプロの必要性を説く根拠になります。
ツールに動かされるのではなく、ツールを「チームの武器」として使いこなしてください。今日から、`–format json`をCIに組み込み、開発の進捗だけでなく「品質の進捗」を語れるチームを目指しましょう。それが、圧倒的な生産性を誇る開発組織への最短距離です。