この記事は
リクルート ICT統括室 Advent Calendar 2023 11日目の記事です。

こんにちは、ICT統括室の中村 昌也と申します。
今年度のお仕事では、オンプレのファイルサーバからクラウドサービスへのデータ移行をどのように進めるかを考えて、実際に推進する役割を担っていました。

この記事では、7日目の記事で掲載しました「オンプレのファイルサーバから、SharePoint・Google Driveといったクラウドストレージへの移行PJ」において、データ移行を行っていくにあたり、どのように現場と調整してきたかについてお話したいと思います。

既存サービスから新サービスへの移行対応で、多くの現場調整が必要となるような案件を担当している方に少しでも参考になれば幸いです。

1) 移行の概要

■ 移行元：オンプレのファイルサーバ
リクルートではオンプレのファイルサーバを構築し、ボリューム単位に切り出して各現場に提供しています。ボリューム毎に利用用途や管理者／利用者が異なります。

■ 移行先：各種クラウドサービス
今回は移行先として以下のサービスを選定しています。
A) クラウドストレージ(SharePoint/GoogleDrive)
B) クラウドNAS (Amazon FSx NetApp ONTAP)

移行対象となるファイルサーバ内のボリューム数は全体で約2200個ありました。
それらをボリューム単位で各現場の利用者からも合意を得た上で「いつ、どこに、どのように移行するのか？」を確定し、期日までに全てのデータを漏れなく移行完遂させなければいけないというのが私のミッションでした。

2) 現場調整から移行実施までの流れ

① ボリューム単位で移行担当者の決定
利用者1人1人とやり取りすることは現実的ではないため、各ボリューム毎に代表者(以降、"移行担当者"と表現します)を選出してもらいました。

② 移行先の確定
移行担当者に、移行先対象候補であるSharePoint/Google Drive/クラウドNASから選択を依頼しました。
7日目の記事の通り、会社方針としてクラウドシフトを目指しているため、今回は移行先を複数併用することも許容する形としました。

③ 移行日の確定
②にて確定した移行先情報を元に、まずはプロジェクトにて各ボリュームの移行時期を決定しました。
その後、プロジェクトで確定した日で問題ないかをボリューム単位で移行担当者に通知し、現場側の合意を得た上で移行日を確定します。

④ 移行実施
移行日を迎えたボリュームの移行を実施します。

3) 過去案件の経験を通して感じていた課題感

・過去の同様の移行推進案件では、Excel等で取りまとめ用のファイルを作成して、現場との移行調整やプロジェクト内での移行管理を実施していました。しかし、用途毎にファイルがどんどん増えてしまったり、下記のような人為的なミスも発生しました。(そのリカバリに時間がかかり、プロジェクトとしても追加工数がかかり、本来業務にも支障が…)
– 実例1：関係者にファイル共有しながら一斉にファイル更新していたところ、フィルタ／コピペの弊害で無意識に関係のないセルも更新されてしまった。
– 実例2：個別に現場担当者とコミュニケーションを取る際、必要な情報をExcelから転記するようなケースで誤って別の人の情報を転記してしまった。

・一度上記のようなケースが発生してしまうと、現場側でも「ちゃんと自分達の回答が反映されているのかな…？」という不信感につながってしまいます。その不安から、何度もプロジェクトに対して状況確認を行ったり、プロジェクトとしてもその対応を行うという悪循環に陥ってしまいます。

4) どのように解決しようとしたか

・Excel等のファイルをベースとした力業での管理にはある種限界を感じたため、現場／プロジェクト双方のWillを満たせるような別の手段での実現が必要でした。

• 現場サイドのWill　　　　 ：「自分達に関係する正しい情報が欲しい」
  「プロジェクトに確認しなくても最新の状態を知りたい」
• プロジェクトサイドのWill ：「手作業を減らしたい、人為ミスをなくしたい」
  「現場からの回答も含めて常に最新の情報を確認／管理したい」

・そこで今回の移行案件では、現場もプロジェクトも各自の好きなタイミングで常にその時点での最新データを確認でき、双方が同一のものを見ながらコミュニケーションができるようなプラットフォーム構築を目指しました。
・プラットフォーム構築にあたり、今回はMicrosoft365のPowerシリーズ(PowerApps/PowerAutomate)を活用することにしました。

