はじめに

前回は、『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』シリーズから、ケースその３「社長！データ品質は我が社の信用そのものです」前編をお送りしました。

物流業界で破竹の成長を続けるG社。

レガシーシステムからの脱却を目指して取り組むシステム刷新プロジェクト。

しかし、最初に取り組んだ「会計システム」の本番移行で大きな失敗をしてしまいました。

プロジェクトは大幅な遅延を余儀なくされましたが、何とか翌年のゴールデンウィークに新たな移行Xデーを確保。

前回の失敗の巻き返しを図ります。

果たしてその結果は……？

再移行Xデー：サーバー負荷を分散せよ 

８ヶ月前の手痛い失敗を繰り返さないため、今回は移行プログラムの並行処理を避けるようデータ移行を３回に分け、４日間かけて行うことになりました。

サーバーの処理能力を考慮した余裕のある作業スケジュールのおかげで、今度は無事に全てのデータ移行まで完了させることができました。

早速、G社の新会計システムは本番稼働が始まり、年に一度の大仕事である決算処理のジョブが実行されました。

これまで経理部スタッフが何日もかけて手作業で行っていた処理が、これからは自動で行えるようになったのです。

ようやくシステム刷新の成果が形になったことで、プロジェクトメンバーは少しだけ満足げな顔を見せました。

一夜が空けて：Xデーに隠れていたワナ 

決算処理のジョブが実行された翌朝、G社本社オフィスは騒然となっていました。

ERPの決算処理の結果、総勘定元帳の勘定残に違算が発生していたのです。

経理部のデスクの周りには会議室からかき集めたホワイトボードが幾つも並び、ERPから出力されたリストと伝票の束を突き合わせながら、手作業による検算結果を次々とホワイトボードに書き出しています。

経理部総出で行った検算は午後まで続き、ついに原因を突き止めました。

ゴールデンウィークのデータ移行が月をまたいだため、４月度の締め分と５月の仕掛り分が混在してしまい、引当金の一部で月ずれが生じていたのです。

ホワイトボードを睨んだまま眉間にシワを寄せる経理部長へ、隣のデスクから心配そうに見ていた総務部長がやってきて小さく声をかけました。

「来週、決算発表ですよね？」

必死のリカバリー作業：一難去って大災難  

違算の原因は突き止めたものの、問題はどうやってリカバリーするかです。

旧グループ３社のデータをもう一度移行し直す案が出されましたが、すでに２日間の稼働で本番データが更新されてしまっていますし、何より８ヶ月前の失敗が頭をよぎり、すぐに却下されました。

問題のレコードだけをオフラインで直接修正する案も出されましたが、ERPパッケージの内部はブラックボックスです。

下手にパッケージの外でデータをいじれば二次災害の恐れがありました。

他に妙案もなく、やむを得ず人海戦術でERPのオンライン画面からデータを一件一件確認して、人手で赤黒伝票を入力して修正することになりました。

経理部スタッフ総出によるオンライン画面と伝票を照らし合わせながらの修正作業が始まりました。

ところが、しばらくすると今度はオンライン画面に“予期せぬエラー”が出てしまい、操作を続けることができなくなってしまいました。

後から分かったことですが、エラーの原因は合併した旧グループ会社Z社から移行した過去分のデータにありました。

日付を表す項目のいくつかで、本来は西暦でなければならないところに和暦が入力されたデータがあったのです。

Z社がG社グループに買収されたとき、プログラムは西暦対応へ修正されていましたが、どうせ見られることもないだろうと10年以上前の過去データは和暦から西暦へ変換されていなかったのです。　

本来なら、データ移行プログラムで変換されるべきでしたが、移行プログラムの開発に使用した“サンプルデータ”には和暦データが含まれていなかったため、変換ロジックが漏れていたのです。

経理部の必死のリカバリーも力及ばず、G社の決算発表は期日に間に合いませんでした。

結末：社長！データ品質は我が社の信用そのものです

決算発表当日の朝を迎え、G社のホームページには『○○年度 決算発表延期のお知らせ』と題した告知文が掲載されました。

延期の理由として書かれていた“情報システムの一部で問題が発生したため”という一文に嘘はありませんでしたが、折り悪く大手銀行の大規模システム障害が社会問題化していた矢先だった事も重なり、株主や投資家は「システムの問題が発生」という言葉に強い疑念を抱きました。

結局、６月の株主総会では社長自ら一連の顛末に対する釈明を余儀なくされ、レガシーシステムからの移行失敗という報告に『物流DX成功企業』と呼ばれていたG社の先進的なイメージは信用を失い、株価も急落してしまいました。

G社　問題の原因はデータ移行の軽視～ 2025年の崖の手前の落とし穴　

『物流DX成功企業』だったはずのG社でしたが、データ移行という意外な落とし穴にはまってしまい、思いもしない経営危機を招いてしまいました。

今日でも多くのITプロジェクトでは、プログラム開発やパッケージ導入といった入れ物となる仕組みづくりに比べて、データ移行は軽視される傾向があります。

しかし実際には、データ移行はプロジェクトの最終局面であり『大将戦』と心得るべきなのです。

G社と同じ轍を踏まないために、データ移行で注意すべきポイントを以下にまとめます。

１．三現主義ならぬ三本番主義

製造業では３現主義（現場、現物、現実）が大原則とされていますが、データ移行に関しては三本番主義（本番データ、本番環境、本番リハーサル）が鉄則です。

G社の会計システム移行が最初につまずいたのは本番環境の処理能力を甘く見積もったことが原因でしたが、本番リハーサルを怠っていなければ、事前に回避できたはずのことです。

また、データ移行プログラムの開発において、本番データではなく、それに “近い“サンプルデータを使ってしまったため、サンプルデータには含まれなかったパターン（今回のケースでは和暦から西暦への変換）への対応が漏れてしまいました。

２．設計ドキュメントを過信せずデータそのものに向き合う

特に長年運用されてきた業務システムは途中幾度となく改修が加えられるものです。

現時点の設計書や定義書だけでは、いま動いているプログラムと最新のデータ仕様しか確認できません。

過去分も含めた移行対象データ全件のアセスメントが必要です。

おわりに

ブログを最後までお読みいただき、ありがとうございます。

第６回『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』ケースその3(後編）いかがだったでしょう？

2025年の崖を目前に控え、多くの企業でレガシーシステムの刷新が進められています。

G社と同じデータ移行の落とし穴にはまらないよう、三本番主義を参考にしていただけたら幸いです。

NTTデータバリュー・エンジニアは豊富な実績と経験から、成功のポイントを確実に押さえたデータ移行ソリューションをご提供します。

次回も皆さまを“データで創る一歩先の未来”へナビゲートさせていただきます。

敬具

※本文中のケースは実際にあった事例をベースとしたフィクションです。実在する企業・団体とは関係ありません。

他の人気ブログ