本番切替に不安がある企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、切替日は作業日ではなく、準備完了を確認する最終日と考えることを重視して進め方を整理します。
この記事では、新旧基幹システムの本番切替を失敗させないために、切替日までに何を確認し、当日と直後に何を備えておくべきかをチェックリストの形で整理します。切替を控えて不安を感じている担当者と、GOサインを出す立場の経営層の双方に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
切替日は「作業する日」ではなく「準備の完了を確認する日」
切替の失敗は、当日のトラブルよりも、当日までの準備不足が原因で起きます。データ移行のリハーサルが済み、所要時間が実測され、現場の教育が終わり、切り戻しの手順が確認されている——この状態を作れていれば、切替日そのものは手順書どおりに進める確認の日になります。逆に、切替日に初めて行う作業が残っているなら、それは日程を延期すべきサインです。
「戻れる状態で切り替える」ことを設計の前提にする
どれほど準備をしても、本番でしか分からない問題は起こり得ます。重要なのは、問題が起きたときに旧システムへ戻れる手順と、戻るかどうかを判断する基準・期限・責任者をあらかじめ決めておくことです。切り戻しの選択肢を持たない切替は、小さな問題でも「進むしかない」という判断の歪みを生みます。戻れる備えがあるからこそ、冷静に進む判断ができるのです。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
切替でよくある失敗は、システムの作業計画はあるのに、業務側の計画がないケースです。切替前後の受注をどう受け付けるか、旧システム最後の締めと新システム最初の締めをどうつなぐか、取引先への案内をいつ出すか。この業務側の段取りが曖昧だと、システムが正常でも業務が混乱します。
また、切替直後の問い合わせ対応を通常の保守体制のまま迎えてしまう失敗も定番です。稼働初週は操作の質問と「数字が違う気がする」という確認依頼が集中します。開発側と業務側の担当者が即応できる体制を初月だけでも敷いておくと、小さな不安が大きな不信に育つのを防げます。
周辺の依存先の見落としも要注意です。基幹と連携しているEDI、会計ソフト、Excelマクロ、帳票ツールは、本体の切替と同時に接続先や形式の変更が必要になることが多く、ここが漏れると本体は動くのに周辺業務が止まります。
自社で確認できるチェックポイント
切替日を確定させる前に、次の項目がすべて「済」になっているかを確認してください。一つでも残っていれば、日程よりも準備を優先すべきです。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
切替ならではの確認ポイント
基本のチェックリストに加えて、移行リハーサルの実施回数と実測時間、新旧の数字の突き合わせ結果（何が一致し、どの差異を許容としたか）、現場教育の受講状況と操作手順書の配布、切替当日のタイムテーブルと役割分担、切り戻しの判断基準・期限・責任者、取引先・社内への案内状況、周辺システムの接続変更の段取りを確認してください。これらを一枚の判定表にして、切替可否の会議で一つずつ確認する形にすると、雰囲気ではなく事実でGOサインを出せます。
チェックの運用では、項目の「済」を宣言する責任者を項目ごとに決めておくことが実効性を左右します。全員で確認したはずが誰も確認していなかった、という事故は、責任の所在が曖昧な確認体制から生まれます。判定表の各行に名前を入れる。それだけで確認の質は目に見えて変わります。
延命・部分改善で対応できるケース
切替のリスクは、方式の選び方でも下げられます。次のような場合は、一斉切替以外の方式を検討する価値があります。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
拠点や業務ごとに順番に切り替える方式や、参照系から先に新システムへ移す方式を取れば、一度に抱えるリスクと対応量を分散できます。切替の方式は開発の終盤で考えるものではなく、プロジェクトの計画段階で移行のしやすさまで含めて設計しておくべきテーマです。
また、切替時期は月初・連休明け・繁忙期を避け、業務量が少なく、かつ問題発覚時に対応時間を取れるタイミングを選ぶのが定石です。決算期をまたぐ切替は、会計側の負担が跳ね上がるため特に慎重な判断が必要です。
費用と期間の目安としては、切替の準備（リハーサル・教育・手順書・体制づくり）はプロジェクト全体の1〜2割の工数を占めるのが健全な水準です。ここを削って開発に回すと、最後の数週間で帳尻を合わせられなくなります。切替直後の集中支援体制も、初月分の保守費用として最初から見積に含めておくと、稼働後の対応が契約の議論で止まりません。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
切替の計画は、採用する構築方式によって力点が変わります。方式別の要点は次のとおりです。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージの場合、切替チェックの中心はデータ移行の検証と業務手順の変更点の周知です。旧システムと操作感が大きく変わるため、教育とマニュアルの整備が切替成功の比重の多くを占めます。
周辺開発で補うケース
周辺開発を伴う構成では、本体と周辺の切替順序と、切替期間中の一時的なデータの流れを設計しておくことが要点です。どちらか一方だけ新しくなる期間の運用を、業務側と合意しておいてください。
スクラッチ再構築が向くケース
スクラッチ再構築の一斉切替では、切り戻し手順の実地確認まで行うのが理想です。バックアップから旧環境を復元して業務を再開できることを一度確かめておけば、切替判断の最後の不安が消えます。
マクティズムの見解
マクティズムの見解として、新旧基幹システムの切替で失敗しないチェックリストでは「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、切替日は作業日ではなく、準備完了を確認する最終日と考えることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
切替の相談では、日程ありきで準備が追いついていないプロジェクトに出会うことが少なくありません。私たちは、延期の進言も含めて安全側の判断を躊躇しないことを方針にしています。切替日を一度延ばす痛みより、失敗した切替をやり直す痛みのほうがはるかに大きいことを、実案件を通じて知っているからです。
相談前に準備しておく情報
切替の相談では、予定している切替時期と方式、移行対象のデータ量、リハーサルの実施状況、連携している周辺システムの一覧、社内の推進体制が分かると、初回からチェックすべき弱点を具体的に指摘できます。すでに不安を感じている箇所があれば、それが最重要の確認ポイントです。
実務では、切替の数か月前から準備状況を判定表で見える化し、開発前診断や第三者レビューの形で「まだ切り替えるべきでない箇所」を率直に指摘したうえで、当日のタイムテーブルと切り戻し基準まで含めた計画に仕上げる支援をおすすめしています。
周到に準備された切替は、当日を迎える現場の空気を変えます。手順と役割と戻り道が明確であれば、担当者は落ち着いて確認に集中でき、その落ち着きが判断ミスを防ぎます。準備は技術であると同時に、人を守る仕組みでもあるのです。
チェックは、切替1か月前・1週間前・前日・当日の節目ごとに行い、未完了項目をゼロにしてから次の節目へ進む形にすると、漏れなく積み上げられます。
切替直後の初週は、朝夕に短い状況共有の場を設けることをおすすめします。現場で起きている小さな違和感を毎日吸い上げて対処の優先順位を決める仕組みがあると、問題が水面下で膨らむことを防げます。切替は当日で終わりではなく、初月の運用が安定して初めて完了と考えてください。
チェックリストは一度作って終わりではなく、リハーサルで見つかった漏れを反映して育てていくものです。切替を経験するたびに項目が磨かれ、会社の資産になっていきます。
また、切替当日の連絡手段と集合場所、判断者への連絡ルートといった当たり前の段取りも、書面にして全員へ配ってください。当日の混乱の多くは、技術ではなく連絡の行き違いから生まれます。
準備の総仕上げとして、切替前の最終週に「もう何もしない期間」を設けるのも有効です。直前の駆け込み変更は検証されないままの状態を本番へ持ち込む行為であり、切替失敗の典型的な引き金です。凍結期間を宣言し、変更したくなる要望は稼働後の改善リストへ回す。この規律が、当日の静けさを守ります。
入念な準備は関係者の自信となり、その自信が当日の落ち着いた判断を支えます。切替は準備がすべてです。
確認の一つひとつが、稼働初日の平穏をつくります。手を抜けるチェックは一つもありません。
準備を尽くした先に、静かな切替当日が待っています。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。切替の場合、予定時期と移行データ量の目安、周辺システムの一覧が分かれば相談を始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。リハーサルの結果しだいでは、部分的に先行稼働させて残りを後日に回す計画へ組み替えることも可能です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。切替のしやすさや移行支援の内容は、構築方式や依頼先を選ぶ際の比較材料として一緒に確認します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。切替計画のレビューや判定表づくりだけといった、部分的なご支援にも対応できます。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。現状の準備状況を伺い、切替可否をどう判定すべきかから一緒に整理します。