<選定のポイント>
・プロジェクトという期間が定まっている案件だからこその”スピード重視のローコード開発”に注目しました。
・リクルートでは社員／パートナー含めてほぼ全員がMicrosoft365アカウントを保持しているため、Microsoft365製品との相性が良かったという点も大きな選定理由の1つです。どの製品を活用するかは会社／組織の特徴に応じて決定すると良いかと思います。

5) プラットフォーム構築での工夫ポイント

Ⅰ. 全ての土台となる"情報管理マスタ"を決める
今回はPowerAppsを採用した事もあり、"SharePointリスト"にて情報を管理することとしました。

<ポイント>
SharePointリストは5000件以上になるとパフォーマンス影響があると言われているため、扱う情報の量も１つポイントになるかと思います。今回は移行対象ボリューム数が約2200個ということもあり、5000以内に余裕をもっておさまっていたため、SharePointリストを採用しました。

Ⅱ. 現場メンバの操作は可能な限り少なくする
例えば、プロジェクトにて決定した移行日を通知して現場側と合意を取るようなケースでは、
プロジェクトからの通知内にあるリンクをクリック(①)し、移行日の確認(②)と「移行日を確認しました」のボタン押下(③)の3ステップで調整が完了するようにしました。

Ⅲ. 管理ステータスを定義し現場メンバやプロジェクト側のアクションと連動させる
各ボリュームが今どのような状況／状態なのか、最新を管理／把握する必要があります。
今回は↓↓のようにステータスを定義し、現場メンバ側のアクション(例えばボタン押下)やプロジェクト側のアクション(ユーザメール通知等)と連動して、自動的にステータスを更新するようにしました。それにより、タイムリーに状況を把握することが可能になりました。

<ステータス変更例>
・プロジェクトから移行日通知を実施：「移行日未展開」→「移行日確定待ち」
・現場メンバが移行日確定ボタンを押下：「移行日確定待ち」→「移行日確定」

Ⅳ. 通知系は全てアプリからの通知
人手で各自のメーラーを使って通知をすることは人為ミスとなる原因の一つ。
プロジェクトに関わる通知は事前に通知文面を用意しておき、プロジェクト側のボタン操作トリガーや日付トリガーでの発信とすることで、通知漏れや通知ミスを極力防止しました。

Ⅴ. 全ボリュームの移行状況を可視化
現場向け／プロジェクト向けそれぞれに全ボリュームの移行状況を可視化した一覧画面を作成。
データソースは同じマスタ情報であるため、常に同じ情報を見ながら現場とプロジェクトがやり取りできるようになりました。

<ポイント>
最初は現場向け／プロジェクト向けと分けずに一律同じ画面でも良いかと考えましたが、現場側とプロジェクト側で見たい情報も異なり、改善要望も異なる観点で挙がる事が多いと想定し、それぞれ分けて作成することにしました。
(結果的にも分けていたことで各々挙がってくる要望に対して柔軟に対応することができました)

6) 効果

・まず、現場メンバの実施する操作を可能な限りシンプルにしたことで、過去案件と比較しても圧倒的に現場からの回答が早く回答率も高くなりました。
・プロジェクト側としても、常に最新の回答状況を確認できるので、次に必要となるアクションプランが立てやすく、問題発生時も素早く検知できるようになりました。(未回答の人がいたらすぐにその人に対して直接確認する 等)
・アプリによる自動化にて、人手作業を極限まで減らしたことにより人為ミスが過去案件に比べて大幅に減少しました。その結果、以前はリカバリに費やしていた工数がなくなり、本来業務等に時間を割くことができました。
・総じて、これまで無駄にかかっていたコミュニケーションの工数を減らして、本来やり取りしなければならないことに注力できたことで順調に現場調整を行うことができました。

7) 最後に

プロジェクトとしては、予定していた全てのデータ移行を無事完了しました。
今回の営みは他の案件でも活用できる工夫点だと考えていますので、引き続き他の案件でもこの知見を活かしながら、更なるブラッシュアップをしていければと考えています。

リクルート ICT統括室 Advent Calendar 2023では、リクルートの社内ICTに関する記事を投稿していく予定です。もし興味があれば、ぜひ他の記事もあわせてご参照ください。