移行・カットオーバー計画の要点

開発が終わっても、プロジェクトは終わりません。作ったものを実際の業務に載せ替える移行（カットオーバー）が残っています。そして、プロジェクトが最も派手に失敗するのは、たいていこの工程です。

理由は単純で、やり直しがきかないからです。設計の誤りは直せますが、本番データを壊した夜は取り返せません。移行計画は、その一晩を無事に越えるための準備です。

移行リハーサルから稼働後支援までの流れと移行判定基準を示した図

この流れで最も省略されやすいのが移行リハーサルです。日程が押してくると「本番でやれば同じだから」と省きたくなりますが、リハーサルの目的は手順の確認だけではありません。所要時間の実測にあります。

データ移行に何時間かかるかは、実際に流してみないと分かりません。「8時間で終わる想定」が実際には14時間かかると判明するのは、リハーサルをやった場合だけです。本番当日に判明すれば、業務開始時刻に間に合いません。

新旧システムの切り替え方には、いくつかの型があります。

どれが正解ということはなく、業務を止められる時間の長さと、失敗したときの影響の大きさで決まります。重要なのは、選んだ理由を関係者と共有しておくことです。並行稼働を選べば現場の負荷が上がり、一斉移行を選べばリスクが上がる。どちらの負担を引き受けるかという選択だからです。

移行計画で最も重要なのは、うまくいく手順ではなく、うまくいかなかったときに戻る手順です。

最後の項目を事前に決めておくことが決定的です。当日その場で判断しようとすると、「あと少しで終わりそうだ」という心理が働き、引き返せる時刻を過ぎてしまいます。「午前4時までに完了していなければ切り戻す」と紙に書いておき、その時刻に判断する人を決めておきます。

そして、切り戻し手順もリハーサルで試しておきます。試していない手順は、手順書があっても使えません。

技術的に最も手間がかかるのがデータ移行です。想定外は、ほぼ既存データの側から出てきます。

これらは仕様書を読んでも出てきません。早い段階で実データを抽出し、件数と内容を確認する作業（データプロファイリング）を挟むことで、設計に間に合います。移行直前に発見すると、手作業での修正を強いられます。

移行は情報システムだけの作業ではありません。利用部門の準備が整っていなければ、稼働初日に業務が止まります。

とくに最後の項目は、日程を決める最初の段階で確認します。月初の処理が集中する日に移行するような計画は、それだけで難度が跳ね上がります。

移行が完了した時点で解散してしまうプロジェクトがありますが、問い合わせが最も多いのは稼働直後の1〜2週間です。

この期間の体制を、あらかじめ計画に含めておきます。開発メンバーが一定期間は対応に入れる状態にしておき、落ち着いたところで運用・保守へ引き継ぐ。この期間を計画に入れていないと、メンバーは次の案件に移っており、誰も答えられない状況になります。

移行は、プロジェクトの中で唯一、やり直しのきかない工程です。だからこそ、判断の基準と引き返す手順を先に決めておくことが、当日の冷静さを支えます。準備の質が、そのまま当日の余裕になります。

ユーザーコメント（0）