Atlassian 組織統合ガイド

要約

アトラシアン組織を統合 (すべての製品/サイトを 1 つの組織から別の組織に転送) する場合、完了までにさまざまな段階が必要です。

このプロセスは主にアトラシアン側で発生し、移行を実現するにあたってさまざまな要件が表面化する可能性があるため、この KB 記事ではプロセスを実現するための準備や期待値について説明します。

アトラシアン組織とユーザー管理 - 異なるエクスペリエンス

まずは、概要を把握して Atlassian 組織の基本を理解しましょう。「Atlassian 組織の使用を開始する」には次のようにあります。

「Atlassian 組織では、全社的な管理設定を確認できます。Atlassian 組織の使用を開始するには、2 つの方法があります。1) 新しいアトラシアン製品にサインアップするか、2) 製品なしで組織を作成するかのいずれかです。

さらに、アトラシアン組織では一元化されたユーザー管理と元のユーザー管理の違いにより、異なるエクスペリエンスが提供されます。これらの違いをまとめると次のようになります。詳細については「アトラシアン組織とは何ですか?」と「アトラシアンの管理をナビゲートする」をご確認ください。

組織の統合

アトラシアンの組織の仕組みをご存知の場合、すべてのサイトとユーザーを単一の組織に統合したいとお考えかもしれません。しかしながら、組織の統合には技術的な側面があり、お客様のビジネスにとって最適ではない可能性があります。

統合の可能性を検討するには、まずは「アトラシアンの組織をマージできますか?」を確認する必要があります。このリンクでは次のような内容が確認できます。

• 対象の組織の統合が技術的に可能かどうか

• ご利用の組織に複数のサイトがあるかどうか

• 一元化されたユーザー管理をすでに使っているかどうか

• Atlassian Guard のサブスクリプションをお持ちかどうか

• お客様のビジネスに最適かどうか

• このプロセスの背後にあるメリット

• 統合しないほうがよい理由

• 組織間で特定の製品のみを移動する

統合を依頼する前に

「すべての製品を別の組織に転送する - 転送の計画」や「アトラシアンの組織をマージできますか?」にあるように、プロセスの背後にあるものを理解することが重要です。

• 統合プロセスでは、統合元の組織から統合先の組織にサイト、製品、およびユーザーが統合されます。

• 統合プロセスでは組織管理者が統合され、統合元組織の組織管理者は統合後に統合先組織の組織管理者になります。組織管理者のグループに製品アクセスが付与されていた場合、これによって対象の製品のライセンス制限の超過が発生する可能性があります。

• 統合先組織で同じアカウント/ユーザーが非アクティブだった場合、そのユーザーは統合された組織でも非アクティブになるため、統合前の製品へのアクセスを失います。

  • ユーザーに以前と同じアクセスを維持させたい場合、統合前にユーザーが非アクティブになっている組織からユーザーを削除し、それからユーザーをアクティブ化 (一時停止を解除) することをおすすめします。

• このプロセスを元に戻すことはできません。統合後に統合先の組織を元の 2 つの組織に分割することはできません。

• 統合中は、両組織の管理ハブは変更されないように読み取り専用モードになります。

• 3 つ以上の組織の統合をご希望の場合、次の統合までに少なくとも 24 時間の待機時間を設ける必要があります。

• 統合は約 4 時間で問題なく完了することが見込まれています。しかしながら、これはすべての要件が満たされたあとに限られます。

• 両方の組織に同じ名前のグループがある場合、統合中に統合元組織のグループの名前が次の形式を使用して変更されます。

  • {グループ名}--{統合元組織名}

• 統合元組織で組織管理権限の付与に使われていたグループ (org-admins または site-admins) の名前は統合中に legacy-org-admins–{セカンダリ組織名} に変更され、管理権限が付与されなくなります。

• 統合は、通常、シドニー時間の火、水、木、金曜日の午前 9 時から午後 12 時の間に実施されます。

統合前の要件

転送のブロックを解除するにあたり、統合元組織または統合先組織で満たす必要がある要件があります。これらの検証はサポートがお手伝いしますが、準備を整えてやり取りの往復を避けるため、次の点に留意してください。

• 両方の組織が一元化されたユーザー管理を使っている必要があります。

• 両方の組織に 1 人 の共通の組織管理者が必要です。

• アトラシアン サポートのアカウントが組織内に存在することはできません (サポート チケットを通じて同意を得た場合)。

• セカンダリ組織のサイトの合計数は 20 未満である必要があります。

• セカンダリ組織に Trello や Bitbucket などのサイトを含まない製品があってはいけません。

• ユーザー、グループ、グループ メンバーシップの合計数は 180,000 未満である必要があります。

• セカンダリ組織で ユーザー アクセス設定をリセットします。

• どのユーザーも、両組織の間でステータスの競合があってはなりません (ユーザーが組織 A ではアクティブだが、同じアカウントが組織 B では非アクティブであるなど)。

