エンジニアの皆さん、こんにちは。アジャイルコーチの視点から、日々現場の「混沌」を「秩序」へと変えるお手伝いをしています。
Jiraを使っていると避けて通れないのが、「プロジェクトを跨いだ課題の引っ越し（Move）」という外科手術です。これを適当にやると、長年積み上げたカスタムフィールドのデータが蒸発したり、ステータスが迷子になったりして、チームの信頼を大きく損ないます。
今回は、Jiraの移行ウィザードという「地雷原」を安全に歩き、メタデータを一切損なわずに課題を移動させるための「極意」を伝授します。
—
1. なぜ「移行ウィザード」は牙を剥くのか？
Jiraの「課題の移行（Move）」機能は、単なるデータのコピペではありません。「異なるコンテキスト（スキーマ）同士の再定義」です。
- 落とし穴1：フィールドの不整合
移行先プロジェクトに、同じ名前のフィールドが存在しない、あるいはデータ型（単一行テキスト vs 選択リストなど）が異なると、データは問答無用で切り捨てられます。
- 落とし穴2：ステータスの乖離
ワークフローのステータスが移行先に存在しない場合、課題は「行き先不明」になります。
- 落とし穴3：リンク関係の断絶
単純移動では、エピックへの紐付けや依存関係が「参照先なし」として壊れることがあります。
—
2. 安全な移行のための「3ステップ・プロトコル」
ぶっつけ本番は厳禁です。以下の手順で「保険」をかけながら進めましょう。
Step 1：フィールドの「完全一致」を保証する
移動する前に、移行先のプロジェクト設定を確認してください。
1. フィールド設定の比較: 移行元と移行先の「フィールド設定スキーム」を並べて表示します。
2. 型を揃える: 移行元で「マルチセレクト」を使っているなら、移行先も必ず同じ型で作成してください。「後で直せばいい」という考えは捨てましょう。
3. コンテキスト設定: カスタムフィールドの「設定」画面から、新しいプロジェクトを含めるように「コンテキスト」を編集してください。これを忘れると、フィールド自体が表示されません。
Step 2：移行ウィザードを「論理的に」使い倒す
課題を選択して「移動」をクリックするとウィザードが始まります。ここで重要なのはマッピングの確認です。
- 「新しいプロジェクトと課題タイプを選択」: ここで課題タイプが変わるなら、フィールドの再マッピングが必須になります。
- 「フィールドの更新」画面: 最も重要な画面です。ここで「値が保持されないフィールド」がないか、虫眼鏡を当てるようにチェックしてください。もし値が空になる項目があれば、移動を中断し、Step 1に戻ってフィールド設定を修正します。
Step 3：事後チェック（HelloWorld的な確認）
移行が終わったら、以下の3点を確認してください。
- データ疎通確認: 移行した課題を1つ開き、カスタムフィールドの値が正しく表示されているかをブラウザで実確認。
- リンク関係の生存確認: エピックリンクや「関連する課題」が切れていないか確認。
- 検索クエリでの抽出: `project = “移行先プロジェクト名”` で検索し、期待通りの課題数がヒットするか確認。
—
3. 現場を救う「魔法のチェックリスト」
作業前に、以下の設定を確認するだけで失敗率は90%減ります。
Jira移行前チェックリスト (YAML風)
checklist:
field_sync:
- 移行先のプロジェクトでもフィールドが「表示」設定になっているか？
- フィールドのデータ型（選択肢の内容含む）は一致しているか？
workflow_sync:
- 移行先のワークフローに、現在の「ステータス」は存在するか？
- 存在しない場合、どのステータスに変換するか事前に決めてあるか？
permission_sync:
- 移行先プロジェクトの「課題の作成」権限が自分にあるか？
backup:
- 移行前にCSVでのバックアップを取ったか？ (超重要)
—
最後に：エンジニアとしての矜持
ツールを使いこなすということは、ツールの仕様に振り回されることではありません。「データがどのように保持され、どう変化するのか」というメタデータの本質を理解することです。
移行が不安なときは、必ず「テスト用プロジェクト」を一つ作り、そこに1件だけ課題を移動させる「検証」を行ってください。この一手間が、数時間分の手戻り作業からあなたを解放してくれます。
Jiraは強力な武器です。正しく使えば、チームのベロシティは確実に加速します。まずは小さな課題から、怖がらずに挑戦してみてくださいね。
何かあればいつでも相談してください。あなたの開発ライフが、より快適で論理的なものになることを心から応援しています！