LASSIC Media らしくメディア
並行稼働と一斉切り替えの違い|期間の決め方と二重入力の負担
監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

この記事の結論
- 並行稼働は、新旧のシステムを一定期間同時に動かし、同じ業務の結果を比べてから切り替える進め方です。
- 旧システムで業務を続けながら移れる反面、利用部門の二重入力と、新旧を動かす設備の負担が重なります。
- 期間は保守の期限と比べたい業務の山から決め、旧システムを止める基準を始める前に合意しておきます。
※ 本記事は2026年10月時点の公式情報(省庁・公的機関、および製品やサービスを提供する事業者が公開している資料)に基づきます。
新しいシステムに切り替えた初日に計算の結果が合わず、もう旧システムには戻せない。並行稼働を決めたものの、現場から二重入力がつらいという声が上がる——。システムの入れ替えを控えた情報システム部門では、こうした悩みが起こりがちです。並行稼働は、新旧のシステムを一定期間同時に動かし、同じ業務を両方で処理して結果を比べながら切り替える進め方です。
切り替えた後に不具合が見つかっても業務を止めずに済む点で、使いどころのある方法です。ただし万能ではなく、利用部門の入力の手間や、新旧を同時に動かす設備の分だけ負担が増えます。本記事では、システムの入れ替えを任された情報システムの担当者に向けて、並行稼働の意味、一斉切り替えとの違い、期間の決め方、二重入力の負担の減らし方、そして外部に頼むときに確認したい点を整理します。
並行稼働とは
IPA(情報処理推進機構)の「システム再構築を成功に導くユーザガイド」は、並行稼働を稼働開始後のリスクへの対策の一つに挙げ、「一定期間、現行システムと新システムの両方で同一オペレーションを実施し、故障を洗い出す」ものと説明しています。*1 テストで確かめきれなかった処理の不具合を、旧システムが動いているうちに本番のデータで見つけるための期間です。
- 新旧の両方に同じ入力をして、出てきた結果を突き合わせる
- 不具合が見つかっても、業務は旧システムの結果で続けられる
- 終わりの日に旧システムを止め、新システムだけの運用に移る
- IPAの非機能要求グレード(性能や移行など、機能以外の要求をすり合わせるための項目一覧)にも、移行の項目として「並行稼働の有無」が入っています*2
似た言葉に「現新比較テスト」があります。同じ入力で現行システムと新システムの出力が一致するかを確かめるテストで、*1 リリースの前に検証用の環境で行います。並行稼働は、この突き合わせを本番の業務の中で続けるものです。
並行稼働と一斉切り替えの違い
一斉切り替えは、決めた日に旧システムを止め、すべての業務を新システムへ一度に移す進め方です。非機能要求グレードは、全業務を一斉に切り替える場合を「効率を優先させて一斉に切り替える」と説明しています。*2 業務や拠点ごとに順に移す段階的な切り替えもあり、並行稼働はこれらと組み合わせて使うこともできます。

| 項目 | 並行稼働 | 一斉切り替え | 段階的な切り替え |
|---|---|---|---|
| 進め方 | 新旧を同時に動かし、同じ業務を両方で処理する | 決めた日にすべての業務を新システムへ移す | 業務や拠点ごとに順に新システムへ移す |
| 旧システム | 期間中は動かし続ける | 切り替えの日に止める | まだ移していない業務の分だけ動かす |
| 利用部門の手間 | 同じ入力を2回する負担が続く | 切り替えの前後に作業が集中する | 移す順番ごとに説明と準備が要る |
| 不具合が出たとき | 旧システムの結果で業務を続けられる | 直すか元に戻すかをすぐ決める | 影響は移した範囲にとどまる |
| 向いている場面 | 計算や帳票の正しさを本番で確かめたい | 止める時間を取れて仕組みが単純 | 拠点や業務の数が多い |
どれを選ぶかは、移行のためにシステムを止められる時間で大きく変わります。非機能要求グレードは、停止の期間を十分に取れるなら並行稼働の必要性は低く、停止の期間が少ない、または止められない場合は、移行時のリスクを考えて並行稼働が必要という段階を示しています。*2 切り替え当日の段取りや元に戻す計画は、システム移行のカットオーバー計画で扱っています。
並行稼働の期間の決め方
並行稼働の期間に決まった長さはありません。IPAのユーザガイドは、利用部門の負担が増えるため「利用部門がどれほど並行稼働を許容可能か」を確かめること、現行システムのサポート終了の期限内に実施できるかを確かめることを求めています。*1 次の4つの順に決めると、根拠を説明できる期間になります。
- ステップ1:右端の期限を確かめる。現行システムのサポート終了日や保守契約の満了日のうち、いちばん早いもの
- ステップ2:比べたい業務の山を選ぶ。月末の締め、給与の計算、年度末の処理など、新旧の結果を比べたい処理が期間に入るか
- ステップ3:利用部門が受け止められる負担を聞く。繁忙期と重ねない
- ステップ4:終わりの基準を決める。どの処理の結果が何回一致したら旧システムを止めるか
中でもステップ4が大切です。ユーザガイドは、テストの完了基準があいまいなままだと完了の判断ができず、テストを際限なく続ける事態に陥ることがあり、特に現新比較テストでそうなりやすいと指摘しています。*1 並行稼働も同じで、終わりの基準を始める前に関係者と合意しておけば、期間がずるずる延びるのを防げます。入れ替え全体の工程表の中で並行稼働をどこに置くかは、システムリプレイスのスケジュールにまとめています。
二重入力の負担と減らし方
並行稼働でいちばん重いのは、同じ伝票や申請を新旧の両方に入力する手間です。利用部門はふだんの仕事に加えて入力を2回こなし、食い違えば理由も調べます。負担が重すぎると入力の漏れが起き、新旧を比べる意味が薄れてしまいます。

