基幹システム刷新が失敗する主な原因は何ですか？

新機能の不足より、止められる業務と止められない業務、移行中の新旧分担、開始を延期する条件、旧システムへ戻す条件が未決のまま本番日を迎えることが原因になりやすい。判断条件と決定者を計画時に固定する。

一括移行と段階移行はどう選びますか？

業務間のデータ依存が強く分離できない場合は一括移行を検討する。境界で渡す項目、正とするシステム、照合方法を明確にでき、先行範囲だけでも効果を確認できるなら段階移行を選びやすい。

切り戻し条件には何を書きますか？

重要業務を続けられない、金額や数量の整合が取れない、未完了取引を引き継げない、障害の復旧見通しを判断できない、といった業務上の条件を書く。誰が何時点で判断するかも同じ行に置く。

基幹システム刷新が失敗する原因｜停止許容・段階移行・切り戻しを決める表

基幹システム刷新の失敗は、予定日に動かなかったことだけを指さない。動き始めても、現場が旧システムや表計算へ戻り、新旧の数字を経営者が毎回確認するなら、刷新前より判断が重くなる。

何を基幹業務と呼ぶかは会社ごとに違う。範囲が未定なら基幹業務の線引きを先に行う。この記事では刷新対象が決まった後の、停止許容、移行方式、切り戻し、責任分担に限定する。

「稼働日」を決める前に停止許容を書く

プロジェクト計画では本番稼働日が先に目立つ。しかし業務側が必要なのは、各工程をいつからいつまで止められるか、止められない場合に何で代替するかだ。受注は止められなくても、在庫更新は一時記録へ逃がせるかもしれない。請求処理は締め日をまたげない一方、分析帳票は後から再作成できる。

業務	停止の影響	一時代替	再入力	判断者
受注	注文を受けられない	受付台帳	要	営業責任者
出荷	納期へ影響	出荷指示一覧	要	物流責任者
請求	請求・入金が遅れる	事前作成または延期判断	条件次第	管理責任者

一時代替を用意すればよいわけではない。代替中に発生した取引を新システムへ戻す担当と、二重登録を照合する方法まで決める。代替手順が複雑なら、それ自体が移行日を選ぶ判断材料になる。

段階移行は分けられる境界がある場合に選ぶ

一括移行は切替が一度で済むが、同時に変える範囲が広い。段階移行は検証範囲を絞れる一方、新旧システムの連携と二重運用が生まれる。どちらが安全かは、業務を分ける境界を定義できるかで決まる。

先行業務から後続業務へ渡す項目が決まっている
移行中にどちらを正とするか、項目ごとに決められる
新旧の照合を日常運用へ組み込める
後続業務が遅れても先行業務を戻さずに運用できる
段階ごとの完了条件を業務の結果で判定できる

分けられない依存関係を無理に切ると、連携のための手作業が増える。ERPを含む対象範囲と段階導入の判断は中小企業のERP選定基準、持ち込むデータの分け方はERPデータ移行の棚卸しも参考になる。

切り戻しは手順より条件を先に決める

切り戻し手順を用意しても、開始するかどうかを誰も決められなければ使えない。本番当日は情報が不完全なまま時間だけが進む。そこで、技術的な障害名ではなく業務上の継続可否で条件を書く。

判定項目	継続条件	満たさない場合	決定者
重要業務	代替を含め処理可能	開始延期または切り戻し	事業責任者
取引データ	未完了状態を引継可能	差分反映をやり直す	業務責任者
金額・数量	定義した照合が一致	原因特定まで確定しない	管理責任者
復旧見通し	業務側が判断できる説明あり	切り戻し判断へ進む	統括責任者

切り戻す場合、切替後に新システムへ入った取引を旧側へどう戻すかも必要だ。戻すほど差分が増えるため、判断の締切時刻を置く。締切を過ぎてからは復旧継続へ切り替えるなど、選択肢を限定しておく。

責任分担表は「相談される人」を増やさない

関係者を多く書くほど安全になるわけではない。作業、内容確認、最終決定、連絡を分け、各行の最終決定者は一人にする。経営者はすべての作業承認に入るのではなく、開始延期、切り戻し、許容する不一致など、事業影響の大きい判断に限定する。

作業担当：データ抽出、設定、切替作業を実行する。
業務確認者：取引を続けられるか、現場の結果で確認する。
決定者：継続、延期、切り戻しのいずれかを選ぶ。
連絡担当：現場、取引先、関係部門へ同じ内容を伝える。

IPAは令和7年度のITストラテジスト試験問題冊子を公式に公開している（IPA公式PDF）。基幹刷新は製品設定だけでなく、事業継続と情報システム戦略の判断として扱う必要がある。この記事の表も、技術担当だけのチェックリストではなく、業務側が判断できる言葉で作る。

リハーサルで確認するのは速度だけではない

リハーサルでは作業時間だけでなく、判断材料が予定どおり届くかを見る。照合結果は誰へ渡るか、不一致の原因を説明できるか、判断者が不在なら誰が代行するか、連絡文面が準備されているかを通す。

停止開始から入力再開までを一連で実行する
未完了取引を新側で次の工程へ進める
意図的に不一致を作り、検知と報告を確認する
継続と切り戻しの判断会議を模擬する
代替記録を新システムへ戻し、二重登録を照合する

刷新判断台帳に、未決事項の期限を置く

移行計画の会議で危険なのは、未決事項が議事録の文章に埋もれることだ。「業務部門で確認する」「ベンダーと調整する」のまま次回へ送られ、稼働直前に経営判断として戻ってくる。未決事項を一行ずつ台帳へ出し、業務影響、選択肢、必要な証拠、決定者、決定期限を持たせる。

未決事項	放置した影響	判断材料	決定者
旧入力の停止時点	差分が増え続ける	停止許容表、代替手順	事業責任者
残る不一致	開始判断ができない	対象取引、金額・数量への影響	管理責任者
機能の後送り	手作業が無期限に残る	代替担当、終了条件	統括責任者

期限は作業完了日ではなく、その判断が後続工程に必要になる日から逆算する。決定者が判断できる粒度まで選択肢を絞り、現場の詳細確認と経営判断を混ぜない。

稼働後の安定を「問い合わせがない」で測らない

現場が困っていても、問い合わせ方法が分からず旧手順で処理していれば件数は増えない。稼働後は、代替台帳に残る取引、新旧の照合差異、手入力で補った項目、管理職への確認待ち、未解決の例外を同じ一覧で見る。

暫定対応には必ず終了条件と担当を付ける。表計算で補完すること自体が失敗なのではない。終了条件がなく、誰も止められないまま第二の基幹システムになることが問題だ。安定判定は、重要業務が回るだけでなく、暫定対応が減り、数字の正が一か所へ戻ったことで行う。

基幹システム刷新の成功条件は、新画面が表示されることではない。重要業務が続き、数字の正が一つに戻り、判断が特定の人へ集中しないことだ。その条件を稼働日の前に表へ置けば、本番当日の迷いを減らせる。

刷新後に旧システムを閉じる判断も、最初から責任分担表へ入れる。旧側でしか参照できない履歴、残っている連携、監査や問い合わせで使う記録を洗い出し、代替先と確認者を決める。旧環境を残すこと自体を安全策にすると、新旧のどちらが正か分からない期間が続く。

最後に、計画時の停止許容表と、稼働後に実際に起きた停止・代替・再入力を比較する。想定外の負担が出た業務は、次の段階移行や機能追加へ進む前に直す。予定どおりの日付で進むことより、業務を継続できる条件を守ることを優先する。