新ITシステム切替に向けて、その時が迫っている段階ではありますが、重要な領域が残っていますので、これから説明していきます。
その重要な領域とは、データ移行です。
データ移行は、ITプロジェクトの失敗事例でも紹介してきました。失敗原因の大きな要素となっています。
データ移行がなぜ難しいのか
データ移行は、新ITシステムが初期動作するために投入するものです。
データ移行が実施されて初めて新ITシステムがユーザのものになったと言えます。
データは予め用意できるものと、切替のその瞬間でないと用意できないものとがあります。
テストでもデータを利用しますが、本番で切り替える意味とは異なりますので、それぞれマネジメントしていく必要があります。
さらにデータには個人情報や機密情報が含まれていることもあります。よってセキュリティ面でのマネジメントも行う必要があります。
マネジメントすべきことが多いのに加え、データ項目それぞれが、新旧で意味が同じようで違うということがあり、変換という一言では済まされない難しさを持っています。
データ移行のタスク
データ移行の計画
データ移行は、新ITシステムに切り替える行為です。
ITシステムを新旧切り替えるのは、入り口を切り替えるだけではないか、と思った人もおられるかもしれませんが、データが反映されて初めて自身が利用できる状態となります。
よって、データこそが自身にとって重要なものです。データ移行は優先して考えるべきものですが、開発・テストと並行して計画していくことになります。
主なデータは以下です。
| 管理するためのマスタデータ | ユーザ属性情報、取引先情報、取引契約条件などの情報 |
| これまで蓄積されたデータ | 過去の取引データ・実績データ、マスタ履歴など |
| 瞬間的に切り替えるべきデータ | 更新前データ、予約・受注などのデータなど |
それぞれのデータは、逐次更新されますので、ある時期に旧ITシステムから取得したとして、新ITシステムのために用意しても、どこかで再度最新にしなければなりません。
また、データ項目は、新ITでそのまま利用できることはありません。
様々なステップで計画しマネジメントしていく必要があります。
- 旧ITからの元データ取得
- 元データからの変換・整備
- 移行プログラムの作成・テストと移行
- 新ITへの移行タイミング
- 移行タイミングごとの計画
- 移行過程でのデータ管理
- 移行失敗時の対応計画
テストデータの計画
データ移行作業は、ITシステムの切り替えタイミングのみ行うものではありません。
旧ITから取得し加工したデータを新ITのテストでも利用します。
用意したデータは、更新されるとテスト結果が変わってしまうので、計画的に準備と利用がなされる必要があります。
移行元データの管理
移行元データは、管理されていないと様々な人が、様々なタイミングで更新してしまい、整合性が取れなくなります。
よって、あるタイミングで取り出し、その時点の情報であることを明示します。
それ以降更新されたものは、差分を取り込むか、またすべてを取り込むか等をデータごとに決めておきます。
データの抽出
新ITに渡すための元データを確保することです。
既存ITから取り出す場合もあれば、業務上利用されているExcelのデータを確保することもあります。
あるいは、全く何もないところから、何らかの情報を確保することもあります。
いずれにしても、元になるデータが存在する場合は、いつのものかが明確になるようにバージョンを管理していきます。
抽出することそのものは、データを利用している側の責任となります。それを受け取ったら、受け取り側の責任で管理されることになります。
データ変換
データを抽出し確保したら、新ITに投入するための変換の作業に入ります。
元データがない場合は、変換ではなく作成となります。
データ変換は、何かの変換ルールに基づいて機械的にできるようなイメージを持ちますが、実際そうすんなりいくものではないことのほうが多いです。
機械的に変換できない主な理由は以下のとおりです。
受注側ベンダーは、移行元データを理解できていないことが多いため、これらに対する対応に苦戦します。
最悪は、新ITシステムが稼働できない、データが入れられないので頓挫した、ということもあり得ます。
それだけ、難しいものであり、なおかつ完璧が求められるものでもあるため、そのつもりでタスクを進めないといけません。
データ移行・切替
ITシステムを、新しいものに移行をする方法はいくつかあります。
もし1週間止めても問題ないものであれば、その間に移行すればいいです。
しかし、止めてしまえば売上が上がらなかったり、製造が止まってしまったりすることもあり、実際は余裕があるものは少ないのではないでしょうか。
移行時の制約等から、主に以下のケースが考えられます。
- 一部から徐々に全体に展開していくケース
- あるタイミングで切り替えるケース
- 事前にデータを同期させて、並行運用後、切り替えるケース
それぞれにおいてデータの準備方法と切替方法は異なります。
いずれにおいても、移行データを確保し、更新されるデータを反映し、切替のその時でないと移行できないデータの段取りを決めるということになります。
データ移行プログラム
データ移行における抽出、変換、移行の各作業において、予め準備できるものについては、移行プログラムを用意することもあります。
プログラム化の判断は、データが多くあり自動化できるもの、自動化しないと作業時間が確保できないもの、正確に実行できる見込みがあるものといった観点になります。実際は機械的にできないことも多くあるため、実現性についても判断が必要です。
作ってテストするタスクも必要となってきますので、計画に組み込んで対応していくことになります。
データ移行・切替のリハーサル
データ移行・切替については、あるタイミングで切り替えるものを中心に、後からとり返しがつかない場合があります。
そのようなものは、リハーサルにより実行可能な状態を担保したいです。
データそのものにエラー値が含まれてしまっていることもありますし、手順に問題がある場合もあります。
正しいデータを正しい手順で実施しないと、うまくいきません。さらに、うまくいかなかった時の対応も考えおき、うまくいかなかった時の手順もリハーサルしておきます。
最悪既存ITの運用に問題が発生してしまいますので、一連の作業を事前確認するのが基本です。
データ移行の責任
データは発注側と受注側どちらのものでしょうか。
データが入ってこそ利用できるITシステムになるのですから、発注側のものであることは間違いありません。
では、持ち主が用意する責任があるのでしょうか。
元データについては、そのとおりになるはずです。
新ITに移行する責任については、どうでしょうか。
これは契約によるところです。
持ち主と発生元が発注側ですので、データ移行一連の作業が共同の側面があります。
新ITを稼働させる責任は双方あるにせよ、稼働できるためにはデータが必要であることから、受注側ベンダーにもIT構築の責任者として責任があると言えます。
変換や移行はうまくいかないことが多いことが分かっているため、賢いベンダーは初めから免責事項に上げてくるかもしれません。
しかし、だからと言って発注側も新ITへのデータ投入に責任を持つのは難しいです。
ゼロからすべて登録するところから始まるのであれば、まだ責任を持てそうですが、そういかないことが多いです。
データ元の関係者が増えることもあり、データ移行は難所となりますので、お互い責任を持って対応できるよう、取り決めしたいところです。
IT導入・システム開発におけるデータ移行のマネジメント法
移行変換の定量進捗評価
移行データの変換については、計画どおりに進んでいるかを監視します。
移行すべきデータ数と件数といった定量的に捉えられますので、進捗を見て進みが悪いところは原因を探ります。
移行元ユーザ分類によるマネジメント
移行元の関係先が多い場合、特定の箇所の進捗が悪いということが起きます。
これは、取引量が多いことや、逆に取引が少ないが特殊であること等によるものですので、すべてを同じマネジメントすることのほうが、無理があります。
データのマネジメント
最終的に移行すべきデータは、最新で正しいものでないといけません。
最新であることは、元データが最新であることも必要ですし、変換・更新されたデータも最新であることが必要です。
結果が間違っていると気づいたときに、元データが誤っていたか、更新データが誤っていたか、はたまた更新作業があやまっていたかを探り、遡って修正するのは意外と骨の折れる作業です。
1件単位で元データと更新ステータスを管理できるようにしておくことが有効です。
また、元データと更新後データそれぞれ、工程のイベントタイミングや定点で正しい状態を確保し、万が一壊れてしまった場合に、遡って復旧できるようなマネジメントを行います。
またテストで使用する場合も、本断移行するためのものと区別するようマネジメントしていきます。
課題に対する責任・役割のマネジメント
データ移行は場合により多数の関係先が登場し、発注側と受注側との共同という側面もあるため、責任が曖昧となり、進捗が滞りがちです。
データ、作業手順、作業そのもの、それぞれ役割があり、責任が発生します。
さらにデータはステータスに応じて役割が分かれることもあります。
移行データ由来の課題が発生したときは、責任元を明確にし、管理します。
課題の発生数と消化数・残数を管理していくのと同時に、責任を明確にすることが重要です。
責任毎に課題タスクが分かれることもあり、その場合それぞれフォローしていけるようにします。
データ移行でありがちな問題
データ変換は一律で評価できない
一連のデータ移行の進捗を見ていくときに、定量的に把握するのであれば、例えば30ファイル中10ファイルが80%完了、などと認識するでしょう。
80%終わっていれば、このままいけば大丈夫という状況に見えているかもしれません。
しかしながら、量だけで難易度による問題が表面化していないことがあります。
難しいものは進捗が止まっていて後回しになっているかもしれせん。そうだとすると、98%になってから停滞し終わらないかもしれません。
難しいものは、先が見えないため先に着手しないといけません。
通常のデータが1回確認すればわかるところを、難しいデータは、関係者を調べて特定し、関係者に実態を聞いて、影響を分析し、場合によっては取引先に確認し、過渡期の対応を検討し、、、といった複雑なステップを踏まないと結論が出ないこともあります。
データの問題かバグの問題かわからないほど不具合がある
データ移行作業で準備したデータを、総合テストや運用テストで利用することがあります。
新IT全般をテストするにあたっては、データも一定以上揃っていないと効率的に実施できないからです。
総合テスト段階では、結合テストまでにすべての機能について検証されているはずですが、総合テストで移行データを投入すると、動かなくなったということが起きます。
受注側のITベンダーが、データの問題だと主張してくることがあります。
データが矛盾しているなどで、本来あり得ない状態になっている等が原因としてあり得ます。
また、普通に運用が開始されたら起きない事象である、と言えるかもしれません。
しかし、そういう時に限って、プログラムバグなどの品質問題とデータ移行の不具合の両方が発生していることが多いです。
バグが発生しているのは、実運用に即したデータでテストできなかったから、ということですし、動かしてみないと移行用データが確認できない、といった鶏と卵の状態になっていることもあります。
新ＩＴの理想が足かせに
新ＩＴではいろいろな要件を盛り込んでいます。
特に蓄積されたデータをリアルに、様々な切り口で活用できるようにするという管理側からの要件が多く盛り込まれることがあります。
これは経営資源の把握や戦略立案などに直結する話なので、実行の意思決定されやすく、よくあることです。
しかし、データを使う側と発生させる側では、意識が違います。
今まで特に何もしていなかったことに対して、営業担当が2件に分けなければならないとか、付帯情報を合わせて登録しないといけないとか、登録順序が厳密になり常に時間外に作業が発生するとか、といったことが起き、結果的に浸透しません。
このような時は、データ移行も複雑になっています。
いままで単純だったデータを複雑にするということは、作り出さないといけないからです。
二重の登録で疲弊
既存ＩＴに対して新ＩＴのデータ構造が大きく変わってしまった場合は、単純にデータ移行することができません。
切り替え時のデータ移行に際して、既存ＩＴで発生したデータが必要になるケースが多いです。しかし、単純に移行できない以上、データ変換や加工をしたいところですが、どうしてもできないケースは発生します。
その場合、新旧ＩＴシステムへの二重登録が発生することもあります。
二重登録は、単純に手間が２倍になりますので、それだけでも疲弊します。さらにデータの意味合いが異なるため、気を使うことになり、さらに疲弊します。
やらなくてよかった要件が発覚
データに細かい識別を持たせれば、より精度の高い分析ができるということで、様々な付帯データを持たせてしまうことがあります。
総合テストや運用テストの段階で、データを用意してやってみようとなったときに、識別させるのが実は困難ということが、発覚することがあります。
新ＩＴが実現できることは確かに素晴らしいのですが、実際データを用意しようとすると、そんなに単純ではないということです。
ＢＩやＡＩなどにより、様々な分析ができるようになったり、データ発生もスマホやセンサーから自動で吸い上げられたりしてきています。よって、実現できそうな世界も広がっていることは確かです。
しかし企業ではそのような世界ばかりではありません。
やらなくてよかったことすらわかってしまうのがデータへの着眼です。企画構想段階からデータにより着目すると、結果は変わっていたかもしれません。
IT導入・システム開発におけるデータ移行で本当にやるべきこと
今回データ移行だけを取り上げました。それは、重要かつ稼働に直接影響するものだからです。
ERPなどパッケージやSaaSといったものも台頭していますので、新ＩＴシステムにはデータ移行しかしないということもあるでしょう。
そういったケースでは、なおさらデータ移行の問題は多く立ちはだかります。
最悪、全く動かないということもあり得なくありません。
今回ご説明してきましたように、データ移行に関して計画を立てて、実行していったとしても、想像以上に難しい面が出てきますので、必ず難所が現れます。
ＩＴ導入・システム開発の上流段階において、よくある失敗の中に、データに着目した分析が不十分であることがあります。
機能や業務フローや構築コストを優先して考え、肝心のデータを後回しに考えているということです。
企画構想段階からデータ分析を行い、データに関する特徴や移行制約などを分かったうえで、導入・構築のプロジェクト計画を立てて実行していきたいです。
コメント