稼働判定と本番切替｜基幹システムのGo/No-Go基準と切り戻し計画の作り方

稼働判定は、新しい基幹システムで本番業務を始めてよいかを、事前に決めたGo/No-Go基準に照らして経営が決める場です。判定の質は、業務・品質・データ・体制・取引先・切り戻しの6つの観点で基準を数字にしておくことと、「ここを過ぎたら戻れない」時刻を含む切り戻し計画を判定の前に用意しておくことで決まります。この記事では、稼働判定と本番切替の進め方、Go/No-Go基準表、切替当日のタイムライン、切り戻し計画の作り方を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

稼働判定とは：本番切替の前の「最後の関門」

稼働判定（Go/No-Go判定）は、新システムへの本番切替を予定どおり行うか、延期するかを決める意思決定です。受入テスト、データ移行リハーサル、操作研修、運用体制の準備がそろったかを確認し、プロジェクト責任者や経営が判断します。

基幹システムの切替は、受注・出荷・請求・支払がすべて新しい仕組みに移るため、失敗すると社外に影響が出ます。公表されている例として、江崎グリコは2024年4月3日に基幹システムを全面移行した際にシステム障害が発生し、全国の物流センターで出荷業務に遅れが出たと開示しています。開示資料によれば、遅配・欠配の解消に向けて4月14日からチルド食品の出荷を一時停止し、4月18日に一部を再開したものの、物流センターでの出荷データの不整合や、想定を超える受注品目数への処理遅れが生じ、翌19日から再び出荷を停止しました。5月8日には、チルド食品の出荷停止の影響を織り込み、2024年12月期の連結売上高予想を150億円、営業利益予想を50億円引き下げています。その後、6月11日の開示で、6月25日以降に一部商品から順次出荷を再開するとしました。

この事例の原因や判定の経緯は開示資料からはわかりません。ただ、データの整合性と、実際の業務量に耐える処理能力が稼働直後に問題になりうることは、規模を問わず参考になります。中小企業の基幹システムでも、稼働判定はこの2点を含めて、確認できる証拠で判断する場にする必要があります。

稼働判定は、プロジェクトの最後に突然行うものではありません。導入プロジェクト全体の流れは基幹システム導入の進め方、受入テストの合否基準の決め方はユーザー受入テスト（UAT）の進め方で解説しています。

切替日の決め方：判定より先に決めること

稼働判定の基準と同じくらい、切替日の選び方が結果を左右します。基幹システムの切替日は、次の条件を重ねて決めます。

• 締め日との関係：月の途中で切り替えると、その月の売上・仕入が新旧システムに分かれ、請求や月次の集計で両方を合算する手間が出ます。多くの会社が月初や期首を選ぶのはこのためです。
• 繁忙期を避ける：年末、年度末、季節商品の出荷期など、件数が多い時期は避けます。問題が出たときに手作業で補う余力がないためです。
• 予備日を取れる：週末や連休の前に切り替えると、問題の修正や切り戻しに使える時間が取れます。
• 社外の予定：取引先のEDI切替、銀行の振込データの形式変更、会計事務所の決算作業と重ならないかを確認します。

切替日が決まったら、そこから逆算して予備判定・最終判定の日程を押さえます。判定の日程が決まっていないと、準備の遅れがそのまま切替日の直前まで見えません。

IPAの「非機能要求グレード」でも、6つの大項目の1つに「移行性」が置かれています。移行の時期や方式は、要件定義の段階で非機能要件として決めておく項目です。

Go/No-Go基準の作り方：6つの観点と基準表

Go/No-Go基準は、「準備はできたか」という問いを、誰が見ても同じ結論になる条件に分解したものです。中小企業の基幹システムなら、次の6つの観点で足ります。

※説明用の例です。基準は業務の重要度と取引先への影響を見て、プロジェクトごとに決めます。

観点2の「ピーク時の件数」は、平均ではなく過去1年でいちばん件数が多かった日を基準にします。たとえば、通常は1日300件の受注明細が、月末や連休明けには900件になる会社なら、900件を流して受注締めから出荷指示までが何分で終わるかを確かめます。余裕を見て、その件数にいくらか上乗せした量で試しておくと安心です。

