新旧システムを並行して使うとき、注文はどちらへ記録する？

並行する仕事と、正本・実出力を分ける

並行運用は、移行の途中で新旧のシステムを同じ期間に使うことです。ただし、同じ仕事を両方で本番処理すること、旧側だけで仕事を続け新側では照合すること、一部の業務や拠点から順に切り替えることは、条件が違います。「並行」という名前だけで登録方法を決めないでください。

ここでいう正本は、その注文の登録・訂正を判断するときに基準とする記録です。新しいシステムだから常に正しい、最後に更新された画面だから正しい、と自動的に決める意味ではありません。誰が何の依頼を根拠に直し、ほかの担当がどこを読むかを業務責任者とそろえます。

照合は、対応する注文の内容や処理状態を、決めた条件で見比べることです。実出力は、顧客への請求・通知や在庫の更新など、画面の外の仕事を動かすことです。表示が合っていることと、意図した側だけが実出力したことは、別の記録で確かめます。

この一件を、本当の注文処理と照合用の表示へどう分ける予定でしょうか。

IPAの2017年の要件定義資料では、移行計画で新旧の並行稼働の有無、中止判断の基準・方法、体制やリハーサルなどを確認する観点を挙げています。一律の期間を指定したり、すべての会社へ同じ方式を求めたりする根拠として使わず、自社で決める条件を見つけるために参照します。

新規注文をどちらへ登録し、何を動かすか決める

最初の場面は、新規注文を受けるときです。元の注文依頼を保ち、担当がどこへ登録するか、照合用の記録をどう対応させるかを決めます。入力する画面の数だけで、二重処理を防げるかは判断できません。

同じ架空注文を、どちらへ登録し、どちらから請求・通知する予定でしょうか。

この節の解説図を原寸で見る

実業務の記録と、照合のための写しを区別する

全体の境界は、旧システムを「新規注文の登録・訂正を実業務の正本として続ける案」、新システムを「同じ架空注文を照合用に表示する案。実出力を行わせるか未承認。」とする案です。新側の画面が使えることを理由に、営業が両方へ同じ注文を本番登録する運用へ広げません。

今回の新規登録は、旧側へ一度登録する案です。新側では照合用の写しを見る案です。旧のどの注文が新のどの表示へ対応するか、参照・転記・連携のどの方法を使うか、どの時点まで反映された状態を見るかを、IT担当と開発会社へ聞きます。対応や反映方法は、この例ではまだ決まっていません。

請求・通知・在庫は、別々の経路で聞く

この場面の実出力は「受注通知と請求は旧側だけの予定案」です。請求については旧側からのみ出す予定案。実設定と停止確認は未実施。メールについても旧側からのみ送る予定案。実設定と送信確認は未実施。在庫の更新は、どちらが実更新するか未決定です。予定を書いたことを、送信や実更新を制御できた結果へ変えないでください。

開発会社には、画面で表示するだけの処理と、請求発行・メール送信・在庫更新へ進む処理がどこで分かれるかを説明してもらいます。営業と業務責任者には、実際に動かしてよい範囲と、それを確認する人を聞きます。新側を照合用にするなら、実出力を行わせない条件を、誰が何の設定・試行記録で示すかも必要です。

実出力を分ける条件を確認できない場合は、未承認の新側で実注文を処理する前提へ進まず、業務責任者と開発会社へ実施範囲を返します。日々の受付を続ける必要と、新側で試してよい条件を分け、現に承認されている仕事の継続方法を関係者と確かめます。

希望納期の訂正を、差分の返却と再照合へつなぐ

次の場面は、同じ注文の希望納期を訂正するときです。最初に移した注文が同じでも、その後の変更が片方だけに残れば、照合する対象はずれます。正本の変更から、差を返した後の確認までを、一つの流れとして追います。

希望納期を訂正する依頼が来たら、どの記録を直し、違いを誰へ返すのでしょうか。

この節の解説図を原寸で見る

1. 訂正の依頼と、正本の注文を結ぶ。営業担当が旧側で訂正する案です。営業は元の依頼、対象の注文、訂正する内容を確認します。希望した日と、会社が受けられることを確認して約束した日を混ぜず、どの意味の欄を変えるかを確かめます。
2. 新側の同じ注文を、同じ時点の条件で見る。訂正後の表示を照合する案です。取り込む時点や反映待ちがあるなら、その条件と確認時点を残します。古い写しと最新の正本を比べた違いを、すぐに入力誤りと決めません。
3. 違いを担当へ返す。社内IT担当が差分を受け、登録担当へ戻す案です。IT担当は、元の依頼、旧新の対応、対象の版・時点、違う箇所、業務への影響を添えます。登録の訂正が必要か、反映・表示の調査が必要かが分からなければ、営業と開発会社へ確認する仕事を分けます。
4. 返答後に再照合し、後の処理も見る。直したという連絡だけで終えず、同じ注文を同じ条件で見直します。訂正後の通知・請求・在庫へ影響するなら、その実結果も担当から受け取ります。前の記録を消さず、何を変えた後の結果かが追えるようにします。

この架空例では、訂正・照合・差分返却・再照合・訂正後の実出力は、いずれも実結果が未確認です。図や手順は今後の確認の組み立てで、修正前後の成功例ではありません。

移した時点の件数・金額・親子関係を詳しく照合する方法は、データ移行で件数・金額・関連データを確かめる記事へつなぎます。本稿では、並行期間中に新しく発生した注文や訂正を、誰がどちらへ反映して確認するかを扱います。営業の受注表と現場の作業表の同じ納期欄を参照する方法は、二重入力を減らす欄と担当の決め方の範囲です。

