長く使ってきた基幹システムを作り替えることが決まると、設計や機能の話より先に、 ある一点で意見が割れることがあります。新しいシステムに一度で切り替えるのか、業務や拠点ごとに分けて少しずつ移すのか。 社内では「一気に変えたほうが混乱が短い」という声と、「万一止まったら業務が回らないから分けるべきだ」という声が同時に出て、 どちらも間違っていないために決着がつきません。
この判断が難しいのは、どちらが安全かという問いの立て方そのものが、答えの出にくい形になっているからです。 一括切替は切り替わる瞬間に負担が集中し、段階に分ける方式は分けている期間のあいだ、旧と新が同時に存在する状態を運用し続けることになります。 この記事では、受託開発を手がけるCoconutWorksが、切り替え方の型と向いている状況、段階に分けると新しく増える作業、 そして自社の仕組みが分けられる構造になっているかの見分け方を整理します。費用の数字は扱いません。 刷新の方針（移植・作り直し・段階移行）の選び方と、現行仕様の調査から始める進め方はレガシーシステム刷新の進め方で扱っているので、ここでは方針が決まったあとの切り替え方に絞ります。なお、そちらでは「区切れるなら区切る」ことを原則としていますが、区切ると新しく増える作業もあるため、この記事ではどちらの負担を背負えるかで比べる立場をとります。
結論: 切り替え方は4つの型に分かれる
| 切り替え方 | 向いている状況 | 新しく増える手間 | つまずきやすい点 |
|---|---|---|---|
| 一括で切り替える | 対象の業務が一本で、止められる日がある | 切替当日の段取りと、戻す判断の基準 | 基準を決めずに迎えると、不具合を抱えたまま走り続けることになる |
| 並行して動かす | 出てくる数字を旧と突き合わせて確かめたい | 同じ入力を二重に行う運用と、旧新の差を照合する作業 | 二重入力の負担で、現場が旧側だけを使う状態に戻る |
| 機能・業務単位で分ける | 大きな仕組みの中に、独立して動く業務が混ざっている | 旧と新の間でデータをやり取りするつなぎ | 暫定で作ったつなぎが、刷新が終わっても捨てられない |
| 拠点・部門単位で分ける | 同じ業務を複数の拠点や部門が別々に回している | 移行済みと未移行が混ざる期間の集計と問い合わせ対応 | 最初の拠点に合わせた作りが、後の拠点で合わない |
表で見ていただきたいのは、どの型にも「新しく増える手間」があるという点です。 段階に分ける方式が慎重な選択に見えるのは、切替当日のリスクだけを見ているときです。 分けると決めた時点で、旧と新をつなぐ仕組みを作る作業、どちらに入力するかを現場に伝える作業、 移行済みと未移行が混ざった状態で数字を出す作業が追加されます。 一括切替はこれらが要りませんが、代わりに切り替えた日の前後に負担が集まります。 どちらが楽かではなく、自社がどちらの負担なら背負えるかという問いに置き換えると決めやすくなります。以下、順に掘り下げます。
一括で切り替えるのが向いているとき
一括切替は、ある日を境に旧システムを止めて新システムに移る方式です。 古い仕組みを長く使ってきた会社では乱暴な選択に見られがちですが、 条件が合えば段階に分けるより手数が少なく、終わりもはっきりします。 合う条件は大きく2つで、対象の業務が一本につながっていて分けどころがないことと、業務を止められる日が年のどこかにあることです。
たとえば受注から出荷、請求までが一本のデータでつながっている仕組みでは、 受注だけを新システムに移しても、その受注データを出荷側の旧システムに渡す仕掛けが必要になります。 つなぎを作る手間が、分けたことで得られる安全よりも大きくなるなら、分けない判断には十分な理由があります。 業務の区切りという点では、連休や決算の谷間、あるいは月初の数日のように受け付けが少ない時期があるかどうかが現実的な分かれ目になります。
ただし一括切替を選ぶ場合、戻す判断の基準を切替前に文字にしておくことが条件に加わります。 当日に不具合が見つかったとき、その場で「戻すべきか、直しながら進めるべきか」を判断するのは難しく、 基準がないと「もう少し様子を見よう」が選ばれ続けて引き返せない位置まで進んでしまいます。 どの処理が通らなければ戻すのか、何時までに復旧しなければ旧に戻すのか、その判断を誰がするのか。 この3つを決めておくだけで、当日の対応は大きく変わります。旧システムの環境を切替と同時に消さず、 しばらく残しておく取り決めも合わせて必要です。
段階に分けると、何が新しく増えるのか
段階に分ける方式を検討するとき、話題になるのは「どこで分けるか」ですが、 実務で重くのしかかるのは分けている期間に発生する作業のほうです。 見落とされやすいものを4つ挙げます。
- 旧と新をつなぐ仕組み — 移行済みの業務で発生したデータを未移行の業務に渡す必要があります。この受け渡しは刷新後には不要になるもので、暫定の作りになりがちです。
- データを二重に持つ状態の管理 — 同じ取引先や商品の情報が旧と新の両方にある期間、どちらを正とするかを決め、変更があったときに両方へ反映する段取りが要ります。
- 混ざった状態での集計 — 月次の数字を出すとき、移行済みの分と未移行の分を合わせて一つの表にする作業が、分けている期間ずっと続きます。
- 現場が覚える手順が2つになる期間 — どの業務がどちら側かを現場が覚える必要があり、問い合わせ対応も「それはどちらのシステムの話か」を確かめる手間が増えます。
この4つのうち、後から効いてくるのが1つ目のつなぎです。 分けている期間だけのために作るものなので、作り込みすぎないのが普通の判断になりますが、 その結果暫定のまま残り、刷新が終わっても捨てられないことがあります。 移行が後ろに延びるほどこの仕組みは業務に馴染んでいき、気づいたときには誰も触れない部分になっている、 という経過をたどることがあります。段階に分けると決めたら、つなぎは「いつ捨てるものか」を最初に書いておき、 移行の完了とセットで撤去する作業を日程に入れておくことをおすすめします。
2つ目から4つ目は、社内の負担として現れます。とくに並行して動かす方式の場合、 同じ入力を旧と新の両方に行う運用になるため、現場の負担は単純に増えます。 負担が続くと、人は慣れていて動くと分かっている側を選びがちです。 つまり旧側だけに入力して新側が空になるという形で崩れ始めます。 並行して動かす目的は旧と新で同じ結果が出ることを確かめることなので、片方が空になると確かめる材料そのものが失われます。 並行稼働を選ぶなら、二重入力の対象を確かめたい業務だけに絞り、終わる条件を先に決めておくほうが保ちます。
自社の仕組みが分けられる構造かを見分ける
段階に分けたいと思っても、分けられるかどうかは今の仕組みの作りで決まります。 希望ではなく構造の話なので、先に確かめておく価値があります。見る観点は次の4つです。
| 見る観点 | 分けやすい状態 | 分けにくい状態 |
|---|---|---|
| データの持ち方 | 業務ごとにデータがほぼ独立していて、他の業務が書き換えない | 同じマスタを複数の業務が書き換えており、どちらが正かを決められない |
| 業務の流れ | 受注・出荷・請求のように、工程で前後に区切れる | 1件の処理が複数の業務を行き来し、途中で差し戻しが起きる |
| 締めの区切り | 月次・年次の締めが業務単位で閉じる | 締めが全業務のデータを集めて初めて成立する |
| 外部とのやり取り | 連携先が業務ごとに分かれている | 1つの連携口から全業務分をまとめて送っている |
この表のうち、判断を左右しやすいのはデータの持ち方です。 取引先・商品・単価といったマスタを複数の業務が書き換えている仕組みでは、 一部の業務だけを新システムに移した瞬間に「どちらのマスタが正しいのか」という問題が立ち上がります。 片方向に同期する仕掛けで凌げる場合もありますが、両側で変更が起きる前提になると途端に込み入ってきます。 逆に、業務ごとにデータがほぼ独立している仕組みなら、分ける負担はかなり軽くなります。
締めの区切りも見落としやすい観点です。月次や年次の締めが全業務のデータを集めて初めて成立する作りだと、 分けている期間は毎回、旧と新から数字を集めて手で合わせる作業が発生します。 一度や二度なら許容できても、移行が数か月にわたるなら、その手間を何回繰り返すのかを数えておく必要があります。
そして、この4つの観点に答えるには今の仕組みの中身が分かっている必要があります。 仕様書が残っておらず、どの業務がどのデータを触っているかを社内の誰も説明できない状態なら、 切り替え方を決める前に現状を把握する工程が必要です。その進め方は仕様書のない既存システムをどう引き継ぐかで扱っています。調査だけを先に切り出して頼むという形も取れるので、 発注を分ける考え方は要件定義だけを先に発注できるかを参考にしてください。
迷ったときのチェックポイントと、進めていく順序
切り替え方を決める前に、次の5点に答えられるか確かめてみてください。 詰まった項目は、進めてから「これでは決められない」として出てくる場所です。
- ①業務を止められる日が年のどこかにあるか — 連休・決算の谷間・受け付けの少ない時期など、候補を実際に挙げられるか。
- ②マスタを複数の業務が書き換えていないか — 書き換えている場合、分ける負担は見込みより重くなります。
- ③締めは業務単位で閉じるか、全業務を集めて成立するか — 後者なら、分けている期間に手で合わせる作業が毎回発生します。
- ④二重入力に現場が何日耐えられるか — 並行して動かすなら、現場に聞いて日数で答えを出しておく。
- ⑤不具合が出たときに止める判断を誰がするか — 役職ではなく、名前で決まっているか。
進める順序としては、①対象の業務とデータの関係を書き出して、分けられる境目があるかを確かめる → ②業務を止められる候補日を社内で挙げる → ③一括か段階かの案を開発会社と持ち寄り、それぞれで増える作業を一覧にする → ④戻す判断の基準と、判断する人を決める → ⑤段階に分ける場合は、つなぎを捨てる時期を日程に入れる → ⑥現場が使う手順を切替前に配り、実際に一度通してみるという流れが無理がありません。
③で「それぞれ増える作業を一覧にする」を入れているのは、 一括と段階を並べて比べるとき、一括のリスクだけが具体的に語られ、段階の負担が抽象的なままになるからです。 段階に分ける側も、つなぎを作る、二重に持つ、混ざった数字を合わせる、という作業を具体的に書き出すと、 同じ土俵で比べられるようになります。どちらを選んでも作業は発生するという前提に立つほうが、 決めたあとで想定外が出にくくなります。
よくある誤解と、起きやすい失敗
「段階に分ければ失敗しない」 — 分けると一回の影響範囲は小さくなりますが、 失敗の種類が変わるだけで、無くなるわけではありません。 段階方式で起きやすいのは、止まるような派手な事故ではなく、 移行が途中で止まったまま旧と新が併存し続けるという停滞です。 最初の業務を移したところで予想より手間がかかり、次の業務の着手が後ろに延び、 そのうち担当者が異動して誰も全体を把握していない状態になる。 分ける方式を選ぶなら、完了までの日程と、途中で止まったときに誰が判断するかを決めておく必要があります。
「並行稼働していれば安心」 — 並行して動かすこと自体に効果はなく、 効果が出るのは旧と新の結果を突き合わせて差を調べたときです。 両方を動かしているだけで照合をしていなければ、二重入力の負担を払って何も確かめていない状態になります。 並行稼働を選ぶなら、何の数字を照合するのか、差が出たときに誰が原因を追うのか、 どこまで一致したら旧を止めるのかを先に決めてください。 照合する担当を決めずに始めると、差が出ても「あとで見る」のまま積み上がります。
「拠点ごとに分けるなら、小さい拠点から試すのが安全」 — 小さい拠点は影響が小さい代わりに、業務の種類も少ないという点に注意が必要です。 例外的な処理や量の多い処理は大きい拠点で起きるため、小さい拠点で問題なく動いたことは大きい拠点で動く根拠にはなりません。 さらに、最初の拠点に合わせて作り込んでしまうと、後の拠点のやり方と合わず、 結局そこで作り直すことになります。順番を小さい方からにするのは妥当ですが、 最初の拠点を基準にせず、全拠点のやり方の違いを先に把握しておくことが前提になります。
「切り替えが終われば刷新は完了」 — 新しいシステムが動き始めた時点では、 まだ旧システムの環境、分けている期間のために作ったつなぎ、旧側のデータの保管先が残っています。 これらを整理するところまでを刷新の範囲に入れておかないと、使われていない仕組みが残り続け、 次に何かを変えるときの調査対象として毎回出てきます。 切り替えの計画には、片付ける作業と、それをいつ誰がやるかまで含めておくことをおすすめします。
よくある質問
まとめ
基幹システムの刷新で切り替え方を決めるとき、問いを「どちらが安全か」ではなく「どちらの負担なら背負えるか」に置き換えると判断しやすくなります。 一括切替は業務を止められる日があり、分けどころのない仕組みに向く代わりに、戻す判断の基準を先に決めておくことが条件になります。 段階に分ける方式は影響範囲を小さくできますが、旧と新をつなぐ仕組み・データの二重管理・混ざった状態での集計・ 現場が覚える手順の増加という作業が、分けている期間ずっと続きます。 そして分けられるかどうかは希望ではなく、マスタを複数の業務が書き換えていないか、締めが業務単位で閉じるかといった今の仕組みの構造で決まります。どちらを選んでも発生する作業を一覧にして同じ土俵で比べ、 止める判断をする人を名前で決めておく。この二つがそろっていれば、進めたあとの想定外は減らせます。 刷新の進め方や切り替え方のご相談はシステム開発・業務改善サービスのページから承っています。相談・お見積もりは無料です。
