移行データをどう作る? データ移行経験20年のベテランが語る絶対知っておきたいデータ移行のポイント!

このコーナーは、リアライズの凄腕PMサクライが、データマネジメントノウハウや、最近のトレンドをご紹介するコーナーです。

 

リアライズの凄腕PMサクライ。数々のデータマネジメントPJを先頭に立ってやり抜く。最近は営業も実施。口癖は「ええねんけどなぁー」。

 

プロローグ

こんばんわ。すっかり寒くなってきましたね。 巷では、クリスマスに、正月の準備と何となくせわしい師走に入ってきましたね。

 

こんな時に思い出すのは。。。そう。本番移行ですw

 

2000年の銀行統廃合以来、毎年のように移行に従事してきた私にすれば、年末年始は何といっても移行の季節! 一年に一度のこのチャンスタイムを逃す手はありませんとばかりに、移行が毎年の行事になっておりました。

 

移行経験者の皆様にすれば、お判りになるかとは思いますが、年末年始のこの時期に、疲れた身体に鞭打って徹夜続きの状態で。。。

 

本番移行成功! 正月なんで、飲もう! なんてことをすると、もう大変ですねw

 

次期システムの稼働を一度もブラさずに実現してきた私にすれば、 もう、正月は宴ですねw そして、入院しそうになりますね。

 

皆様は、そのような愚かなことはきっとなさらない事と思います。

 

この数年、データ移行の問い合わせが増えている

弊社にも、年間1~2本程度のデータ移行に関する問い合わせは入ってくるのが常でしたが、ここ数年(2015年頃から)は、増える傾向にあります。

 

基本的には、景気が良くなってくると、これまで我慢していたシステム刷新をここぞとばかりに、「やろう!」となり、それについて回るのが「移行」という訳です。

 

ですので、アベノミクスは、きっと何か良い循環をもたらしているのでしょうね。
(はっきり言わないところが、良いでしょう?)

 

このついて回る「移行」は、くせ者で、規模にもよりますが、システム構築の総予算に占める割合は、2~4割と言われています。
(失敗すると、期限延長になるので、4割とかに膨れ上がります。要するに、「倍」ですね)

 

私の経験上では、2割程度が適切ではないかと感じています。

 

※ここでいう「移行」とは、「データ移行」、「システム移行」、「業務移行」を指します。それぞれの詳細は、また別の機会で述べるとしましょう。

 

システム開発者は、システムは作っても移行データは作ってくれない場合多い

新システムの要件や、機能拡張、新しいサービスへの適合など、システム開発者はあくまでも、システムに関わるHW、SW、PPに関して色々と知恵をしぼって作ってくれます。
でも、現行業務システムに格納されているデータをいかにして、新システムに移していくのか?については、「ユーザ(お客様)」側の作業にしてしまうことが多々見受けられます。

 

これには、幾つかの理由があります。
・データはお客様の資産(持ち物)なので
・新システムのマスタメンテは、お客様のユーザ部門の責任
・現行システムがよく分からないので、お客様がやった方が安い(と思う)
・現行システムに格納されているデータが、汚い(めちゃくちゃ)
・当初は、データ移行しない方針だった(よく考えてなかった)
・基本機能に変更をかけないので、そのままデータをコピーすれば良い(と思っていた)

 

はい。業務継続性を考えると、システムよりもデータの方が遥かに長い時間、利用され続けることをご存知の皆様は、お気づきですね。

 

システム部門が、業務を把握出来ていないと、上記の様な理由に起因した悲劇が起こることを。

 

絶対に押さえないといけないポイントはこれ

仮に、データ移行が発生しない結果になったとしても、システム開発の上流工程(概要設計とか、要件定義とか)の時点で、移行計画の立案は必須です。

 

弊社は、データ移行のスペシャリストですので、データ移行にフォーカスしますが、以下のような観点で、移行計画を立案しておくことが、痛い目に合わないポイントです。

 

・移行要件の整理
・移行方法
・移行体制
・役割分担
・移行スケジュール
・移行における共通事項
・移行対象の選定
・移行手順・移行の流れ
・移行手順・システムの状態
・移行手順・移行作業内容
・移行手順・移行リハーサル
・移行手順・移行結果検証
・移行ツールの基本方針
・移行の影響
・段階移行中の運用への影響

 

え?なんですか?多いですか?
そんなことは、ありませんよ。
一番大きな見出しを列挙しただけで、これ以外にも、移行ならではのテスト観点や、役割・体制の構築の仕方なんていうのもボリューム満点です。

 

例えば、移行要件の整理だけでも結構考えないといけないんです

「移行要件の整理」では、細かいことはともかく、「だいたいこんな風にやったら、上手くいくと思ってる。」ことを、まとめておきます。

 

例えば、「現行システムから新システムへのデータ移行対象(DB、ログファイル、外部連携ファイル等)や、
新システムへの移行の前提となる制約条件(ネットワーク容量や、営業日の扱い、年末年始の業務予定、外字の取扱い等)
業務や他システムへの影響(業務ストップや、他社へのお願い事項等)の移行要件を整理し、データ移行の作業対象スコープのあたりを付けておきます。

 

この様に、移行の計画立案時点で、これから起こるであろう、将来に対する心構えと準備をするだけでも随分と違ったプロジェクト推進になります。

 

え?なんですか?他のも教えてほしいのですか?

 

いえいえ、皆様の楽しみを奪うようなことはしてはいけませんので、今日はこのくらいにしておきます。

 

また、気が向いたら、続きを書くかもしれませんので、お楽しみにw