古い基幹システムを入れ替えたい。業務を止めずに刷新できる？

最初に調べたいのは「止まると誰が困るか」

説明用の例として、受注、在庫、請求を一つの古いシステムで扱う会社を考えます。営業は外出先から受注状況を見たい一方、経理は月末の請求を今までどおり確定したい。両方を同時に作り替える以外にも、照会だけ先に新しくする道があります。まず改善したい仕事と、今は変えられない仕事を分けると、最初の一歩を選べます。

その前提として、停止の影響を時間帯と業務で確かめます。画面を閉じられる休日でも、ECからの注文受信や自動集計は続いているかもしれません。停止中の受注をどこに残すか、出荷の締め切りまでに何を再開するかが分かれば、必要な移行方式を議論できます。「休日に切り替える」だけでは、業務が止まらない根拠にはなりません。

見えている画面の外に、仕事がつながっている

現行システムの画面一覧を渡すだけでは、刷新の範囲を拾い切れません。夜間に作るファイル、経理が加工するCSV、取引先へ送る帳票、年に一度だけの集計も対象です。資料の有無にかかわらず、担当者が普段どう仕事を終えているかをたどります。月次・年次の業務カレンダーを見れば、短い観察期間では見えない処理を補えます。

調査では、ソースやデータを取得できるか、旧環境をいつまで使えるかも確かめます。外部連携の相手が接続変更を受け付ける時期は、自社の開発工数とは別の条件です。分からない仕様を経験則で埋めず、「この帳票の計算が未確認」のように具体的に残してください。何が未確認かを説明できる調査結果が、次の見積もりの土台になります。

段階移行と一括切り替え、どちらが向いている？

AWSが紹介するStrangler figパターンは、既存機能を段階的に置き換える考え方です。先ほどの例なら、照会、受注登録、請求の順に移す案が考えられます。ただし受注登録だけを移しても、旧請求が同じデータを使うなら、新旧をつなぐ処理が必要です。分割する単位は部署名より、データを誰が確定するかで考えます。

反対に、主要機能が同じデータを頻繁に更新し、分離が難しいなら、一括切り替えも比較対象です。段階移行は一回の影響を絞れる反面、共存期間が長くなります。一括切り替えは共存の複雑さを減らせますが、停止時間内に移行と確認を終える準備が必要です。方式の名前ではなく、自社が負担できる作業で選びます。

表が収まらない場合は横にスクロールできます。

参考：Amazon Web Services：Strangler fig pattern

データが移っても、請求できるとは限らない

移行ツールの成功表示は、営業や経理が仕事を再開できる証拠とは別です。AWS DMSには移行元と移行先の行を比較する検証機能がありますが、照合にも処理時間や負荷がかかります。ツールで対応できる対象を確認したうえで、受注残、在庫残、請求金額、取消済み案件など、業務としての結果も比べます。

新旧で集計時点が違えば、正しく動いていても差が出ます。同じ締め時刻のデータで比べ、変換や除外による差は理由を残します。本番前の試行には、抽出と取り込みだけでなく、利用部門が代表的な取引を確かめる時間も含めてください。新画面で一件登録できることと、月末の仕事を終えられることを分けて評価します。

参考：Amazon Web Services：AWS DMS data validation

「何かあれば戻す」は、取引を始める前に決める

新システムで注文を受け、取引先へ発注した後に、切り替え前のバックアップへ戻したらどうなるでしょうか。新しい注文は消えても、相手側の発注は残ります。これは説明用の例ですが、切り戻しがデータの復元だけでは済まない理由を示しています。新しい取引を始める前なら戻しやすく、開始後は外部の結果まで確かめる必要があります。

当日は、原因不明の金額差が残る、重要な帳票が出ない、連携が追いつかないときに延期する判断者を置きます。利用開始後に問題が出た場合は、戻すより新側で直す方が適切なこともあります。どちらを選ぶか、そのために何を保存しておくかを事前に話し合います。判断時刻と確認項目を具体化すると、現場の焦りだけで進めずに済みます。

最初の発注は、全体開発より現状調査が合うこともある

仕様やデータの状態が分からない段階では、総額の安さより、調査で何が分かるかを比べます。依存関係、移せるデータ、未確認の計算、切り替え候補が揃えば、試行と本移行を見積もりやすくなります。調査の次に自動的に全開発へ進む前提にせず、結果を見て範囲や方式を判断できる区切りを設けるのが現実的です。

費用には新機能の開発だけでなく、新旧の接続、データ補正、リハーサル、旧環境の維持と停止作業が含まれます。依頼先には「最初にどの業務を移すか」「共存をいつ終えるか」を説明してもらいましょう。ダンドリへの相談でも、既存資料、止められない仕事、利用終了の期限を入口に範囲を整理できます。大規模な全面刷新の価格や期間を、一部の開発料金から推定することはできません。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □停止すると困る業務と、その締め切りを挙げる。確認状況・メモ：
• □夜間・月次・年次の処理と手作業の連携を探す。確認状況・メモ：
• □旧環境の資料・データ・ソースの取得可否を確かめる。確認状況・メモ：
• □段階ごとに取引を更新するシステムを一つにする。確認状況・メモ：
• □同じ時点の残数・金額を利用部門と照合する。確認状況・メモ：
• □利用開始前と開始後の復旧方法を分ける。確認状況・メモ：
• □共存期間の費用と旧環境を停止する条件を決める。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Strangler fig patternAmazon Web Services
• AWS DMS data validationAmazon Web Services