サーバーリプレース計画書の書き方【項目と書くべき内容】

仕事・現場リアル

サーバーリプレースの計画書を作ることになった。

でも、何を書けばいいのかわからない——。

正直に告白します。私も最初に計画書を任されたとき、白紙のドキュメントを前にして固まりました。前任者が残したものを見ても、案件ごとに書き方がバラバラで、何が正解なのかわからなかったんです。

19年やってきて、今なら言えます。

計画書は、自分のためではなく「関係者の判断のため」に書く文書です。

顧客が承認するため。上長が体制を判断するため。作業者が当日動けるため。読み手が違えば、必要な情報も違います。

今回は、リプレース計画書に必要な項目と、それぞれ何を書くべきかを実務目線でまとめます。

リプレース全体の進め方はサーバーのリプレース作業で失敗しないための進め方にまとめているので、流れを先に押さえたい方はそちらから読んでみてください。

計画書は、誰のために書くのか

項目の前に、ここを押さえておくと迷いが減ります。

リプレース計画書には、読み手が3種類います。

1. 承認する人(顧客の責任者、自社の上長)

知りたいのは「やっていいか判断できる材料」です。目的、費用、リスク、影響範囲。技術的な詳細より、判断に必要な情報を求めています。

2. 調整する人(顧客の情報システム部門)

知りたいのは「社内にどう説明し、いつ何を止めるか」です。スケジュール、停止時間、影響を受ける部署。この人は計画書を持って社内を回ります。

3. 作業する人(自社のメンバー、協力会社)

知りたいのは「当日何をするか」です。作業手順、体制、判断基準。

1つの計画書で3者を満たす必要があります。だから項目が多くなる。逆に言えば、この3者の視点で読み返せば、抜けに気づけます。


リプレース計画書の11項目

構成としては、この11項目を押さえれば大きく外しません。案件の規模によって、削るか統合するかを判断します。

  1. 目的・背景
  2. 対象範囲
  3. 現行環境と新環境の構成
  4. 移行方式
  5. スケジュール
  6. 体制と役割分担
  7. 作業内容(当日の流れ)
  8. テスト計画
  9. 切り戻し計画
  10. 影響範囲と停止時間
  11. リスクと対応策

以下、それぞれ何を書くかを見ていきます。


①目的・背景:なぜやるのかを1ページで

意外と軽視されますが、ここが弱いと承認が通りません

書くべき内容は、この3つです。

  • なぜリプレースが必要なのか(老朽化、サポート終了、性能限界など)
  • やらなかった場合に何が起きるか
  • リプレースによって何が改善されるか

「やらないリスク」を書くのがポイントです。

「サポートが終了するから」だけでは弱い。「サポート終了後は脆弱性が修正されず、セキュリティインシデントのリスクが高まる」まで書くと、判断材料になります。


②対象範囲:やること・やらないことを明記する

トラブルの半分は、ここの曖昧さから生まれます。

  • 対象となるサーバー、システム、機器の一覧
  • 移行するデータの範囲
  • 今回のスコープに含まれないもの

特に3つ目が重要です。「アプリケーションの改修は含まない」「クライアント端末の設定変更は顧客対応」——こういう線引きを書いておかないと、後から「それも含まれていると思っていた」となります。

私は必ず「本作業に含まれない範囲」という項目を独立して立てています。書きにくい内容ですが、書かないほうが後で揉めます。


③現行環境と新環境の構成

現行と新環境を、対比できる形で示します。

  • サーバー構成(台数、スペック、OS、ミドルウェア)
  • ネットワーク構成(IPアドレス、セグメント)
  • 連携している外部システム
  • 変更点の一覧

変更点の一覧が特に大事です。「何が変わるのか」が一目でわかると、顧客側も影響を検討しやすくなります。

構成図は文章より伝わるので、簡易的でも入れておくことをおすすめします。


④移行方式:どうやって移すのか

方式によってリスクもスケジュールも変わるので、明示します。

代表的な方式は3つです。

  • 一括移行:一度にすべて切り替える。期間は短いが、失敗時の影響が大きい
  • 段階移行:システム単位、拠点単位で分けて移行。期間は長いが、リスクは分散
  • 並行稼働:新旧を一定期間並行させる。安全だが、コストと運用負荷が高い

なぜその方式を選んだのかの理由も書いておくと、承認が通りやすくなります。「業務停止を最小化するため段階移行を選択」といった形です。


⑤スケジュール:全体と当日を分けて書く

スケジュールは、粒度を分けて2種類書きます。

全体スケジュール(週単位・月単位)

設計、構築、テスト、移行、切り替え後の並行監視期間まで。

移行当日のタイムライン(分単位)

当日の作業は、時刻を切って書きます。

20:00  サービス停止、利用者への告知
20:15  最終バックアップ取得
21:00  データ移行開始
23:30  データ移行完了、整合性確認
00:30  新環境でのサービス起動
01:00  疎通確認・動作確認
02:00  判定会議(継続 or 切り戻し)
03:00  サービス再開、利用者への連絡

「判定ポイント」を必ず入れてください。 「この時刻までに完了していなければ切り戻す」という基準がないと、当日ずるずると時間が延びます。


⑥体制と役割分担

