Jiraの「カスタムフィールド地獄」を解体する：パフォーマンスと秩序を取り戻すアーキテクチャ再設計
Jiraは強力だ。しかし、その強力さは「無制限の自由」という劇薬と表裏一体である。
多くのチームが直面する「カスタムフィールド地獄」。プロジェクトが進むにつれ、数千ものフィールドが乱立し、検索画面のインデックス作成はタイムアウトし、画面のレンダリングは重くなる。
これは単なる管理不足ではない。Jiraのアーキテクチャに対する理解不足からくる「設計の敗北」だ。
今日は、Jiraをただのチケット管理ツールから、高速でスケーラブルなエンジニアリング基盤へと昇華させるための、深層最適化の手法を伝授する。
—
1. 負の遺産の棚卸し：静的解析による「死んだフィールド」の炙り出し
「使っていないはずだが、消すのが怖い」という心理こそが技術的負債の正体だ。まずはデータで殴れ。Jiraのデータベースを直接叩くか、`rest/api/2/field` を活用し、使用率を可視化する。
以下のスクリプトは、過去3ヶ月間、値が一度も更新されていない、あるいは空のカスタムフィールドを特定するための概念コードだ。
Jira REST APIを利用して、更新頻度が極端に低いフィールドを抽出する（概念）
import requests
def get_unused_fields(api_url, auth):
fields = requests.get(f”{api_url}/rest/api/2/field”, auth=auth).json()
# ここで各フィールドの検索インデックス統計を取得（Luceneの利用状況を確認）
# 実際にはSQLで “customfieldvalue” テーブルの更新日時を追跡するのが最も確実
for field in fields:
if is_stale(field[‘id’]): # 最終更新日時が一定期間以前のものを判定
print(f”Candidate for removal: {field[‘name’]} ({field[‘id’]})”)
現場のアドバイス：
削除前に必ず「スクリーンから削除」し、数週間放置せよ。
それでも誰も文句を言わなければ、そのフィールドは最初から不要だったのだ。
—
2. パフォーマンス最適化の極意：コンテキストの分離
Jiraが重くなる最大の原因は、「グローバルコンテキスト」の乱用だ。
全てのプロジェクトで同じカスタムフィールドを共有すると、Jiraは全課題に対してそのフィールドのインデックスを維持しようとする。これはメモリの無駄遣いである。
究極の設計戦略：
1. プロジェクト・コンテキストへの絞り込み: フィールドは可能な限り「特定のプロジェクト」または「特定の課題タイプ」に限定せよ。
2. コンテキストの分割: グローバル設定を排除し、必要なスコープのみにリソースを割り当てる。これにより、Jiraの内部Luceneインデックスが劇的に軽量化される。
—
3. 命名規則の「厳格なプロトコル」
フィールド名がバラバラなチームは、文化もバラバラだ。
検索性を担保し、API連携でミスを起こさないための「名前空間ルール」を強制せよ。
- 命名テンプレート: `[層].[属性].[項目名]`
- 例: `sys.env.deployment_target`
- 例: `biz.fin.budget_code`
- なぜこれが必要か:
- APIからデータを取得する際、ネームスペースでソートが可能になる。
- どのチームの、どのレイヤーのデータかが一目で判別できる。
- 誤って別チームのフィールドを再利用する事故を物理的に防ぐ。
—
4. 自動化によるガバナンス：CI/CD的なJira管理
Jiraの変更を「手作業」で行うな。それは即ち、設定のドリフトを許容することを意味する。
Jira Configuration Manager を活用するか、あるいは Terraform (Jira Provider) を用いて「Infrastructure as Code (IaC)」ならぬ「Configuration as Code」を構築せよ。
フィールドの追加や変更はすべてPull Request経由で行い、構成管理ツールが自動的に検証する。
Terraformによるカスタムフィールド管理の例
resource “jira_custom_field” “deployment_target” {
name = “sys.env.deployment_target”
description = “デプロイ対象環境（自動化スクリプト参照用）”
type = “com.atlassian.jira.plugin.system.customfieldtypes:select”
# コンテキストを限定してインデックス負荷を抑制
scope {
project_ids = [10001]
}
}
—
5. 伝説的アーキテクトからの提言
Jiraを「ただのチケットツール」として扱うのは、F1マシンを買い物に使うようなものだ。
- フィールドを増やす前に考えろ: それは「課題の属性」か、それとも「メタデータ」か？ メタデータなら外部のRDB（PostgreSQL等）に逃がし、Jiraからは外部オブジェクト参照（Assets/Insight）を使うのが正解だ。
- 検索性を捨てろ: あらゆる情報をJiraのフィールドに詰め込もうとするな。検索が必要なものはElasticsearchへ同期し、Jiraは「ワークフローの駆動」に専念させるのが、スケーラブルな組織の共通言語だ。
結論を言おう。
Jiraを軽量に保つことは、組織の思考を軽量に保つことと同義だ。
無意味なフィールドを排除し、スコープを制御し、コードで管理せよ。ツールが重いと感じた時、それはあなたの設計が、ツールが支えられる限界を超えようとしているサインなのだから。
今すぐ、最初の「死んだフィールド」を削除することから始めよ。それが、君のチームのベロシティを加速させる最初の一歩になる。