Jira Cloud移行：ID・グループ統合と権限引継ぎ

Jira Cloud 移行ナレッジ Server/DCからCloudへの移行 ID・グループ統合と権限引継ぎガイド 認証キーの変換・グループ乱立回避・段階的移行を成功させる実践設計 岡崎 文哉 LOG Sprout合同会社

LOG Sprout合同会社のご紹介 Mission 「想いを形に、未来を紡ぐ。」 人の多様な経験からなる小さな気づきを記録（LOG）し、積み 上げ、芽開く（Sprout）。 単なるツール移行で終わらせず、現場の限界を超える「質の高 い伴走」で組織の成長を牽引します。 © LOG Sprout G.K. All rights reserved. 会社概要 商号: LOG Sprout合同会社 ミッション: チーム伴走型ITイノベーションの推進 事業内容: アジャイル開発・Jira活用定着コンサルティング ITインフラ・ツール運用の伴走型業務改善支援、その他 2

Cloud移行時に直面する「アカウント＆権限」の壁 Server/DC版のデータをそのまま移行しようとすると、アーキテクチャの違いによりトラブルが頻発します。 旧環境のデータ/権限を そのまま一括移行 ➔ キー不一致・重複発生 アカウント紐付け失敗 ➔ グループ競合・多重化 権限設定の破綻・無秩序化 💡 本資料の位置付けと公式ガイドの参照について 本内容はAtlassianの移行案内から、特に現場で発生しがちな「ID・認証・権限」の課題をピックアップして特筆しています。 全体の最新手引きについては Atlassian 公式サイトの Jira Cloud 移行ガイド も併せてご参照ください。 © LOG Sprout G.K. All rights reserved. 3

• https://www.atlassian.com/ja/migration/plan/cloud-guide#setup-in-cloud

認証キーの違い：User ID から メールアドレスへ 旧 Server / DC 版の識別キー User ID （例: john_doe） LDAP / Active Directory の `sAMAccountName` 等に依存 メールアドレスが空白・ダミー値でもシステムは稼働可能 だった ドメイン名を含まない一意の文字列で識別管理 © LOG Sprout G.K. All rights reserved. Jira Cloud 版の識別キー メールアドレス （例: [email protected]） Atlassian account の仕様により メールアドレスが一意の鍵 移行ツール（JCMA）は「メールアドレス」をマッチング キーとして移行 アドレスが不正だと、別ユーザーとして新規作成されるか 移行失敗 4

メールアドレス不整合の3大トラブルと事前対策 1. メールアドレスの「空白」 2. 同一アドレスの「重複」 3. 「未所有外部ドメイン」 対策: AD/IdP側で ダミー無効化アドレスを一括補完 対策: ユーザー単位の 一意な個人アドレスへ修正 対策: 社外用ドメイン払い出しまたは 招待フロー統一 旧環境で退職者やシステムアカウントの メールアドレスが空欄になっている。 © LOG Sprout G.K. All rights reserved. 複数の旧User IDで同じ共通メーリングリ スト宛先が登録されている。 社外パートナーの個人アドレス （`gmail.com` 等）が 直登録されている。 5

グループ管理構造の違い：インスタンス単位 から 組織単位へ Cloud版は「組織（Organization）」で集中管理 Server/DC版ではJiraインスタンスごとにグループが完結していま したが、Cloud版では上位の「Atlassian Organization（組織）」 全体でグループを共有します。 他製品や他サイト間でもグループを使い回せるメリットがある反 面、命名規則の重複や衝突が起きます。 © LOG Sprout G.K. All rights reserved. 既定グループ名の不一致（競合） 区分 アクセス権 管理単位 連携技術 Server / DC 版 `jira-users` インスタンス個別 LDAP 直結 Cloud 版 `jira-software-users-` Organization 全体 SAML / SCIM (IdP) 6

移行時に発生する「グループ多重化・権限破綻」 旧グループのまま移行した際のアクシデント 旧環境の `jira-users` や社内共有グループをそのまま移行すると、 Cloud側の自動生成グループ（`jira-software-users-`）と二重登録 状態が発生します。 結果: 誰がライセンスを消費しているのか把握不能になり、異動・ 退職時の権限剥奪漏れやライセンスコスト激増につながります。 © LOG Sprout G.K. All rights reserved. 単一のグループを複数用途で使い回さない 「ログイン権限」「管理者権限」「プロジェクトの閲覧権限」を すべて1つのグループで兼務させている状態を解消しなければ、 Cloud移行後の権限統制は不可能です。 7

