「もう古いシステムは限界だから入れ替えよう」——そう判断して動き出した経営者が、半年後に頭を抱える光景があります。データが思うように移行できない、新旧並行運用で現場の負担が倍になった、「前のシステムと同じことができないと困る」という声で要件がふくらみ予算超過——こうした移行の地獄は、技術的な難しさではなく『判断の順序』が原因で起きます。本記事では既存システムの入れ替えで失敗する3つのパターンと、移行を成功させる経営者目線の判断軸を整理します。
この記事の結論（3行）
- 入れ替え失敗の典型は『データ移行軽視』『並行運用の設計不足』『現行業務の再現要求過多』の3パターン
- 移行費用は新規開発費の30〜70%が相場。これを甘く見積もると予算が1.5〜2倍に膨らむ
- 解決の方向性は『移行は新規開発と別プロジェクト』として独立予算化すること
既存システムの入れ替えが『地獄化』する構造
システム入れ替えは新規開発よりも難易度が高い仕事です。新規開発は『ゼロから作る』のに対し、入れ替えは『動いているものを止めずに別物に置き換える』必要があります。飛行中の飛行機のエンジンを交換するような難しさで、経営者がこの構造を理解せず『単なる買い替え』の感覚で動き出すと、必ず地獄化します。
- データ移行を『最後の作業』だと思っている
- 並行運用の期間と費用を見積もっていない
- 『今と同じこと』ができることが当然だと現場が思っている
これらは技術論ではなく、経営者の認識ギャップの問題です。発注先のベンダーがどれだけ優秀でも、発注側がこの3点を押さえていないと、プロジェクトはコントロールを失います。
データ移行を『最後の作業』だと思っている
入れ替えプロジェクトの初期計画で、データ移行はしばしば『最後の仕上げ』として扱われます。実際には、データ移行は最初に設計を始めるべき項目です。旧システムのデータ構造を読み解き、新システムのデータ構造へマッピングし、整合性を担保するスクリプトを書く——この一連が、プロジェクト全体の30〜40%の工数を占めることが珍しくありません。最後にやろうとすると、リリース直前にデータが入らず稼働延期、という事態になります。
並行運用の期間と費用を見積もっていない
新システムが稼働しても、旧システムを即日停止できることは稀です。3〜6ヶ月の並行運用期間が必要で、その間は旧・新の両方の運用費用がかかります。サーバー、ライセンス、運用人件費——これらが二重に発生します。当初予算に並行運用費を入れていないと、リリース後に『想定外の追加コスト』として現れます。
『今と同じこと』ができることが当然だと現場が思っている
入れ替えの議論で必ず出るのが「今のシステムでできていたAは、新システムでもできますよね」という現場からの確認です。これに『はい』と答えてしまうと、要件は青天井に膨らみます。10年前から積み重なった機能の中には、もはや誰も使っていないものや、新しいUIでは別の方法で実現できるものが混ざっています。すべて再現する前提だと、入れ替えのコストは新規開発の倍以上になりかねません。
失敗の3パターンを比較表で整理
| 失敗パターン | 表面の症状 | 本質的な原因 | 追加コスト目安 | |---|---|---|---| | データ移行軽視 | リリース1ヶ月前に『データが入らない』が判明 | 移行スクリプト工数を初期見積もりに入れていない | 初期予算の20〜40%増 | | 並行運用の設計不足 | 現場が新旧両方を入力する二重作業で疲弊 | 移行期間中の運用設計を発注前にしていない | 月額5〜30万円×3〜6ヶ月 | | 現行業務の再現要求過多 | 『前と同じ』が大量に出て要件が膨らむ | 機能棚卸しを発注前にしていない | 開発工数1.5〜2倍 |
3パターンに共通するのは、いずれも『発注前の準備不足』が根本原因だという点です。発注した後にこれらを解消しようとすると、ベンダー側の追加工数として乗ってきてしまい、結局見積もりが大きく膨らみます。発注前の段階で業務改善・システム見積もりAI適正診断を使って準備すると、これらの失敗パターンを構造的に避けやすくなります。
パターン1：データ移行軽視で起きる悲劇
データ移行で失敗する典型は、旧システムのデータ構造を『甘く見ていた』ケースです。「テーブル20本くらいだから、SQLでさっと移せる」と発注時に思っていたら、実際にはテーブル設計が崩壊していた、文字コードが混在していた、過去データに欠損があった、というパターンが頻発します。
旧データの『汚れ』を見ない発注
旧システムのデータは、10年運用していれば必ず汚れています。重複レコード、形式違反、論理的に矛盾するデータ——これらをすべて新システムへそのまま入れると、新システム側で動作不良が起きます。発注前にデータクレンジングのスコープを決めずに進めると、リリース直前に「データが汚いから動かない」と判明します。
移行リハーサルを1回もやらないリスク
データ移行は必ず本番稼働の前にリハーサルが必要です。少なくとも2〜3回。1回目は技術的に通せるか、2回目は時間がどれくらいかかるか、3回目は本番想定での総合確認、というステップです。リハーサルなしで本番に臨むと、移行作業中に問題が起きた時のリカバリーができません。
移行スコープを『年単位』で線引きする
すべての過去データを新システムへ移行するのは現実的でないケースが多いです。「過去3年は完全移行、それ以前は参照用に別データベースへ退避」のような線引きを、発注前に決めてください。この決断ができれば、移行工数を3〜5割減らせます。
パターン2：並行運用の設計不足が現場を疲弊させる
新旧並行運用は、入れ替えプロジェクトで避けて通れない期間です。この期間の設計を発注前に詰めておかないと、現場が疲弊し、結果として新システムへの反発を生みます。
並行運用中の運用設計で押さえるべき論点は、データの『正』をどちらに置くか、入力作業を二重にするか片方にまとめるか、業務トラブル発生時にどちらを使うか、移行完了の判定基準は何か、という4点です。これらを発注前に決めずに見切り発車すると、現場では『どっちに入力すればいいか分からない』状態が常態化します。
並行運用期間の長さは業務規模で決まります。基幹業務なら3〜6ヶ月、部門システムなら1〜3ヶ月が目安です。この期間の運用人件費とライセンス費は、必ず予算化してください。「移行が終わってから考える」では遅く、発注前に総コストとして織り込むことで初期判断の精度が上がります。
並行運用中の『データの正』をどちらに置くか
新旧両方が動いている間、業務上の『正しいデータ』をどちらのシステムで持つかを明確にしてください。両方を『正』にすると、不整合が起きた時に原因追跡ができません。基本は『旧が正、新は検証用』で始め、3〜4週間後に『新が正、旧は参照用』へ切り替える二段階が安全です。
並行運用の『卒業日』を最初から決めない
並行運用の終了日を発注時に確定させると、当日に問題があっても止められません。『3ヶ月を目安に、現場が新システムで業務完結できることを確認してから旧停止』という条件型の終了基準にしておくと、現場の納得感も得られます。
パターン3：『現行業務の再現要求過多』で予算が膨らむ
入れ替えで一番怖いのが、要件が膨らみ続けて予算が制御不能になる事態です。原因は『現行業務をすべて新システムでも再現する』前提です。
機能棚卸しをしないと『使われない機能』も移植される
旧システムの機能の中には、ここ1年で誰も使っていない機能が必ず混ざっています。発注前に「過去1年で実際に使われた機能のリスト」を作り、それ以外は移植対象から外すと、要件が3〜5割減ります。中小企業の基幹系で20〜30機能が削れることはよくあります。
『前と同じUI』要求への対処
ベテラン現場担当者から「前のUIと同じにしてほしい」という要望が出ることがありますが、これに全部応じると新システムの設計思想が崩れます。「同じ業務が、新しいUIで、より速くできる」を目指す方針を経営者から打ち出してください。発注時に項目別に整理できれば、要件の取捨選択もしやすくなります。
経営判断としての『捨てる勇気』
入れ替えは『機能を増やす機会』ではなく『機能を整理する機会』です。経営者が「これは捨てる」と判断すれば、ベンダーはその方針に従って設計します。逆に経営者が現場の『前と同じ』要求をすべて呑むと、ベンダーは作るしかありません。捨てる判断の責任は、経営者にあります。中途半端に呑むと予算超過と現場不満の両方が起きるため、判断を先送りせず発注前に方針を固めておくほうが結果的に現場の納得感も高まります。
経営者目線で考える『入れ替えを成功させる5つの判断軸』
ここからは経営の話です。システム入れ替えを成功に導くための判断軸を5つに整理します。どれも発注前に持っておくべきものです。
- 移行は新規開発と別プロジェクトとして独立予算化する
- データ移行スコープを年単位で線引きする
- 並行運用期間と費用を当初予算に組み込む
- 機能棚卸しを発注前に完了させる
- 『前と同じ』を捨てる判断を経営者が打ち出す
移行費用は新規開発費の30〜70%が相場で、データ件数が多いほど比率が上がります。これを別プロジェクトとして独立予算化することで、新規開発側の見積もりと混ざらず、経営判断がしやすくなります。
並行運用は『あったほうがいい』ではなく『なくてはならない』ものです。月額5〜30万円の追加運用費が3〜6ヶ月発生する前提を、最初から経営判断に組み込んでください。これを後出しで気づくと、現場の士気が一気に下がります。
機能棚卸しと『前と同じ』を捨てる判断は、経営者にしかできない仕事です。現場任せにすると要件は膨らみ続けますし、ベンダー任せにすると安全側に倒して全機能を見積もりに入れてきます。経営者が『使われている機能だけ移植する』方針を打ち出すことで、初めて要件が現実的なサイズに収まります。
ぷらすわんの実例：じちなびで実践した『機能棚卸し前提』の開発
ぷらすわんが取り組んでいる『じちなび』の事例をお伝えします。じちなびは自治体・地域DXのマッチングポータルで、市場相場300〜800万円の機能を200万円規模で立ち上げました。
この差を生んだのが『現行業務をすべて再現する』発想を最初から捨てたことです。企画段階では、自治体の窓口業務をデジタル化する従来型の発想も検討されました。しかしそれをすると、紙の手続きをWebに置き換えるだけで『窓口が増えた』状態になります。そこで「地域の事業者と利用者がつながる」という本質だけを切り取り、申請フロー・承認フロー・履歴管理といった『あったほうがいい機能』を後回しにしました。Next.js + Supabase構成で、コストを大幅に抑えながら実用レベルのポータルを実現しています。
システム入れ替えでも同じ発想が効きます。「現行業務のすべて」を再現せず、「業務の本質はどの3〜5機能か」を経営者が決め切ることで、見積もりは市場相場の半分以下に収まる場合があります。手元の入れ替え計画について移行リスクを診断する場合、こうした機能棚卸しの観点から具体的に整理できます。
まとめ
既存システムの入れ替えで失敗する3パターンは、『データ移行軽視』『並行運用の設計不足』『現行業務の再現要求過多』です。いずれも発注前の準備不足が根本原因で、発注後にベンダー任せにすると追加工数として跳ね返ってきます。経営者が事前に5つの判断軸（独立予算化・データスコープ・並行運用設計・機能棚卸し・捨てる判断）を持って臨むことで、移行は地獄化を回避できます。
入れ替えは『同じものを別の場所に動かす』作業ではなく『業務を整理し直す機会』です。経営者の判断軸が定まっていれば、旧システムの資産は古い負債ではなく、業務知識の塊として新システムへ引き継がれます。入れ替え計画を整理したい経営者の方は、現状を比較を依頼する流れで複数視点を入れることをお勧めします。