はじめに

ブログ連載「拝啓、データの向こう側より」第５回は、システムの移行プロジェクトで生じたデータの不備が企業経営の危機にまで発展した事例を紹介します。

『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』

ケースその３「社長！データ品質は我が社の信用そのものです」を紹介します。

G社：『物流DX成功企業』 

国内の運輸会社G社は４３年前に大手メーカー企業の物流代行を請け負うBtoBビジネスとして創業した会社です。

１５年ほど前から積極的な事業拡大に転じ、中小の引っ越し会社や地方の宅配業者をM&Aによってグループ会社化することで、BtoC市場へも参入し急速な成長を遂げています。

今ではG社のトレードマークのダチョウマークが付いたトラックを街中で見ることができます。

BtoBとBtoCのノウハウをつぎ込んだ自動倉庫は、最新式のロボットを導入した先進的なもので、他の業界からも注目を集め、企業からの見学者が後を絶たないほどの評判です。

そして３年前、かつてM&Aで買収したグループ会社３社をG社本体へ合併すると同時に悲願であった株式上場も果たしました。

快進撃を遂げるG社は、次なる戦略として「AIによる輸送計画の最適化」構想を発表し、マスコミはこぞってG社のことを『物流DX成功企業』と称賛しました。

物流業界の中にあって、G社はまさに花形的な存在になりました。

上場した株価も急上昇を続けています。

G社が抱える課題：レガシーシステムの呪縛 

順風満帆に見えるG社でしたが、急成長の影で問題も抱えていました。

吸収合併した３つのグループ会社の情報システムは、M&Aされる以前から各社が使用していたシステムを使い続けていました。

各々のシステムに最小限の改修を加えることで、かろうじてG社本体の業務システムと連携させていたのです。

また、システム間の連携はバッチ処理で行われるためリアルタイムでの柔軟な業務連携ができず、例えば旧グループ会社をまたいで配送トラックの割当てを変更するには、出荷指示をいったんキャンセルして、もう一度最初から入力し直さなければなりませんでした。

その都度「必要最小限の改修」が繰り返された結果、システムはすっかり複雑化してしまい、業務プロセス改善の足かせになってしまう典型的なレガシーシステムと化していました。

G社の今後の業務改革やAI導入の効果を最大化するためには、このレガシーシステムから脱却するためのシステム刷新は、避けては通れない道でした。

脱レガシープロジェクト：G社ERPへの統合 

３つの旧グループ会社のシステム刷新は、G社本社のERPパッケージへ統合する形で実施する方針となりました。

プロジェクト全体のPMはERPパッケージベンダーから紹介されたコンサルティング会社が担当し、ERPパッケージのカスタマイズ開発は、運用アウトソーシングで多くの受託実績を持ち、パッケージのクセを知り尽くした大手SIerへ委託することが決まりました。

プロジェクトは業務システムごとに『会計』、『物流・配車』、『契約・販売』、『人事』の４つのチームに分けられ、下表の開発・移行スケジュールが立てられました。

一番最初にスタートした「会計」チームのカスタマイズ開発は順調に進み、最後の移行作業は予定通り８月のお盆休み期間でシステムを停止することができる２日間を使って行われました。

移行１日目の作業では、カスタマイズを反映したERPパッケージを本番サーバで再起動し、すべてのプログラムのチェックが行われました。

作業は夜間にまで及びましたが、１件のエラーもなく正常稼働が確認されるとプロジェクトメンバーの顔に安堵の笑みが浮かびました。

最終局面でのつまずき：終わらない移行プログラム

移行２日目の作業は、カスタマイズと並行開発した「データ移行プログラム」を使って、３つの旧システムの業務データを新システムに流し込むだけです。予定では昼過ぎには処理が終了して、早めの時間から打ち上げに繰り出すつもりでいました。

しかし、待てど暮せどデータ移行プログラムが終了しません！

時間ばかりが刻々と過ぎ、プロジェクト計画書に書かれた“移行判定基準”の午後４時を迎えると、PMは苦渋の表情で移行の延期とシステム切り戻しの判断を下しました。

調査の結果、問題の原因はデータ移行プログラムを実行するサーバの処理能力を甘く見積もったことでした。

合併前の３社（旧X社、旧Y社、旧Z社）は、それぞれ異なる業務システムだったので、データ移行プログラムも各々用に３つ作る必要がありました。

各々のデータ移行プログラムは各システムから抽出した“サンプルデータ”を使って開発され、想定されるパターンすべてを網羅したテストもパスしていたのですが、本番の移行データ全件を３つ同時に処理するのは初めてで、予想以上にサーバ負荷が発生していたのです。

再スケジュール：遙かなるXデー

原因が判明したことでプロジェクトは息を吹き返します。

早速、仕切り直しの日程調整に入りました。

しかし、システム移行のために本番システムを停止できるタイミングは限られています。

次の候補である年末年始休暇は、すでに開発が進んでいる『物流・配車』システムの移行に割り当てられてしまっていたので、まだ開発に着手していない『契約・販売』システムのスケジュールを融通してもらい、何とか翌年のゴールデンウィークを新たな移行Xデーにすることができました。

実に8ヶ月のスケジュール延期ですが、やむを得ない選択でした。

辛うじて確保できた新たな移行Xデーでしたが、そこには大きな罠が潜んでいたのです。

――後編に続く

おわりに

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

『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』

ケースその３「社長！データ品質は我が社の信用そのものです」(前編）いかがだったでしょう？

破竹の成長を続け、物流業界の花形となったG社。

更なる発展のためのシステム刷新プロジェクトでしたが、最初のターゲットである会計システムの本番移行で、思わぬつまずきに見舞われました。

果たしてプロジェクトは新たな移行Xデーで起死回生できるのでしょうか？

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

敬具

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

他の人気ブログ