Access移行の並行稼働｜新旧システムを同時に動かす期間の設計

結論：並行稼働は省くと後が怖い

新旧システムを同時に動かす「並行稼働」は、当社の案件では現場の負担が大きくなりやすい期間です。同じ業務を2つのシステムで処理しなければならないため、現場からは「余計な手間が増えた」と不満が出ることもあります。

それでも当社が並行稼働を原則として外さないのは、新システムの問題を発見できる安全網になるからです。本稼働後に「結果が合わない」「この業務が動かない」となった場合、稼働可能な旧環境も、復元可能なバックアップと切り戻し手順もなければ、迅速な切り戻しが難しく、データの修復作業が大変になります。

並行稼働で確認することは「新システムで業務が回るか」だけではありません。データの整合性、帳票の出力結果、例外処理の動作まで含め、本番相当のデータで検証することが目的です。

並行稼働の期間の決め方

並行稼働の期間は、移行する業務の複雑さと処理サイクルに合わせて決めます。当社の実務では、2〜4週間を目安にしているケースが多いです（当社実務基準）。

月次処理がある業務（月次集計、月末締め、請求処理など）は、原則として異なる2か月分の締め処理を確認できる期間を確保します。開始日を締め日に合わせる前提で、当社ではおおむね6〜8週間を目安にしています（開始日が締め日の直後だと6週間では締め日を1回しか迎えない場合があるため、開始日の調整が前提です）。週次処理を含む業務は3〜4週間、日次処理が中心なら2〜3週間が目安です（いずれも当社実務基準。詳細は次の表を参照）。

期間を短くしたい場合は、対象業務を絞るのが現実的です。「全業務を4週間並行稼働させる」より「リスクの高い3業務だけ2か月並行稼働させる」ほうが、現場の負担と検証の密度のバランスが取れます。

二重入力の負担とその軽減

新旧双方を手作業で更新する方式では、旧Accessと新システムの両方にデータを入力する「二重入力」が発生します（自動同期やバッチ連携で片側を省く設計もありますが、その場合は後述のとおり連携処理自体の検証が必要になります）。当社の経験では、手作業の二重入力は現場にとって特に負担の大きい部分です。

軽減策として当社がよく提案するのは、新システムへの入力を「本番」と位置づけ、旧Accessへの入力は後から確認用にまとめて行う方法です。逐一2画面を操作するのではなく、新システムで入力した後、旧Accessには翌朝まとめて転記するだけにする運用です。完全な同期を目指すと現場が疲弊するため、「差異を検出するには十分な粒度があるか」という視点で運用の省略を判断します。

自動連携（新システムから旧Accessへデータを書き出すバッチ処理など）を組む方法もありますが、その連携処理自体が正しいかどうかを検証する工数が増えます。並行稼働の目的はあくまで「業務が正しく動くか確認すること」なので、連携の複雑さと検証コストのバランスを見て判断します。

データ同期の考え方

並行稼働中のデータ同期方法は、どちらのシステムを「正」とするかによって設計が変わります。当社の実務では「新システムを正」とする方針を基本にしています。

当社では移行完了を後押しするため、並行稼働の開始時から新システムを正とする方針を基本にしています。旧Accessを正に置く設計も可能ですが、その場合は新システムへ切り替える時期と条件をあらかじめ決めておかないと、現場が旧システムに留まりやすくなります。

このとき旧Accessの役割は、時期によって切り替わる点を整理しておくと混乱しません。並行稼働中は、二重入力によって旧Accessも更新し続ける「検証用のシャドー環境」であり、同時に、新システムに重大な問題が出た場合の「緊急の切り戻し先」でもあります。そして本稼働へ切り替えた後は、更新を止めて「履歴参照用のアーカイブ（読取専用）」に位置づけを移します。同じ旧Accessでも、更新できる期間と読取専用にする期間を明確に分けるのが、当社の整理の仕方です。

並行稼働中に発生する差異は、必ず記録して原因を特定します。差異が「操作ミスによるもの」か「システムの処理ロジックの違いによるもの」かで、対応の優先度が変わります。ロジックの違いによる差異が出た場合は、どちらの動作が業務的に正しいかを業務担当者に確認して判断します。

旧システムを止めるタイミングと撤退基準

並行稼働を終えて旧Accessを停止するタイミングは、「後述の技術・運用上のGO/NO-GO基準を満たし、最終的に業務担当者が承認した時点」です。基準を満たしていても、現場の担当者が納得していなければ本稼働に踏み切るべきではありませんし、逆に担当者の感覚だけで基準未達のまま切り替えるのも避けます。

当社が使う撤退基準（本稼働切り替えのGO/NO-GO判定）は以下の通りです（当社実務基準）。

