Contents
Jira Service Management 移行 手順：実務視点での移行プロセスと注意点
Jira Service Management（以下、Atlassian Jira Service Management）への移行は、IT担当者や運用管理者にとって業務効率化のための重要課題です。Atlassian Jira Service Management 移行 手順を正しく理解せず実施すると、データ整合性の喪失やオペレーションの中断が発生する可能性があります。本記事では、移行前の環境調査からテスト環境での検証まで、具体的な手順と実務的な注意点を解説します。
移行前の環境調査と要件定義
JSMへの移行は、既存システムの構造を把握した上で進める必要があります。まず現状のデータ構造や運用プロセスを精査し、移行後の要件を明確にすることが不可欠です。
現状のデータ構造分析
既存のチケットデータやカスタムフィールド、ワークフローの設計を見直すことで、JSMでの再構築可能性が確認できます。例えば、「チケットカテゴリ」や「優先度マップ」といった項目は、移行後の運用に直接影響を与えるため、事前に定義しておく必要があります。
移行範囲の明確化
全データを一度に移行するのではなく、「過去1年以内のチケット」や「特定プロジェクトのデータ」など、優先順位付けが重要です。また、移行対象外となるデータがある場合は、明文化してドキュメント化してください。
リソース・スケジュールの設定
移行に必要な人材（IT担当者・外部支援）や時間配分を事前に計画します。例： 300件程度のデータ移行には「1週間」、5000件以上なら「2〜3週間」が目安です。
サイトインポート機能によるデータ移行手順
Atlassian公式ドキュメント（Jira Service Management データ移行ガイド）に記載されているインポート機能を活用し、CSV形式でデータを整形・移行します。特に大規模データの場合、分割戦略を検討する必要があります。
CSV形式でのデータ整形ガイド
以下は、JSMの現行仕様に基づいた具体的な整形ルールです。
- 必須フィールド：チケットタイトル、担当者、状態（解決済み/未対応）、日付など
- カスタムフィールド：JSMで新たに作成したフィールド名とマッチさせる
- エラーハンドリング：CSVの形式ミスが発生した場合、Atlassian公式サポート（トラブルシューティング）を参照し、修正後再インポート
| フィールド | 値例 | 補足 |
|---|---|---|
| 件名 | サーバー障害 | 30文字以内に制限あり（JSM仕様に基づく） |
| 担当者 | 山田太郎 | 空欄の場合は「未指定」で統一 |
| 優先度 | 高 | JSMで定義済みの値を使用 |
大規模データの分割戦略
10万件以上のデータを一度にインポートすると、性能低下や失敗リスクが高まります。「年別」「プロジェクト別」などに分割し、段階的に移行するのが実務で推奨されます。
OpsgenieからJira Service Managementへの移行方法
OpsgenieをJSMに移行する際は、API連携とアラートルールの再構築が鍵となります。Atlassian公式サポート（インテグレーションガイド）に記載された手順に基づいて実施してください。
API連携設定のベストプラクティス
Atlassianのドキュメント（REST API 3.0 リファレンス）に記載されている以下のエンドポイントを活用します。
- GET /rest/api/3/issue：既存チケットデータの取得
- POST /rest/api/3/issue：新規チケットの作成
API利用時は、認証トークン（API Token）の管理とレート制限（Rate Limiting）を意識してください。
アラートルールの再構築プロセス
Opsgenieで設定されていた「通知先（メール/Slackなど）」や「トリガー条件（エラー発生時）」を、JSM内での通知ルールと自動化ルールに再現します。
注意： 移行後も Opsgenie のアラートが継続して送信される場合があります。必ず移行完了後に「OpsgenieのAPI連携設定」を確認してください。
移行後のアラート設定とオペレーション最適化
JSMに移行した後は、アラート体系やダッシュボードのカスタマイズによって運用効率が大きく変わります。以下のステップで最適化を図りましょう。
通知ルール構築のポイント
- 状態変更時の通知：チケットが「未対応→解決済み」になった際に自動通知する
- 担当者向けのメールテンプレート作成：アラート内容を簡潔にまとめたHTML形式のメールを作成
ダッシュボードカスタマイズ手法
- カスタムフィルタの追加：「過去24時間の新規チケット数」や「未対応件数ランキング」など
- ウィジェットの配置例：
- チケット一覧（ステータス別）
- 最近更新されたプロジェクト
テスト環境での検証プロセス
本番移行前のテストは、移行後のトラブルを防ぐために不可欠です。擬似データを使ってシナリオテストを行い、異常時のロールバック計画を作成してください。
擬似データによるシナリオテスト
- 正常なケース：インポート後のチケットがJSM内に正しく表示されるか
- 異常ケース：「日付フォーマットミス」や「重複するチケットID」がエラーとして検出されるか
移行後のパフォーマンスモニタリング
- テスト環境でJSMのレスポンスタイムを測定し、本番環境の負荷対応に備える
- 大規模データ移行後は、「ロールバック手順」を文書化しておきましょう
公式ドキュメント活用とサポート情報確認
最新バージョンのJSMには、移行プロセスに関する公式サポートが随時更新されています。移行準備中に以下を確認してください。
最新版の確認手順
- Atlassian公式サイト（リリースノート）から「Jira Service Management Cloud」のリリースノートを確認
- 「Migrate your users in advance」のセクションを参照し、ユーザー移行手順を精査
サポートチケット開票ガイド
- ドキュメントで解決できない場合は、Atlassianサポートチケットを開票します。
- 件名：「JSM 移行に関する相談」
- 内容：移行エラーログの添付（例：
Error: Invalid field name 'customfield_12345'）
- 事前の環境調査で要件を明確に
- CSV整形とインポートツールを使ってデータ整合性を確保
- OpsgenieからJSMへの移行時のAPI連携ミス防止策を検討
- テスト環境での検証で移行後のリスクを最小限に
- 公式情報の正確な活用で効率的な移行を実現
これらのステップを踏むことで、Atlassian Jira Service Managementへの移行はスムーズかつ確実なものになります。移行作業を開始する際は、公式ドキュメントと併せて最新のサポート情報を確認し、段階的に実施してください。