古いデータは、そのまま保存するべきだ

システム開発の問題

システムマイグレーションについての個人的な意見を述べさせていただきます。

少し古い記事ですが、こんな報道がありました。

NTT西日本の工事システム障害で新事実、「汚れた」移行データ6.3万件が停止招く

旧システムから新システムへマイグレーションするとき、旧システムのデータを新システムのデータに合わせて移行するときに、旧データが壊れて、その後のシステム障害の原因になったという事例です。

データ構造を変更するデータ移行は失敗する

NTT西日本に限らず、システムマイグレーションでは旧システムのデータを新システムのデータに移行するときに、データの一部が壊れてしまうのは、ほぼ必ず起きる現実です。

組織の偉い人達は、こういう事を知らないので、無理なデータ移行計画を立てて失敗を誘発します。

私は、システムマイグレーションを何度も経験しておりまして、データ移行も何度もやっています。

そして、その経験から言わせて貰えば「データ構造を変更するデータ移行は必ず失敗する」と言えます。

データというのは、今のデータ構造に合わせて作られているので、新システムへの移行のように、異なるデータ構造のデータベースへデータを移行しようとした時点で、元の「データとデータの関係」が必ず失われるので、その部分からデータは必ず壊れるのです。

現代のシステムデータは全てRDBで構築されていますから、リレーション構造が変われば、そのリレーションが失われるのは、当然なのです。

RDBを理解していない偉い人達は、データを「単なる断片的情報」としか認識していないので、「ウイスキーを樽からボトルに移し替える」ように、「簡単に入れ物を入れ替える事ができる」と考えます。

しかし、RDBのデータはリレーションとデータの組み合わせで成り立つ情報なので、この組み合わせを切り離すと、データは壊れてしまいます。

多くの場合、企業組織のデータマイグレーションは、古いデータの一部が壊れる事を認める形で、データ移行を実施しています。

私の知る限り、全てのデータを完璧にデータマイグレーションできているケースは皆無です。

多くの場合、意図的に古いデータの一部を捨てるか、多少はデータが壊れる事を許容してデータマイグレーションしており、問題があれば「運用でカバー」しているケースが大半です。

医療情報システムの例

データ構造の話と少し違いますが、以前生成AIに書いて貰った以下の記事を読んでみて欲しいと思います。

なぜ、UTF-8ではなく、まだ Shift-JIS が使用されているのか

この記事に出てくる、「医療情報システム」のケースでは、過去の電子カルテ情報などのShift-JISデータ量が膨大すぎて、最新の UTF-8 に変換する事ができない現実が説明されています。

過去のデータが「電子カルテ」のように絶対に失われてはいけないデータである場合、安易にデータマイグレーションを実施する事ができません。

この記事でも、医療情報システムでは以下のように生成AIが回答しています。

医療情報システムにおけるShift-JISの使用は、長年の歴史と膨大な患者データ、そして医療特有の要件に起因しています。患者の生命に直結するシステムであるため、安定性と正確性が最優先され、エンコーディングの変更には特に慎重にならざるを得ません。

しかし、医療のデジタル化や国際化の進展に伴い、UTF-8への段階的な移行も進められています。多くの医療機関では、新規導入システムや更新時期を迎えたシステムでUTF-8を採用しつつ、既存システムは慎重にShift-JISを維持するというハイブリッドアプローチを取っています。

これは文字エンコーディングの変更に限らず、システムマイグレーション時のデータ構造の変更でも、当てはまる事です。

もし、旧システムのデータが重要なデータであり、失われてはいけないのなら、データ移行をしてはいけないのです。

古いデータは年々増加する

当たり前の話ですが、古いデータは年々増加していきます。

日本の医療情報などは、古いものは1980年代からデジタル化されているわけで、もう50年近いデータの蓄積があることになります。 官公庁でも1990年代からデジタル化されています。

データではないですが、中小の工場では、今でもNECの PC-9801シリーズをFAに使用していたりするぐらい、デジタル化の歴史は長いものになってきました。

デジタル化の歴史が長いと、蓄積されたデータも膨大な量になっていきます。

システムのデータ規模によっては、システムマイグレーションより、旧データのデータマイグレーションの方が、コストが高くなる事態も考えられます。
医療と官公庁の個人データは既にそうなっているようです。
他の業界も時間の問題でしょう。

昔は、過去のデータ量が少ないので、データマイグレーションにそこまでコストと時間を掛ける事はありませんでした。
しかし、現代ではマイグレーションの際、40年50年というデータ蓄積の重みを、考慮する事が重要になってきています。

旧データは、そのまま保存すべき

