「サーバーのリプレース、どれくらいかかりますか」
顧客からこう聞かれたとき、即答できますか。
正直に告白します。私は若いころ、この質問に感覚で答えていました。「3ヶ月くらいですかね」と。
そして、まったく足りませんでした。
調査に思ったより時間がかかり、機器の納期が読めず、テスト期間が削られ、最後は深夜作業の連続。あのときの見通しの甘さは、今でも反省しています。
今回は、リプレースの工程ごとにどれくらいの期間がかかり、どんな体制が必要かを書きます。案件の規模で変わりますが、目安があるだけで見通しが立てやすくなります。
リプレース全体の進め方はサーバーのリプレース作業で失敗しないための進め方にまとめているので、流れを先に押さえたい方はそちらから読んでみてください。
全体像：企画から完了まで
まず、工程を6つに分けて整理します。
| 工程 | 期間の目安 | 主担当 |
|---|---|---|
| ①企画・要件定義 | 1〜2ヶ月 | 顧客＋営業＋リーダー |
| ②設計 | 1〜2ヶ月 | 設計担当 |
| ③調達 | 1〜3ヶ月 | 営業＋調達 |
| ④構築 | 1〜2ヶ月 | 構築担当 |
| ⑤テスト | 3週間〜1ヶ月 | 構築＋運用 |
| ⑥移行・切替 | 1日〜1週間 | 全員 |
| ⑦切替後フォロー | 1ヶ月 | 運用担当 |
合計すると、小規模でも4〜6ヶ月、中規模なら6〜12ヶ月が目安です。
「3ヶ月でできますか」と聞かれることがありますが、よほど小さい構成でない限り厳しいというのが実感です。
以下、工程ごとに見ていきます。
①企画・要件定義：1〜2ヶ月
何をするか
- リプレースの目的整理（老朽化、サポート終了、性能限界）
- 現行環境の調査
- 要件のヒアリング
- 概算見積の提示
- 予算取得の支援
なぜ時間がかかるか
一番読めないのが、顧客側の意思決定です。
技術的な検討は2週間もあれば終わります。でも、社内稟議、予算承認、関係部署との調整——ここに1ヶ月以上かかることは珍しくありません。
見落としやすい点
現行環境の調査を甘く見ないこと。
「構成図があるから大丈夫」と思っていたら、実際は更新されていなかった。連携しているシステムが把握できていなかった。この段階の抜けが、後工程すべてに響きます。
②設計：1〜2ヶ月
何をするか
- 新環境の構成設計
- ネットワーク設計
- 移行方式の決定
- 移行計画書の作成
体制
設計担当が1〜2名。顧客との認識合わせのため、リーダーも並行して動きます。
なぜ時間がかかるか
設計そのものより、レビューと承認に時間がかかります。
設計書を出して、顧客が確認して、指摘が返ってきて、修正して、また確認——このサイクルが2〜3回は回ります。
計画書に何を書くべきかはサーバーリプレース計画書の書き方にまとめました。
③調達：1〜3ヶ月
ここが一番読みにくい工程です。
何をするか
- 機器・ライセンスの発注
- 納品
- 検収
なぜ読めないか
納期が外部要因で決まるからです。
自社の努力ではどうにもなりません。半導体不足のような状況があれば、3ヶ月待ちも普通に起きます。クラウドなら調達は不要ですが、オンプレなら必ずここがボトルネックになります。
対策
- 見積の段階で納期を確認する（概算でいいので押さえる）
- 納期が読めない場合、スケジュールに余裕を持たせる
- 顧客にも「納期次第で全体がずれる」と事前に伝えておく
私は過去に、機器の納期遅れで全体スケジュールが2ヶ月ずれた案件があります。こればかりは、早めに動く以外に対策がありません。
④構築：1〜2ヶ月
何をするか
- OS・ミドルウェアのインストール
- 設定
- 単体での動作確認
体制
構築担当が1〜3名。規模によりますが、ここは並行して進められる部分が多いです。
この工程の特徴
比較的、期間の見積が立てやすい工程です。台数と作業内容が決まっていれば、工数は計算できます。
ただし、想定外の設定でハマることはあります。古いアプリケーションを新しいOSで動かすとき、互換性の問題で時間を取られることも。
バッファを1〜2週間見ておくと安心です。
⑤テスト：3週間〜1ヶ月
一番削られやすく、一番削ってはいけない工程です。
何をするか
- 単体テスト
- 連携テスト
- バッチ・定期処理テスト
- 性能テスト
- 障害テスト
- 運用テスト
体制
構築担当に加え、運用担当も参加します。実際に運用する人が触らないと、運用テストになりません。
なぜ時間がかかるか
月次バッチの確認があるからです。
日次・週次はすぐ確認できますが、月次処理は時刻を変えて強制実行するなどの工夫が必要です。ここを飛ばすと、移行の翌月に問題が出ます。
具体的なテスト項目はサーバーリプレースのテスト項目一覧にまとめました。
⑥移行・切替：1日〜1週間
何をするか
- データ移行
- 切り替え作業
- 動作確認
- 判定
体制
全員参加です。 構築担当、運用担当、顧客側の担当者、必要に応じてベンダー。
そして、判断できる人が必ず現場にいること。 深夜作業中に「これ、続けていいですか」となったとき、決められる人がいないと止まります。
期間
一括移行なら1日（深夜作業）。段階移行なら数日〜1週間。
当日の作業内容はサーバーリプレースの作業項目に時系列でまとめました。
⑦切替後フォロー：1ヶ月
ここまでが工程です。 切り替えたら終わり、ではありません。
何をするか
- 翌営業日の稼働確認
- 問い合わせ対応
- 週次バッチの初回確認
- 月次バッチの初回確認
- 旧環境の停止・撤去
なぜ1ヶ月か
月次処理を1回通すまで、完了とは言えないからです。
移行の翌月に月次バッチが動かない。これは実際によくある事故です。カレンダーに印を付けて、必ず確認してください。
体制の考え方
工程によって、必要な人が変わります。
ずっと関わる人
- リーダー・PM：全工程。顧客との窓口、判断、進捗管理
工程ごとに入る人
- 設計担当：②設計が中心。③〜⑤でも相談対応
- 構築担当：④構築、⑤テスト、⑥移行
- 運用担当：⑤テストから参加。⑥移行、⑦フォロー
運用担当を早めに巻き込むのがポイントです。
テストから参加してもらうと、運用目線での指摘が出ます。そして何より、移行後に自分たちが運用する環境を、自分で確認できる。これは後々の安心感が違います。
スケジュールを引くときのコツ
最後に、実務的な話を3つ。
1. 後ろから逆算する
「いつまでに切り替える必要があるか」から逆算します。サポート終了日、契約更新日、繁忙期を避ける——制約から決めるほうが現実的です。
2. 調達にバッファを置く
一番読めないのが調達です。ここに余裕がないと、全体が崩れます。
3. テスト期間を先に確保する
削られやすいので、最初から工程として明示しておきます。「テストは3週間」と書いておけば、削るときに議論が必要になります。曖昧にしておくと、いつの間にか消えます。
まとめ
サーバーリプレースの工程と期間の目安をまとめます。
全体：小規模4〜6ヶ月、中規模6〜12ヶ月
- 企画・要件定義（1〜2ヶ月）— 顧客の意思決定に時間がかかる
- 設計（1〜2ヶ月）— レビューと承認のサイクルが2〜3回
- 調達（1〜3ヶ月）— 外部要因で読めない。最大のリスク
- 構築（1〜2ヶ月）— 見積は立てやすいが、互換性でハマることも
- テスト（3週間〜1ヶ月）— 月次バッチの確認が必要
- 移行・切替（1日〜1週間）— 全員参加、判断できる人が現場に
- 切替後フォロー（1ヶ月）— 月次処理を1回通すまでが完了
スケジュールのコツ
- 後ろから逆算する
- 調達にバッファを置く
- テスト期間を先に確保する
「どれくらいかかりますか」と聞かれたとき、感覚で答えないこと。
工程ごとに積み上げて答えれば、根拠のある期間を示せます。そして、その根拠があるからこそ、途中で削られそうになったときに説明できます。
次のリプレースが、無理のないスケジュールで進むことを願っています。
コメント