- 対象を絞る:計算や帳票の正しさを確かめたい業務だけを並行稼働にし、照会だけの業務は先に切り替える
- 入力を1回にする:旧システムに入ったデータを、決まった時刻に新システムへ取り込む仕組みを用意する
- 比べる作業を道具に任せる:新旧の出力を突き合わせる表や仕組みを用意し、差の出た所だけを人が見る
- 窓口を決める:食い違いを見つけたときの連絡先と、直すまでの業務の扱いを先に決めておく
設備の手当ても忘れずにおきます。新旧を同時に動かす間は、機器を置く場所と電源も両方の分が要ります。非機能要求グレードも、並行稼働をする場合は移行時の設置スペースと電力について別に対策を検討するよう求めています。*2 クラウドへ移る場合も、期間中は新旧の利用料が重なる点を見込んでおきます。
外部に頼むときに確認しておきたい点
並行稼働は、開発を担う会社と利用部門の両方が深く関わる期間です。移行を外部に頼むときは、見積もりの前に次の点を確かめておくと、期間中の行き違いを減らせます。
- 範囲:期間中の結果の突き合わせと、食い違いの調査をどこまで任せるか
- 二重入力の手当て:データを新システムへ流す仕組みや、出力を突き合わせる道具を用意してもらえるか
- 終わりの基準:旧システムを止める条件を数値で決め、関係者と合意する場を設けるか
- 不具合への体制:期間中に不具合が出たとき、誰がどれだけの時間で直すか。ユーザガイドは、開発の要員を運用の担当として残す計画を例に挙げています*1
- 延長の決め方:基準を満たさないときに期間を延ばすのか、切り替えを見直すのか
特に終わりの基準と延長の決め方は、契約の範囲や費用に関わります。並行稼働の途中で決めようとすると、旧システムの保守の期限が迫り、選べる手が少なくなります。
まとめ:並行稼働で確かめておきたい3つの点
並行稼働を計画するうえで、確かめておきたい点は3つに整理できます。第一に、移行のためにシステムを止められる時間を確かめ、一斉切り替えで足りるのか、並行稼働が要るのかを決めること。第二に、保守の期限と、比べたい月末や年度末の処理から期間を決め、旧システムを止める基準を始める前に合意すること。第三に、二重入力の負担を、対象の絞り込みやデータの取り込み、突き合わせの道具で軽くしておくことです。この3点を踏まえておけば、「並行稼働を始めたものの、いつ終えてよいか分からないまま現場が疲れ切った」という事態を避けやすくなります。期間の決め方や仕組みづくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
並行稼働をしないという選択もありますか
あります。移行のために業務を十分に止められ、仕組みが単純なシステムでは、一斉切り替えで足りることがあります。非機能要求グレードも、停止の期間を十分に確保できる場合は並行稼働の必要性は低いとしています。*2 その場合は、切り替え前の移行の予行演習と、元に戻す手順の準備を厚くしておきます。
並行稼働中に新旧の結果が食い違ったらどうしますか
まずは旧システムの結果で業務を続け、食い違いが新旧どちらの誤りから来ているのかを調べます。旧システムの側が誤っていたと分かることもあるため、どちらを正とするかを業務部門と決めてから直します。食い違いの件数と直した内容を記録しておくと、終わりの判断に使えます。
並行稼働の費用はどう考えればよいですか
新旧2つのシステムを動かす分の利用料や保守費、利用部門の入力の手間、結果を突き合わせる作業の工数が重なります。期間が延びるほど増えるため、終わりの基準と合わせて、延長したときの費用も見積もりの段階で確かめておきます。
並行稼働とシステム移行のご相談
並行稼働の期間と終わりの基準の設計から、データ連携や結果の照合の仕組みづくりまで、元請(プライムベンダー)としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考:独立行政法人情報処理推進機構(IPA)「システム再構築を成功に導くユーザガイド 第2版」(https://www.ipa.go.jp/archive/publish/secbooks20180223.html)。出典:表3.8 各テストの実施内容(現新比較テスト)、テストの完了基準、表3.9 リスク対策の例(並行稼働、故障対応体制/マニュアル整備)の記述を参照(2026年10月確認)
- *2 参考:独立行政法人情報処理推進機構(IPA)「非機能要求グレード2018 改訂情報 ~初版との差異~」(付録 非機能要求グレード2018 活用シート)(https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000066170.pdf)。出典:2018年4月25日。D.1.1.3 並行稼働の有無、D.2.1.2 業務展開ステップ数(全業務一斉切り替え)、F.4.2.3 並行稼働スペース(移行時)、F.4.4.3 並行稼働電力(移行時)の記述を参照(2026年10月確認)