業務システムの入れ替え:新旧システムの並行運用が役立つのはどんなときか
新旧の業務システムを並行運用するのはどんなときか。結果の比較、段階的な責任移行、二重書き込みを、正とするデータ、切り戻し、終了条件とあわせて整理します。

置き換え期間中も古い業務システムを利用できる状態にしておくと、結果を比較したり、作業を無理のない段階に分けて移行したりできます。この期間を承認する前に、具体的な目的、どの記録を正とするか、差異を調査する担当者、終了に合意した条件の4点を決めてください。
CEO、業務責任者、財務責任者にとって、この判断は正確な記録を保ち、日々の業務を完了する方法に関わります。「両方を動かす」だけでは未決事項が多く残ります。各システムの役割、従業員が使うシステム、一時的な運用にかかる費用を計画に明記する必要があります。
「両方を動かす」には3つの異なる意味がある
出力結果を比較する。一方のシステムが実際の業務処理を続け、置き換え先のシステムは比較用の結果を計算します。たとえば会計システムを置き換える仮定のケースでは、既存システムが請求書を発行する一方で、定めた同じ期間と入力条件でレポートを比較できます。計算結果を比べる際に、請求書を二重に発行したり、支払い、注文、メールを重複して処理したりしないようにしてください。
どの差異を重視し、誰が調べるのかを合意します。合計が一致しても、個々の記録、丸め規則、処理時期が異なる場合があります。データのコピーに成功しても、訂正や例外処理を含む必要な業務フローを従業員が完了できるかは別の問題です。
責任を段階的に移す。対象を明確にした機能や顧客グループを置き換え先に移し、ほかの業務は旧システムに残します。各段階で、従業員が変更をどこに入力するか、レポートがどの記録を参照するかを明確に指示してください。両方のアプリケーションを利用できる状態にしても、すべての記録について両方が決定権を持つわけではありません。
Microsoft の Strangler Fig ガイダンスでは、機能を段階的に移し、最終的に旧システムを廃止する進め方を説明しています。依存関係と共有データには、移行全体を通じた対応が必要です。事業責任者にとっては、各段階を運用し、確認できるだけ明確に責任を分けられるかが判断のポイントです。
意図的に両方のシステムへ書き込む。ソフトウェアを設計し、変更内容を2か所に記録します。これにより、片方の書き込みが成功し、もう片方が失敗した場合の対応を決める責任が生じます。誰かが差異を検知し、どちらの記録を正とするかを判断して、欠けた処理を完了または修正する必要があります。
Ed Murray による2020年の AWS 移行切り戻しの実務解説は、二重書き込みと段階的な切り戻しに伴う調整を示しています。これは特定時点の技術事例であり、そのまま使える実装計画ではありません。手作業で重複入力したり、同期を約束したりしても、こうした責任は解決しません。
リハーサル済みの一括切り替えと比較する
段階的な移行なら、一度に変更する作業範囲を抑えられます。一方で、2つの運用環境を維持すると、サポート、トレーニング、照合作業、一時的な連携作業が増えます。置き換えの判断には、これらの費用と一時的な接続を撤去する費用も含めてください。
Ian Cartwright、Rob Horn、James Lewis は2022年の記事 Transitional Architecture で、一時的な橋渡しと最終的な撤去について説明しています。その経験は、橋渡しが役立つ目的を果たす一方で、専用の予算と終了計画も必要であることを示しています。
システムが小規模な場合、責任を分割できない場合、適切な連携点がない場合、または緊急の廃止期限により長期間の並行運用が難しい場合は、リハーサル済みの一括切り替えも比較対象になります。Microsoft も、段階的な置き換えが適さない条件を挙げています。こうした条件があっても、一括切り替えが自動的に安全になるわけではありません。準備、運用確認、判断権限を特に明確にする必要があります。
提案する移行のリハーサル結果と、続行または停止するために合意した条件を求めてください。継続しなければならない実際の業務を基準に、2つの選択肢を比較します。どちらの方法にも、あらゆる状況に当てはまる期間や受け入れ基準はありません。
新しい取引が切り戻しの判断を変える
置き換え先に有効な業務記録が入力された後で旧アプリケーションに戻すと、新しい記録が置き換え先に残ることがあります。注文がすでに配送、支払い、通知を発生させている場合、データベースを復元しても、それらの後続処理は取り消せません。
AWS の切り替えガイダンスは、新しいデータがない段階での切り戻しと、新しい取引により元のデータベースが古くなっている場合の切り戻しを区別しています。切り戻しを承認する前に、新しい記録とその後続処理をどう扱うのか、具体策を求めてください。バックアップがあるだけでは、業務を整合性のある形で再開できるとは限りません。
求めるべき意思決定記録
簡潔な記録を作成し、業務を運営する人が次の質問に答えられるようにします。
- 目的と対象範囲:どの業務を比較または移行するのか。両方のシステムを残す目的は何か。
- 正とする記録:各段階で変更をどこに入力するのか。対象となるレポートや処理では、どの記録を正とするのか。
- 照合:差異を誰が調べ、どのように記録し、見解の分かれた結果を誰が解決するのか。
- 受け入れ:次の段階へ進むためにどんな根拠が必要か。何があれば停止するのか。続行または停止を誰が決めるのか。
- 切り戻し:旧システムに戻る場合、新しい取引と完了済みの後続処理をどのように扱うのか。
- 終了:廃止を認める根拠は何か。一時的な連携を誰が撤去し、適用される要件に基づき、どの記録へのアクセスを維持するのか。
並行運用の目的と運用上の責任が費用に見合い、実行可能な終了計画がある場合に承認してください。システムの置き換えをご検討中でしたら、現在のシステム、継続が必要な業務、変更に伴う制約について、当社のレガシーシステムの置き換えサービスからご相談いただけます。