システム移行とは？システム移行の方式や進め方、留意点について解説
システム移行は、企業や組織が既存の情報システムから新しいシステムへと移行するプロセスを指します。
通常新システムの導入ではシステム開発→システムテスト→システムの移行という流れで進行します。
システム移行はその中でも最後の工程となります。
システム移行には主に一斉移行方式、順次移行方式、並行運用移行方式の三つの方式があります。
- 一斉移行方式
全てのシステム一度に移行する方式です。メリットとしては移行期間の短さやコストの低さがありますが、デメリットとしては移行の際に問題が生じた場合、リスクが高くなります。このような移行のリスクを回避するために入念な移行計画書の作成及びリハーサルが必要となります。 - 順次移行方式
システムを業務・機能などの単位で順次移行する方式です。メリットとしては移行負荷の低さとトラブル発生時の影響の低さが挙げられます。
一方デメリットとしては費用の高さが挙げられます。また、この方式の注意点としては分解された業務や機能の関連性について検証が足らず、移行後にデータがうまく繋がらない場合があります。そのため移行業務や機能の関連性を事前に充分検証する必要があります。 - 並行運用移行方式
新旧のシステムを一定期間同時に運用し、徐々に切り替えていく方式です。
メリットとしては安全性の高さがありますが、デメリットとして移行にかかる手間とコストが高いこと、新旧のデータの不整合が起こりやすいというものがあります。
システム移行の手順は、以下の4つになります。
1. システム移行方針書の作成
PJ要件やテスト方針書を踏まえてシステム移行方針書を作成し、プロジェクトメンバー内で合意を得ます。
システム移行方針書では、現行システムから新システムへ切り替える方法の方針について整理します。(移行時期、並行稼働可否など)
2. システム移行計画書の作成
システム移行方針書を基にシステム移行の要件、移行時期、移行範囲、移行方式、移行ツール、移行結果の検証方法などについて具体化していきます。
なお、システム移行計画書は随時更新していくものであり、受入テスト・本番移行のフェーズでも随時更新していきます。
3. システム移行手順書の作成
システム移行計画書を基に、システム移行の作業工程、各工程に必要な設備や環境及びデータ、各工程の完了基準を整理し、システム移行手順書を作成します。
作成時は作業実施者の視点で、何をするのかが明確にわかるように記載することが重要となります。
4. 移行リハーサルの実施
移行手順書に従い、移行リハーサルを行います。
仮に問題が発生した場合は、受入テストまでに不具合の改修と再テストを行います。
5. 受入テストの実施
システム開発のプロセスの中で最後に行われるテストを指します。
これが完了することでシステム開発が完了し、システム開発会社が納品を行う基点となります。
なお、受入テスト実施に向けて受入テスト実施者には研修を実施するため、利用機器・端末、テスト環境の準備が必要となります。
6. 本番移行/一般向け研修(全社員・社外)の実施
受入テストで問題がない場合、本番移行と並行して新システムの社員向けの研修を行います。
システムの本番移行作業はシステム移行手順書に基づいて実施されます。
本番移行後は移行手順書に記載した内容が全て完了していることを確認し、新システムの稼働状況を判定します。システム稼働後も問題がなければ新システムをリリースします。
システム移行を成功させるためには、システム移行計画書で具体化する内容(システム移行の要件、移行時期、移行範囲、移行方式、移行ツール、移行結果の検証方法など)が最も重要です。
この内容に不備が発生すると開発の手戻りや遅延につながるためです。
よくある質問
システム移行で特に注意すべき留意点は何ですか？
システム移行においては、計画の綿密な策定とリスク管理、データ整合性の確保、関係者間の円滑なコミュニケーションを特に重視する必要があります。
注意すべき留意点
1. 計画の詳細化と段階的実施
移行スケジュールや作業範囲を具体的に定め、段階的かつ段取り良く進めることが重要です。
2. データの整合性と品質管理
データ移行時に誤りや欠損が発生しないよう、事前の検証と移行後の検証を徹底する必要があります。
3. リスクの把握と対策
移行作業中のサービス停止やトラブル発生に備え、リスクシナリオを洗い出し、対応策を用意しておくことが求められます。
4. 関係者間の情報共有と連携
発注者、ベンダー、利用部門間での定期的な情報共有を行い、認識の齟齬や作業遅延を防止することが望ましいでしょう。
5. 移行後の検証とフォローアップ
移行完了後に動作確認や性能検証を実施し、不具合があれば速やかに対応する体制を整えておくことが必要です。
これらの留意点を踏まえた適切な計画と実行管理により、システム移行の安全かつ円滑な完了が期待できるでしょう。
システム移行にかかる期間やコストはどのように見積もればよいですか？
システム移行の期間やコストは、移行対象のシステム規模や複雑さ、移行方式、リスク対応策の内容に応じて個別に見積もる必要があります。具体的には計画段階で詳細な要件定義を行い、各工程ごとの工数やリスクを加味して算出することが基本です。
見積もりのポイント
1. 移行対象の範囲と規模の明確化
移行するシステムやデータの量、連携する周辺システムの数を正確に把握することが重要です。
2. 移行方式の選定
一斉移行方式や順次移行方式など方式によって工数や期間が大きく異なるため、適切な方式の選択が必要です。
3. 作業工程の詳細化
現行システムの調査、移行計画の策定、データ移行作業、動作検証、トラブル対応など工程ごとに必要な工数を見積もります。
4. リスク管理と余裕工数の確保
移行時の障害やトラブル対応のため、一定の予備期間や追加コストを見込むことが望ましいでしょう。
5. 関係者調整や教育の工数
利用者教育や関係者間の調整にかかる時間も計上し、全体のスケジュールに反映させます。
システム移行の見積もりは、これらの要素を総合的に評価し、発注者がプロジェクト全体の計画を立てるうえでの基盤とすることが求められます。
移行後のフォローアップや検証はどのように行うべきですか？
移行後のフォローアップや検証は、システムの安定稼働を確保し、問題発見や改善を迅速に行うために計画的かつ継続的に実施することが重要です。
実施すべき主なポイント
1. 動作確認と機能検証の徹底
移行後に全機能が正常に動作しているかを、業務フローに沿って詳細に検証します。
2. データ整合性の確認
移行されたデータが正確かつ完全に反映されているか、データの欠損や不整合がないかを重点的にチェックします。
3. パフォーマンス評価
システムの応答速度や負荷状況を評価し、移行前後で性能劣化がないかを確認します。
4. ユーザーからのフィードバック収集
利用部門やエンドユーザーからの意見や問題報告を速やかに収集し、対応体制を整えます。
5. 問題発見時の迅速な対応
検証やフィードバックで判明した不具合や課題は速やかに修正し、再検証を行う体制を構築します。
6. 定期的なレビューと改善計画
フォローアップ期間中に定期的なレビューを実施し、長期的な安定運用に向けた改善策を検討・実施します。
移行後のフォローアップと検証は、計画的に実施することで移行リスクを低減し、システムの信頼性と業務継続性を確保することができます。
あわせてこの用語と記事をチェック
この記事の編集者
大野 誠司
日本のIT変革の一助となりたいと考え（株）グローバル・パートナーズ・テクノロジーに新卒入社。 主に民間企業の情シス業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するというメディア運営業務にも携わる。
