ちなみに、データセンターの利用スペース内にグループ企業のシステムやベンダー保有のシステムなどを置いている場合もあるでしょう。それらの担当者にも忘れずに連携しましょう。
システムの利用部門に対しては、原則的には通常のシステムメンテナンスと同様のプロセスで、停止時間や影響などの情報連携を行います。ただし、できれば、システム個別に調整を始める前に、移転プロジェクトチームから概要レベルの情報を提示しておくことでその後の調整がスムーズに進むこともあります。
各システム担当の調整の負荷を減らすためにも「プロジェクト概要」「期間」「影響」「システム利用部門側に依頼、協力いただきたい旨」について簡潔にまとめたものを展開できるとよいでしょう。システム向けの移転計画書を抜粋して利用できるとよいですね。
移転の作業関係者は、データセンターに入り実際の工事や搬送を行うメンバーです。移転プロジェクトチームとともに移転計画を詳細化していくプロセスを進め、全体スケジュール、各移転作業当日のタイムチャート、作業手順書、機器の配置図などの作成を実施します。また、作成したそれらの情報を共有します。
実際にデータセンターに入るメンバーがスムーズに作業できるよう、新しいデータセンターの「入退館やPC利用、機器の持ち込み、車両の利用、セキュリティに関するルール」をまとめておくことも必要ですね。郊外や地方のデータセンターの場合は、交通ルートや近隣の飲食店、ビジネスホテルなどのTipsを書き添えると喜ばれます。
2.「えっ、全員引越希望日がバラバラ？」希望を聞いていたら移転作業回数が膨大に…素直に見積もったら費用が大変なことに
前回の第6回では、引っ越し（物理的な搬送作業）の見積についてお話ししました。引っ越しコストの要因の一つは、搬送の回数です。搬送作業ごとに、梱包・輸送・搬入そのもののコスト、また設置や工事などのコストもかかります。引っ越しのタイミングは極力集約し、回数を限定したほうがよいでしょう。
このためには、システム担当者と日程を検討する際、自由な日程を提示してもらうのではなく、プロジェクトチーム側である程度指定する、または「可能な日」ではなく「NGである日」をヒアリングする方法もあります。規模と期間にもよりますが、仮に移転を週末作業とすると、最低隔週～隔月で1回程度の頻度に抑えるよう計画しないと、移転以外のシステムメンテナンス作業とのバッティングやプロジェクトメンバーの疲弊を招きます。
ただし、移転日を集約するのであれば、移転日当日の作業量は極力減らせるように作業を分解することを検討しましょう。当日でなくてはできないこと、後日で可能なことを分けて、長時間の作業や待機などを削減できないか、タイムチャートを検討します。移転プロジェクトは、ある程度長期にわたるプロジェクトですので、コストとメンバーの作業負荷、双方のバランスをとっていくことが必要です。
