システム開発における移行リハーサルのポイント

コラムカテゴリー：プロジェクトマネジメント

システム開発は家づくりに似ていると言われることがありますが、システム開発の移行を家づくりに例えると引越しに該当します。
家づくりの場合は、家を完成させるまでのコストに対して、引越しのコストが非常に低いこともあり、家が完成してから引越しの準備をすることもあると思います。
しかし、システム開発の移行をこのように捉えてはいけません。
一般社団法人日本情報システム・ユーザー協会の「システム開発・保守調査報告書 2020年版」によると、プロジェクト全体の工数に対する移行の工数割合は平均で7.72%です。
中止・延期を繰り返すと、決して低くないコストが追加となることが分かると思います。
そのようにならないためにも、本コラムに記載する移行リハーサルのポイントを実践していただければと思います。

一言に移行と言っても、それが意味する範囲は広く、移行の内容で分類すると、業務移行、システム移行、データ移行に分けることができます。
業務移行には新システム稼働後に必要な業務の移行、システム移行にはサーバやネットワークなどの移行、データ移行にはデータベースに格納されたデータなどの移行があります。
これら3つの移行について、業務移行を受入テスト、システム移行とデータ移行を移行リハーサルで最終的に検証します。
本コラムでは、移行リハーサルに関する3つのポイントをお伝えします。

1つめは、移行リハーサルの実施タイミングです。
全ての工程が完了してから、すなわち受入テストが完了してから移行リハーサルを実施すると、受入テストで一部の不具合を検出できなくなる可能性があります。
当然ですが、本番の移行はシステム移行とデータ移行が完了してから新システムが稼働します。
つまり、システム移行とデータ移行後に業務移行が行われます。
例えば、システムテストのテストデータが残っている状態で受入テストを実施すると、そのデータが存在することでシステムが正常な動作をしてしまい、初回業務で発生する不具合を見落とす可能性があります。
そのため、移行リハーサルは、受入テストの直前に、受入テストの環境作成も兼ねて実施することが望ましいです。

2つめは、移行リハーサルと移行本番との実施日によるソフト的な環境差です。
本番移行は業務影響を考慮し、土日や祝日に実施することが多いですが、移行リハーサルは通常の稼働日である平日に行うことが多いと思います。
その際、本番移行日を考慮せずに移行リハーサルを実施すると、土日など特定日のみに実行するプログラムが起動しない状態で移行リハーサルを実施することになります。
それにより、移行に掛かる時間を短く見積もってしまうなど、本番との差異が生じる可能性があります。
そのため、実行するプログラムを洗い出して仮想的に本番移行日を設定するなど、可能な限り本番移行日を再現したリハーサルになるように計画してください。

3つめは、コンティンジェンシープランの検証です。
コンティンジェンシープランとは、予期せぬ事態に備えて、予め定めておく緊急時の計画です。
コンティンジェンシープランの一部を例に挙げると、移行延期を判断するタイミングを設定し、そこまでに移行が完了しなかった場合、「移行のために停止していた現行システムを起動させる」、「新システムの設定を移行開始前に戻す」といった内容です。
コンティンジェンシープランを検証せずに本番移行を実施すると、実際にコンティンジェンシープランを実行させたときに、「移行開始前の状態に戻すための仕組みが動作しない」といったシステム的な問題だけでなく、「対応者が長時間労働になってしまう」といった管理面の問題も、本番移行で明らかになる可能性があります。
実機で検証することが現実的に難しい内容については、関係者間で読み合わせを行うなどを含めて、コンティンジェンシープランを検証するようにしてください。

受入テストで明らかにならない初回業務の不具合や計画外の方法による移行中止などのリスクは、上記の移行リハーサルのポイントを実践することで、低減させることができます。
ぜひ、本コラムで紹介した内容を活かし、移行を成功に導いていただければと思います。

関連サービス