システム移行とは何なのか、何をするのか、いつ行うかなどをそんな疑問にお答えするため本記事をまとめました。
実際の進め方など具体的に解説しているので、これからシステム移行を進めたいという方、知識として習得したい方々にとって参考になると嬉しいです。
1.システム移行とは
そもそもシステム移行とは、何をすることなのか1章では解説していきます。
1-1.現行のシステムから新たなシステムに移行すること
文字通りですが、システム移行とは、現行使用しているシステムを新たなシステムへデータなども含めて移行することです。
現行システムがOSのサポート切れなどのタイミングで今後使用できなくなるケースでシステムの移行をせざるを得ないケースがあります。
分かりやすい言葉で言うと「引越し」です。
例えば、家の老朽化や居住者の増加などが発生すれば引越しを行います。また、道路の工事区画に入っていた場合は立ち退きを交渉されることもあると思います。
現在の住まいが何らかの理由で使えなくなるまたは引越しすべき理由が出てきたことで、システム移行同様に新しい住まいに引越しを行います。
1-2.システム移行が必要になるタイミング
システム移行は現行使用しているシステムから新たなシステムへ移行することですが、よくあるシステム移行のタイミングとしては下記の点が想定されます。
- ハードウェアやOSなどのサポート切れ
- データセンターの設置場所など変更
- 組織の再編によりシステムの統廃合
- オンプレミスからクラウドへの移行
- システムの老朽化
これ以外にも、単に新しいシステムに移行したいというそれだけの理由もあるでしょう。
1-3.システム移行のパターン
システム移行は、大きく分けて2つに分けることができます。1つずつ確認していきましょう。
＜オンプレミスからオンプレミスへ＞
オンプレミスからオンプレミスの環境へ移行をします。
オンプレミスとは、自社に設置したサーバやネットワークを使ってシステムの運用を行っていく手段です。インターネットを介さずにローカル環境で実施できるのが特徴です。
そのため自社システムとの連携のしやすさやセキュリティなどの管理がしやすいというメリットがあります。
ただ、サーバの設置やメンテナンスなどコストや手間がかかることや障害の復旧対応なども発生します。オンプレミスは少し古い考えと言われてもいます。
＜オンプレミスからクラウドへ＞
オンプレミスからクラウドへ移行をします。
オンプレミスは前述したとおりですが、クラウドはインターネットを介してサーバにデータを保管し運用することです。
オンプレミスに比べてコストが抑えられ拡張性や利便性の高さからクラウドへの移行が積極的に行われています。
また、クラウド事業者がセキュリティやバックアップの対応を行うため管理の手間も削減できます。ただ、ローカル環境で作業することは難しくなります。
近年の傾向としてはクラウドを活用する企業が増えているように思います。
1-4.システム移行の方式
システム移行の方式について解説していきます。方式としては大きく分けて全部で3つあります。
| 移行方式 | 特徴 |
|---|---|
| 一括移行 | 現行システムから一気に移行させる |
| 段階移行 | 部分ごとに移行させる |
| 並行運用 | 現行システムかと新システムを同時に運用 |
＜一括移行＞
一括移行は、現行システムから新システムへ一気に移行を行う方式です。
一括で行うため、現行のシステムを完全に停止させ作業をする必要があり、一定期間システムを使用することができません。
業務に支障が出ないように日程の調整が必須になります。 他の方式と比較し一括で行うため、ある程度のコストが抑えることができます。
移行後のトラブルなどに備えて、現行システムはバックアップとして残しておくことも必要となります。
＜段階移行＞
段階移行は、機能単位などシステムの部分ごとに順次移行していく方式です。
1日や数時間単位でシステム停止を行いながら移行を進めていくため、影響度も大きくありません。
しかし、完全に移行が完了するまでは現行システムと連携してシステムを使用する必要があり、手間や場合によってはコストが発生し、高くつく可能性もあります。
＜並行運用＞
新システムへの移行が完了した後に新システムと旧システムを同時に使用し運用する方式であり、新システムに不具合や問題が無いか確認ができたら旧システムを停止させます。
トラブル発生時など、リスクは最小限に抑えることができますが、データを新と旧で2回入力する必要があるなど手間が発生します。
1-5.データ移行との違い
システム移行は旧システムから新システムへ移行することですが、その過程で旧システムで使用していたデータを新システムへ移行することがデータ移行です。
システム移行時に一緒に実施され、新システムになっても使用できるような状態にしておくが重要です。
そこまで完了して、システム移行の中のデータ移行が完了となります。
2.システム移行の流れ
続いて、2章ではシステム移行の流れについて解説していきます。
2-1.現行システムとデータの調査
現行システムとデータの調査を行います。調査する内容として少なくとも下記を調査しましょう。
- 設計書や仕様書の有無
- データやファイル形式
- データ総量
調査内容を基に、どのくらいの量を移すのか、工数、時間を検討していきましょう。
2-2.移行計画書の作成
次に移行計画書の作成を行います。計画書には下記の項目を記載していきます。
| 項目 | 内容 |
|---|---|
| 移行要件・方針 | 移行時の制約条件などを書き出し、全体の方針を記載 |
| 移行スケジュール | 移行完了までのスケジュールを記載 |
| 移行対象 | 現行システムから新システムへ移行するデータなどの対象物を記載 |
| 移行方法 | 前項で解説した「システム移行の方式」から今回採用する方式を記載 |
| 移行による影響 | 移行に伴って、システムのストップなど業務への影響を記載 |
| 移行体制 | 移行を行う体制（チームなど）を記載 |
2-3.移行リハーサル
ここからはシステム移行計画書に沿って進めていくことになりますが、実際に移行に入る前にリハーサルを実施します。
本番の移行作業を円滑に進めるために、できる限り本番環境に近い状況でリハーサルを実施しましょう。
また、トラブルが発生した場合は内容など詳細に履歴として残しておきましょう。
対応方法も試したことなどをメモしておき、本番時にも仮に発生した場合にも対処できるようにしておきましょう。
リハーサルは1度だけでなく複数回行うことをおすすめします。
トラブルは当然つきものではありますが、予防することもできることから、準備は抜かりなく行いましょう。
2-4.移行作業の実施
リハーサルが完了したら、実際に移行作業を進めていきましょう。
基本的には移行計画書に沿って移行を進めていきますが、前項のリハーサルを確実にできていれば、大方問題なく進めることができます。
とはいえ、予期せぬトラブルは起こりうるかもしれません。
作業は複数人で行いつつ、作業ログを取りながら進めていきましょう。
2-5.移行後のテスト
移行が完了したら、テストを実施します。
これまで通りの使用をしてもエラーは出ないのか、データの移行はできているのか、負荷がかかった場合も正常に動作するかなど確認を行いましょう。
よくあるケースとして、データが移行されていないなど、直接業務に影響が出るトラブルなどもあります。
そのため、実際に運用をスタートする前に確実にテストを行いましょう。
2-6.現場担当者へレクチャー
システムの移行により、中身の仕様が多少なりとも変わることはよくあることです。
現行システムからの変更点やトラブル時の窓口、使用方法など円滑に業務ができるようレクチャーを実施します。
また、マニュアルの作成なども行うことで、実際に使用する現場の者としては安心できます。
3.システム移行を成功させるコツ
システム移行の流れについて解説してきましたが、3章では、システム移行を成功させるためのコツを解説していきます。
システム移行は業務の停止という失敗したら大きな代償を背負う可能性があります。そのためリスクを最小限にさせるためにも成功のコツを掴みましょう。
3-1.バックアップを取る
まずは最も重要なポイントの1つである、バックアップを必ず取っておくことです。
万が一、移行途中にデータを消失してしまった場合、状況によっては復旧させることができず、業務に大きな影響を与えるだけでなく会社の業績への影響も否定できません。
保険をかけるという意味でもバックアップがあることで、作業者のプレッシャーも軽減させることで良いパフォーマンスにもつなげることができます。
3-2.移行計画書をしっかり作る
移行計画書に沿ってシステム移行を行うことから、移行計画書を作りこむことも成功させるためのコツの1つです。
移行計画書に記載されている内容が不十分である場合、確認する作業も発生してしまい、移行全体の遅延にもつながります。
また、移行手順が誤っている場合など、移行ができない最悪の事態も想定されます。移行計画書の作成は特に注意して行いましょう。
3-3.コンティンジェンシープランを立てておく
コンティンジェンシープランを立てておくことも成功させるためのコツとなります。
まず、コンティンジェンシープランとは緊急事態など予期せぬ事態に対して被害を最小限にするために事前に対策や行動指針を定めたものです。
バックアップ同様に保険的なイメージになるが、このプランによりやるべきことがそれぞれ統一化され、効率よくシステム移行が可能となります。
また、トラブル発生時のフローも確立しておきましょう。例えば、「トラブル発生時は〇〇に連絡」など経路を明確にしておくだけでも有事の際に素早く対応することができます。
3-4.データの移行漏れに注意
データ消失だけでなく、データの移行漏れに注意しましょう。
データの移行漏れによって新システムで担当者が戸惑うこともあります。
「このデータが無い」などのトラブルが発生しないよう、移行計画書の内容と実際に新システムを使用する現場担当者とのコミュニケーションを密にとりながら、抜け漏れなく移行をしましょう。
4.システム移行の失敗事例
システム移行の失敗は海外そして日本国内でも発生しており、対策や安全性が求められます。こんな事例があります。
- 高い変換率を実現する為に無理なツール変換を行った。
- OS等まで弄る基盤を導入したので、OSが不安定になり、バグ対応がとても難しくなった
- 当社が火消に参加したにもかかわらず、納期が大幅に遅れてしまい、品質も悪かった
- パッケージで大規模基幹システムを再構築したので、Fit＆Gapが困難で、本番になった時に沢山の機能が実業務に合わなく、会社の運営が厳しくなった
これらの失敗につながる要因としては、以下のようなことが考えられます。
- テスト、検証が不十分
- データ移行が漏れている
- 他のサービスとの連携ができていない
システムの移行で最も気をつけるべき点は、新システムが停止することであり、仮に停止した場合は業務へ大きな支障があることを覚えておきましょう。
5.システム移行は自力でできるのか？
最後に5章では、システム移行は自力でできるのか考えていきましょう。
5-1.ノウハウとリソースがあれば自力でできる
過去にシステム移行を経験しており、人的リソースつまり移行ができる人員が揃っている場合は自力で移行ができます。
例えば、オンプレミスで使用していた旧顧客管理システムからクラウドで管理するキントーンへ移行するケースを考えてみましょう。
移行させるデータ数や他のシステムとの連携など状況により異なりますが、データ数が数千規模であれば、1～3カ月程の期間でシステム移行を経験しているエンジニアが2名以上必要となります。
他のシステムとの連携など複雑になるほど、そしてデータ数が増えるほど期間も必要人員も増加します。
もちろん、この状況でもプロに外注したいと検討することも多いかと思いますが、自力で移行をした場合は、この2つをクリアしているか確認しましょう。
少しでも懸念されるのであれば、外部委託することをおすすめします。
5-2.失敗したときのリスクが懸念される場合は、外部委託
たとえ前項の状況であっても、失敗時のリスクが懸念される場合はプロに外注することをおすすめします。
当然費用はかかりますが、その分安心して任せることができ、スムーズに移行を進めることができます。
各社の状況に応じて判断していただくことが大事ではありますが、プロに外注することを特におすすめします。
「システム移行」まとめ
システム移行について方法も含めて解説してまいりました。
現行システムから新しいシステムに変えることを意味するシステム移行ですが、いかがでしたでしょうか。これからシステム移行を考えている方、知識としてご覧いただいた方、様々な立場の方に目を通していただいたかと思いますが参考になっていましたら幸いです。
このようなお悩みありませんか？
- 「システム移行したいが、システム全体を理解している人が社内におらず、説明できるか不安…」
- 「システム移行したいが、システムの内部構造を説明するのに時間が掛かりそう…」
- 「万が一、システム移行に失敗した時は委託事業者が責任取ってくれるか不安…」
そんな弊社は業務自動化を支援する企業の1つであり、システム開発会社です。お客様と一緒になってお客様の課題解決をシステムの提供という形で支援しています。また、様々な体制を組むことが強みでもあり、オフショア開発、ニアショア開発、オンサイト（常駐型）開発、受託開発など…お客様の状況に合わせてご提案いたします。相談は無料！なのでお気軽にお問い合わせください。
