移行から考える

移行から考える

システム開発プロジェクトにおいて、忘れがちだけれど非常に重要なことがあります。
それが「移行」です。

既に運用中のシステムから、新しく開発したシステムへ置き換える。
こうしたプロジェクトは決して珍しくありません。

私が一メンバーとして関わったあるプロジェクトでも、設計・開発フェーズがとにかく難航しました。
そして開発フェーズの終盤になって、ようやく「そろそろ移行のことを考えないといけないですね」という話が持ち上がりました。

移行は“別の開発”である

移行元と移行先のシステムでは、キー項目やデータ同士の関係（リレーション）が異なることが多くあります。
それが数十万件単位で積み上がっている場合、
単純なコピーでは済まず、「移行専用のプログラム」を作って加工する必要があります。

ここで注意したいのが、移行プログラムの特殊性です。

通常の業務プログラムは、
開発後にテストを重ね、実運用の中で想定外を経験しながら品質が磨かれていきます。
一方で移行プログラムは、次のような性質を持っています。

• 原則として一度しか使われないため、品質保証が難しい
• 切替作業中の限られた時間内で、確実に完走することが求められる

そのため、繰り返しリハーサルを行い検証を重ねる必要があります。しかし、一度しか使われないという前提は変わらないため、移行はどうしても「想定外のコスト」になりやすい領域です。

「どう飛ぶか」ではなく「どう着地するか」

たとえ話をすると、少し分かりやすくなります。

飛行機が発明された当初は、「どれだけ高く、どれだけ長く飛べるか」を競う時代でした。
しかし現代の飛行機は違います。最も重要なのは、滑走路に無事着陸できることです。その前提のもとで、機体が設計され、運航計画が立てられています。

システム開発も同じです。
「どう作るか」だけでなく、「どう切り替え、どう着地するか」について、開発ベンダーとシステムオーナーがあらかじめ目線を合わせておかないと、想定していたコストや納期に間に合わない、という事態が起こり得ます。

移行対象はすべて同じではない

参考までに、データは種類ごとに整理して考える必要があります。

• マスタデータ

顧客情報、商品情報など

• トランザクションデータ

見積伝票や請求データなど、履歴性の強い情報

マスタデータは新システムへ移行するが、トランザクションデータはCSVファイル保存で十分、といった判断が現実的なケースも少なくありません。

用語の整理

最後に、よく混同されがちな用語を整理しておきます。

• 移行

多くの場合、データ移行を指します。

• 切替
• ユーザー目線

旧システムの利用を停止し、新システムで業務を開始すること

• ベンダー目線

システム切替そのものに加え、DNSやロードバランサの切替作業なども含みます