仮説検証で完成した移行時間予測ロジック。大手HR企業、約10万人の1PB(ペタバイト)データの移行を支援
・大手HR・販促事業及びグローバル斡旋・販促事業会社における、EOSL（メーカー保守終了）をきっかけとしたファイルサーバリプレイスのプロジェクト。
・中長期で社内ICT環境のクラウド化を進めており、単なるファイルサーバのリプレイスでは無く、クラウド化を推進したい意志がクライアント側にあった。
・ファイルサーバに内包するデータサイズが約1PB(ペタバイト)と、超大容量であり且つ利用者が約10万人のため個々人でデータ移行させるには、社内NWトラフィックの問題や完了確認の点から困難であった。
・特にデータ移行視点では、超大規模な上に技術的にニッチであり且つユーザー業務理解と調整が必要であり、技術理解がありユーザーとの調整・管理が出来るマルチな人材が必要であった。加えて、ユーザー調整を行うにあたりこの企業の社風理解も必須であり、経験者が必要であった。
・プロジェクト参画の背景
従来より、情報システム部門にて関連会社のユーザーとICT情報の展開・調整の支援を行っていたメンバーが、データ移行の実施仕様の作成と実行支援について参画要請をいただいた。
・役割と戦略
①ファイルサーバ移行の実施仕様（方式、単位、スケジュール等）を管理方法も含め検討・作成の支援を行う。
②実行に付随して掛かる具体的な資料・手順・テストについて検討・作成の支援を行う。
③ユーザー対応を主として実施精度を高く保ち、スケジュールの順守・コストの最適化に努めたデータ移行の支援。
・移行仕様・移行マスタスケジュールの設計・調整支援
・移行準備（申請書・手順書などの作成・作成支援、ユーザーコミュニケーション用のアプリ仕様調整、実施・管理に使用するマスタデータの設計・作成など）
・ユーザー調整/問い合わせ対応・支援
・移行管理（実績管理、トラブル時のリカバリ対応・調整、レポーティング）
データ量が巨大であるため移行に時間が掛かるが、ファイルサーバと言うサービスの特性上、利用停止のポイントを作れないためデータ移行の技術的工夫だけでは乗り切れない状況であった。こうした課題に対して、ミクレニティが取り組んだことは、データの静止点が必要であるため、移行仕様の調整とユーザー調整を横断的に行う事で、ユーザーの利便性を損なう事を最小限とした静止点を作り出す事ができた。
スケジュールが年単位と長期である事、また、ファイルサーバのデータ量(サイズ・数量)は日々変化する事から、当初調整・決定したものからリスケジュールせざるを得ない状況がある程度発生する状況が予想された。こうした課題に対して、ミクレニティが取り組んだことは、予めユーザーへのヒアリングを行う事と想定するリスケジュールのシミュレーションを行い、受入可能な代案を用意した。
国内でもトップサイズのリプレイスプロジェクト
今回のプロジェクトは、利用者約10万人かつデータサイズは1PB(ペタバイト)など、日本国内でもかなり上位に入るのではないかと思える程の巨大ボリュームに加え、「希望によりSharePointOnline/GoogleDriveも選択可能」とする移行を実現する事となり、経験のない未知の領域の移行プロジェクトにチャレンジする事となりました。
仮説と検証の繰り返し。移行時間予測ロジックの完成
まずは正確な状況把握から実施する事となりました。“どの部署”に“どの程度の利用者”が居て“どの程度のデータ量”を持っていて、それは“いつ”使えないといけないのか。
これを、移行専門のエンジニアチームを中心に移行に掛かる時間の測定・検証を行いました。データ量と移行時間の関係性を把握する事で、データ量から移行時間を予測し、スケジュールを立てるためです。
予感はしていましたが、最初のこの時点で問題に直面する事となりました。試行回数を重ね精度は上がりますが、予測するための“精度”が上がりませんでした。業務データ量は日々更新が加えられ増減します。
さらに、検証において同じデータ量でも移行時間に大きな差が出ました。特にSharePointへの移行はメーカーにも例が無く、インターネットを経由する事から同じ条件下でも結構な幅でブレが出ました。このブレに対して、仮設を立て検証する事を繰り返し、なんとか“移行時間予測ロジックVer1.0”(笑)が完成しました。
移行先の選択とスケジュール調整の難しさ
次に、ユーザーとの調整です。移行先の選択肢が増えた事で移行の自由度は広がったものの、これが思ったより調整難易度を上げる事となりました。
移行先を選択するためには、ユーザーに移行先のサービス内容・特性をある程度理解いただく必要があります。加えて、該当するデータに業務上の特性があって、例えば経理系で言えば月末月初にデータへのアクセスが集中するので、移行のスケジュールを組んで欲しく無いなどです。
この企業は、多種多様なサービスを展開しているためユーザーのＩＴリテラシはまちまちです。これを解決するため、ユーザー向けにYes/Noの選択肢に答えていくだけでお奨めの移行先が提示される資料を考案したり予めNG日程をヒアリングする、さらにこれらを専用のサイトとアプリを作り、手続きを分かりやすく後から確認しやすくするなど随所に工夫をちりばめてすり合わせを行いました。
後から聞いた話ですが、今回の移行は従来の移行と比較して難しかったが情報がまとまってて見やすく、部署内への周知や展開がスムーズに行ったと言う声もいただきました。
プロジェクトを振り返ってみて。ファイルサーバ移行を極めること
多くの企業さんは、ファイルサーバ移行でこれだけ手間を掛けて移行する事はなかなか見ないのでは無いでしょうか。
良く見る方法としては新しいファイルサーバーを用意して、一定期間を設けて、各部署で移行して古いファイルサーバーは期間終了後火を落とす、と言う方法では無いでしょうか。実はこの企業さんも何度かこの案は上がるのですが、何しろデータが巨大でユーザー数も多いので、移行時のNW流量の問題やドラッグ＆ドロップでは移行出来ないなどのトラブル、さらには移行残りが出た際のリカバリなどを考えると、結局前始末をした方が良いと言う結論になりました。
ここまで深くファイルサーバー移行にタッチすると、他のどんな企業さんのファイルサーバー移行が来ても怖くない位の経験・知見は得られたかなと思いますね(笑)