基準を作るときに押さえたいのは、次の3点です。

• 証拠を指定する：「確認済み」とだけ書くと、口頭の報告で通ってしまいます。どの報告書・どの照合表で確認するかまで決めます。
• 条件付きGoの扱いを決める：「重要度Bが2件残るが回避策あり」のような状態で進めるかどうか、誰がその判断をできるかを先に決めておきます。
• 基準を判定の1か月以上前に確定する：判定の直前に基準を作ると、現状に合わせて基準を緩めたくなります。

IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド 第2版」も、テストの完了基準は業務継続性を担保できる要件を定量的に定め、実施前に各ステークホルダと合意しておく必要があるとしています。同ガイドの事例では、「日次の業務処理が正常に実行されること」という目標を、特定の1日分のサイクルテストで「実行エラー0件、またはエラー原因が特定され解消の見込みがあること」という完了基準に置き換え、それらがすべて満たされた状態をカットオーバー（本番切替）の基準にしています。稼働判定の基準も、このように「目標→数えられる条件」に分解して作ります。

判定会議の進め方：3段階で判定する

稼働判定は1回の会議で決めるより、時期をずらして3段階で行うほうが安全です。早い段階で問題を見つければ、対策の時間が取れます。

1. 予備判定（切替の2〜3週間前）
   6つの観点の進み具合を確認し、残っている課題と期限を洗い出します。この時点で基準を満たす見込みが立たない観点があれば、延期の検討を始めます。延期するなら、取引先や社内への連絡が間に合ううちに決めます。
2. 最終判定（切替の数日前）
   最終リハーサルとUATの結果をもとに、Go・条件付きGo・No-Goを決めます。出席者は、プロジェクト責任者、各業務の責任者、情シス、ベンダーの責任者です。決定は議事録に残し、条件付きGoの場合は条件と期限を明記します。
3. 切替後判定（切替当日〜翌営業日の朝）
   本番データの移行結果と、稼働直後の確認作業の結果をもとに、業務を新システムで開始するか、切り戻すかを決めます。判断期限を過ぎたら、新システムで進めることを前提に対応します。

判定会議では、各観点の責任者が「基準を満たしている／満たしていない」を証拠とあわせて報告し、責任者が決めます。全員の合意を待つ形にすると、誰も反対しないまま問題が持ち越されます。会議体の役割分担はステアリングコミッティとはも参考にしてください。

判定会議の資料：判定シートの記入例

最終判定の会議では、6つの観点を1枚にまとめた判定シートを使います。説明に時間をかけず、判断に必要な情報だけを並べるためです。

※説明用の例です。判定は○（満たす）、△（条件付きで満たす）、×（満たさない）の3段階としています。

△がついた観点は、「誰が、いつまでに、何をするか」を残課題の欄に書き、その条件で進めることを判定者が承認します。×が1つでもあればNo-Go、とあらかじめ決めておくと、会議が長引きません。

本番切替の方式：一斉切替・段階切替・並行稼働の選び方

本番切替の方式は、稼働判定より前、移行計画の段階で決めておくものです。中小企業でよく使われる3つの方式を比べます。

IPAの同ガイドは、リリース後のリスク対策として並行稼働、故障対応体制の整備、段階的リリースを挙げています。並行稼働については、利用部門の負担が増えるため、どれほど許容できるかの確認が必要としています。段階的リリースについては、先行拠点で問題なく稼働することを確かめてから残りの拠点に展開することで、トラブルの影響範囲を限定できるとしています。

中小企業では、全面的な並行稼働は現場の負担が大きく、長くは続けられません。現実的なのは、一斉切替を基本にしつつ、請求や給与など金額の誤りが許されない処理だけを1〜2回分並行して照合するやり方です。並行する範囲を限定することで、現場の二重入力を最小限にできます。

※方式の向き・不向きは説明用の目安です。業務のつながり方や拠点数によって変わります。

