肥大化したJiraを蘇生せよ：プロジェクトの「墓場」を整理し、インデックスを再構築する究極のアーキテクト・ガイド
Jiraが遅い？ それは君のチームの努力の結晶が、巨大な負債としてシステムを圧迫している証拠だ。
数万の課題、数千のカスタムフィールド、終わりのないワークフロー。これらが混在する環境では、DBのインデックスは断片化し、Luceneのインデックスは肥大化し、JVMのヒープメモリはGC（ガベージコレクション）の悲鳴で溢れかえる。
今日は、小手先のクリック作業ではない。Jiraのアーキテクチャを理解し、APIとCLIを駆使して「システムを爆速に回帰させる」ための戦術的アプローチを伝授する。これは掃除ではない。パフォーマンスを取り戻すための外科手術だ。
—
1. なぜJiraは「重く」なるのか？（ボトルネックの正体）
Jiraのパフォーマンス低下の真因は、主に以下の3点に集約される。
- 過剰なカスタムフィールド: 全てのプロジェクトで利用可能なカスタムフィールドは、Jiraのインデックス計算コストを指数関数的に増大させる。
- 「Done」課題の飽和: 検索クエリ（JQL）は基本的にインデックスを全走査する。アーカイブなきプロジェクトは、過去の遺物まで毎回スキャンさせることになる。
- 非効率なワークフローと自動化スクリプト: トリガー過多なAutomation for Jiraは、DBへの書き込みロック競合を引き起こす。
—
2. 大掃除の戦術：アーカイブ戦略の自動化
「手動でアーカイブ」などという無益な作業は忘れろ。我々はコードで支配する。
ステップ1：ゴミの特定（カスタムフィールドの断捨離）
まず、使われていないカスタムフィールドを特定する。以下のSQL（PostgreSQL例）で、どのフィールドが「値を持っていない」かを抽出せよ。
— 値がNULLであるカスタムフィールドを特定する
SELECT cf.cfname, count() as empty_count
FROM customfield cf
LEFT JOIN customfieldvalue cfv ON cf.id = cfv.customfield
WHERE cfv.stringvalue IS NULL
AND cfv.textvalue IS NULL
GROUP BY cf.cfname
ORDER BY empty_count DESC;
注: これでヒットしたものは即座に削除対象ではない。まずは`Contexts`を制限し、特定プロジェクト以外では利用不可に設定することから始めよ。
ステップ2：APIによる自動アーカイブ・パイプライン
完了から180日経過した課題を自動アーカイブするスクリプトだ。Pythonと`requests`ライブラリを使用する。
import requests
import datetime
設定
JIRA_URL = “https://your-domain.atlassian.net”
AUTH = (“email@example.com”, “API_TOKEN”)
HEADERS = {“Accept”: “application/json”, “Content-Type”: “application/json”}
180日前の日付計算
threshold_date = (datetime.datetime.now() – datetime.timedelta(days=180)).strftime(‘%Y-%m-%d’)
JQL: 完了済みかつ180日以上更新がない課題を抽出
jql = f”statusCategory = Done AND updated < '{threshold_date}'"
def archive_tasks():
# 課題検索
res = requests.get(f"{JIRA_URL}/rest/api/3/search", params={"jql": jql, "maxResults": 50}, auth=AUTH)
issues = res.json().get('issues', [])
for issue in issues:
# アーカイブ実行API (Jira Cloud向け)
requests.post(f"{JIRA_URL}/rest/api/3/issue/{issue['key']}/archive", auth=AUTH)
print(f"Archived: {issue['key']}")
if __name__ == "__main__":
archive_tasks()
---
3. インデックスの再構築（Re-indexing）の極意
多くのエンジニアが誤解しているが、「インデックス再構築」は頻繁に行うものではない。
これはLuceneインデックスをゼロから再構築する重い処理だ。
- ベストタイミング:
1. 大規模なデータ移行後
2. カスタムフィールドを大幅に削除した直後
3. 検索結果のレスポンスタイムが閾値（例: 2000ms）を超え続けた場合
- 鉄則:
必ず「Locking Indexing（ロックインデックス）」を選択せよ。バックグラウンド再構築は運用中の環境では負荷が爆発する。深夜2時、メンテナンスウィンドウを確保して実行するのがプロの作法だ。
—
4. チームの検索ストレスをゼロにする「ナレッジの断捨離」
Jiraはデータベースであり、ファイルサーバーではない。
1. 添付ファイルの外部化: 巨大なバイナリはJiraのDB/ファイルシステムを食いつぶす。Amazon S3等へ退避させ、リンクのみをJiraに残す連携を構築せよ。
2. JQLのプリセット化: ユーザーに複雑なJQLを書かせるな。頻繁に使うクエリは「ダッシュボード」に登録し、システム側でインデックスを最適化しやすい構造に固定する。
3. プロジェクトの「棚卸し」: 1年に1度、プロジェクト単位で「ステータスアーカイブ」を実施する。プロジェクト自体を「アーカイブ」状態にすることで、グローバル検索のノイズを劇的に減らせる。
—
5. 伝説的アーキテクトからの提言
Jiraが重いのは、ツールが悪いのではない。「管理しきれない情報の濁流」をそのまま放置しているチームの怠慢だ。
真のアジャイルチームは、コードだけでなく「管理プロセス」もリファクタリングする。
- 今すぐやること: 本番環境の「カスタムフィールド数」を確認せよ。もし300を超えていたら、君のJiraはすでに病んでいる。
- 来週やること: 上記のAPIスクリプトをCI/CDパイプラインに組み込み、週次でアーカイブを回せ。
Jiraを、単なるタスク管理ツールから「チームの血流を加速させるハイパフォーマンスな基盤」へと進化させるのは、他でもない君だ。
さあ、コンソールを開け。最初の一歩は、その重いインデックスを綺麗に拭き去ることから始まる。