移行データの正当性検証基準を考える

旧システムから新システムに切り替える時、エンジニアの多くは「新システム」を

　「どう作るか」

ということにばかりご執心となります。ほんの少し上位のエンジニアでも

　「何を実現するか」

ということにばかり目が移ってしまいます。
すると何が起こるのかというと

　・旧システム作成時の事情や状況を考慮しない
　・システム間のリソース移行を考慮しない

という状態が生まれます。特に軽視されがちなのは、

『旧システムのテーブル構成を完全に無視して
　新システムのＤＢ設計（テーブル構成）を新しく作り直す』

あるいは

『「旧システムのデータを使いまわすと楽だから」という理由だけで
　旧システムのＤＢ設計をそのまま踏襲する』

という乱暴な開発をしようとする人が出てきます。前者はエンジニアに多く、後者はマネージャーに多い傾向があります。

そういうシステム開発に関わってしまった時、一番被害を被るのはいつも

　・システム切替
　・データ移行

を担当しているチーム、担当者です。最近でこそ移行ツールが徐々に普及してきたこともあって、昔のように「移行するためだけの自動化プログラムを１から作成する」という機会は徐々に減ってきているのではないかと思います。その分、多少は楽になった現場も増えてきてはいるのでしょうが、

　「楽になったから」
　「自動化してるんだから」

という稚拙な理由だけで軽率に扱われがちな業務があります。それは

　移行データ検証

業務です。旧システムに存在するデータベース上のデータを新システムに移し替えるわけですが、この時そっくりそのまま映すわけではなく

　・テーブル構成の変化にあわせてカラムごとの再配置が必要
　・項目ごとの新仕様にあわせてデータ編集が必要

となることはよくあります。

たとえば、

　「今までは２桁で取り扱っていたコードだが、
　　市場の拡大にあわせて今後は３桁で管理する」

という仕様に変わった場合、既存の２桁のコードに対してゼロプレス…prefixに"0"を付与する編集が必要になったり…というものです。

　旧）00～99
　新）000～999

このように、データ自身を加工した場合は本当にその加工する処理が正しく機能しているのか確認するために、アウトプットとしてできあがった新システム用データを検証しなければなりません。

もし、数億～数十億件あるデータの中のたった１個でも仕様にないデータが存在してしまった場合、最悪システムがシステムエラーを起こして止まってしまう可能性だってあるのです。その結果、データそのものを復旧できないくらい破壊してしまった事故も過去にはたくさんありました。

ですので、たった１個のミスも許されません。

ここでポイントになるのは移行データに対して『検証を通過する条件とは何か』ということです。この品質基準が明確でなければOK/NGの判断も難しくなってしまいます。

仮に品質基準が

　「旧システムのデータ件数が漏れなく、
　　新システムへ移行できるレベルになっていること」

という定義だとすると、とにかくデータが移っている"らしい"ことしか判断できず人によって結論は変わってくるでしょうし、そもそもこの程度の定義であれば検証を不通過とすることはなかなかできません。

よって、検証の品質基準とは必ず"定量化"し、その数値を判断基準とする必要があるのです。

ただし、一般的に見た目などのいわゆる「知覚品質」と呼ばれるものに対して定量的な移行基準を定義することは非常に難しいため、これらに対しては都度品質基準の改善を加えていくものとします。

これは、私が長年関わってきた「データ移行」のプロジェクトから

　面・線・点

の３つの視座から確認するために設けた各レイヤーとなります。