Jira⇄Backlog移行実務ガイド：乗り換える／乗り換えないの判断と、課題・添付ファイル・権限の移行手順

「どちらが良いか」ではなく「乗り換えるか」が論点になる場面

当サイトの「プロジェクト管理ツール比較」は新規導入時の選定基準を、「プロジェクト管理ツールのAI機能比較」はAI機能の有無を扱った。しかし、すでにJiraかBacklogのどちらかを使っている組織が実際に直面する問いは別にある。もう一方のツールへ乗り換えるべきか、乗り換えるなら課題・コメント・担当者・添付ファイル・権限のうちどこまでが運べて、どこで作り直しが発生するか、という問いである。この問いには機能比較では答えられない。個々のデータがどういう形式で出入りするかを、両社の公式ドキュメントで具体的に確認する必要がある。

この記事は、Atlassian公式サポートドキュメントとBacklog公式ヘルプセンター・公式ブログの一次情報にもとづき、BacklogからJiraへ、JiraからBacklogへという両方向について、乗り換えるかどうかを決める判断軸と、実際にデータを移行する際につまずきやすい4つの壁を整理する。どちらのツールも、計画・進捗・課題などの情報を集約するPMISの実装の一つにすぎない。実装を変えても管理したい情報の中身は変わらないが、情報の運び方そのものには、それぞれの設計に由来する固有の制約がある。

この記事の編集基準

本記事にアフィリエイトリンク・紹介料・掲載料は一切ない。仕様の記述は、Atlassian公式サポートドキュメント(support.atlassian.com)、Atlassian Confluence上のナレッジベース(confluence.atlassian.com)、Backlog公式ヘルプセンター(support-ja.backlog.com)、Backlog公式ブログ(backlog.com/ja/blog)で確認できた範囲に限定している。価格や料金プランの詳細は「プロジェクト管理ツール比較」で扱っており、本記事では移行そのものに絞る。

移行を決める前に確認する3つの軸

「乗り換えたほうがよいのでは」という相談の多くは、新しいツールの機能に惹かれて始まる。だが機能の魅力は移行の判断材料としては不十分である。先に確認すべきは、今のツールに蓄積されたデータのうちどこまでが新しいツールに運べ、どこが運べずに作り直しになるかである。

Backlog公式ブログは、既存の管理表からBacklogへ移行する際の考え方として「全部移さなくていい」という方針を示している。リピート受注で同じ仕様を再び扱う可能性が高い案件、手戻りや不具合が起きて原因と対処を記録しておきたい案件、担当者交代で引き継ぎが必要な案件だけを移行対象にし、すでに終了していて参照する可能性が低い案件は元のツールに置いたままでよい、という判断基準である。この考え方は、JiraとBacklogのあいだの移行にもそのまま当てはまる。全件移行を前提にすると、後述する壁のすべてに同時にぶつかることになる。

壁(1) 受け皿を先に用意しないとインポートが失敗する

JiraのCSVインポート機能は、Jiraの管理画面から「システム」→「外部システムインポート」→「CSV」を選ぶか、プロジェクト内の「すべての作業」から「CSVから課題をインポート」を選んで実行する。Atlassian公式ドキュメントは、この機能が「CSV形式のみに対応し、実行できるのは管理者のみ」であることを明記しており、さらに「インポート中に新しいステータス、ワークタイプ、カスタムフィールド、カスタムフィールドのオプションを追加することはできない」としている。

つまり、BacklogのCSVに書かれた種別名やステータス名が、移行先のJiraのスペースに一字一句一致する形で事前に作られていなければ、インポートはその時点で失敗する。Backlogの「種別」とJiraの「課題タイプ(work type)」は名前も粒度も異なるため、インポートの前にJira側で対応表を作り、スペースの設定画面で先に作っておく作業が実質的な前提になる。