方式に迷ったときは、次の3つの問いに順に答えると絞り込めます。

1. 業務を分けて切り替えられるか：受注・在庫・請求が1つのデータでつながっているなら、業務ごとの段階切替は難しく、一斉切替が基本になります。
2. 拠点ごとに先行させる意味があるか：拠点の業務がほぼ同じで、拠点が3か所以上あるなら、小さい拠点から先行する段階切替が選択肢になります。
3. 新旧の結果を本番で比べる必要がある処理はどれか：その処理だけを並行稼働の対象にし、期間は1〜2回分の締めに限ります。

切替当日のタイムライン例

本番切替は、業務の影響が小さい週末や連休に行うことが多くなります。切替当日のタイムラインで大事なのは、作業の順番よりもどの時刻に、誰が、何を見て、進むか止まるかを決めるかです。次の表は、従業員120名・1拠点の卸売業が、金曜の業務終了後に切り替え、月曜朝から新システムで業務を始める場合の判断ポイントの例です。データの抽出・変換・照合の細かな時間割は基幹システムのデータ移行で扱っているため、ここでは判断に関わる行に絞っています。

※説明用の例です。データ量や作業の分担によって、所要時間や判断の時刻は大きく変わります。

この例では、切替後判定を土曜の夕方に置き、日曜をまるごと予備日にしています。判定を日曜にずらすと、切り戻しに使える時間が短くなり、月曜朝の業務開始に間に合わない場合が出てきます。判定の時刻は、切り戻しにかかる時間（リハーサルの実績）を、業務開始の時刻から逆算して決めます。たとえば切り戻しに4時間かかるなら、月曜8時から4時間に余裕を足した時刻より前に、最後の判断を終える必要があります。

タイムラインを作るときは、各作業の所要時間をリハーサルで測った実績から置きます。机上の見積もりで作ると、データ変換が想定より長引き、照合と判断の時間が削られます。

当日の連絡体制も、タイムラインと一緒に決めます。作業の完了報告を誰に、どの手段（電話、チャット、共有の進捗表）で送るかを決め、予定より30分以上遅れたら責任者に報告する、といった基準を置きます。深夜や休日の作業では、報告の遅れがそのまま判断の遅れになります。照合作業を担う経理や営業事務の担当者には、土曜の何時に出社すればよいかを前もって伝え、作業の待ち時間を減らします。

切り戻し計画の作り方

切り戻しは、新システムでの業務開始をやめ、現行システムに戻すことです。「切り戻しはしない前提で頑張る」という計画は、計画ではありません。戻る手段があるから、冷静にGo・No-Goを判断できます。

切り戻し計画には、少なくとも次の5点を書きます。

• 切り戻しの条件：どの状態になったら戻すか。例「移行後の売掛残が現行と一致せず、日曜12時までに原因が特定できない」
• 判断者と連絡方法：休日の夜でも判断できる人と、連絡がつかない場合の代理
• ポイント・オブ・ノーリターン：これを過ぎたら戻れない、または戻るほうが損失が大きくなる時刻。新システムで受注や出荷の入力を始めると、その分を現行に戻す作業が発生するため、業務開始の時刻が実質の期限になることが多くなります
• 戻す手順と所要時間：現行システムを再開する手順、取得しておくバックアップ、再開までの時間
• 関係者への連絡：社内・取引先・ベンダーへ、誰がどの文面で知らせるか

切り戻すときのデータの扱い

切り戻しで見落とされやすいのが、新システムで入力してしまったデータの扱いです。ポイント・オブ・ノーリターンを過ぎてから重大な問題が見つかり、それでも戻すと決めた場合を考えます。月曜の朝から数時間でも新システムで受注や出荷を登録していれば、その分は現行システムに入れ直す必要があります。件数が多いほど戻る作業は重くなり、戻すこと自体が新たな誤りを生みます。

このため、稼働初日の午前中は、受注書や出荷指示の控えを紙やExcelでも残しておく、という手当てが有効です。戻す場合に再入力の元になり、戻さない場合でも新システムの入力内容を照合する材料になります。あわせて、切り戻した場合に取引先へ出した納品書や請求書の番号がどうなるか（新旧で番号が重複しないか）も、事前に確認しておきます。