【解決策】グループ用途の3分離原則とライセンス要件 1. 製品アクセス用 ライセンス消費の制御 例: `jira-software-users` SCIMプロビジョニング連携 プロジェクト権限に使用しない 2. グローバル権限用 全体の作成・管理権限 例: `jira-project-creators` 雇用形態属性（正社員等）と連動 特定管理者・責任者のみ付与 3. PJロール用 PJ内での配役・役割 例: `all-fulltime-employees` PJロールに付与するIdPグループ 現場リードが柔軟に指定 📌 重要：Atlassian Guard std（旧Atlassian Access）のライセンス要件 IdP（Okta/Entra ID等）とSCIMプロビジョニング連携を行うには、Atlassian Guard Standard エディション以上 が必須です。 ※ Cloud契約が Enterpriseプラン や Teamwork Collection の場合は Guard が標準付帯されます。それ以外のプラン（Standard/Premium）の場合は、個 別契約が必要かどうかのライセンス判断が事前に必要となります。 © LOG Sprout G.K. All rights reserved. 8

Active Directory を同一ソースとした並行連携アーキテクチャ 【単一マスター構成】同一 AD を起源とするデュアル同期アーキテクチャ 同一データソース ➔ LDAP Atlassian専用OU （グループ・メール精査済） ➔ 同期Agent Active Directory 【従来ルート】現行環境への同期 現行稼働維持 Jira Server / DC 版 【追加ルート①】クラウドIdP IdP (Okta / Entra ID) ➔ SCIM 【追加ルート②】Cloud環境 Jira Cloud 版 ※ IdP ➔ Jira Cloud への SCIMプロビジョニングには Atlassian Guard std が使用されます。 デュアル同期による最大のメリット：メンバー差分の即時追従 業務都合により移行期間中に人事異動・メンバー追加が毎日発生する環境であっても、Active Directoryを単一マスターとして両環境へ並行で直接 同期させます。 事前にSCIMでCloud側へ正しいアカウント・グループ基盤（受皿）を自動生成しておくことで、新旧環境間の乖離を最小限に抑えた安全な移行が 実現します。 © LOG Sprout G.K. All rights reserved. 9

移行スケジュールの原則 と 大規模環境での「ウェーブ方式」 ⚠️【大前提】移行は「極力短期間」でやり切る 💡【現実解】大規模環境での「ウェーブ方式」 クラウド仕様更新への追従: JCMA（移行ツール）やCloud側仕様は頻繁にアップデートされるた め、期間が長引くほど「事前リハーサルで未発生だった不具合」へ遭 遇するリスクが急増します。 二重管理コストの削減: 新旧環境の並行期間を短縮し、情シスの運用の負担を最小化します。 依存関係の薄い単位で分割切り替え: 独立性の高いPJ単位等に移行対象を切り分け（ウェーブ化）、影響範 囲を局所化します。 メンテナンス時間枠内で完結: 各ウェーブの移行を夜間・週末の短時間で完了させ、翌営業日からス ムーズにCloud利用を開始します。 原則として、移行プロジェクトは長期化させず短期間で一気に切り 替えることが推奨されます。 © LOG Sprout G.K. All rights reserved. PJ数やデータ量が膨大な環境では、一括移行だとメンテナンス時間 （夜間・週末）内に完了できません。 10

まとめ：ID・グループ移行 成功のための3つの鉄則 アカウントクレンジングとグループ用途分離で安全なCloud移行を実現 1. 移行前にメールアドレス（認証キー）の不整合を完全クレンジングする （AD/IdP側で一意なメールアドレスを付与し、空白・重複・外部ドメイン問題を事前に解消する） 2. グループ用途を分離し、Atlassian Guard要件（SCIM）を事前確認する （3分離原則を適用し、SCIMに必要なGuardライセンスの有無・個別の必要性を評価する） 3. デュアル同期で乖離を防ぎ、大規模環境では短時間ウェーブ方式で切り替える （短期間移行を原則としつつ、事前にIdP経由でユーザー・グループのアカウント基盤（受皿）をCloud側に自動生成し、夜間・週末のメンテナ ンス枠内でPJ切替を完遂する） © LOG Sprout G.K. All rights reserved. 11

ご清聴ありがとうございました。 © LOG Sprout G.K. All rights reserved. 12