エンジニアの皆さん、こんにちは。日々のコードレビューで「セミコロンを付けるか否か」の些細な指摘に時間を溶かしていませんか？
伝説的なプロジェクトは、常に「本質的な課題」に集中しています。ソースコードの美学やスタイルの議論に脳のリソースを割くのは、今日で終わりにしましょう。今回は、ESLintとPrettierという「最強の守護神」を使い、チームの心理的安全性を最大化するための極意を伝授します。
—
1. なぜ「セミコロン論争」がチームを破壊するのか
技術的な議論には「正解」がありますが、フォーマットには「合意」しかありません。
セミコロンの有無（`semi: true` or `false`）そのものに、プログラムの実行効率上の差はほぼありません。しかし、「自分たちの書いたコードが、誰のチェックも通らずにメインブランチにマージされる」という状態は、チームの無秩序化の始まりです。
フォーマット設定がバラバラなチームでは、コードレビューのたびに「セミコロンがない」「クォートが統一されていない」といった、機械がやるべき指摘にエンジニアの貴重な時間が奪われます。これはモチベーションを削ぐだけでなく、コードの差分（Git Diff）を無意味に巨大化させ、バグの温床を作ります。
「フォーマットを機械に任せ、人間はロジックの改善に集中する」。これこそが、開発効率を極限まで引き上げるための第一歩です。
—
2. 導入：守護神を召喚する
まずは、モダンな環境におけるESLintとPrettierの鉄板構成を構築します。
インストールとセットアップ
まずはプロジェクトのルートで以下のコマンドを叩いてください。必要なパッケージを一気にインストールします。
Prettier本体と、ESLintとの競合を防ぐための設定を追加
npm install –save-dev prettier eslint-config-prettier eslint-plugin-prettier
- `prettier`: コード整形エンジンそのもの。
- `eslint-config-prettier`: ESLintのルールとPrettierのルールが衝突した際、Prettierを優先させるための「防波堤」。
- `eslint-plugin-prettier`: Prettierのフォーマット結果をESLintのルールとして実行し、エディタ上でエラーとして可視化する橋渡し役。
—
3. 「絶対揉めない」ための設定ファイル構成
設定ファイルを単なる「呪文」と思わないでください。これは「チームの規約をコード化したもの」です。
.prettierrc（フォーマットのルール）
{
“semi”: true, // セミコロンは付ける派（JavaやC#経験者が多いチームはこれが安牌）
“singleQuote”: true, // ダブルクォートよりシングルを優先
“tabWidth”: 2, // インデントは2スペース
“trailingComma”: “all” // 末尾のカンマはすべて付ける（Git差分を最小化するため）
}
.eslintrc.js（ESLintとの統合）
module.exports = {
extends: [
‘eslint:recommended’,
‘plugin:prettier/recommended’ // ここでPrettierの設定をESLintに統合
],
rules: {
// チームでどうしても譲れない独自のルールがあればここに追記
‘no-console’: ‘warn’
}
};
なぜ `trailingComma: “all”` なのか？
これはチーム開発における「Git差分」の魔法です。新しい要素を追加した際、末尾にカンマを付けておけば、前の行を変更せずに済みます。結果として、`git blame`で追った時に「どのコミットが変更したのか」が明確になり、コンフリクトの確率が劇的に下がります。
—
4. 精度高い「HelloWorld」的動作確認
設定が終わったら、正しく機能しているか確認しましょう。わざと汚いコードを書くのがコツです。
1. `test.js` というファイルを作成し、以下の「あえて汚いコード」を貼り付けてください。
const name=”World”
console.log(`Hello ${name}`)
2. VS Codeで保存（`Ctrl+S` / `Cmd+S`）した瞬間、あるいは以下のコマンドを実行してみてください。
npx prettier –write test.js
3. 魔法の瞬間： コードが以下のように整えば成功です。
const name = ‘World’;
console.log(`Hello ${name}`);
もしこれで自動修正されなければ、VS Codeの「Format on Save（保存時に整形）」設定がオフになっている可能性があります。「人間がフォーマットを気にする時間はゼロにする」。これが、最強のチームの鉄則です。
—
5. 伝説のDevOpsリードから、最後のアドバイス
チームの合意形成において重要なのは、「どちらが正しいか」を議論することではありません。「どちらを選択しても、機械が自動で統一してくれるから、議論するコストが掛からない」という状況を作ることです。
一度ルールを決めたら、`.prettierrc` をコミットして、全員の環境で強制適用してください。もし誰かが「セミコロンなしが良い！」と言い出したら、こう伝えてください。
「その議論のコストを払うより、全員でこの設定を使って開発速度を10%上げる方が、僕たちのキャリアにとって遥かに価値があると思わないか？」
技術は手段です。最も重要なのは、あなたがコードを書くときに「脳のメモリ」を空けておくことです。今日から、セミコロンのことはPrettierに任せて、あなたはもっとクリエイティブな課題に挑戦してください。
それでは、素晴らしい開発ライフを！