システムの移行ってなんでしょうか？

簡単に言ってしまうと、古いシステムから新しいシステムへのお引越しです。

例えば、住まいの引っ越しであれば、現在の住宅で生活をしながら、新しい住居を決め、持っていく家財と捨てる家財を分類し、持っていく家財は新しい住居のどの部屋に設置するか決め、引越し業者に伝えて家財を移動してもらいます。

まさにシステムでもこれと同じことを行います。

古いシステムで業務を運用している間に、新しいシステムを企画・開発し、新システムの完成時に古いシステムのデータを新しいシステムに移し替えます。

データならコピーすればいいのだから、簡単だろう、そう思われるかもしれません。

しかし、システムの引っ越しはそこまで簡単ではありません。古いシステム上に蓄積したデータを新しいシステム上に正しい形で引っ越しさせるのはなかなか難しい作業であったりします。

ものすごい簡単な一例を挙げると、利用者の情報を保持するデータベースがあったとします。
性別のようなカテゴリーごとに決まった種類を管理する際にはマスタテーブルが使われます。例えば現行システムには次のような性別を定義するマスタがあったとします。

次に新システムではジェンダーフリー対応などでマスタをこのように見直したとします。

なにも考えずに登録済みデータを新システムへ持ってくると、既に登録済みのデータの男性は性別なしに、女性は男性になってしまいます。これを元の意味を維持するようデータ変換を行います。

これはとてもシンプルな例ですので簡単に見えますが、実際は複雑にデータ設計されたシステムでは現行システムのデータを正しく新システムのデータに変換するには大変な労力がかかります。

今回は、システム切り替えやデータ移行とはどんなもので、何に気をつけないといけないのかという点について、書いてみたいと思います。

私のシステム移行経験

いろいろありますが、今回はその中の１つ、データベースに蓄積されているデータの引っ越しに焦点を絞って書きたいと思います。

私はお客様先で運用していたシステムの移行担当を数回経験しています。その中でも規模が大きかったもの、それととても苦労したので記憶に焼き付いているものの２つを紹介します。

その１、MS-AccessデータベースからWebシステムへのデータ移行

2000年代では小規模なシステムならAccessデータベースで作って手軽に運用するシステムが私の周りでは流行っていました。

MS-Accessデータベースで作成された小さいシステムでしたが、それをWebアプリケーション化しようというものでした。

現行システムから新システムへの移行で特に気をつけないといけないのは、現行システムで採用しているデータベースと新システムで採用したデータベースが異なっていたため、カラムの型の違いを解決する必要がありました。

型には文字型、数値型、日付型など大まかな型はほぼ共通ですが、データベースシステムによって細かい点が異なり、型だけではなく、どんな使われ方をしているかなど細かく現行システムを解析しないとデータが正しく移行できません（まるで方言のようです）。

また、先の例のように現行システムのデータがそのまま新システムのデータとして使えないものもあれば、データ構造自体が変わるため新システムでも同じ解釈されるようにデータ構造自体を変換する必要があるものもあり、困難を極めました。

データベースの全データを洗い出して新システムのデータベースのどこにどう値を入れるか１つひとつ検証していき、無事に新システムへのサービス切り替えに成功したのでした。

その２、Webシステムの大型リニューアルに伴うデータ変換

リリース済みのシステムでもつねにバージョンアップを重ねて使い勝手の向上や新機能の追加などを行っていきます。

その中で大きな機能追加や機能改善などを行う場合、内部のデータ構造を大きく変更する必要があったりします。

内部のデータ構造に変更を行った場合は、追加や改善した機能以外の機能が正しく動作するか再検証が必要となります。こちらもその１と同様にデータのマッピングや変換仕様を決めてプログラムを設計開発しました。

データ移行で一番気を使うのは現行システムからのデグレーションがあってはならないということです。今まで動いていたものが新しくしたら動かなくなったというのは印象最悪ですよね。これを予防するため、何回もデータ移行リハーサルを行い、異常がなくなるまで繰り返しました。

このようにシステムの移行はとても繊細で緻密な移行計画や作業によって行われ、少しでもミスがあると新システムに切り替えた後にトラブルを誘発してしまうエンジニア観点で言うと神経をすり減らす大変な作業であります。

しかし、お客様から見ると最初に書いたようにシステムを切り替えるだけだからそんなに難しいの？（お金がかかるの？）という印象を持たれることが多いです・・・

現行システムから新システムへ切り替える場合、新システムの安定稼動の鍵を握っているのは、このシステム移行なのです。

移行が必要な新システムを開発する場合の注意点

依頼するITベンダーの選定基準

私がシステムリニューアル担当であったなら、まずは現行システムを開発したITベンダーに依頼します。

当たり前のことですが、現行システムを知り尽くしているので、新システムを設計・開発する際にどのデータをどこに配置すればよいのか理解できているため最も安全です。

但し、現行システム開発からしばらく期間が空いてしまっている場合は、現行システム開発当時のエンジニアがもう在籍していない場合もありますので、そこは要注意です。
また、最近ではオンプレミス構成で稼動させていたシステムをクラウド化したいというようなケースもあります。その場合はクラウド開発の実績がある新しいITベンダーに依頼した方がよいというケースもありますので一概には言えないところはあります。

私の経験上、何らかの理由があって現行システムを開発したITベンダーに依頼できないケースがあるようで、実際には現行システムを知らない新しいITベンダーに依頼するケースが多いように思います。

新システムの設計開発と移行設計開発は並行が計画した方がよい

システム移行は新システムの設計開発のどの段階から考え始めればよいのでしょうか？

私としては、新システムの設計が始まってデータベース設計を行うタイミングがよいと思っています。

このタイミングで現行システムのデータベース構造を解析して新システムのデータベース構造を決めますので、このタイミングで現行のデータをどう移し替えるかというところまで検討しておくと二度手間になりません。

但し、新システムのデータベース設計が未熟な状態で並走すると設計変更が発生する度にデータ移行設計にも反映させる必要もあり、ダブルメンテとなって余計に手間が発生することもありますので、移行設計の開始時期はケースバイケースだと思います。

設計工程の状況に合わせて柔軟に移行設計開始時期を決められるようにしておくとよいと思います。

システム移行で発注者側が確認しておいた方がいいポイント

システム移行についてはシステム発注側もいつ、なにを行う予定なのか、ITベンダー側と認識をあわせておいた方がよいでしょう。

• システム移行の費用見積もり時期はいつか

• 移行計画（誰が、なにを、いつまでにやるか）は明確か

• システム切り替えは一回で切り替えるのか、段階的に切り替えるのか

• 現行システムと新システムの並行稼動の有無、あるならその期間は妥当か

• 切り替え手順は明確にドキュメント化されているか

• 切り替えリハーサルは計画されているか

• 切り替えに失敗した場合のコンチプランは準備されているか

• 新システム稼動後の保守体制は万全か

最後に

今回のシステムの移行について書いてみました。いかがでしたでしょうか。
いろいろ書いていたら、当時のことを色々と思い出してしまいました。

現行システムから新システムへの切り替えは、システムを使うユーザ側からみると、ああ、新しくなったなーぐらいなのですが、その裏にはシステムエンジニアの奮闘のドラマがたくさんあります。

今でも大きなシステムのリニューアルのニュースや記事を見るたびに、その裏にはどんなドラマがあったのだろうと想像してしまいます。

逆にうまくいっていないニュースを見ると他人事ですが、身が縮む思いがしてしまいます。

それではまた！