新旧システムを並行稼働させる必要がある企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、並行稼働は期間を長くするより、検証項目を明確にすることを重視して進め方を整理します。
この記事では、新旧の基幹システムを並行稼働させる際に、期間・体制・検証をどう設計すれば安全かつ現場が疲弊しない形になるかを整理します。切替方式を検討中の情報システム担当者と、二重入力の負担を心配する現場責任者の双方に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
並行稼働の目的は「安心」ではなく「検証」
並行稼働は、新システムの結果を旧システムと突き合わせて正しさを確認するための期間です。目的を曖昧にしたまま「不安だからしばらく両方動かそう」と始めると、何を確認できたら終えるのかが決まらず、二重入力の負担だけが延々と続きます。並行稼働を設計する第一歩は、期間を決めることではなく、「何と何が一致していれば新システムを信じるのか」という検証項目を列挙することです。
全業務の並行より「山場を含む1サイクル」を確実に
並行稼働の範囲と期間は、月次の締め・請求・支払といった業務の山場を最低1回含む1サイクルを基本に設計します。日々の入力が合っていても、締め処理や月次帳票で差異が出ることは珍しくないためです。逆に、山場を2回3回と含めても検証として得られる情報は大きく増えず、現場の負担だけが積み上がります。長さより「どの山場を通すか」で考えるのが、負担と安心のバランスを取るコツです。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
並行稼働でよくある失敗は、二重入力の負担を過小評価することです。通常業務に加えて同じ伝票を二つのシステムへ入力する期間は、現場にとって確実に残業要因になります。入力の応援体制や一部データの自動転送を用意せずに始めると、疲弊した現場が新システム側の入力を省略し始め、肝心の検証データがそろわないという本末転倒が起きます。
また、新旧で数字が合わなかったときの調査ルールを決めていないケースも危険です。差異は必ず出るものであり、問題はその原因を「新の不具合・旧の不具合・入力ミス・仕様の違い」に切り分けて記録し、判断者を決めて対処することです。差異の扱いが場当たりだと、並行稼働が終わっても新システムへの信頼が積み上がりません。
さらに、並行期間中の「正」をどちらのシステムに置くかを宣言していないと、請求書はどちらから出すのか、在庫はどちらを信じるのかで現場が混乱します。正は旧、新は検証用、と最初に明示するのが原則です。
自社で確認できるチェックポイント
並行稼働の計画を立てる前に、次の点を確認しておくと、無理のない設計ができます。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
並行稼働ならではの棚卸しポイント
基本のチェックリストに加えて、二重入力が発生する伝票の1日あたり件数と担当者数、検証で突き合わせる帳票・数字の候補（売上集計・在庫残・債権残・試算表など）、月次の山場の日程、そして差異が出た場合の調査担当と判断者を確認してください。突き合わせは「全件の目視」ではなく、件数と金額の合計一致を軸に、差異があった部分だけ明細を追う方式にすると、検証の負担を現実的な範囲に抑えられます。
並行稼働の体制では、現場の検証担当をあらかじめ指名し、その期間の通常業務を軽減しておくことも重要です。検証は片手間ではできません。誰が・どの帳票を・いつ突き合わせるのかを当番表の形に落とすと、検証が特定の熱心な人の善意に依存する状態を避けられます。
延命・部分改善で対応できるケース
すべての切替に長い並行稼働が必要なわけではありません。次のような場合は、並行期間を短くする、あるいは省く判断も合理的です。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
たとえば、対象業務が限定的でデータの検証が事前のテストで十分に行える場合や、旧システムがすでに信頼できる比較対象になっていない場合は、リハーサルと初月の重点監視に力を入れ、並行稼働は短期にとどめるほうが総負担は小さくなります。並行稼働は手段であって義務ではありません。
一方で、請求金額や在庫評価といった対外的・会計的な影響が大きい数字を扱う切替では、最低1回の締めを並行で通す価値は十分にあります。省くかどうかは、間違えたときの影響の大きさで決めるのが判断軸です。
費用と期間の目安としては、並行稼働そのものの追加費用は開発費よりも「現場の労務負担」と「支援体制」に現れます。期間は1〜2か月（締め1〜2回分）が一般的で、二重入力を軽減するデータ転送ツールを用意する場合は数十万〜数百万円の追加開発を見込みます。この投資は現場の疲弊と検証品質を大きく改善するため、対象件数が多い場合には十分に元が取れます。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
並行稼働の設計は、切替方式の選択と一体です。次のような観点で、自社に合う方式を検討してください。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージ移行の場合、旧システムと画面や集計の考え方が異なるため、数字の突き合わせには「仕様の違いによる差」を織り込む必要があります。どの差異が正常でどれが異常かの基準表を作ってから並行を始めると、調査の空回りを防げます。
周辺開発で補うケース
業務や拠点を区切って部分的に新システムへ移す段階切替では、新旧をまたぐデータ連携を一時的に用意することで、全社一斉の並行稼働を避けられます。連携の作り込みは必要になりますが、一度に抱えるリスクを小さくできる現実的な方式です。
スクラッチ再構築が向くケース
全面刷新で一斉切替を選ぶ場合こそ、並行稼働あるいはそれに代わる徹底したリハーサルが安全装置になります。切り戻しの手順と判断期限をあらかじめ決めておき、「戻れる状態で切り替える」ことを設計の前提にしてください。
マクティズムの見解
マクティズムの見解として、基幹システムの並行稼働を安全に進める方法では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、並行稼働は期間を長くするより、検証項目を明確にすることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
並行稼働の相談では、「とにかく長く並行すれば安全」という思い込みをほどくところから始まることが多くあります。私たちは、検証項目が消化できたら予定より早く終える判断も含めて、現場の負担と検証の質を両立する設計を大切にしています。並行稼働の成否は期間の長さではなく、始める前の準備の質で決まるというのが実案件からの実感です。
相談前に準備しておく情報
並行稼働の相談では、対象業務と1日あたりの伝票件数、月次の締めスケジュール、検証に使えそうな帳票、現場の人員の余力感が分かると、初回から現実的な期間と体制の話ができます。過去の切替で苦労した経験があれば、それも重要な設計材料になります。
実務では、現行調査で業務量と山場を把握し、開発前診断で検証項目と差異の判断ルールを定義したうえで、二重入力の軽減策と切り戻し条件を織り込んだ並行稼働計画に落とし込む流れをおすすめしています。
丁寧に設計された並行稼働は、新システムの検証だけでなく、現場が新しい操作に慣れる助走期間としても機能します。切替日を「初めて触る日」にしないことが、稼働直後の混乱を最小にする一番の近道です。
計画は、検証項目の定義、負担軽減策の準備、山場を含む実施、判定と切替、の順で組み立てます。各段階の完了条件を文書にしておけば、関係者の認識ずれも防げます。
また、並行稼働で見つかった差異と対処の記録は、そのまま新システムの引き継ぎ資料になります。なぜこの仕様にしたのか、旧システムとどこが違うのかという記録は、稼働後の問い合わせ対応や将来の改修で必ず役に立ちます。検証の記録を使い捨てにしない意識が、資産を一つ増やします。
並行稼働の終了判定は、あらかじめ決めた検証項目の消化率と未解決差異の件数という数字で行い、関係者がそろう場で宣言する形にすると、だらだらと延長される事態を防げます。終わり方を決めてから始めることが、並行稼働を計画たらしめる条件です。
なお、旧システムは切替後もすぐには廃棄せず、参照専用として一定期間残しておくと、過去データの照会や万一の検証に役立ちます。停止と廃棄の時期は分けて計画してください。
検証で使う帳票は、金額の大きいもの・対外的に出るもの・締めに直結するものの三つの観点で選ぶと、限られた労力で守るべき数字を押さえられます。すべてを疑うのではなく、間違えてはいけない順に確かめていく。この優先順位の設計が、並行稼働を短く濃いものにします。
準備の質が高いほど、並行稼働は短く静かに終わります。それが理想の姿です。
その静けさこそが、検証を尽くした証と言えます。
一つひとつの突き合わせが、稼働後の安心を形づくっていきます。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。並行稼働の場合、対象業務と伝票件数の目安が分かれば十分に相談を始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。部分的な業務だけ新システムへ先行移行し、残りは現行を使い続ける段階的な方式も検討できます。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。新旧で集計の考え方が違う場合の差異の扱いも、比較の基準づくりから一緒に整理します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。二重入力を軽減するデータ転送の仕組みだけを用意する、といった支援も可能です。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。切替への不安の中身を伺い、検証で潰せるものから順に計画へ落とし込みます。
