基幹システムの入れ替えで失敗が起きるのは、運が悪かったからではありません。データ移行、現場運用、並行稼働、体制のどこかに共通するつまずき方があり、事前に潰せるものがほとんどです。この記事では、基幹システムの入れ替え失敗がなぜ起きるのかを4つの型に整理し、公開されている事例から読み取れる教訓、契約前に確認すべき項目、そして切り替え前に決めておきたい「戻す条件」まで、発注側の目線でまとめます。
この記事のポイント
- 基幹システムの入れ替え失敗は、データ移行・現場運用・並行稼働・体制の4つの型に分かれる
- 公開されている失敗事例の共通点は、想定より複雑な移行作業と短すぎる並行稼働期間
- 失敗の多くは契約前の確認項目を洗い出しておくことで防げる
- 切り替え当日に迷わないよう「戻す条件」を事前に決めておくことが重要
目次
基幹システムの入れ替え失敗はなぜ起きる？よくある4つの型
基幹システムの入れ替え失敗を個別事情の積み重ねとして見てしまうと、対策も後手に回ります。実際には、業種や規模が違っても共通する失敗の型があります。ここでは、データ移行・現場運用・並行稼働・体制の4つに分けて整理します。
| 失敗の型 | 起きやすいタイミング | 典型的な症状 |
|---|---|---|
| データ移行 | 移行リハーサル〜本番直前 | コード体系の変遷や重複データが直前に発覚 |
| 現場運用 | 切り替え直後 | 例外処理や帳票が新システムで再現できない |
| 並行稼働 | 本番切り替え後 | 入力形式やマスタの不整合が連鎖的に表面化 |
| 体制 | プロジェクト全体 | 続行・中止の判断者が決まっておらず対応が遅れる |
データ移行の見落としで起きる失敗
基幹システムには数年から数十年分のデータが積み上がっています。運用が長いシステムほど、途中でコード体系が変わっていたり、同じ取引先が表記違いで重複登録されていたり、本来必須のはずの項目が空欄のまま残っていたりします。
こうした不整合は、要件定義の段階では見えず、実際にデータを移してみて初めて発覚することが少なくありません。移行直前になって「想定より件数が多い」「クレンジングが終わらない」と分かり、スケジュールが後ろ倒しになるのはよくあるパターンです。データの棚卸しと移行リハーサルを早い段階で始めるほど、この型の失敗は避けやすくなります。
特に、月次や年次でしか使わないデータ(過去の取引履歴や、特定の時期にしか発生しない例外処理のデータなど)は見落とされがちです。移行リハーサルを1回だけで終わらせず、通常月と締め処理の月それぞれで一度ずつ試しておくと、直前になって慌てる事態を減らせます。
現場運用と新システムのズレによる失敗
新しい基幹システムは、旧システムの画面や入力手順をそのまま再現しているわけではありません。現場の担当者が長年の勘で運用していた例外処理や、紙の帳票とセットで回っていた業務フローが、新システムの標準機能には存在しないというケースがよく起きます。
要件定義の場に現場の担当者が十分に関われていないと、切り替え後になって「この作業ができない」「毎日この帳票を使っていた」という声が一気に出てきます。業務フローの棚卸しは、情報システム部門だけでなく、実際にシステムを使う現場を巻き込んで進めることが欠かせません。
現場の声を集める際は、担当者に「今の業務を説明してください」と聞くだけでは、当たり前になりすぎている手順が抜け落ちがちです。「1日の作業の流れを、朝から順番に洗い出す」「月に一度しかやらない作業も別途書き出す」といった具体的な聞き方に変えると、要件の抜け漏れを減らせます。
並行稼働の設計不足が招く失敗
切り替え直後は、旧システムと新システムを一定期間並行して動かし、結果を突き合わせて確認するのが基本です。ところがコストや期間の都合で並行稼働期間を短く切り詰めてしまうと、想定していなかった入力形式の違いやマスタデータの不整合、帳票の出力エラーが本番後にまとめて表面化します。
いったん現場が混乱すると、旧システムへ緊急で切り戻し、原因を洗い出して再移行するまでに数か月かかることもあります。並行稼働の期間は「短くできるか」ではなく「何を確認し終えたら終了してよいか」という基準で決めるべきものです。
並行稼働の期間を決める際は、単純な日数や週数ではなく、業務のサイクルを基準に考えるのがポイントです。日次処理だけでなく、月次の締め処理、可能であれば四半期や年次の処理まで一巡できるかどうかを基準にすると、期間を削るべきではないラインが見えやすくなります。
体制・役割分担の不備による失敗
基幹システムの入れ替えは、要件定義からデータ移行、テスト、切り替え判断まで関わる範囲が広く、発注側・開発会社のどちらが何を決める責任を持つかが曖昧なままだと、判断の遅れがそのままスケジュールの遅延やトラブル対応の遅れにつながります。
特に、切り替え当日にトラブルが起きたときに「誰が続行・中止を判断するのか」が決まっていないと、現場が混乱している間に被害が広がってしまいます。役割分担は契約前の段階で言葉にしておく必要があります。
体制の不備は、プロジェクトの初期には表面化しにくいという特徴もあります。要件定義やテストの段階では多少の役割の曖昧さがあっても大きな問題にならず、切り替え直前になって初めて「誰の指示で動けばいいのか分からない」という状態が露呈します。プロジェクト計画書に体制図と責任範囲を明記し、定例会議で更新していくことが対策になります。
公開されている失敗事例から読み取れること
2024年4月、江崎グリコが基幹システムの切り替え後にシステム障害を起こし、乳製品などチルド商品の出荷を一時停止した事例が報じられました。同社の公式発表によると、出荷の完全復旧までに半年以上を要し、後日公表された決算では、この障害が業績に大きく影響したと説明されています。
この事例に限らず、報道された基幹システムのトラブルに共通するのは、切り替え後にデータや処理の不整合が連鎖的に広がり、復旧までの期間が当初の想定を大きく超えている点です。個別の技術的原因を断定することはできませんが、影響の大きさを知っておくことは、自社の入れ替えプロジェクトにどれだけの慎重さが必要かを判断する材料になります。
報道された事例の多くは、自社よりはるかに大きな取引規模を持つ企業のものですが、「切り替え直後の混乱が長期化すると事業全体に影響しうる」という構造そのものは、企業規模にかかわらず共通しています。自社の規模なら大丈夫だろうと油断せず、影響範囲を洗い出しておくことが備えになります。
基幹システムの入れ替え失敗を防ぐために発注側がやること
基幹システムの入れ替え失敗を防ぐポイントは、切り替え当日にどう乗り切るかではなく、契約前にどこまで決めておくかにあります。ここでは、発注側が契約前に確認しておきたい項目と、切り替え前に決めておくべき撤退判断の基準を整理します。
契約前に確認しておきたいチェック項目
見積もりや提案内容だけを見て発注してしまうと、後になって「そこまで含まれていなかったのか」というトラブルにつながりやすくなります。契約前には、少なくとも次のような項目を開発会社とすり合わせておくと安心です。
契約前に確認しておきたい項目
- データ移行の対象範囲と、移行できなかった場合の代替手段
- 並行稼働の期間と、切り替え可否を判断する基準
- 現行の業務フローで再現できない機能があるかどうか
- 切り替え後トラブル時の対応窓口と復旧目標時間
- 追加費用が発生する条件と、その通知タイミング
これらは提案書には明記されないことも多いため、発注側から具体的に質問し、回答を書面で残しておくことが大切です。口頭でのやり取りだけで済ませてしまうと、いざトラブルが起きたときに「言った・言わない」の水掛け論になりやすく、対応がさらに遅れる原因になります。
特に見落とされやすいのが、追加費用の発生条件です。「現行踏襲」という言葉だけで進めてしまうと、実際に現行の仕様を再現しようとした際に想定以上の作り込みが必要になり、後から追加見積もりが提示されるケースがあります。何をもって現行踏襲とするかの範囲は、契約前にできるだけ具体的にすり合わせておきましょう。
切り替え前に「戻す条件」を決めておく
切り替え直後にトラブルが起きたとき、現場が混乱している最中に旧システムへ戻すかどうかを一から議論していては手遅れになります。「どの症状が出たら旧システムに戻すか」「誰が最終判断するか」「判断までに許容できる時間はどれくらいか」を、契約前から開発会社と合意しておくことが重要です。
戻す条件をあらかじめ決めておくと、切り替え当日の判断が速くなるだけでなく、開発会社側にも「どこまで慎重に準備すべきか」という緊張感が生まれます。稟議を通す段階でも、この撤退基準を示せると、経営層への説明がしやすくなります。
具体的には、「受注データの登録件数が想定と◯%以上ずれている」「基幹の在庫連携が◯時間以内に復旧しない」といった、現場が客観的に判定できる基準を数値で置いておくのが実務的です。感覚的な基準では、当日の混乱の中で「まだ様子を見よう」という判断に流されやすくなります。
基幹システムの入れ替え失敗に関するよくある質問
- Q. 基幹システムの入れ替え失敗が起きたとき、責任は開発会社と発注者のどちらにありますか？
- A. 契約形態や事前の合意内容によって変わります。要件定義の内容や現行仕様の確認が不十分だった部分は発注側の責任が問われることもあれば、テスト工程での見落としのように開発会社側の責任が問われることもあります。だからこそ、契約前にどこまでを誰が確認する責任を持つかを言葉にしておくことが重要です。責任の所在があいまいなまま進めてしまうプロジェクトほど、トラブル時の対応が遅れやすくなります。
- Q. 並行稼働の期間はどれくらい確保すればいいですか？
- A. 一律の日数で決めるのではなく、月次・年次の締め処理など、業務のサイクルを一巡確認できる期間を目安にするのが安全です。コスト削減のために期間だけを短縮すると、締め処理のタイミングで不整合が発覚し、かえって手戻りが大きくなることがあります。
- Q. 戻す条件は契約書のどこに書けばいいですか？
- A. 個別の条項として明文化するのが望ましいですが、難しい場合は移行計画書や切り替え手順書に「判断基準」「判断者」「判断までの許容時間」を明記し、契約書からその文書を参照する形でも運用できます。あくまで一般的な整理であり、実際の契約内容は個別の案件に合わせて確認してください。