誤登録や二重通知が疑われたときの戻り先を決める

違いが出たときの担当と、判断に必要な記録を先に決めます。新旧の値を同じにしたことだけで、外へ出た通知や在庫の状態まで元に戻ったとは扱いません。次は、今後そのような場合が起きたときの確認方法です。今回の架空注文で発生した事故ではありません。

二重の通知や新側だけの訂正が疑われるとき、何を残して誰へ相談するのでしょうか。

この節の解説図を原寸で見る

旧側へ誤って登録した・同じ注文らしい記録が複数ある

元の依頼と登録の記録を残し、同じ注文の重複か、別の依頼かを営業へ確認します。どちらを正本としてどう訂正するか、どの実出力が既に進んだかを分けます。担当が決めないまま片方を削除し、確認に必要な経緯まで失う進め方は避けます。

同じ通知が二つ届いた・二つの請求が疑われる

画面にある記録と、実際に外へ出た記録を分けます。何がどちらの経路からいつ出たか、顧客へ何が届いたかを、権限のある担当へ確認します。IT担当だけで取消しや再送を決めず、業務責任者と開発会社へ影響と調査対象を返します。処理を止める必要がある場合も、止める範囲・権限・受付を続ける方法を確認します。

新側だけへ変更が先に入っていた

新側に記録があることだけを理由に、旧側の正本を上書きしません。元の変更依頼と、誰が何の権限で変更したかを確かめます。業務上正しい変更なら、責任者が正本と反映順を判断します。表示比較だけを予定していた新側で実処理まで動いた疑いがあれば、登録の差と実出力の影響を別々に調べます。

差異が残る・対応する注文や反映時点が分からない

同じ対象を比べられない間は、合計一致や画面の見た目を根拠に差分ゼロへしません。どの対応表、対象版、反映時点が不足するかをIT担当と開発会社へ返します。調査の結果、今回の方式では必要な条件を満たせないなら、並行する範囲や切替方式、担当の体制を見直します。

AWSの切替ガイダンスも、新しい取引やデータが生じた後の戻しを、変更がない場合の戻しと分けています。両側への書込みにはアプリケーション側の対応が必要となる文脈であり、手で両方へ入力すれば同じ対策になるという説明ではありません。クラウド移行の技術的な例を、この架空の会社で実装・検証済みの方式へ変えないでください。

実記録を集めて、並行期間の終了を判断する

最後の場面は、並行期間を終える判断をするときです。単に予定日が来たことや、同じ件数を表示できたことだけで終えません。新規登録と訂正、実出力、差を返した後の再確認を、対象と版が分かる実記録で確かめます。

並行期間を終えてよいか、誰が何の実結果を見て判断するのでしょうか。

この節の解説図を原寸で見る

この例の確認は、新規・訂正・請求・通知・在庫の各経路と差分返却を業務責任者が確認する案です。終了は業務責任者の承認を要する案です。営業の受注担当が登録を終えたことと、会社として切り替えてよいと判断したことを分けます。社内の誰がその判断権限を持つかも、実施前に確認します。

1. 登録と訂正の結果を集める。正本へ入れた内容、新側の対応する表示、どの変更まで取り込まれているかを、元の依頼と照らします。初回の写しと、その後の変更を分けます。
2. 請求・メール・在庫の実結果を集める。動かす予定だった側と、実際に動いた経路を確かめます。画面上のプレビューを発行・送信の結果に代えず、出していないことを確認すべき側も、担当が何を根拠に確認したかを残します。
3. 差分の返却と再照合を追う。誰へ何を返し、どの版でどう直した後に、誰がどこまで見直したかを結びます。未解決の差や未確認の処理は、影響と次の担当を付けて責任者へ渡します。
4. 終了する範囲と、続ける確認を判断する。業務責任者は結果、未確認、業務への影響、戻す方法を読み、開発会社と必要な担当へ確認します。重要な条件が不足するなら終了を保留し、何を誰が返せば次の判断ができるかを明らかにします。

今回の架空例では、承認、照合結果、残る差分、実切替、実際に戻した結果は未確認です。差分の記録が未取得であることを、差分がなかったという値へ置き換えません。実際に終了を判断できた事例ではありません。

IPAの2010年の調査報告書のカットオーバー時期のモデルは、順次展開の際、新旧で管理する情報と業務規則を確認し、整合性のために特別な管理が必要なら、移行・業務の手順へ反映する考え方を示しています。古い意思決定モデルの一つとして参照し、この例の役割分担や実装の成功を証明する資料とは扱いません。

切替当日の続行・保留・戻す判断と時間の組立ては、システム刷新の移行計画の記事で扱います。利用者へ停止・確認待ち・再開をどう案内するかは、切替時の利用者への連絡の記事へつなぎます。ここで整理した記録先と実施条件を、担当への案内と矛盾させないでください。

まとめと、今日の最初の一歩

新旧システムを同時に使う期間は、どちらも自由に本番処理してよい期間ではありません。同じ注文の正本、登録・訂正の担当、照合の時点、請求・通知・在庫の実経路をそろえます。旧側を正本、新側を照合用にする案でも、実出力や権限を確認済みにはできません。

違いを見つけた後は、元の依頼と対象の記録を担当へ返し、直した後の再照合まで追います。結果と未確認を分け、終了の条件がそろわなければ業務責任者へ戻してください。

今日、一件の注文を開いて、何を誰へ聞くのでしょうか。