ITの世界で旧データの扱い方は、まだ確立された方法論が定まっていないと思いますが、個人的経験から言わせて貰えば、旧システムの旧データは、文字エンコーディングやデータ内容とデータ構造を、変更することなく、そのまま保存すべきだと思います。

これは、医療データのように「絶対に失われてはいけない旧データ」に限ります。 多少データの一部が失われても良いなら、新データ構造に移行すべきでしょう。

現実には、老朽化したシステムは、新技術のシステムにマイグレーションしなければなりません。 マイグレーションのときに、データ構造を刷新して新しいデータ構造に変更するのは、当然と言えます。
しかし、同時にデータ構造を変更して、データ移行するとデータの一部が壊れる事を認識しておかなければなりません。

もし、旧データが失われてはいけないのなら、旧データと新データの DB-Server (データベース・サーバー)を分けるべきです。
旧データは旧データ構造の DB-Server にそのままのリレーション構造で保存して、新データだけを新システムの新データ構造上で管理すべきです。

誤解の無いように言っておきますが、古いDB機器をそのまま使えと言っているわけではなく、機器は新しい物に更新しても、データ構造は変更することなく旧データ構造の DB-Server を作成して、そちらに旧データを移行するという意味です。

システムマイグレーションの場合は、旧データは編集更新する事が無いはずなので、旧データ DB-Server は読取り専用の DB-Server となるはずです。

先の医療用情報システムのように、新旧ハイブリッド構成にすべきです。

当然の事ながら、旧データの内容を変更してはいけません。
旧データは、そのままで「正しい」のです。「旧データの正規化」などという愚かなマネをしてはいけません。

旧データは、化石や古典絵画・芸術作品や古代文書のように、そのままの形で保存すべきです。

なぜ、新旧データを統一する必要があるのか?

そもそも、ITシステムの世界では、なぜ新旧のデータを同じDBに格納するのでしょうか。

昔のメインフレームなどが代表的ですが、昔はDB機器が高価で、何台ものDB機器を設置する事ができなかったので、システムをマイグレーションするときは、古いデータも新しいデータも一つのDB機器に格納する必要がありました。
しかし、現代はクラウドの時代であり、クラウド側のDBサーバーを必ずしも一つに統一する必要はないと思います。
旧データと新データは、別々の DB-Server に格納して、旧データを旧データ構造の中でそのまま保管し、新データは新データ構造の DB-Server で運用すれば良いと思います。
文字エンコーディングなども、無理に Shift-JIS を UTF-8 に変換したりせずに、旧データは Shift-JIS のまま保存し、新データは UTF-8 で運用した方が良いでしょう。

旧データと新データの両方のデータを参照しなければならないケースは、新旧の DB-Server をアプリが両方参照するか、集計が必要な場合は、旧データの一部を新 DB-Server にコピーして利用すると良いと思います。
集計については、他に集計の前処理だけ旧 DB-Server で行い、新データと合わせる必要のある部分だけを新 DB-Server にコピーするという事も考えられます。

やり方は、いくらでもあるはずです。

もし、新旧二つの DB-Server 開発より、旧データの移行の方がコストが高くつくようなら、新旧のデータを別々の DB-Server で分けて管理する事を検討すべきでしょう。

少なくとも、私は新旧の DB-Server を一つに統一する考え方は、古く時代遅れの考え方だと思います。

何度も失敗しているのだから辞めた方が良い

実際、多くのシステムマイグレーションで、旧データの新システムへの移行は、何度も失敗しているはずです。 日本の多重請負SIerへシステム開発を丸投げにしている会社は、システム開発で何がどのように失敗しているのか把握していない会社が多いと思いますが、データ構造の大きな変更を伴うデータマイグレーションは一部のデータが破損する形で、失敗しているのです。

先に説明したように、実運用では多少のデータ破損は許容する事で、運用の努力で業務を回しているのが現実です。

データマイグレーションで成功しているのは、データ構造が変わらないか、旧データ構造を新データ構造が完全な形で内包している設計の場合だけです。

下から報告が上がっていないのだと思いますが、これまで何度もデータマイグレーションに大なり小なり失敗しているのだから、そろそろ現実の問題に向き合うべきだと思います。

蛇足

地方公共団体の基幹業務システムの統一・標準化

デジタル庁の進めている自治体データ標準化は、まさにこの記事で書いた典型的システムマイグレーションです。
自治体には膨大な過去のデータの蓄積がありますから、データマイグレーションも大変な作業になるでしょう。

残り1年半も混迷の自治体システム標準化、データ連携で新たに「レファレンス」作成へ

まだ、結果の出ていないプロジェクトですが、報道などに流れてくる情報を見る限り、上手く行っているようには見えません。
個人的には、良くない予感がします。

以上です。

タイトルとURLをコピーしました