階層構造のずれも実務でつまずきやすい点である。「Jiraのワークフロー・課題タイプ設計」で整理したとおり、Jiraの課題タイプはエピック・標準課題・サブタスクという3階層で構成され、サブタスクは子にしかなれず、1件の親課題に表示できる子課題は公式ドキュメントが示す上限として500件とされている。一方Backlogの親子課題は親と子の2階層である。Backlogの親子2階層をJiraの3階層にそのまま流し込もうとすると、どの階層に何を割り当てるかという設計判断が先に必要になり、CSVの列を揃えるだけでは終わらない。

壁(2) 担当者とコメントの投稿者は、表示名のままでは運べない

担当者の移行でもっとも実務に響くのが、ユーザーの識別方法の違いである。Atlassianのナレッジベースは、CSVインポートで発生する代表的なエラーとして「user doesn't exist」を挙げ、原因を「JiraはCSV内の表示名をメールアドレスやAtlassian Account ID(AAID)に解決できない」ことだと説明している。対処として案内されているのは、CSVにAssignee IDとReporter IDの列を別途用意してそれぞれのフィールドにマッピングする方法、またはユーザー選択形式のカスタムフィールドであれば表示名をメールアドレスに置き換える方法である。BacklogのCSVエクスポートは担当者を人の名前で出力するため、Jiraへそのまま読み込ませると、この変換作業を挟まない限りエラーで止まる。

コメントの投稿者と日時を保持したまま移行できるかどうかも、公式ドキュメントで確認できる。Atlassianのサポート記事は、投稿者と日時を指定してコメントをインポートする書式を「日時;Atlassian Account ID;コメント本文」という形で示しており、記事内の例は「31/Mar/24 6:49 AM;<Atlassian Account ID>;New Comment」となっている。ここで使う識別子はメールアドレスではなくAtlassian Account IDに限られ、Account IDは各ユーザーがJira Cloudにログインし、プロフィール画面のURL末尾から確認する。日時の既定書式は「dd/MM/yyyy HH:mm a」で、インポート時に変更もできるとされている。コメントは投稿者と日時のどちらかが欠けた状態では存在できないため、一方だけを省いて移行することはできない。

要するに、BacklogからJiraへコメント履歴を投稿者つきで移すには、Backlog側のユーザー名とJiraのAccount IDの対応表を事前に作る作業が挟まる。この対応表を作らずにCSVをそのまま流し込むと、コメントの本文だけが残り、誰が書いたコメントかという情報が失われる。

壁(3) 添付ファイルは、外部に公開した状態でないと読み込めない

Atlassianのナレッジベースは、CSVによる添付ファイルのインポートについて「Cloud限定の機能であり、添付ファイルはHTTPまたはHTTPS経由で外部からアクセス可能な場所に置かれている必要がある」と明記している。CSVの添付ファイル列にはURLを直接記入する形式で、投稿者と日時を含める場合は「01/01/2012 13:10;Admin;image.png;file://image-name.png」のような書式を使う。指定したURLに到達できない場合は「An exception occurred dealing with "<添付ファイルのURL>"」というエラーで処理が止まる。

BacklogからJiraへ添付ファイルを運ぶ場合、この要件を満たす受け皿を用意する作業が工程に入る。添付ファイルを一括で取り出し、HTTPまたはHTTPSで外部から到達できるストレージに配置したうえで、そのURLをCSVの添付ファイル列に記入する。件数が多いプロジェクトほど、この配置作業の量がそのまま移行の工数に積み上がる。

壁(4) 権限は複製できない。再設計になる

「Backlogの権限・ユーザー管理実務ガイド」で整理したとおり、BacklogのアクセスはAdministrator(管理者)・Project Administrator(プロジェクト管理者)・Member(一般ユーザー)・Guest(ゲスト)という4段階の基本ロールを軸に組み立てられている。一方「Jiraの権限・ロール管理実務ガイド」で整理したとおり、Jiraの権限はサイト全体に適用されるグローバル権限、スペース単位で何ができるかを決める権限スキーム、作業項目ごとの可視性をさらに絞り込む課題セキュリティスキームという3つの層と、権限を人ではなく役割に紐づけるプロジェクトロールの組み合わせで決まる。