• 並行稼働期間中の未解消バグがゼロになっていること
• 直近5営業日の差異件数がゼロ、または差異の原因がすべて操作ミスのみであること
• 業務担当者が「通常業務を新システムだけで対応できる」と判断していること
• 月次処理がある場合は、原則として異なる2か月分の月次処理を新システムで完遂していること（並行稼働の開始日を締め日に合わせて確保する。日程上1か月分しか通せない場合は、例外承認のうえ代替テストで補うこと）
• 切り戻し手順と切り戻し判断の責任者が明確に決まっていること

切り替え後の旧Accessは、段階を分けて扱うのが安全です。当社では、まず切り替えと同時に更新を停止して「見られるが書き込めない」読取専用にし、少なくとも1〜3か月はこの状態で保管して過去データの照合や例外対応に備えます。その後の「通常参照の終了」「アプリ本体の撤去」「保存義務のあるデータの最終削除」は、後述のとおりそれぞれ別の時期・条件で判断します。

移行スケジュール全体の立て方についてはAccess移行のスケジュールの立て方で詳しく解説しています。移行後にAccessを残すかどうかの判断を含め、計画段階から想定しておくと良いでしょう。

並行稼働をしない一括切替との使い分け

並行稼働が必ず正解というわけでもありません。業務の性質によっては、一括切替（一定日を境に旧システムを完全停止して新システムに切り替える）のほうが適切な場合があります。

一括切替が向くのは、次の条件がそろっている場合です。

• 業務が複数システムにまたがらず、データの整合性確認が比較的容易
• 段階移行などで新システムの一部が先行稼働しており、現場が操作に慣れている
• テスト工程が十分で、業務担当者が事前に動作確認を終えている
• 切り戻しのコストが低い（データ量が少ない、処理が単純など）

当社では、一括切替は本番稼働後に新旧の結果を継続して突き合わせる期間がないため、問題の発見が遅れる可能性があると考えています。切り戻すには、事前のバックアップ、入力済みデータを旧環境へ戻す手順、切り戻すかどうかの判断基準をあらかじめ用意しておく必要があります。これらの備えがないまま切り替えると、問題発覚時の業務停止リスクが大きくなる点を、業務担当者が把握した上で判断することが前提になります。

段階的に移行を進める設計パターンについては全面移行しない選択肢｜Accessと新システムのハイブリッド段階移行で整理しています。業務単位で新旧を切り分ける方法も参照してください。

移行プロジェクト全体の7ステップはAccess移行プロジェクトの進め方で解説しています。並行稼働はステップ6に位置し、その前後の工程と連動して設計する必要があります。

どの移行方式が自社のAccessに向くか判断がつかない場合は、まず現状のシステム規模と業務の性質を確認することから始めます。無料の解析可否チェックで、Accessファイルの構造と移行の難易度を事前に把握できます。

よくある質問

Q. 並行稼働中に新旧のデータが合わなかった場合、どう対処すればいいですか。

まず差異の原因を切り分けます。操作ミスであれば手順の見直しで対応、システム側の処理ロジックの問題であれば修正して再テストします。差異を「無視してよい」と判断するには業務担当者の確認が必要です。差異を記録せず放置するのが最もリスクが高い対処です。

Q. 並行稼働の期間を短縮するために何ができますか。

当社では、テスト工程を充実させることが有効な短縮策の一つと考えています。本番稼働前のテストで業務担当者が実際のデータを使って動作確認を終えていれば、並行稼働の期間を短縮しやすくなります。逆に「テストはシステム会社に任せた」という状態で並行稼働に入ると、現場が初めて触る業務が続き、期間が想定より延びます。

Q. 旧Accessを完全に消すのはいつがいいですか。

本稼働後、最初の月次処理や年次処理が問題なく完了してからが目安です。前述のとおり、切替直後はまず読取専用にし、その後の扱いを段階で分けます。当社では、旧Accessアプリ本体の撤去（起動できる状態を終える）は、切替後おおむね半年〜1年を見直し時期の目安としています。ただしアプリを撤去しても、保存義務のある業務データはデータ単体で別途保管が必要です。会計・監査対応でデータ参照が必要になるケースもあるため、参照終了・アプリ撤去・データ最終削除のそれぞれの時期と条件は、部門の要件を確認してから決めてください（当社実務基準）。

Q. 並行稼働と段階移行は何が違いますか。

並行稼働は「同じ業務を新旧2システムで処理し、結果を比較する」期間のことです。段階移行は「業務や機能を分けて、順番に移行する」進め方の方針です。当社の案件では、段階移行の各段階に、業務ごとの並行稼働期間を設けることがあります。混同しやすい言葉ですが、並行稼働は検証の手法、段階移行はプロジェクトの進め方の設計です。