システム本番移行計画書で書くべき６つのこと（記載例つき）

システムを本番移行する際にはいくつかのポイントを整理のうえ、システム内部と顧客（利用者）との合意を得なければなりません。

今回はそういったシステム本番移行前に作成する「システム本番移行計画書」について書くべきポイントを整理しました。

システム移行計画書に書くべきこと

システム移行計画書に書くべきことは下記の5W1Hです。

1. システム/機能の目的（Why）
2. 移行対象（What）
3. 移行方法（How）
4. 移行に伴う影響範囲（Where）
5. 移行スケジュール（When）
6. 移行体制と連絡先（Who）

システム移行計画書は利用部門を含めて方案に問題がないかを確認する資料のため、細かい作業手順までは記載しません。作業手順は「本番移行手順書」として整理します。

それではそれぞれの項目について補足していきます。

0. まえがき

まえがきとして「資料の目的」を書いておくと、本文に導入しやすいです。

記載例）
当資料は、請求書電子開示システムの本番移行について、移行対象・影響・スケジュール・移行方法・体制等を整理することで、関係者の理解を深めスムーズな本番移行を目的とする。

1. システム/機能の目的（Why）

システム移行計画書には「システム（あるいは機能）の用途・目的を記載しましょう。

システム移行前には有識者に声をかけて移行計画のレビューを行いますが、ベテラン有識者はシステムが本番移行された姿をイメージしながら計画書に目を通していくので、システムの用途・用途が書かれていないとイメージが狂ってしまいレビューの効果が半減してしまうからです。

記載例）
1.システムの目的
請求書電子開示システムは、現在手作業で郵送している請求書を電子化（PDF）し、社外ポータル上に開示することで、取引先が自由にダウンロードできるようにするシステムである。

上記はシステムの目的に加えて、「社外ポータル」という稼働基盤についても簡単に記載しています。こういった稼働前提を書いておくとレビュー側としては内容に入りやすいです。

2. 移行対象（What）

今回の移行対象を記載します。レビュー者はここの記載で移行対象に抜け漏れがないかを判断します。

大きなプロジェクトでは段階的な移行を行う場合がありますが、そういう場合はプロジェクト全体移行計画書を作成し、移行フェーズ毎に移行計画書を整理します。そのうえで「今回のフェーズの移行対象は下記の通りです〜」といった流れで移行対象を述べます。

移行対象には下記のように基盤系とAP系に分かれますが、移行計画書として整理すべき内容は同じです。

移行対象の種類
基盤系：ハードウェアやミドルウェア
ＡＰ系：アプリケーションやデータ

記載例）
2.移行対象
1) システム基盤
1-1）オンライン環境
WASにインスタンスを追加

1-2）バッチ環境
●●●●●●●●●●
※ジョブ管理は既存（xxx）を利用

1-3）DB環境（Oracle）
既存PDB（xxx）にスキーマを追加

2) アプリケーション
2-1）オンライン機能一覧
2-2）バッチ機能一覧
2-3）バッチジョブ一覧

3) 業務データ
業務データの移行は行わない。
本番後の発行分から管理対象とする。

業務データ移行の要否は要件定義時点で合意しておくこと。モメる要因になります。上記例で言えば移行直前になって「過去分の請求書も電子開示してもらわないと困る！」と言われてもシステム対応できません。

3. 移行方法（How）

前述の移行対象をどのように移行するかを整理します。また、トラブル発生に備えて旧システムへの切り戻し方法についても記載しておきましょう。

記載例）
3.移行および切り戻し方法
1）移行方法
1-1）新システム
今回の本番移行は新規システムのため、システム停止は不要。
基盤構築が完了後、アプリケーションを本番環境にデプロイし、必要な初期設定を行う。

1-2）既存システム
既存システムの移行機能はバッチのみであるため、システム停止は不要。
ただし、新システムの稼働前提となる機能のため、既存システムを先にデプロイする。

2）切り戻し方法
2-1）新規システム
新規のためシステムの切り戻しは不可。

2-2）既存システム
改修機能の障害が発生し、復旧までに時間を要することが考えられる場合は協議のうえ、改修前の状態へと切り戻しを行う。

システム停止や切り戻しが発生しない新システムは難易度が低いですが、既存システムについては障害が発生したときの対処方法（切り戻しなど）を必ず考えておきましょう。（でないと、本番移行して障害が発生したときにパニックになります）

4. 移行に伴う影響範囲（Where）

続いてシステム本番移行に伴う影響範囲についてです。大きなプロジェクトになればなるほど影響範囲が馬鹿デカくなるので難易度が高くなります。

記載例）
4.移行に伴う影響範囲
新システムのため、移行時のシステム停止は発生しない。
（既存システムの停止も発生しない）

今回の例ではシステム停止なし（＝ 影響なし）としていますが、当然ながら移行内容によってはシステム停止が必要となる場合もあります。そういった場合は「xx月xx日 xx:xx 〜 xx月xx日 xx:xx までシステムを停止する」というように停止時間を明記しましょう。

業務影響を抑えるかがポイントになるので、昼休みや定時後、あるいは休日での本番移行を選択することもあれば、段階的な移行を考えることもあります。

5. 移行スケジュール（When）

移行スケジュールは、①日単位と②時間単位のタスクを整理します。

① 日単位スケジュール
移行判定〜業務利用開始までの主要タスクを記載する。

②時間単位スケジュール
移行当日のタスクと役割などを記載する。具体的な作業手順は「本番移行手順書」に記載するため移行計画書には書かない。

上記の例は極めてシンプルなものですが、イメージは伝わると思います。このように誰が・いつ・何をするのかが分かるように整理をしましょう。

6. 移行体制（Who）

本番移行の体制をシステム側および顧客側（利用者）をそれぞれ整理します。関係者の多いプロジェクトは連絡が漏れる可能性も高くなってしまうので、体制図に表記することでリスクを軽減できます。

体制図に連絡先電話番号まで書くかどうかは判断が分かれると思いますが、少なくとも私は自分の会社携帯には連絡ができるように関係者の番号は入れるようにしています。

下記は体制図のイメージです。

以上、システム移行計画書に書くべきポイントを述べてきました。

小さなメンテナンスであっても、こういった内容を整理しておくことで移行漏れや考慮漏れのリスクを減らすことができます。初回は整理するのが面倒ですが、一度整理してしまえば次回移行はコピペで必要なところを修正していけるので作成負荷も少なくなります。

ご参考になりますと幸いです。