Atlassian 組織統合ガイド
プラットフォームについて: Cloud のみ - この記事は クラウド プラットフォームのアトラシアン製品に適用されます。
アトラシアン組織を統合 (すべての製品/サイトを 1 つの組織から別の組織に転送) する場合、完了までにさまざまな段階が必要です。
このプロセスは主にアトラシアン側で発生し、移行を実現するにあたってさまざまな要件が表面化する可能性があるため、この KB 記事ではプロセスを実現するための準備や期待値について説明します。
アトラシアン組織とユーザー管理 - 異なるエクスペリエンス
まずはアトラシアン組織の基本を確認しましょう。「アトラシアンの組織の使用を開始する」には次のようにあります。
アトラシアンの組織では、全社的な管理設定を確認できます。アトラシアンの組織は、次の 2 つの方法のいずれかを使用して開始します。1) アトラシアンの新しい製品にサイン アップする、2) 製品なしで組織を作成する
さらに、アトラシアン組織では一元化されたユーザー管理と元のユーザー管理の違いにより、異なるエクスペリエンスが提供されます。これらの違いをまとめると次のようになります。詳細については「アトラシアン組織とは何ですか?」と「アトラシアンの管理をナビゲートする」をご確認ください。
一元化されたユーザー管理
統合されたユーザー基盤: ユーザーとグループは 1 つの組織内のすべてのサイトを横断して中央で管理されます。つまり、すべてのサイトを横断して単一のユーザー ディレクトリが共有されるため、ユーザー管理が簡素化されます。
一元化された管理: ユーザーとグループの管理は、サイトごとに個別に行うのではなく、管理ハブの中央のディレクトリを通じて行われます。
シンプルなアクセス: 単一の招待で複数の製品へのアクセスをユーザーに付与できるほか、ユーザーの詳細情報にすべての製品を横断してアクセスできます。
グループ管理: グループは中央で管理され、サイト間で同じ名前を持つ同期されていないグループは、競合を避けるために名前が変更されます。
制限: 一元化されたユーザー管理の有効化後は、複数の組織を横断して個々のサイトを転送することはできません。一元化されたユーザー管理を無効化するには 1 つのサイトを除くすべてのサイトを削除する必要があります。
元のユーザー管理
分離されたユーザー基盤: 1 つの組織内の各サイトが独自のユーザー基盤を個別に管理するため、サイト間の分離が強化されます。
サイト固有の管理: ユーザーとグループの管理は各サイトで独立して行われるため、プライバシーやコンプライアンス上の理由のために分離が必要な組織にとって有益です。
個別アクセス: ユーザーは個々の製品に招待され、ユーザーの詳細情報は各製品に固有です。
グループ管理: グループは各サイトで個別に管理されるため、柔軟性はありますが、より多くの管理作業が必要になります。
分離によるメリット: このモデルは、異なる地域やプロジェクトでユーザーやコンテンツを分離する必要がある一部の大規模な組織に適しています。
元のユーザー管理には、一元化されたバージョンとの機能差分が提供される予定です。詳細については次のページをご確認ください。 https://community.atlassian.com/t5/Enterprise-articles/An-update-on-the-centralized-user-management-experience-rollout/ba-p/2881501
組織の統合
アトラシアンの組織の仕組みをご存知の場合、すべてのサイトとユーザーを単一の組織に統合したいとお考えかもしれません。しかしながら、組織の統合には技術的な側面があり、お客様のビジネスにとって最適ではない可能性があります。
統合の可能性を検討するには、まずは「アトラシアンの組織をマージできますか?」を確認する必要があります。このリンクでは次のような内容が確認できます。
対象の組織の統合が技術的に可能かどうか
ご利用の組織に複数のサイトがあるかどうか
一元化されたユーザー管理をすでに使っているかどうか
Atlassian Guard のサブスクリプションをお持ちかどうか
お客様のビジネスに最適かどうか
このプロセスの背後にあるメリット
統合しないほうがよい理由
組織間で特定の製品のみを移動する
統合を依頼する前に
「すべての製品を別の組織に転送する - 転送の計画」や「アトラシアンの組織をマージできますか?」にあるように、プロセスの背後にあるものを理解することが重要です。
統合プロセスでは、統合元の組織から統合先の組織にサイト、製品、およびユーザーが統合されます。
統合プロセスでは組織管理者が統合され、統合元組織の組織管理者は統合後に統合先組織の組織管理者になります。組織管理者のグループに製品アクセスが付与されていた場合、これによって対象の製品のライセンス制限の超過が発生する可能性があります。
統合先組織で同じアカウント/ユーザーが非アクティブだった場合、そのユーザーは統合された組織でも非アクティブになるため、統合前の製品へのアクセスを失います。
ユーザーに以前と同じアクセスを維持させたい場合、統合前にユーザーが非アクティブになっている組織からユーザーを削除し、それからユーザーをアクティブ化 (一時停止を解除) することをおすすめします。
このプロセスを元に戻すことはできません。統合後に統合先の組織を元の 2 つの組織に分割することはできません。
統合中は、両組織の管理ハブは変更されないように読み取り専用モードになります。
3 つ以上の組織の統合をご希望の場合、次の統合までに少なくとも 24 時間の待機時間を設ける必要があります。
統合は約 4 時間で問題なく完了することが見込まれています。しかしながら、これはすべての要件が満たされたあとに限られます。
両方の組織に同じ名前のグループがある場合、統合中に統合元組織のグループの名前が次の形式を使用して変更されます。
{グループ名}--{転送元組織名}
統合元組織で組織管理権限の付与に使われていたグループ (org-admins または site-admins) の名前は統合中に legacy-org-admins–{セカンダリ組織名} に変更され、管理権限が付与されなくなります。
統合は、通常、シドニー時間の火、水、木、金曜日の午前 9 時から午後 12 時の間に実施されます。
組織の統合を計画している場合、またはご質問をお持ちの場合は、サポート チーム (support.atlassian.com/contact) までお気軽にお問い合わせください。
統合前の要件
転送のブロックを解除するにあたり、統合元組織または統合先組織で満たす必要がある要件があります。これらの検証はサポートがお手伝いしますが、準備を整えてやり取りの往復を避けるため、次の点に留意してください。
両方の組織が一元化されたユーザー管理を使っている必要があります。
両方の組織に 1 人 の共通の組織管理者が必要です。
アトラシアン サポートのアカウントが組織内に存在することはできません (サポート チケットを通じて同意を得た場合)。
セカンダリ組織のサイトの合計数は 20 未満である必要があります。
セカンダリ組織に Trello や Bitbucket などのサイトを含まない製品があってはいけません。
ユーザー、グループ、グループ メンバーシップの合計数は 180,000 未満である必要があります。
セカンダリ組織でユーザー アクセス設定をリセットします。
- どのユーザーも、両組織の間でステータスの競合があってはなりません (ユーザーが組織 A ではアクティブだが、同じアカウントが組織 B では非アクティブであるなど)。
グループ名は統合プロセス中に変更されるため (統合元と統合先組織の両方に同じ名前のものがあった場合)、グループ名を含む JQL フィルターを取り除いたり、IT サービス管理 (ITSM) 内にスキーマがあればそこからグループを取り除いたりするようにします。これらをセルフサービスで行うための機能リクエストがあります。ここには回避策も含まれています。
ライセンス超過を防ぐため、グループに存在する非アクティブなユーザーを取り除きます。
If you already have a ticket open with the support team, we will contact you to identify and resolve any requirements. You can do this yourself or, in case of any blockers, support might ask for approval to do it on your behalf.
また、サポートは、アトラシアンのアカウントがお客様の組織内に存在しないことを確認するお手伝いをします。このようなアカウントはプロセスをブロックする必要があります。
これらの要件に加えて、「製品を別の組織に転送する - 転送チェックリスト: 削除して再作成する設定とサブスクリプション」も確認する必要があります。
このプロセスで期待しておくべきこと
統合では、最初に要件を満たしておく必要があります。つまり、すべての計画作成を含む合計時間は、完了までに数営業日かかる可能性があります。完了までに 1 週間以上かかる場合もあります。ブロッカーが解除されたら、前述のとおり、統合そのものは約 4 時間で終わります。
サポートは統合の実現のため、プロセスを通じて、次のようなさまざまな段階を案内します。
情報収集
すでに完了しているかもしれませんが、サポートが統合元と統合先組織の両方の関連情報を確認します。たとえば、「アトラシアンの組織をマージできますか?」や「製品を別の組織に転送する - 転送チェックリスト: 削除して再作成する設定とサブスクリプション」でハイライトされている内容です。
一元化されたユーザー管理への移行
主な要素の 1 つに、両方の組織で「一元化されたユーザー管理」が使われているのを確認することがあります。「一元化されたユーザー管理」への変換では、次のような異なる要件があります。
組織に複数のサイトがある場合、変更が発生している間、管理ハブが読み取り専用モードになります。製品内で変更やダウンタイムは発生しません。
これを有効化するには、サイト管理者と信頼済みユーザーが組織管理者や通常ユーザーになる必要があります。
一度有効化したあとは次の影響に注意する必要があります。
組織内の各サイトがユーザーとグループを管理するための独自のユーザー基盤を持つ代わりに、この組織は組織内のすべてのサイトで共有されるユーザーとグループ用の単一のユーザー基盤を持ちます。このため、ユーザーがサイト内の製品へのアクセス権を持つかどうかにかかわらず、組織内のすべてのサイトにすべてのユーザーが存在します。
組織内の全サイトのユーザーとグループは、各サイト内の個々のユーザー管理ではなく、管理ハブの [ディレクトリ] タブで管理されます。
認証済みドメインを管理するための [ドメイン] タブは、[ディレクトリ] タブから管理ハブの [設定] タブに移動します。
[設定] 配下の [管理者] メニューはなくなります。代わりに [ディレクトリ] タブの [ユーザー] ページからユーザーの組織管理権限を管理できます。
上記と同様、組織内の複数のサイトに同じ名前を持つ非同期の (IdP) グループがあった場合、それらの名前は 1 つまたはそれ以上のサイトで変更され、サイト名が追加されます。
別の組織からこの組織に個々のサイトを転送したり、この組織から別の組織に個々のサイトを転送したりすることはできなくなります。
一元化されたユーザー管理エクスペリエンスを無効化したい場合、1 つのサイトを除くすべてのサイトを組織から削除する必要があります。
事前チェック
統合前の要件セッションに記載された条件を確認するために事前チェックを実行します。これ以上ブロッカーがないことを確認する必要があるため、この部分では多少のやり取りの往復が想定されていました。
一元化されたユーザー管理への移行が完了するまでは、これらのブロッカーに関連する変更 (非組織管理者のユーザーをサイト管理者や新しいグループに追加するなど) は行わないでください。これによって新たなブロッカーが発生し、移行が遅れる可能性があります。
ドライ ラン レポート
ドライ ラン レポートは実際の変更を行うことなく統合のシミュレーションを行うため、実際の統合で発生する内容の詳細なプレビューを確認できます。ドライ ラン レポートの主なポイントは次のとおりです。
目的: 移行後に非アクティブになるユーザーなど、期待される変更をお知らせするために使われます。これはデバッグ ツールとして機能し、実際の統合前に潜在的な問題を特定するのに役立ちます。
プロセス: 事前チェック (前述) に成功すると、「ドライ ラン」レポートが生成されます。このレポートは、レビューと承認のために共有されます。レポートに記載されている変更に異議がなければ、統合作業を進めることができます。
コンテンツ: このレポートには多くの場合、技術的な詳細情報が英数字で (AAID、グループ ID、サイト ID) 含まれており、お客様にとって理解しやすい用語に翻訳する必要があることがあります。サポートが翻訳をお手伝いします。
承認: ドライ ラン レポートの承認がないと、統合プロセスは続行されません。これにより、すべての関係者がこれから起こる変化を認識し、同意していることが保証されます。
タイミング: 混乱を最小限に抑えてスムーズな移行を実現するために、統合はドライ ラン レポートが提供され承認された直後に行うのが理想的です。
転送後のチェック
統合が完了したら、ユーザー アクセス、グループ名、ライセンスの詳細を確認し、そしてもっとも重要なこととして、すべての再設定 (例: ドメイン認証、SSO の有効化、IdP との接続) を行う必要があります。