From: リスキルテクノロジー 松田航
新宿本校にて、、、
前回は「データ移行」についてお話ししました。
しかし、
システムリリース時に注意すべき事項は
データ移行だけではありません。
ユーザーに安心して新システムを使用していただく為、
考慮する事項はまだまだあります。
前回はデータの移行方法を説明しましたが、
今回は「システム移行」についてお話ししましょう。
目次
システム移行は「引越し」に似たり
システム移行は
身近な話で言うと「引越し」に似ています。
旧システムという家では
家族も増えて手狭になって来たので...
最新式設備のある
新しく広いデザイナーズ設計の家に引越しするイメージです。
既に新しい家は建築済で、
これまで使用していたソファや冷蔵庫など、
新しい家で住むのに必要な資産は業者に運んでもらいました。
これが前回お話しした「データ移行」にあたります。
そして実際に人が移り住み、
生活を営む事が「システム移行」にあたるのですが...
システム移行方法には３種類あります。
(1)新旧の家で実際に住み比べる方法
今までの家で住み方と、
新しい家での住み方を比較し
今まで住んでいた家での利便性や快適性が確認できてから引越しします。
(2)部分的に順次引越しする方法
ひと部屋ずつ順番に引越しして住み心地を確認し、
住み心地に問題が無ければ別の部屋の引越しを始めます。
(3)一斉に引越しする方法
とりあえず一家全員
引越しして新しい家での生活を開始します。
移行方法にはそれぞれ特徴がありますが
具体的にはどのように異なっているのかを見て行きましょう。
３種類のシステム移行方法の特徴
上で述べた移行方法は、それぞれ...
(1)並行稼働 (新旧の家で実際に住み比べる方法)
(2)部分移行 (部分的に順次引越しする方法)
(3)一斉移行 (一斉に引越しする方法)
...と呼ばれています。
(1)並行稼働
これは最も安全性の高い移行方法ですが
移行期間や人的リソースが多くかかる方法です。
具体的には、
旧システムと新システムで
ユーザーに同じデータを入力してもらいます。
例えば入金伝票を登録する際、
旧システムにも入金伝票を入力し、
新システムにも同じ入金伝票を入力するのです。
並行稼働中は
新旧両システムの入出力内容を比較して同じであれば問題はなく、
これまでのシステムと同じ動作確認が取れているという意味を持ちます。
そして全体の動作確認が取れた上で、
新しいシステムに完全に切り替えてしまう方法です。
ただし、
平行稼働中はユーザーの手間も２倍かかり、
またある程度の稼働期間を確保した上で行う必要があるため、
移行期間と人的リソースを大幅に確保しないといけません。
(2)部分移行
支店単位、業務単位、機能単位といった、
カテゴリ別に新システムを導入してゆく方法です。
新システムを導入して問題が発生した場合、
旧システムに戻してリカバリーを行う事により
トラブルの拡大を最小限に抑えられるという効果があります。
ただし、部分移行期間中は
旧システムと新システムの連携が必要となるため、
開発時に新旧システム連動が正しく行われる事をテストする必要があります。
実際に部分移行という方法は、
都市銀行の統合などで使用される手法として有名。
支店単位で移行する事により、
システムトラブルが発生した場合の影響を
支店という限定された範囲に抑え込むことができるのです。
全店でシステムトラブルとなるよりは、安全な移行策であると言えます。
(3)一斉移行
これは文字通り、
あるタイミングを持って新システムに一斉切り替えを行う方法。
ゴールデンウィークといった大型連休など、
一定の間、ユーザーがシステムを使用しない期間に行われる事が多いです。
休み明けにユーザーが出社したら
新しいシステムに切り替わっているという流れですね。
短期間でシステム移行を行う必要があり
予め立てておいたシステム移行の計画に則り移行が行われます。
移行コストという面では
他の移行方法に比べて抑えられますが、
システム移行後にトラブルが発生した場合に
どのように対処するかという事を想定した上で行う必要があります。
問題が大きい場合は
旧システムに戻すという手段も想定されますが…
その問題が一斉移行後に発覚した場合、
ユーザーの業務が停止してしまうため、リスクは大きいと言えます。
リハーサルによる事前確認で
リスク検知・安全性確認
システムの移行方法は
業種や案件の種類によって異なりますが、
多くの場合は一斉移行の方法が採用されています。
ただし、
その前にある程度の期間を設けて
ユーザーテスト的に並行稼働期間を設けるケースもあります。
例えばテスト的に約１カ月間、
経理担当に新旧両システムにデータを入力してもらいます。
そして請求書データの突合などを行い...
新旧システムで数値が一致した！
...という機能的な保障を取った上で、一斉移行を実行するのです。
会計データなどを扱うシステムの場合は
新旧システムで入力・出力したデータの整合性は特に注意されます。
また、システム移行において、
移行時のトラブルを極力避ける為、
システム移行実施前にリハーサルを行うケースがほとんどです。
本番環境と同様のテスト環境を構築し
データ移行とシステム移行を行い、
移行時に発生するリスクを前もって把握しておくのです。
リハーサルであまりにも大きな問題が発覚した場合
システムリリースが延期される場合もあります。
リリースが延期されるのは
何もシステムに重大なバグがある場合ばかりではありません。
ハードウェアやネットワークに問題があり
期待した以上の処理速度が出ずに、本番稼働に耐えられないといった
環境的な設計に問題がある場合にもリリースが延期されるケースがあります。
システムリリースには
ユーザーが協力しあうサポート体制が必要
システムリリースではサポート体制が重要です。
何度もリハーサルを行い、
何度もシステム設定を確認し、
移行はもう大丈夫！と判断しても、
移行本番時には何が発生するかわかりません。
これは何もITの現場にだけ言える事ではありません。
どのようなスポーツでも、
どのような業種職業でも、
どれだけ研鑚やトレーニングを積んだとしても、
試合本番や実際の現場では、何が起こるかわかりません。
本番という事で緊張する事もありますし
何らかの理由により、少し予定が変わってしまうだけで
冷静な判断ができなくなる場合もあります。
どのようなトラブルにも対応できるように
リリース時のサポート体制は特に重要なのです。
リリース時のサポート体制には、
システム開発側だけでなく、ユーザーにも協力者が必要です。
リスクを検知した際、
ユーザーの協力が必要な場合であれば、
速やかにユーザーに相談した上で解決策を講じる必要があります。
ユーザーとの連携力を高める為にも、
普段からユーザーとの関係を良好にして…
「一緒に新システムを作りましょう！」
...という姿勢でシステム開発を進めて行く必要があるのです。
システム移行やデータ移行など
新システムのリリースをするということは、
システム開発ベンダー側だけが頑張ればできるというものではありません。
システム開発ベンダーとユーザーが協力し
リスクを極力回避できるサポート体制をもって臨む事により
新しいシステムをリリースすることができるのです。
システムはひとりだけでは作れないし、
リリースもできない。
関係各所の協力があって初めて、
成し遂げることができるのです。
リスキルテクノロジー
松田
PS
あなたが新しい家を買ったとして
欠陥住宅だとわかったらどう思いますか？
誰も欠陥住宅には住みたいと思わないですよね。
新システムを使うことによって
より快適で、より便利な生活が始まることが期待されています。
あなたが作るシステムは
ユーザーの生活の一部になるのです。
決して欠陥品を提供する訳にはいかないのです。
PPS
