こんにちは。現場で戦うエンジニアの皆さん、あるいはこれから最前線を目指す皆さん。
「コードの品質を担保する」と聞くと、多くの人が「面倒な作業」や「人間がやらなきゃいけないチェック」を想像します。しかし、一流の現場では違います。「品質チェックは、人間が意識せずとも、自動的に、かつ強制的に行われるもの」であり、それこそが開発速度を最大化する秘訣です。
今日は、ESLintとPrettierをGitHub Actionsと組み合わせ、あなたのリポジトリを「自動で品質が保たれる聖域」に変えるための、本質的な話をしましょう。
—
1. なぜ「手動チェック」が開発を殺すのか
まず、役割の再定義をしましょう。
- ESLint: コードの「論理的なミス」や「アンチパターン」を排除するガードマン。
- Prettier: コードの「見た目」を統一し、議論を無意味にする秘書。
これらを個人のPCで実行するだけでは不十分です。「動けばいい」という甘えや、設定を忘れた同僚のコードが混入した瞬間に、品質の防波堤は崩壊します。CI/CDでGitHub Actionsを導入するのは、「守れないルールは存在しないのと同じ」という現実を突きつけるためです。
—
2. 実践：最強のCIパイプラインを構築する
単にコマンドを叩くだけでは、CIはすぐに「遅い」と見捨てられます。キャッシュを活用し、無駄な処理を徹底的に排除した設定を見ていきましょう。
GitHub Actionsの構築（`.github/workflows/lint.yml`）
name: Quality Gate # パイプラインの名称
on:
pull_request: # プルリクエスト作成時のみ発火させることで、無駄なCIコストを削減
branches: [main]
jobs:
lint-and-format:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4 # リポジトリのクローン
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’ # ここが重要：npmの依存関係をキャッシュし、インストールを爆速化
- name: Install dependencies
run: npm ci # npm installではなくciを使う。lockファイル通りの依存関係を生成し、再現性を保証する
- name: Run Lint & Format Check
run: |
# Prettierのチェック：フォーマットが崩れていればエラーを吐く
npx prettier –check .
# ESLintの実行：ルール違反があれば即座にパイプラインを停止
npx eslint . –max-warnings 0
—
3. なぜこの設定が「現場」で評価されるのか
1. `npm ci` の絶対性
`npm install` はパッケージを更新する可能性がありますが、`npm ci` は `package-lock.json` に完全に準拠します。CI環境で「ローカルでは動いたのに！」という悲劇を防ぐための必須コマンドです。
2. `–max-warnings 0` の哲学
ESLintはデフォルトで警告（Warning）を出しますが、放置すると警告は肥大化します。`–max-warnings 0` を指定することで、些細な警告すらも「エラー」として扱い、技術的負債の蓄積を物理的に防ぎます。
3. キャッシュ戦略の賢明さ
GitHub Actionsの `cache: ‘npm’` を有効にすることで、node_modulesの再インストール時間を数分から数秒へ短縮できます。開発体験（DX）を損なわないことが、チームにツールを定着させる最大のコツです。
—
4. 導入後の「HelloWorld」的動作確認
設定が終わったら、あえてルールを破ったコードをコミットして、プルリクエストを送ってみてください。
1. わざとPrettierのルールを破る: インデントを適当に崩したり、ダブルクォートをシングルに変えたりする。
2. わざとESLintのルールを破る: 未使用の変数（`const x = 1;` と書くだけで使わないなど）を宣言する。
結果:
GitHubのプルリクエスト画面で、ステータスチェックが「×（失敗）」になりますよね？ これこそが、「あなたの代わりにツールが品質を監視してくれている」という、最強の安心感です。
—
最後に：ツールに支配されるな、ツールを使い倒せ
この仕組みを導入すれば、レビューの現場から「ここ、インデントずれてますよ」「この変数使ってませんよ」という、人間がやる必要のない低レベルな指摘が消滅します。
レビューで議論すべきは「コードの書き方」ではなく、「ビジネスロジックの妥当性」や「設計の美しさ」です。機械に任せられることは機械に任せ、あなたはあなたにしかできない「人間らしい創造的な判断」に集中してください。
この設定をマスターすれば、あなたのコードはGitHub上で常に磨かれ、チームの誰が触っても清潔な状態が保たれます。さあ、今すぐパイプラインを走らせて、開発環境を一段上のレベルへ引き上げましょう。
応援していますよ。