エンジニアの皆さん、こんにちは。
コードを書いている時、「この警告、直す価値はあるのか？」「チーム全体でコードの品質は向上しているのか？」と立ち止まったことはありませんか？
ESLintをただ「赤線を消すためだけのツール」だと思っているなら、それは宝の持ち腐れです。今回は、ESLintの真の価値である「データの可視化」に焦点を当て、あなたのチームの技術的負債を「数値」として捉え、CI/CDパイプラインを「品質管理ダッシュボード」へと昇華させる戦略を伝授します。
—
1. なぜ「JSON出力」なのか？：静的解析のパラダイムシフト
通常、私たちはターミナルに流れるESLintの結果を眺めて一喜一憂します。しかし、これは「今」のバグにしか反応できない「対症療法」です。
ESLintの `–format json` オプションを使うと、解析結果が構造化データ（JSON）として吐き出されます。これこそが、「品質の時系列解析」への扉です。
- 推移の可視化: 警告数が週単位で増えているのか、減っているのか。
- ボトルネックの特定: どのファイル、あるいはどのルールが最も開発速度を削いでいるのか。
- 自動化された品質ゲート: 特定の閾値を超えたらCIを落とすだけでなく、Slackに「今週は警告が10件増えました」と通知する。
これをマスターすれば、あなたのチームは「感覚」ではなく「事実」に基づいてコード品質をコントロールできるようになります。
—
2. 実践：JSON出力を活用したパイプラインの構築
まずは、開発環境でESLintのJSON出力を確認しましょう。以下のコマンドを実行してください。
–format json で結果をファイルに出力する
–output-file で指定した場所にJSONを保存する
npx eslint . –format json –output-file lint-report.json
この `lint-report.json` には、どのファイルで、どのルールが、何行目に違反しているかが配列で収められています。これが、CIツールが読み解く「設計図」になります。
CIパイプラインへの統合（GitHub Actionsの例）
CI上で結果を保存し、それを分析ツールに渡すワークフローの雛形です。
.github/workflows/lint-check.yml
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Dependencies
run: npm ci
- name: Run ESLint with JSON output
# 失敗しても後続のステップで結果を分析したいので、|| true で終了ステータスを制御する
run: npx eslint . –format json –output-file lint-report.json || true
- name: Upload Report
# このJSONをアーティファクトとして保存し、後続のダッシュボード作成プロセスへ渡す
uses: actions/upload-artifact@v3
with:
name: eslint-report
path: lint-report.json
—
3. 「現場で震えるほど役立つ」データ解析の考え方
JSONを取得したら、次は解析です。私はよく、このJSONをスクリプトで集計し、「警告ルール別のランキング」を生成しています。
例えば、`no-unused-vars`（使われていない変数）が圧倒的に多いなら、「型定義を見直すべき」という戦略的判断ができますし、`complexity`（循環的複雑度）が高いなら「設計の刷新時期」というサインになります。
簡単な解析スクリプト（Node.js）
// analyze-lint.js
const fs = require(‘fs’);
const report = JSON.parse(fs.readFileSync(‘lint-report.json’, ‘utf8’));
// ルールごとの違反数をカウントする
const stats = report.reduce((acc, file) => {
file.messages.forEach(msg => {
acc[msg.ruleId] = (acc[msg.ruleId] || 0) + 1;
});
return acc;
}, {});
console.table(stats); // ターミナルに美しい表として出力
—
4. チームの文化を変える「品質ダッシュボード」
このデータを「Grafana」や「QuickSight」などのBIツールに流し込むと、驚くような変化が起きます。
1. 視覚的な達成感: 「警告数が減っている」というグラフは、コードレビューよりも強力なモチベーションになります。
2. 経営層への説明責任: 「なぜリファクタリングの時間が必要なのか？」という問いに対し、「品質グラフがレッドゾーンに達しているため」と、即座に根拠を提示できるようになります。
最後に：自動化は手段であり、目的ではない
ESLintとPrettierの導入、そしてJSON解析による可視化。これらはすべて、「コードレビューという人間同士の対話を、より建設的な議論にするため」にあります。
些細な構文の指摘はツールに任せ、人間は「この設計でビジネスの要件を満たせるか？」という高い視座の議論に時間を割く。これこそが、アーキテクトが目指すべき理想の開発環境です。
今日から、あなたのコードを「静的な文字列」としてではなく、「解析可能な資産」として扱ってみてください。その先に、これまでとは全く違うレベルの開発体験が待っています。
何か詰まったら、いつでも聞いてくださいね。あなたのエンジニアリングを全力でサポートします。