2007年1月に基幹システムを「地銀共同化システム」に移行した常陽銀行は，本番移行に先駆けてリハーサル（予行演習）を繰り返した。同行では，「システム間の相関関係が複雑過ぎて影響範囲が読み切れず，段階移行は困難」（システム部 次長 尾又良一氏）との理由で一括移行を選択していた。第3回で解説したように，一括移行はリスクが高い。リスクを抑えるために，8回ものリハーサルを通じて移行手順を確立した（図1）。

図1●リハーサルを繰り返すことで本番移行時のトラブル要因を取り除ける
図1●リハーサルを繰り返すことで本番移行時のトラブル要因を取り除ける
常陽銀行の尾又良一氏らは，基幹システムの一括移行で合計8回ものリハーサルを実施した。リハーサルのたびに「改善項目」を洗い出し，次回のリハーサルに反映した
[画像のクリックで拡大表示]

　8回には及ばなくとも，多くの現場は2～3回のリハーサルは実施して本番に臨むものである。ところが，せっかくリハーサルをしても，十分に生かし切れないケースは多い。「対象のあいまいさ」と「臨場感の不足」が，リハーサルの効果を減退させてしまうのだ。

「手順」と「時間」の妥当性をチェックする

　リハーサルの目的は「計画書通りに作業すれば間違いなく移行できる」と確認すること。分かってはいても，リハーサルの最中に新システムのバグが見つかると，ついついバグの修正を始めてしまいがち。「リハーサルがいつのまにか結合テストにすり替わっていたこともある」（富士通 産業ビジネス本部 システム事業部 プロジェクト部長 島津めぐみ氏）。こんな経験は多くのエンジニアが持っているはずだ。

　こうした混乱が起こる要因として，リハーサルで「何を検証するか」があいまいなことが挙げられる。リハーサルでの検証対象は，「リハーサル計画書」に明記する。具体的には，システム全体のどの部分の移行か，移行プロセス内のどのタスクか――など，対象を明らかにしておく。

　対象を絞り込んだうえで，特に重点的にチェックすべきポイントが二つある。「手順」と「時間」である。移行手順は，リハーサル前までに「移行手順書」に明記しておくが，この内容に間違いがあると，正しく移行できることはまずあり得ない。例えば，実行しなければならないコマンドが漏れたり，確認すべきメッセージ内容が書かれていなかったりすると，失敗のリスクが高くなるのは当然だ。一方，移行時間が見積もりと大幅にずれると，予定していたサービス開始時刻に間に合わなくなってしまう。

手順の正しさは最低ライン

図2●切り戻しの条件や手順を検証して手順書や工程表に反映する
図2●切り戻しの条件や手順を検証して手順書や工程表に反映する
いつ，どうなったら，移行を中断して現行システムにどのように切り戻すのかも，リハーサルを通じて明確化し，検証する。東映アニメーションの遠田浩文氏らは，Windowsドメインの移行で切り戻し（回復）ポイントを手順書に明記した（上）。常陽銀行の尾又良一氏らは，切り戻しに特化した工程表を作成した（下）
[画像のクリックで拡大表示]

　移行開始から完了に至る手順の正しさを確かめることは，厳守すべき最低ラインである。現実にはそれだけでなく，移行を中断して復元する「切り戻し」の条件や手順をチェックしておくことが必要だ。それらは，手順書や工程表に反映する（図2）。

　基幹システムの移行に伴い社内インフラのWindowsドメインを「Active Directory」に切り替えた東映アニメーションの遠田浩文氏（情報システム室）は，移行を支援した日本IBMのエンジニアの協力を得て，切り戻せるポイントを移行手順書に「回復ポイント」として書き記し，リハーサルで実際に切り戻せることを確認した。常陽銀行の尾又氏らの場合は，切り戻しに特化した工程表を準備。移行中止を決断してから，休暇明けの業務開始時間までにシステムを切り戻せるかどうかを，時間を計って確かめた。

　移行手順書の内容が正しいかどうかだけではなく，読み手に誤解や勘違いの余地がないかもチェックしたい。図2上の項番0-1には「ドメインコントローラのフルバックアップを確認」とある。こうした記述は，できればフルバックアップを確認するにはどうするか，どう表示されたらフルバックアップできていることになるのか――まで書き込むことが望ましい。

　東映アニメーションの場合は，エンジニアである遠田氏が実際の作業を担当したのであまり問題にならなかったが，システムの所有部門の担当者が移行に立ち会う場合などは特に，誰が見ても分かる記述レベルにしておかないと，作業の実施承認を得られないことがある。そこで，「実際に入力するコマンド・ラインをそのまま記述し，実行結果の確認方法は（業務担当者が見ても分かるように）表示内容をそのまま記入する」（NEC 第一OMCS事業部 事業部長 上席プロジェクトオーガナイザ 小川真示氏）ようにしたい。移行手順書は構成管理の対象とし，勝手に修正したり，古い移行手順書を誤って使用したりすることがないように管理することも不可欠である。