システム切り替え計画で発注者が決めること ｜ 実施・延期・中断を誰がいつ判断するか

システムの切り替えでは、日程を決めるだけでなく「何が確認できたら実施するか」「誰が、いつまでに判断するか」「進められないときに仕事をどう続けるか」を先に決めておきます。当日になってから話し合うと、作業を止めるべきかどうかの判断が遅れやすいためです。

この記事は、新しいシステムへの切り替えを控えた発注者や業務責任者に向けた整理です。サーバーの操作や復旧の手順ではなく、開発会社とそろえておきたい判断の材料を扱います。

受入テストが終わっても、切り替えの判断は別に必要

受入テストは、合意した内容が実際の仕事に沿って動くかの確認です（詳しくは「受入テストで発注者が確認すること」）。切り替え計画では、旧システムの仕事を区切り、新システムで利用を始めてよいかを決める段取りを扱います。

テストが終わっていても、最後に入った注文の扱い、外部サービスとの接続、作業する人の予定が決まっていなければ、当日は進めにくくなります。「機能は確認できた」と「業務を切り替えられる」は分けて考えましょう。

最初に、止められる仕事と止められない仕事を分ける

「週末なら影響が少ない」と決める前に、切り替えの間に動く仕事を書き出します。受注、出荷、請求、店舗の受付などは、社内の休みと関係なく動いていることがあります。取引先や連携先の予定も確かめます。

例えば受発注の仕事なら、旧システムに最後に入力する注文と、切り替え中に届く注文を分けて扱います。入力を止めている間に受けた注文をどこに控え、誰が後で入力・確認するかも決めます。これは架空の業務での整理例で、特定のやり方を勧めるものではありません。

新旧を一時的に並行して使う場合は、どの業務をどちらで行うか、正しい記録をどちらに残すかを決めます。両方に自由に入力すると、件数は合っていても中身が食い違うことがあります。並行して使えるかどうか自体も、システムと業務の条件を開発会社に確かめましょう。移すデータの整え方は「Excelデータ移行の前に整えること」で扱っています。

判断メモには、条件・記録・担当・期限を書く

「問題がなければ始める」だけでは、人によって判断が変わります。何を見て決めるかを、業務の言葉で書いておきましょう。

次の表は、発注者と開発会社の打ち合わせで使うための、この記事独自の整理例です。条件や期限は、実際の業務と技術上の制約に合わせて決めます。

残る課題は件数だけで判断しません。「帳票の見た目が少し違う」と「確定した注文を取り消せない」では、仕事への影響がまったく違います。残したまま始めてよいかは、影響する業務、代わりの手順、対応する担当と時期を見て決めます。

技術担当者は、予定の作業が終わったかを確かめます。発注側は、その状態で仕事を始められるかを確かめます。確認を分担しても、最後に誰が実施を決めるかはあいまいにしないことが大切です。

Microsoftが公開しているDynamics 365向けの切り替え計画の手引き（英語）でも、最終的に実施を判断する人と、判断の基準を決めておくことが挙げられています。特定の製品向けの内容なので、ここでは考え方の参考にとどめています。

記録がそろわないときに、誰がいつまでに決めるかも決めておきます。当日に使う計画の置き場所と更新担当をそろえ、古い計画で判断しないようにします。

架空の受発注業務なら、判断メモは次のようになります。

範囲

受注入力と出荷指示。請求は今回移さない

条件

移した注文を照合し、差が出たものはすべて、原因・業務への影響・対処の担当と時期を確かめたうえで、残したまま始めてよいか、始める前に直すかを決めてある

判断する人

業務責任者。不在のときは事前に決めた代わりの人

期限

延期を決めたときに、現場へ知らせて当面の受付方法に切り替える時間を見込み、開発会社と決めた時刻

満たせないとき

延期を決め、現場には事前に決めた当面の受付方法を伝える

リハーサルでは、作業時間と判断の受け渡しも確かめる

切り替えのリハーサルは、データの移し替えが成功するかだけを見るものではありません。確認まで含めて予定の時間内に終わるか、次の担当者に完了が伝わるか、問題が見つかったときに判断する人へ届くかも確かめます。

発注者は、確認を頼まれる時間帯と、そのとき見る業務を予定に入れておきます。「確認する人が不在で待った」「どの帳票を見ればよいか決まっていなかった」といった手待ちも、本番の計画に影響します。

結果は成功・失敗だけで終わらせず、手順を直した箇所と、まだ分からない点を記録します。本番とデータ量や環境が違う状態で試した場合は、その違いが作業時間や確認結果に影響しないかを技術担当者に確かめましょう。先ほどのMicrosoftの手引きでも、テスト環境でリハーサルを行い、その結果を踏まえて計画を更新することが挙げられています。何回行うか、どこまで試すかは案件ごとに決めます。

「戻す」と決める前に、戻せる範囲を確認する

問題が起きたら旧システムに戻せばよい、と一律には言えません。新システムで入力が始まった後や、取引先への通知・出荷の指示などが外へ出た後は、データや業務の食い違いを整える作業が必要になることがあります。どの処理を取り消せるかは、システムや相手先によって違います。

バックアップがあることと、その時点の仕事を元どおりに再開できることも同じではありません。どの時点まで戻せるか、戻すのに何が必要か、切り替え後に生まれた記録をどう扱うかを、事前に技術担当者と確かめます。

始める前の延期と、始めた後の中断も分けて考えます。延期した場合に旧システムをそのまま使い続けられるか、中断する場合に利用者の操作をどこまで止めるかを確かめます。戻せない処理があるなら、直しながら続ける方法や、一時的な仕事の手順も検討します。どの方法を取るかは、発注側の希望だけでなく、技術的にできるかどうかも合わせて決めます。

当日は、判断した理由と残る課題を記録する

判断時点の進み具合、確認結果、残る課題を並べ、満たした条件と、残して進める課題を記録します。延期・中断を決めた場合も、満たせなかった条件と理由を残します。

実施を決めたら、利用者へ開始を知らせる担当に引き継ぎます。延期・中断の場合も、次にいつ知らせるかを伝え、現場の自己判断で新旧両方を使い始めないようにします。