Server から Cloud への移行のテスト

移行する前に、クラウド組織を確認してください

現在、移行エクスペリエンスに影響する可能性のある変更をロール アウト中です。admin.atlassian.com の組織で、[ユーザー] リストと [グループ] リストが [ディレクトリ] タブにある場合は、改善されたユーザー管理エクスペリエンスを利用できます。つまり、複数サイト全体のユーザーとグループが組織でマージされます。グループと権限の移行方法に関する詳細を、ご参照ください。ご不明な点がありましたら、サポートまでお問い合わせください。

[ユーザーとグループ] ではなく新しい [ディレクトリ] タブを表示する、新しい admin.atlassian.com ビューの図

テスト移行または UAT の場合、テスト クラウド サイトは、製品サイトもホストしている組織に含まれないものを使用することをお勧めします。製品サイトは、別の組織でホストするようにしてください。これは、関連するユーザーとグループのスムーズな移行を確保するためです。

サーバーまたは Data Center 製品からクラウド製品への移行を計画する際、移行する前にトライアル実行を実施することを強くおすすめします。テスト移行は次のことに役立ちます。

  1. 予想されるダウンタイムも含めた、実際の移行のタイムラインの明確化。

  2. データの検証とユーザー受け入れテスト (UAT) の実行。

  3. ローンチの準備とオンボーディング時のコミュニケーションの構築。

  4. 実際の移行の前に解決する必要がある潜在的な問題や手順の確認。

このガイドでは、ベスト プラクティスやテスト対象を含む、Jira または Confluence のテスト移行を実行する方法の概要を紹介します。

はじめる前に

  • 計画ガイドを確認する: 移行を成功させるには、移行をよく計画する必要があります。テストを開始する前に、移行計画ガイドを確認する時間を確保してください。テストを開始する前に知っておくべき情報を含む、主要なフェーズや各ステップでの考慮事項が記載されています。

  • 移行方法を選択する: クラウド製品への移行にはさまざまな方法があります。テストを行う前に、それらの方法を比較して最適なものを選択する必要があります。

  • 前提条件の完了: 移行方法を選択したら、ドキュメントを確認し、テスト前に実施する必要がある前提条件となる手順がないことを確認します。

動作の仕組み

移行前のチェックを完了したら、移行を開始しましょう。

移行のテストと本番環境の移行の準備におすすめしている基本的なステップの概要は、以下のとおりです。

  1. データのクリーンアップ

  2. クラウド サイトへのサインアップ

  3. (オプション) Atlassian Access のセットアップ

  4. テスト移行の実行

  5. データの確認とユーザー受け入れテスト (UAT) の実施

  6. (オプション) テスト サイトのリセット

  7. 移行手順書の作成

  8. 変更管理とローンチ計画の作成

ステップ 1: データのクリーンアップ

移行するデータが多くなるほど、移行にかかる時間が長くなり、移行がより複雑になる可能性が高くなります。このため、テスト移行を実行する前にデータをクリーンアップする時間を取ることをおすすめしています。これによって、移行がスムーズになり、パフォーマンスの問題が軽減され、クラウド製品での生産性が向上する場合もあります。 

データのクリーン アップの詳細については、「移行前のサーバー インスタンスのクリーン アップ」を参照してください。

ステップ 2: クラウド サイトへのサインアップ

クラウド サイトにサインアップしていない場合、今すぐサインアップを完了しましょう。テストをトライアル サイトで実行するか、本番サイトで実行するかを決定する必要があります。 

トライアル サイトを使用する場合、次のことが可能です。

新しい本番サイトへの移行テストを予定している場合は、Free、Standard、または Premium プランから選択できます。 

サイト名 (URL) の形式は https://example.atlassian.net/ になります。ここで、example はユーザーが指定する一意の文字列です。

サイト名は、クラウド製品に初めてサインアップする際 (例: Jira Software Cloud または Confluence Cloud への初回サインアップ時) に、Atlassian Cloud サイト全体に対して選択されます。

サイト名を指定する際には、いくつかの点に考慮する必要があります。

  • 3 文字以上の一意の文字列にする必要があります。

  • 英数字とハイフンのみを使用できます。

  • 1 文字目または最後の文字をハイフンにすることはできません。

個別のテスト環境とステージング環境を設定する方法については、詳細をご確認ください。

ステップ 3 (オプション): Atlassian Access をセットアップする

Atlassian Access は、SAML SSO、ユーザー プロビジョニング (SCIM)、強制 2 段階認証、監査ログなどのクラウド セキュリティおよびユーザー管理機能を提供します。これはすべてのアトラシアン クラウド製品およびドメインにわたって動作するため、ユーザーとセキュリティ ポリシーを 1 か所で管理できます。 

クラウド製品で Atlassian Access を使用する予定がある場合、テスト移行を開始する前に 30 日の無料トライアルにサインアップし、すべてのユーザーに対して SSO をセットアップして、ユーザー プロビジョニングおよび監査ログをテストできます。30 日以上の期間が必要な場合は、お問い合わせください

ステップ 4: 移行前のチェックリストを完了する

テスト移行を開始する前に、JiraConfluence で移行前のチェックリストを実行して、あなたとそのデータの準備が整っていることを確認します。 

ステップ 5: テスト移行を実行する

移行をテストする準備ができました。

Jira および Confluence Cloud Migration Assistant の場合

  1. Confluence Cloud Migration Assistant」または「Jira Cloud Migration Assistant」に記載されている手順に従い、データをインポートします。 

  2. データを移行したら、クラウド製品で使用する予定のアプリを移行またはインストールします。 

移行を複数回テストする必要がある場合、再インポートする予定のデータを手動で削除する必要があります。これは、移行アシスタントがクラウド サイトにすでに存在するデータを上書きしないためです。データを削除するには 2 つの方法があります。

  1. クラウド サイトからすべてのデータを削除する

  2. 個々のスペースを削除するか、個々のプロジェクトを削除する

