セミコロンの有無で議論する時間は0秒にせよ：Prettierによる「チームの心理的安全性」最大化戦略
開発現場で最も無駄なリソースの浪費、それは「コードのスタイル」に関する議論です。セミコロンを付けるか否か、シングルクォートかダブルクォートか。これらに費やされる時間は、ビジネス価値を一つも生まないどころか、チームの心理的安全性を確実に蝕みます。
私はこれまで数多くのプロジェクトを渡り歩いてきましたが、「コードフォーマットの自由度」を許容しているチームで、高い生産性を維持できている場所を見たことがありません。
今回は、ESLintとPrettierを単なる「ツール」としてではなく、チームの文化を強制し、開発スピードを極限まで引き上げる「インフラ」として運用するための戦略を伝授します。
—
1. なぜ「セミコロン論争」は地獄への入り口なのか
JavaScriptにおいて、セミコロンの有無はASI（Automatic Semicolon Insertion：自動セミコロン挿入）という仕様に依存します。技術的には「極めて稀なケースを除き、どちらでも動く」のが答えです。
しかし、人間は「自分の見慣れた形式」を正解だと直感し、他人のスタイルを「ノイズ」と認識します。この認識のズレが、PR（プルリクエスト）における「どうでもいい修正要求」を生み、レビュワーの集中力を削ぎ、投稿者のモチベーションを下げます。
「技術的最適解」ではなく「合意可能な規約」を強制すること。 これこそが、アーキテクトが担うべき最初の職務です。
—
2. チーム合意形成のための「フォーマット憲法」チェックリスト
議論を終わらせるために、以下の項目をチームの「憲法」として定義し、`.prettierrc`に固めてください。
- セミコロン (`semi`): 個人的には「なし」を推奨します。理由は、コードの視覚的ノイズが減り、ミニマルな現代的スタイルに合致するからです。しかし、チームが「あり」を好むなら即座にそれに従います。重要なのは「どちらか一つに決めること」です。
- クォート (`singleQuote`): JSXとの親和性を考えると、シングルクォートが優位です。
- 末尾のカンマ (`trailingComma`): `all` 一択です。Gitの差分（diff）を最小化し、不要な行変更を防ぐために必須です。
—
3. 実践的ベストプラクティス：`.prettierrc.json` の構成
設定は「思考を介在させない」レベルまで追い込みます。以下の構成が、最も衝突が少なく、かつ保守性が高いテンプレートです。
{
“semi”: false, // セミコロンを廃止し、行のノイズを低減
“singleQuote”: true, // 視認性の高いシングルクォートを採用
“trailingComma”: “all”, // 変更差分を最小化するため、全要素にカンマを付与
“arrowParens”: “always”, // 常に括弧を付け、型定義との一貫性を確保
“printWidth”: 80, // 80文字で折り返し。モニター分割時でも可読性を維持
“tabWidth”: 2, // インデントは2スペースで統一
“endOfLine”: “lf” // 改行コードはLFで統一（Windows/Macの差異を排除）
}
—
4. 開発効率を爆速にする「隠れた」テクニック
ツールを入れて終わりではありません。「無意識に整形される環境」を構築して初めて生産性が向上します。
① 「保存時自動整形」の強制（VS Code）
`.vscode/settings.json` をプロジェクト配下に置き、チーム全員の環境を強制的に統一します。
{
“editor.formatOnSave”: true, // 保存時にPrettierを自動実行
“editor.defaultFormatter”: “esbenp.prettier-vscode”, // 既定のフォーマッタをPrettierに
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit” // 保存時にESLintのルールも自動修正
}
}
② 神プラグイン：`eslint-plugin-prettier` の活用
PrettierとESLintが喧嘩しないようにする魔法のプラグインです。これを導入すると、Prettierで整形できないルール違反をESLintが検出し、逆にESLintのルールをPrettierが考慮して整形するという完璧な循環が生まれます。
必要な依存関係をインストール
npm install –save-dev eslint-plugin-prettier eslint-config-prettier
③ husky + lint-staged による「汚染防止」
どんなにルールを決めても、設定を忘れるメンバーは必ずいます。`git commit` の直前にチェックを強制しましょう。
// package.json への追記例
“lint-staged”: {
“.{js,ts,tsx,json,md}”: [
“prettier –write”, // コミット対象のファイルのみを強制整形
“eslint –fix” // フォーマット後のコードを静的解析
]
}
—
5. 最後に：アーキテクトからのアドバイス
「セミコロン論争」に終止符を打つために必要なのは、「個人の好み」を「チームの規約」という名のゴミ箱に捨てる勇気です。
私がリードする現場では、フォーマットに関する議論が起きた瞬間、即座にPrettierの標準設定へ戻すか、多数決で決めて数分でクロージングします。なぜなら、その議論に使う数分間があれば、ユーザーに価値を届けるためのロジックを一行でも多く書けるからです。
「ツールに全てを委ね、人間はビジネスロジックに集中する」。
これが、最強の開発チームを構築するための唯一の哲学です。今すぐ設定ファイルをコミットし、無意味な議論から解放されてください。