ユーザーの資産を守るということ

ユーザーの資産を守るということ

From: リナックスアカデミー 松田航
新宿本校にて、、、

「システムリリースの際に注意しないと
 いけないことは何でしょうか」

この質問に対しては正直に言って、
ひとことでは答える事ができません。

システムリリースにおいては
ユーザーにできる限り負担がかからない様、
気を付けないといけない事は数多くあります。

今回はその中でも重要事項のひとつ、
「データ移行」についてお話ししましょう。

システムだけを作ってしまえば
それで終わりではない

携帯電話やスマートフォンの
機種変更をされた経験がある方は多いでしょう。

新しい機種に変えてから、まず何を行いますか?

そう、電話帳データの移行です。

多くの携帯電話ショップでは
電話帳データの移行サービスを行っていますが…

「完全に移行できるとは限りませんのでご了承ください」

…と言われる事が多いのが現状。

事実、私も何度か機種変更した時
携帯電話ショップでの移行を依頼したことがありますが、
正しく移行できたという経験はあまりないです。

同じキャリアだと移行しやすいそうですが、
別キャリアに機種変更する場合は、失敗する確率が高いようです。

電話帳が移行できないと
1件1件手入力で電話帳データを入力しなおすか、
電話帳移行ツール等を新しく購入して試してみるなど、
利用者に作業負担がかかってしまいます。

数十件程度ならそれほど苦になりませんが、
何百件、何千件も電話帳データがある場合は大変です。

これは、システムでも同じことが言えます。

既存のシステムを廃止して
新しいシステムを開発して導入する場合、
既存のシステムで使用していたデータを移行する必要があります。

システム開発とは、
システムだけを作ってしまえば終わりではありません。

既存システムのデータを移行した上で、
新システムを使用してもらう必要があるのです。

データはユーザーの大切な資産

既存システムにおいて
日々の業務で入力されてきたデータ。

これらはユーザーの大切な資産です。

新システムにおいて
その資産を有効に活用できないという事は、
ユーザーにとって新システムに移行するメリットがないという事を意味します。

ツール系アプリケーションの場合
定期的にシステム改良を伴ったバージョンアップが行われますが…

旧バージョンのデータが使用できない場合、
ユーザーからクレームが来ることは必至です。

アプリケーションの改良により
機能が増えました!処理が早くなりました!
だけど旧バージョンのデータは使えません!

それでは、ユーザーは納得しません。

業務系システムの場合も同様。

これまでの業務によって培った
会計データや、顧客データ、営業履歴、案件データなど…

それらの資産が使用できないと
新しいシステムに変わったところで意味がないのです。

また、業務内容やデータの種類にもよりますが
データには法律で保存期間が設けられている場合もあります。

例えば会計帳簿データであれば
会計法では10年、法人税法では7年と定められています。

あまりにも古いデータの場合
とりあえずCSV形式に変換して
磁気テープ等に保存するという企業がほとんどです。

ですが営業売上を管理するシステムなどで…

「過去3年間の月間利益率と当年の月間利益率の対比を見たい」

…といった要望がクライアントから出た場合、
最低でも過去3年間の売り上げに関するデータは移行する必要があります。

データはユーザーにとって資産であり
今後の営業戦略を決定する上での判断材料ともなるのです。

どうやってデータ移行は行われるのか?

では、実際にどのようにデータ移行が行われるのでしょうか?

データの移行方法については
上流工程フェーズにおいて検討される必要があります。

既存システムと新システムのデータベース項目を比較し、
移行できる項目や、移行するのに加工が必要な項目などを検討。

基本的には
既存システムで使用中の全項目が
移行できるのが理想的ですが…

既存システムがオリジナルシステムで
新システムがパッケージシステムの場合など、

パッケージシステム側のデータベースに
既存システムで使用していた項目がない
といったケースもあり得ます。

その項目をどうしても移行しないといけない場合は、
追加費用を支払い、パッケージをカスタマイズした上で
移行しなければなりません。

移行するのに加工が必要な項目とは、
これまで使用していたコード体系を
新システム導入と同時にコード体系を変更して運用する項目などが挙げられます。

例えばこれまでの商品コードが10ケタであり
上位3ケタが商品分類、下位7桁が商品コードとしていたが
新システムでは商品分類と商品コードの2つの項目に分けたい場合…

既存システム「商品コード」
ABC0000001

新システム「商品分類」
ABC

新システム「商品コード」
0000001

…と分割した上で、新システムに登録しなければいけません。

データ移行では
主に移行用のプログラムを作成しての移行や
SQLを使用してデータ移行するのが一般的です。

データ加工が必要な項目の場合は、
移行用プログラムに加工条件をプログラムし、
新システム側のデータベースに加工データを自動登録します。

しかし中には、
ユーザーが判断しながら登録しないと
いけないデータもあります。

こういったデータ項目がある場合は
ユーザーに手入力で入力してもらうか、
あらかじめCSVデータをユーザーから入手して
CSVデータを新データベースに反映する方法が採られます。

データ移行はこのような流れで行われ、
新システムの動作確認を行った上で稼働準備が整うのです。

覚えておいてください
資産を守るという重要性

データ移行を疎かにしてはいけません。

データ移行が疎かにされ、
訴訟にまで発展したケースも実際にあるのです。

薬局の業務システム開発において
データ移行が適切に行われなかった為、通常業務に支障が発生。

裁判所から開発費用の返金命令が下った判例があります。
(東京地判平22・11・18)

先ほども言いましたが、
データはユーザーにとっての大切な資産です。

その資産を守る為に
データ移行については様々なケースを想定した上、
システムの上流工程から早めに検討しておく必要があります。

そしてシステムによっては…

・随時処理(随時データ更新されるもの)
・日次処理(1日に1回処理されるもの)
・月次処理(ひと月に1回処理されるもの)
・年次処理(1年に1回処理されるもの)

…など、処理されるタイミングがさまざまな場合も。

どのタイミングでデータ移行するのか
そういった事も含めて、移行計画を立案する必要があります。

もちろん、データ移行にはユーザーの協力も必要です。

場合によっては、
ユーザー企業の全社員にシステムの使用を中止してもらい
限られた時間内でデータ移行をしなければならないケースもあります。

ユーザーとの円滑なコミュニケーションなしには
データ移行どころかシステムリリースさえもうまく進みません。

ユーザーが新しいシステムに望んでいるもの。

それは効率性や利便性、
操作性や事業拡張性など、ユーザーによってさまざまです。

ただ共通している点は、
今現在使用しているシステムに限界を感じており、
新たな期待を込めて、新システムを導入しようとしている点。

IT技術者には、
ユーザーのさまざまな期待に応える必要がありますが
データ移行もそのうちのひとつです。

「ユーザーの資産を守る」ということ。

その重要性を、どうか覚えておいてください。

 

リナックスアカデミー
松田

PS

ユーザの資産を守ることは
あなたとユーザーの信頼関係の良化に繋がります。

良好な信頼関係を育む事は
あなたにとって「最高の資産」となるのです。

PPS

Javaプログラミングとデータベースを学ぶなら、こちらのスクールで