データを削除した後にテスト移行を再実行できます。

Jira サイト インポートの場合

  1. Jira サイト インポーターを使用してサーバーからクラウドに移行する」の手順に従ってデータをインポートします。

  2. データを移行した後、クラウド製品で使用する予定のアプリを移行またはインストールします。 

移行を再テストする必要がある場合、Jira のサイト インポートを行うと、以前インポートした Jira データやクラウド サイトに存在するデータなどのすべての既存のコンテンツが削除されます。つまり、過去のテスト移行のデータは自動的に削除されるため、複数回テストする場合に最初にデータを削除する必要はありません。

ステップ 6: データの確認とユーザー受け入れテスト (UAT) の実施

移行後、クラウド サイトを確認して、すべてが想定どおりに動作していることを検証します。 

一般的な確認事項

  • Jira 課題にリンクされている Confluence ページなど、他のコンテンツへのリンクが機能していることを確認します。

  • 他のサーバー製品へのアプリケーション リンクの再構成が必要になる場合があります。この場合、再構成を行ったあとに機能を再テストし、連携が想定どおりに機能していることを確認します。 

  • 移行したアプリやアプリ データが想定どおりに動作していることを確認します。

  • Jira、Confluence、または Bitbucket などの他の製品との連携をテストします。

  • 移行およびローンチ後に予定されるトレーニングやコミュニケーションのためにスクリーンショットを取得し、サーバー製品とクラウド サイトとの間の変更を文書化します。

Jira の場合

  • ワークフローが想定どおりに動作していることを確認します。たとえば、移行されていないサードパーティ製アプリに依存している事後操作がある場合があります。これらがクラウド製品では機能しないが、サーバー サイトでは引き続き機能していることがあります。 

  • 製品の使用やテスト データの作成を試します。新しいプロジェクトの作成、課題の作成と編集、添付ファイルのアップロードなどをテストします。

  • Jira マクロの修復を実行し、動作しなくなったマクロが修正されるかどうかを確認します。

Confluence の場合

  • 添付ファイルが正しくインポートされていることを確認します。

  • 移行したアプリやアプリ データが想定どおりに動作していることを確認します。Gliffy Diagrams などのサードパーティ製アプリに依存しているマクロが動作しない可能性があります。この場合、修正が可能かどうかをアプリ ベンダーにご確認ください。

UAT および変更管理のベスト プラクティス

ユーザー受け入れテストを実施する理由

一部のエンドユーザーにテスト サイトを使用して一般的な日常タスクを模倣してもらう、UAT を実施することをおすすめします。これによって、予期していない問題を把握できるだけでなく、組織が変更に対して準備することができます。

対象に含めるべき人物

これは組織ごとに異なりますが、次のようなユーザーとテストを行うことをご検討ください。

  • 特定のチームのメンバー

  • ヘビー ユーザーと使用頻度の低いユーザーの組み合わせ

  • クラウド サイトに移行する各チームから選定されたメンバー

明確で建設的なフィードバックを提供できるユーザーを選定することもご検討ください。一般に、インプットを得るために、クラウド サイトを使用するすべての主要なユーザー タイプまたはロールを招待することをおすすめします。

テストすべき対象

慣れ親しんだ機能が移行で変更されることによる、ユーザーへの次のような問題を記録するようにします。

  • 新機能

  • 新しいユーザー インターフェイス

  • 異なるアプリ

  • 新しい URL とブックマークの変更

  • ユーザー管理の違い

製品固有の推奨事項

  • Jira Software と Jira Management の場合: スプリントの作成、バックログへの課題の追加、ボードの表示などをテストします。

  • Jira Service Management (旧 Jira Service Desk): キューの表示、ポータル ビューの確認、その他の一般的なアクティビティをエージェントに依頼します。

  • Confluence: 新しいスペースの作成、ページの作成と編集、添付ファイルのアップロードなどをユーザーに試してもらいます。

ユーザーが混乱した領域や機能変更を記録します。これらはローンチ前やオンボーディング時に提供するコミュニケーションとトレーニングに含めることができます。 

ステップ 7 (オプション): テスト サイトをリセットする

本番環境インスタンスを使用してテストしたり、テストを再実行したりする必要がある場合などに、クラウド サイトからデータを削除して再度開始する必要がある場合があります。クラウド サイトからすべてのデータを削除して、既定の設定にリセットするには、次のステップに従います。

ステップ 8: 移行手順書の作成

移行手順書は、移行を完了するために必要な作業をまとめた詳細な手順ガイドです。これを作成することで、本番環境への移行を計画どおりにスムーズに実施できます。

手順書には、プロセスの各ステップ、それらのステップで必要な手順、それらを実施する担当者、予想される時間などを含める必要があります。

ステップ 9: 変更管理とローンチ計画の作成

テストが完了したら、ユーザーが移行の結果としてどのような変更に備えるべきかを予測できるようになります。ユーザーが作業を素早く再開するために必要なトレーニング、ドキュメント、コミュニケーションを準備します。 

これらをまとめる際は、変更内容だけではなく、その理由や、ユーザーが移行から得られるメリットを強調するようにします。

ユーザー向けの一般的なメリットには、以下が含まれます。

  • 無料のクラウド モバイル アプリにアクセスする

  • どこからでも作業を行い、素早く安全にアクセス可能 (VPN は不要)

  • 他の SaaS ツールやクラウド アプリとのより良い連携

詳細情報とサポート

移行をサポートする多数のチャネルをご用意しています。

 

最終更新日 2021年04月28日)
次でキャッシュ 11:07 PM on Nov 26, 2021 |

その他のヘルプ