この2つの設計は粒度も考え方も異なるため、BacklogのロールをJiraの権限スキームに機械的に当てはめる1対1の対応表は存在しない。移行のたびに「誰が何を作成・編集・削除・閲覧できるか」をJira側の3層構造でゼロから組み直す作業が必要になる。ガバナンスの観点では、この再設計こそが移行プロジェクトの中で最も時間を要する工程になりやすい。CSVでのデータ移行が終わっても、権限の設計が追いついていなければ、意図しない人が作業項目を編集・削除できる状態のまま運用が始まってしまう。

逆方向、JiraからBacklogへの移行は壁が低いか

方向を逆にすると、壁の高さは変わる。Atlassian公式ドキュメントは、Jira Cloudからエクスポートできる対象として「作業項目、ユーザー、ユーザーグループの設定、作業項目の添付ファイル、ユーザーのアバター、スペースのロゴ」を挙げている。添付ファイルそのものがエクスポートの対象に含まれているため、JiraからBacklogへ運ぶ場合は、添付ファイルを外部ストレージに置き直すという壁(3)の手間は発生しない。

受け入れ側のBacklogは、Backlog公式ブログが示す一括登録の仕様で、件名だけが必須で、種別・担当者・開始日・期限日・カテゴリー・マイルストーン・優先度は任意に指定でき、親子課題も同じファイル内で指定できるとしている。担当者はCSVの出力時点でID(数値)として扱われるため、Excel上で名前に置き換える作業を挟む必要があると同記事は説明している。カスタム属性もプロジェクトに合わせた列として一緒に運べる。一括登録は1回のアップロードで250件までとされており、件数が多い場合は分割してアップロードする必要がある。

構造として見ると、JiraからBacklogへの移行は「3階層・3層の権限」という精緻な設計を「親子2階層・4段階ロール」という粗い設計に畳み込む作業になる。情報が欠落する方向ではあるが、欠落のさせ方は「複雑な設定をあきらめて単純化する」という一方向の判断で済み、BacklogからJiraへ移行するときのように先に受け皿を作り込む準備は要らない。どちらの方向でも、Backlog公式ブログが示す「全部移さなくていい」という考え方に立ち返り、本当に運ぶ必要があるデータから優先順位をつけることが、作業量を現実的な範囲に収める。

データ種別ごとに、何が運べるか

ここまでの4つの壁を、データの種類ごとに両方向で並べ直す。

移行作業に入る前には、現在のデータを保管しておく。Backlog公式ヘルプセンターは、課題の検索結果一覧表の右上・右下にあるアイコンから、課題とコメントをCSVまたはExcel形式でダウンロードする操作を案内している。この機能を使えば、移行の成否にかかわらず現在のデータをファイルとして手元に残せる。

段階的に移行を進める手順

4つの壁と、データ種別ごとの違いを踏まえると、移行は一度に全件を流し込む作業ではなく、絞り込み・準備・試行という順番で進める作業になる。

まとめ：運ぶ前に、運ぶ価値があるかを決める

ここまで整理した4つの壁、受け皿の事前準備、担当者とコメント投稿者の識別子変換、添付ファイルの外部公開、権限の再設計は、いずれもツールの機能不足ではなく、BacklogとJiraが異なる設計思想のうえに作られていることから生じる。この違いを飛ばして「とりあえずCSVを流し込む」形で移行を始めると、インポートがエラーで止まるか、エラーなく通っても担当者やコメントの投稿者が欠けた状態のデータが残る。

移行の工数を見積もる際は、CSVファイルの変換作業だけでなく、移行先の受け皿を作る設計作業、ユーザー対応表の作成、権限の再設計という、データそのものの移動とは別の工程を別建てで数えておく必要がある。これらの工程を数えたうえで、それでも乗り換える理由が残るかどうかが、最終的な判断になる。