誰が何をやるのかを明確にします。

  • 各作業の担当者(自社、顧客、ベンダー)
  • 当日の連絡体制(緊急連絡先、エスカレーション先)
  • 判断権限を持つ人(誰が切り戻しを決めるか

特に「判断権限を持つ人」は必ず書いてください。深夜作業中に「これ、続けていいんですかね」となったとき、誰に聞けばいいかが決まっていないと、時間だけが過ぎます。

顧客側の緊急連絡先も、事前に確認しておきます。


⑦作業内容:当日の流れ

⑤のタイムラインを、もう少し具体的にしたものです。

  • 各作業のステップ
  • 使用するツール、コマンド
  • 各作業の想定所要時間
  • 確認ポイント

計画書に詳細な手順まで書くか、別途手順書を作るかは規模次第です。大規模案件なら「詳細は別紙手順書のとおり」として分離したほうが読みやすくなります。


⑧テスト計画:何をどこまで確認するか

計画書には、テストの方針と区分を書きます。

  • テストの区分(単体、連携、バッチ、性能、障害、運用)
  • 各区分で確認する内容の概要
  • テストの実施期間と担当
  • 合格基準

合格基準を書いておくのがポイントです。「正常に動作すること」では曖昧なので、「現行と同等のレスポンスであること」など、判定できる形にします。

具体的なテスト項目は、サーバーリプレースのテスト項目一覧【現場で実際に確認していること】に一覧としてまとめています。計画書には方針を書き、詳細は別紙にするのが実務的です。


⑨切り戻し計画:失敗したときにどうするか

ここが書かれていない計画書は、承認されるべきではありません。

書くべき内容は3つです。

  • 切り戻しの判断基準(何が起きたら戻すか、何時までに完了しなければ戻すか)
  • 切り戻しの手順(どうやって元に戻すか)
  • 切り戻しに要する時間

一番大事なのは、切り戻しに何時間かかるかです。

たとえば深夜2時に「切り戻そう」と判断しても、切り戻しに3時間かかるなら、朝5時までかかります。業務開始に間に合うのか。間に合わないなら、判断はもっと早い時刻にしなければならない。

この逆算をしておかないと、当日「戻すこともできない」状況に陥ります。


⑩影響範囲と停止時間

顧客が社内調整に使う情報です。ここが具体的でないと、顧客は動けません。

  • 停止するシステム・サービス
  • 停止時間(開始時刻と終了予定時刻)
  • 影響を受ける部署、利用者
  • 業務への影響内容
  • 利用者への告知内容と告知タイミング

停止時間には余裕を持たせてください。 「23時〜翌1時」と伝えて2時までかかると信頼を失います。想定より長めに告知して早く終わるほうが、はるかに印象がいいです。


⑪リスクと対応策

想定されるリスクと、その対応を書きます。

書き方としては、この3点セットにすると伝わります。

  • リスクの内容
  • 発生した場合の影響
  • 対応策(予防策と、起きた場合の対処)

リスクを書くのは「起きるかもしれない」と認めることなので、抵抗があるかもしれません。 でも、書いておくと2つの効果があります。

  1. 顧客が心構えを持てる(起きたときの信頼低下が小さい)
  2. 事前に対策を検討できる

隠して起きるより、書いて備えるほうが結果的に評価されます。


承認を通すためのコツ

最後に、実務的な話を3つ。

1. 判断に必要な情報を、前半に集める

承認者は全部を読みません。目的、影響範囲、スケジュール、リスク——判断に使う情報は前半に置きます。技術詳細は後半か別紙へ。

2. 数字を入れる

「停止時間は短い」ではなく「停止時間は3時間(23:00〜翌2:00)」。曖昧な表現は質問を呼びます。

3. 事前に口頭で握っておく

計画書を出す前に、キーパーソンと方向性をすり合わせておく。いきなり完成品を出すと、根本から覆されることがあります。計画書は合意を確認する文書であって、合意を作る文書ではありません。


まとめ

サーバーリプレース計画書の項目をまとめます。

必要な11項目

  1. 目的・背景 — やらないリスクまで書く
  2. 対象範囲 — 含まれない範囲を明記する
  3. 現行環境と新環境の構成 — 変更点の一覧が重要
  4. 移行方式 — 選んだ理由も書く
  5. スケジュール — 全体と当日を分ける、判定ポイントを入れる
  6. 体制と役割分担 — 判断権限を持つ人を明確に
  7. 作業内容 — 詳細は別紙手順書でも可
  8. テスト計画 — 合格基準を判定できる形に
  9. 切り戻し計画 — 所要時間から逆算する
  10. 影響範囲と停止時間 — 余裕を持って告知
  11. リスクと対応策 — 隠さず書いて備える

承認を通すコツ

  • 判断に必要な情報を前半に集める
  • 数字を入れる
  • 事前に口頭で握っておく

計画書は、書くのに時間がかかります。正直、面倒です。

でも、計画書に時間をかけた案件ほど、当日は静かに終わります。逆に、計画が甘い案件は必ず当日にしわ寄せが来ます。

次のリプレースで、この項目リストが少しでも役に立てば嬉しいです。

コメント

タイトルとURLをコピーしました