• グループ名は統合プロセス中に変更されるため (統合元と統合先組織の両方に同じ名前のものがあった場合)、グループ名を含む JQL フィルターを取り除いたり、IT サービス管理 (ITSM) 内にスキーマがあればそこからグループを取り除いたりするようにします。これらをセルフサービスで行うための機能リクエストがあります。ここには回避策も含まれています。

• ライセンス超過を防ぐため、グループに存在する非アクティブなユーザーを取り除きます。

このプロセスで期待しておくべきこと

統合では、最初に要件を満たしておく必要があります。つまり、すべての計画作成を含む合計時間は、完了までに数営業日かかる可能性があります。完了までに 1 週間以上かかる場合もあります。ブロッカーが解除されたら、前述のとおり、統合そのものは約 4 時間で終わります。

サポートは統合の実現のため、プロセスを通じて、次のようなさまざまな段階を案内します。

情報収集

すでに完了しているかもしれませんが、サポートが統合元と統合先組織の両方の関連情報を確認します。たとえば、「アトラシアンの組織をマージできますか?」や「製品を別の組織に転送する - 転送チェックリスト: 削除して再作成する設定とサブスクリプション」でハイライトされている内容です。

一元化されたユーザー管理への移行

主な要素の 1 つに、両方の組織で「一元化されたユーザー管理」が使われているのを確認することがあります。「一元化されたユーザー管理」への変換では、次のような異なる要件があります。

• 組織に複数のサイトがある場合、変更が発生している間、管理ハブが読み取り専用モードになります。製品内で変更やダウンタイムは発生しません。

• これを有効化するには、サイト管理者と信頼済みユーザーが組織管理者や通常ユーザーになる必要があります。

一度有効化したあとは次の影響に注意する必要があります。

• 組織内の各サイトがユーザーとグループを管理するための独自のユーザー基盤を持つ代わりに、この組織は組織内のすべてのサイトで共有されるユーザーとグループ用の単一のユーザー基盤を持ちます。このため、ユーザーがサイト内の製品へのアクセス権を持つかどうかにかかわらず、組織内のすべてのサイトにすべてのユーザーが存在します。

• 組織内の全サイトのユーザーとグループは、各サイト内の個々のユーザー管理ではなく、管理ハブの [ディレクトリ] タブで管理されます。

• 認証済みドメインを管理するための [ドメイン] タブは、[ディレクトリ] タブから管理ハブの [設定] タブに移動します。

• [設定] の [管理者] メニューはなくなります。代わりに、[ディレクトリ] タブの [ユーザー] ページからユーザーの組織管理者権限を管理できます。

  • 詳細については、「https://support.atlassian.com/user-management/docs/give-users-admin-permissions/#Centralized-user-management-content 」を参照してください。

• 上記と同様、組織内の複数のサイトに同じ名前を持つ非同期の (IdP) グループがあった場合、それらの名前は 1 つまたはそれ以上のサイトで変更され、サイト名が追加されます。

• 別の組織からこの組織に個々のサイトを転送したり、この組織から別の組織に個々のサイトを転送したりすることはできなくなります。

• 一元化されたユーザー管理エクスペリエンスを無効化したい場合、1 つのサイトを除くすべてのサイトを組織から削除する必要があります。

事前チェック

統合前の要件セッションに記載された条件を確認するために事前チェックを実行します。これ以上ブロッカーがないことを確認する必要があるため、この部分では多少のやり取りの往復が想定されていました。

ドライ ラン レポート

ドライ ラン レポートは実際の変更を行うことなく統合のシミュレーションを行うため、実際の統合で発生する内容の詳細なプレビューを確認できます。ドライ ラン レポートの主なポイントは次のとおりです。

1. 目的: 移行後に非アクティブになるユーザーなど、期待される変更をお知らせするために使われます。これはデバッグ ツールとして機能し、実際の統合前に潜在的な問題を特定するのに役立ちます。

2. プロセス: 事前チェック (前述) に成功すると、「ドライ ラン」レポートが生成されます。このレポートは、レビューと承認のために共有されます。レポートに記載されている変更に異議がなければ、統合作業を進めることができます。

3. コンテンツ: このレポートには多くの場合、技術的な詳細情報が英数字で (AAID、グループ ID、サイト ID) 含まれており、お客様にとって理解しやすい用語に翻訳する必要があることがあります。サポートが翻訳をお手伝いします。

4. 承認: ドライ ラン レポートの承認がないと、統合プロセスは続行されません。これにより、すべての関係者がこれから起こる変化を認識し、同意していることが保証されます。

5. タイミング: 混乱を最小限に抑えてスムーズな移行を実現するために、統合はドライ ラン レポートが提供され承認された直後に行うのが理想的です。

転送後のチェック

統合が完了したら、ユーザー アクセス、グループ名、ライセンスの詳細を確認し、そしてもっとも重要なこととして、すべての再設定 (例: ドメイン認証、SSO の有効化、IdP との接続) を行う必要があります。