切り戻しの手順は、移行リハーサルの中で1回は実際に試しておきます。現行システムのライセンスや保守契約の終了日が切替日の直後に設定されていると、戻る先がなくなります。現行システムの契約は、稼働後の最初の月次締めが終わるまで残すのが安全です。IPAのガイドも、並行稼働を選ぶ場合の注意点として、現行システムのEOL・EOS（販売や保守の終了）の期限内で実施できるかの確認を挙げています。現行システムの保守期限と、切り戻しや並行稼働に使う期間が重なっていないかを、切替日を決める段階で確かめます。

稼働後の初期安定化：最初の締めまでが本番

本番切替が終わっても、基幹システムの稼働はまだ確定していません。日々の受注・出荷は初日から動きますが、請求締め・月次締め・支払といった周期の処理は、稼働から数週間後に初めて本番を迎えます。このため、稼働後しばらくは「初期安定化（ハイパーケア）」の期間として、通常より厚い体制を置きます。

初期安定化の期間に毎日確認したいのは、次の指標です。

• 受注・出荷・入荷の件数が、現行システムでの同じ曜日の件数と大きくずれていないか
• 出荷の遅れや、受注残の積み上がりが起きていないか
• 問い合わせの件数と、未解決の件数が減っているか
• 夜間処理や連携処理が、予定の時刻までに終わっているか

体制としては、次の3つを稼働前に決めておきます。

• 問い合わせ窓口：現場からの質問を1か所で受け、「操作の質問」「不具合」「要望」に分けて記録する担当者
• ベンダーの待機：稼働後1〜2週間は、不具合の調査と修正にすぐ動ける要員。月次締めの日にも待機してもらう
• 日次の短い会議：毎日決まった時刻に15分程度、件数と未解決の課題を確認し、その日のうちに対応を決める

前述の公表事例で、一部再開後に「想定を超える受注品目数」への処理遅れが開示されたことは、稼働直後の業務量の確認がいかに大事かを示しています。テストやリハーサルでは、平均的な日ではなく月末や連休明けなど、件数が多い日の量で処理時間を確かめておきます。

初期安定化の終わりは、「最初の請求締めと月次締めが終わり、数字が照合できた時点」と決めておくのが目安です。ここで改めて振り返りの会議を開き、残った課題と稼働後の改善要望の扱いを決めます。リプレイス全体の考え方は基幹システムのリプレイスで解説しています。

稼働判定の前に確認する10のチェックポイント

• Go/No-Go基準が6つの観点で数字になり、判定の1か月以上前に合意されている
• 各基準に、確認する証拠（報告書・照合表）が指定されている
• 条件付きGoを認める条件と、その判断をできる人が決まっている
• 最終の移行リハーサルで、件数と金額が現行と一致している
• 処理時間を、月末など件数の多い日の量で確認している
• 取引先への帳票変更・EDI変更の通知が済んでいる
• 切替当日のタイムラインが、リハーサルで測った時間で作られている
• 切り戻しの条件・判断者・ポイント・オブ・ノーリターンが文書になっている
• 切り戻し手順をリハーサルで1回は試している
• 現行システムの契約が、最初の月次締めが終わるまで残っている

よくある質問

まとめ

稼働判定は、準備が整ったという感触で決めるものではなく、業務・品質・データ・体制・取引先・切り戻しの6つの観点で決めたGo/No-Go基準を、証拠で確かめて決める場です。基準は判定の前に合意し、3段階で判定する。切り戻しは条件・判断者・期限まで書き、リハーサルで試す。本番切替のあとも、最初の月次締めが終わるまでを本番と考えて体制を残す。この流れを押さえれば、稼働直後に業務が止まるリスクを大きく減らせます。

自社の移行計画や判定基準に抜けがないか確認したい場合は、無料診断で現在の進み具合を整理し、稼働までに決めておくべきことを確認できます。