こんにちは、技術部情報システムグループの黒木です。
2024年2月にConfluenceとJiraをServer版からCloud版に移行完了しました！
これらのシステムはほとんどの社員が毎日利用しているものであり、情報システムグループとしてもかなり大きなプロジェクトでした。
今回データ移行作業はベンダーにお願いしましたが、この記事では移行プロジェクトの流れや各フェーズでのポイントについてお話をしたいと思います。
移行の背景
こちらのブログ記事にもある通り、リブセンスでは長年Server版のConfluence・Jiraを使い続けていました。 made.livesense.co.jp
このタイミングでの移行となったのは2024年2月のServer版サポート終了が大きな理由ですが、それ以外にも以下のような理由があります。
- 全体的な視覚性、操作性、利便性の向上が見込める
- 外部サービス連携による業務効率化が見込める（※Server版でも一部連携可能だが、Cloud版は連携ハードルがより低くなる）
- バージョンアップや脆弱性対応が不要になる、自社サーバーを持つ必要がなくなるなどの管理・運用工数削減
プロジェクトの流れと各フェーズでのポイント
移行方針策定
移行先
期間の縛りや移行コストの兼ね合いから最終的にCloud版への移行を選択しましたが、他社製品やDataCenter版など移行先の選択肢を洗い出し、検討を行いました。
また、データについても全てを移行する形ではなく、今回の移行タイミングで必要データのみに絞り、新規ページやチケットの作成がなく参照頻度の低いConfluenceスペースやJiraプロジェクトは移行対象から除外しました。
Cloud版環境でアーカイブしておくことも1つの選択肢でしたが、Server版のデータ容量が膨大になっており、将来的にシステムリプレイスがあった場合の移行ハードルを下げておくことも目的としていたため、上記のようなデータは対象外としました。
認証
移行前の構成は以下の通りです。
上記構成を以下のように変更しました。
今回Atlassian Accessを追加し、GoogleSAML認証とユーザープロビジョニングを実現しました。
既に実装済みだったGoogleのコンテキストアウェアアクセスによるデバイス制御と併せて、Atlassian製品へのユーザー認証もGoogleSAMLに統合することでセキュリティ向上を図りました。
これにより、情報システムグループで管理していなかったAtlassian製品にもGoogleSAMLが強制適用され、共通のAtlassianアカウントを利用してのアクセスとなったため、退職時や異動時のアカウント削除漏れを防ぐこともできます。
また、ユーザープロビジョニングによってGoogleアカウント発行/削除のタイミングでAtlassianアカウントが有効/無効化されるため、管理者側の工数削減にも繋がっています。
トライアル環境での移行前調査と社内周知
弊社のServer版Confluence・Jiraは少々バージョンが古いものを使っていたため、Cloud版と仕様が違う点がいくつかありました。
これらを事前調査し資料化して全社へと事前案内することで、移行前の懸念事項や注意事項を洗い出し、移行後の混乱がないようにしました。
また、社内へはCloud版移行のメリット（同時編集やアプリ連携、オートメーション機能など）も大きくアピールし、移行に対するポジティブな印象をもってもらうような働きかけも行いました。
移行作業
移行作業は「検証」「リハーサル」「本番」の3フェーズに分けて行いました。
検証
この段階での検証はベンダー側での手順確認と移行作業にかかる時間を測定することが目的です。
検証結果を元にリハーサル及び本番のスケジューリングを行いました。
後述するリハーサルと本番フェーズでも同様ですが、移行作業としては本番環境への影響がないよう下図のように中継サーバーを介してデータ移行を行いました。 （中継サーバーは弊社側で構築し、ベンダーには構築した中継サーバーからCloud版環境へと移行してもらう流れです）
こうすることで、データ移行を業務時間中に実施しても本番環境へ負荷がかかりません。 また、移行元環境で修正して移行したいようなケースがあったとしても、中継サーバーで修正すれば本番環境に影響はありません。
データ移行については、Atlassian公式のMigration Assistantというツールが提供されているため、そちらを利用してベンダーによる移行作業を実施しました。
リハーサル
リハーサル段階では再度最新データをCloud版環境に移行し、実際の利用者にCloud版の環境に触れてもらう期間（UAT：User Acceptance Test）を2週間設けました。
特にマクロについては利用実績が多く、Server版で利用できていたものがCloud版には対応しておらず、移行できないものも多かったため、管理者側（情報システムグループ）でも細かくチェックを行いました。 移行できないマクロをリストアップして、利用者へ必要に応じて手動移行 or 修正してもらうよう手順書化して依頼しました。
UATを実施することで、管理者側で把握していなかった利用方法（JavaScriptを利用したJiraチケットへのテンプレ文言挿入など）や足りていない設定などが洗い出され、本番移行前にそれらを解消しておくことができました。
本番
利用者への影響を小さくするために、移行作業は3回に分けて実施しました。
1回目：添付ファイルのみの移行
2回目：Jira及びConfluenceサイトスペースの移行
3回目：Confluenceの全社共通スペース、個人スペースの移行
ベンダー作業後には確認作業を行いました。 その際、データ件数やユーザー数、権限等のチェックだけではなく、検証やリハーサル時点で確認できた課題点やマクロの反映など、事前にリストアップしていた確認項目についてもチェックを行いました。 確認項目を事前に作成しておくことで、確認作業をスムーズに終えることができました。
しかし、ちょうど本番運用開始するぞというタイミングでAtlassianの認証まわりの障害が起きてしまいました。 アカウントのアクティベーションが上手くいかなかったり、その影響で検索がうまく機能しなくなったりなど、移行後は少々混乱もありました。 とはいえその後は数日で解消が確認でき、今は安定的に利用することができています。
本番移行後の対応
Confluenceの新旧URL対応表取得
今回の移行でConfluenceのURLが全体的に変更になってしまうとのことで、事前にベンダーに申請をお願いし、Atlassian社から新旧URL対応表を取得しました。
また、社内では同じ技術部のソリューションチームと連携しリダイレクトの仕組みを構築しました。
詳細はこちら↓↓
SaaS移行で発生したURL変更に自作リダイレクトツールで対応した話 - LIVESENSE ENGINEER BLOG
部署内で閉じずに他部署と連携したことでこういったリリースが短期間で実現できました。 この仕組みについては、社内からも喜びの声が多く上がっていました。
まとめ
さて、ここまでプロジェクトの流れを辿ってきました。
今回はConfluenceとJiraというかなり影響範囲の大きいシステム移行だったのに対し、スケジュールの遅れもなく終えることができました。 移行後の問い合わせは製品障害の影響によるもの以外発生していません。
移行作業がうまくいったポイントとしては以下の3点を挙げたいと思います。
- 事前調査を怠らず、移行前後の機能差分や注意事項を明示することで利用者の混乱を低減できるよう努めたこと
- 移行できないマクロの対応について資料化した など
- 利用者視点に立ち、利用者が移行で気にするであろうポイントに対して前もって準備を行ったこと
- Confluenceの新旧URL対応表を取得できるよう準備した など
- ベンダーとの認識相違が起きないよう努めたこと
- 報告や連絡タイミングを事前にすり合わせておく
- WBSを常に最新状態に保ってもらう
- 共通の課題管理表による進捗管理を行う（弊社とベンダーでどちらボールのものかも明確にしておく） など
Server版とCloud版でUIが大きく変わったり、機能差分がいくつかあったりするにも関わらず、使用方法に関する問い合わせもほとんどなく、社内メンバーのキャッチアップ力にも助けられていたと思います。
Cloud版移行による機能追加について社内から喜びの声をもらったり、情報システムグループとしても管理工数が軽減していることを実感したりしています。
その後も安定的に運用できていますが、今後はさらなる付加価値の提供によって、今回の移行がより良いものになっていくよう引き続き情報システムグループメンバー全員で取り組んでいきます。
