2017-12-09

このコーナーは、リアライズの凄腕PMサクライがデータマネジメントノウハウや、最近のトレンドをご紹介するコーナーです。数々のデータマネジメントPJを先頭に立ってやり抜く。口癖は「ええねんけどなぁー」。

プロローグ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜関連記事＞
データ移行ソリューション
ワーキングマザーDのデータマネジメント的日常：第３話　家庭内データ移行

※記載内容は執筆当時のものです。株式会社リアライズは2023年1月1日に株式会社NTTデータ バリュー・エンジニアに社名変更しました。

他の人気ブログ

関連コンテンツ

データ移行ソリューション

システム刷新に伴うデータ移行を、データ設計から本番移行までサポートします。