こんにちは！チーム開発を進めていると、「人によってインデントの幅が違う」「保存した瞬間にフォーマットが崩れてGitの差分（Diff）が汚れる」「レビューでスタイルに関する指摘ばかりしてしまう」といったモヤモヤに直面したことはありませんか？
大規模なシステム開発でも、数人のWebアプリ開発でも、コードの見た目や書き方がバラバラだと、それだけでcognitive load（脳の認知負荷）が跳ね上がり、本質的なロジックのレビューに集中できなくなってしまいます。
今回は、JetBrains社の最高峰IDE「WebStorm」と標準規格である「EditorConfig」を組み合わせ、チーム全員の開発環境を完全に同期させ、コード品質と開発体験を劇的に引き上げる手法を、シニアエンジニアの視点から優しく、かつ深く解説していきます。
これをマスターすれば、あなたのチームから「フォーマットの不一致による無駄なGit差分」を永遠に排除できますよ。ぜひ最後までついてきてくださいね。
—
1. なぜチーム開発で「設定の共有」が必要なのか？
私たちがコードを書くとき、IDE（統合開発環境）は単なるテキストエディタ以上の仕事をしています。シンタックスハイライト、コード補完、リアルタイムの静的解析など、WebStormはあなたの最強の相棒です。
しかし、もしメンバーAのWebStormは「タブ幅4スペース」に設定され、メンバーBのWebStormは「タブ幅2スペース」に設定されていたらどうなるでしょうか？
Git上でほんの数行変えただけなのに、ファイル全体が差分として検知されてしまい、プルリクエスト（PR）のレビューが地獄のように難しくなります。
これを防ぐためには、「個人のエディタ設定に依存せず、プロジェクト（リポジトリ）側がルールを強制・共有する仕組み」が必要です。WebStormとEditorConfigを使えば、これを驚くほどエレガントに実現できます。
—
2. WebStormの心臓部：`.idea` ディレクトリのGit共有
WebStormは、プロジェクトを開くと自動的に `.idea` という隠しフォルダを作成します。ここには、コードスタイル、インスペクション（静的解析）ルール、タスクランナーの設定などがすべて詰まっています。
標準状態では、`.gitignore` に `.idea/` が含まれていることが多いため、これをチームで共有できるように選別してGit管理下に入れましょう。
共有すべきファイル・除外すべきファイル
すべてのファイルを共有すると、個人のウィンドウ位置や開きっぱなしのタブ履歴まで同期されてしまい迷惑です。以下の戦略でGit管理を行います。
- 共有するべきもの（Gitに含める）
- `codeStyleSchemes/` （コードスタイルの詳細設定）
- `inspectionProfiles/` （静的解析のルール）
- `webstorm.xml` やプロジェクト固有のモジュール設定
- 共有してはいけないもの（`.gitignore` で除外）
- `workspace.xml` （個人のウィンドウ位置、最近開いたファイルなど）
- `usage.statistics.xml` （使用統計）
WebStormでの設定のエクスポート
チーム全員に同じコードスタイルを適用するため、まずはあなたのWebStormの設定をプロジェクト用に保存しましょう。
1. メニューの `Preferences`（Windowsの場合は `Settings`）を開く。
2. Editor > Code Style に進む。
3. 「Scheme」の歯車アイコンをクリックし、「Project」を選択する。これで、この設定はこのプロジェクト（`.idea`内）に保存されるようになります。
—
3. 業界標準「EditorConfig」でエディタの壁をブチ抜く
WebStormだけでなく、VS Codeなど他のエディタを使っているメンバーもチームにいるかもしれません。「IDEが違うからスタイルが揃わない」という言い訳を封殺するのが `.editorconfig` です。
プロジェクトのルートディレクトリに `.editorconfig` というファイルを置くだけで、IDEの種類を問わず、保存時にインデントや文字コードを自動で統一してくれます。
実践的な `.editorconfig` の書き方
以下のコードをプロジェクトのルートに作成してください。各行に丁寧な解説を入れています。
ルートエディタ設定ファイルの指定（これより上位の階層を探しに行かない）
root = true
[]
すべてのファイルに対して適用
charset = utf-8
末尾の空行を自動挿入
insert_final_newline = true
行末の不要な空白を自動削除
trim_trailing_whitespace = true
[.{js,ts,jsx,tsx,json}]
JavaScript, TypeScript, JSONファイルの設定
indent_style = space
indent_size = 2
end_of_line = lf
[.{css,scss,less,html}]
スタイルシートやHTMLはインデント2スペース
indent_style = space
indent_size = 2
> 先輩からのアドバイス: WebStormは標準でEditorConfigを完全サポートしています。特別なプラグインを入れなくても、このファイルが存在するだけで、WebStorm側が自動的にコードスタイルの設定を `.editorconfig` の内容に上書きしてくれます。最高にスマートですね！
—
4. 精度高い「HelloWorld」で動作確認をしよう
設定が正しく機能しているか、実際に手を動かして確認してみましょう。環境構築の醍醐味は、この「意図通りに自動化される瞬間」を味わうことにあります。
ステップ1: テスト用ファイルの作成
プロジェクト内に `test.js` というファイルを作成し、あえてめちゃくちゃなインデントと、行末に不要なスペースを入れたコードを書いてみます。
// あえて崩したコードスタイル
function helloWorld( ) {
const message = “Hello, WebStorm Code Style!”;
console.log(message);
}
helloWorld();
(※ `function` の後ろに余計なスペースがあり、インデントも4スペースやバラバラになっています)
ステップ2: 自動フォーマットの実行（またはファイル保存）
WebStormの強力な機能を使ってみましょう。
1. キーボードショートカット（macOS: `Cmd + Option + L` / Windows: `Ctrl + Alt + L`）を押して、「Reformat Code（コードの再フォーマット）」を実行します。
2. または、ファイルを保存（`Cmd + S` / `Ctrl + S`）します（※保存時に自動フォーマットする設定を有効にしている場合）。
ステップ3: 期待される結果の確認
瞬時に次のように整形されれば大成功です！
// EditorConfigとWebStormの設定によって美しく整えられたコード
function helloWorld() {
const message = ‘Hello, WebStorm Code Style!’;
console.log(message);
}
helloWorld();
インデントが綺麗に2スペースに揃い、行末の余計な空白もキレイに消去されています。これなら、誰がどの端末で書いても全く同じ美しいコードが維持されます。
—
5. チームへの導入を円滑に進めるためのベストプラクティス
最後に、この設定をチームに導入する際、メンバーからの反発を生まずにスムーズに浸透させるための「現場の知見」をいくつか授けましょう。
1. 既存のコードベース全体をいきなり書き換えない
いきなり大規模なフォーマット変更をコミットすると、過去の `git blame`（誰がそのコードを書いたか）が汚れてしまい、他のメンバーが嫌がります。最初は新規ファイルや、これから触る部分から適用していくのが定石です。
2. PrettierやESLintとの共存
もしプロジェクトでPrettierやESLintを使っている場合は、WebStormの「Prettier integration」を有効にしましょう。WebStormが自動でPrettierのルールを読み込み、競合を防いでくれます。
—
まとめ
今回は、WebStormの設定共有とEditorConfigを活用したコードスタイルの統一について解説しました。
- `.idea` の一部をGit管理してWebStormの設定をチーム共有する
- `.editorconfig` を配置して、エディタを問わずコーディング規約を強制する
- ショートカットや保存時自動フォーマットで、無駄なストレスをゼロにする
たったこれだけの準備で、チーム全体のコードレビューの質が跳ね上がり、「インデントがどうこう」という不毛な議論がチームから消え去ります。
毎日のコーディングが驚くほどスムーズになりますので、ぜひ明日の開発からプロジェクトに取り入れてみてくださいね。あなたの開発ライフがより快適になることを応援しています！