IDEを「既製品」で使うな：IntelliJ Platform SDKでチームの作法を強制的に最適化せよ
多くのエンジニアがIntelliJ IDEAを「高機能なエディタ」として使っている。しかし、真のアーキテクトにとって、IntelliJは「チームの集合知をコードベースに刻み込むためのプラットフォーム」だ。
既存のプラグインをインストールするだけでは、真の生産性向上は訪れない。なぜなら、現場固有のビジネスロジックや、チーム特有の設計思想（例えば、特定のレイヤーでのみ許される例外処理や、レガシーコードの隠れた罠）を理解してくれるプラグインは、世界中どこを探しても存在しないからだ。
今回は、IntelliJ Platform SDKを使い、独自の「インテンション・アクション（Intention Action）」を開発して、チームのコーディング作業を型にはめるための極意を伝授する。
—
なぜ「インテンション・アクション」なのか
インテンション・アクション（`Alt + Enter`）は、単なる自動修正ボタンではない。これは「IDEとエンジニアの対話インターフェース」である。
チーム開発において、「このコードはこう書いてほしい」という暗黙知をドキュメントに書いても誰も読まない。IDEが「その書き方は古い、こう修正すべきだ」と即座に提案し、ワンクリックで修正させる仕組みこそが、コードの品質を担保する唯一無二の手段だ。
独自のインテンションを構築するロジック
IntelliJのプラグイン開発は、PSI（Program Structure Interface）を理解することから始まる。PSIはソースコードを抽象構文木（AST）として解析するためのインターフェースだ。
// 独自のインテンションの核となるロジック（抜粋）
class MyCompanyCodeStyleIntention : PsiElementBaseIntentionAction() {
// どのコンテキストでアクションを有効化するか
override fun isAvailable(project: Project, editor: Editor?, element: PsiElement): Boolean {
// 例: 特定のクラス名やメソッド呼び出しのパターンをPSIで検知
return element.parent is PsiMethodCallExpression && isTargetMethod(element)
}
// 修正の本体：ASTを書き換える
override fun invoke(project: Project, editor: Editor?, element: PsiElement) {
val factory = JavaPsiFacade.getInstance(project).elementFactory
val newExpression = factory.createExpressionFromText(“newService.execute()”, element)
element.replace(newExpression) // 既存コードを安全に置換
}
}
このロジックを実装することで、チーム全員の環境で「間違った書き方」をIDEが検知し、自動で「ベストプラクティス」に変換できるようになる。
—
チーム開発を加速させる「設定共有」の絶対ルール
プラグイン開発と並行して、プロジェクト設定の標準化は避けて通れない。` .idea` ディレクトリをGit管理する際、以下のファイル構成を徹底せよ。
`.idea/codeStyles/Project.xml` の活用
チームで「改行位置」「スペースの数」を議論するのは時間の無駄だ。プロジェクト直下に設定を配置し、IDEの「Share via VCS」を有効にすれば、全員が全く同じコードフォーマットを強制される。
—
現場の生産性を爆上げする「隠れた」Tips
1. 「Search Everywhere」を使いこなす究極形
`Shift` 二連打は基本中の基本だが、検索窓で `is:action` や `is:setting` をプレフィックスに付けることで、設定画面に直接遷移できることを知っているか？設定の階層を迷う時間は、年間で見れば数時間に達する。
2. 神プラグインの選定基準
機能が多すぎるプラグインはIDEを重くするだけだ。以下の3つは、チームの生産性を底上げする「ミニマリズムかつ強力」な選択肢である。
- `Key Promoter X`: マウス操作を検知し、ショートカットを強制学習させる。新人の教育コストを最小化できる。
- `SonarLint`: インテンション開発の補完として。IDEのローカル環境で静的解析を行い、負債の発生をリアルタイムで防ぐ。
- `GitToolBox`: 行単位の blame 表示。誰がなぜこのコードを書いたのかというコンテキストを、エディタから離れずに把握できる。
—
アーキテクトからの提言：IDEを「会社のもの」にせよ
優秀なチームとは、ツールを個人の好みに任せず、「開発という行為そのものを標準化」できているチームだ。
1. 独自のインテンションを開発し、社内の「アンチパターン」を排除する。
2. 設定ファイルをVCSで共有し、フォーマットの議論をゼロにする。
3. チーム専用のプラグインを社内の内部レポジトリで配布する。
これらを行うことで、あなたのチームは単なる「コードを書く集団」から、「IDEというプラットフォームを使いこなすエンジニアリング組織」へと進化する。
IntelliJ IDEAは、単なる開発ツールではない。あなたのチームの「標準化された思考」そのものなのだ。 さあ、明日の朝からあなたのチームの暗黙知を、IDEの中にコードとして刻み込んでみてほしい。