開発会社や保守担当から「そろそろ古い業務システムを入れ替えませんか」と提案されると、ありがたい反面、戸惑います。直して使い続けるのか、別の製品に乗り換えるのか、一から作り直すのか。金額も期間も大きく違うのに、どれが自社に合うのかを判断する材料が手元にありません。
「古い業務ソフトの入れ替えを提案されたが、改修・乗り換え・作り直しのどれが自社に合うのか判断できない」
先に結論をお伝えします。「どの方法が良いか」は、技術の優劣ではなく、自社の業務とシステムの状態で決まります。 提案を受けたら、次の5つを開発会社と一緒に確認し、答えをそろえてから選ぶのが現実的です（執筆時点：2026年11月）。
- 何に困っているのか（動かない・直せない・業務に合わない・人がいない）
- 仕様や中身が分かる資料が残っているか（ブラックボックス化していないか）
- 業務はこの先も今のままか、変わるか
- 止められる時間と、移行にかけられる期間・体制
- 将来の保守を誰が担えるか
この記事では、システム（＝ここでは社内の業務で使うソフトウェア）の入れ替えを検討するときの3つの選択肢と、選ぶための考え方を、チェックリストと質問例つきで解説します。
入れ替えの提案が出てくる3つの背景
まず、なぜ「入れ替え」の話が出るのかを整理します。背景が分かると、提案の中身を冷静に見られます。
背景1：古いシステムは、直しにくくなる性質がある
経済産業省の「レガシーシステムモダン化委員会総括レポート」（2025年5月）は、運用や改良が難しくなったシステム（レガシーシステム）の特徴を、技術面で次の3つに整理しています。
- 技術の老朽化（古い技術に対応できる技術者の確保が難しい）
- 肥大化・複雑化（機能の追加や変更が難しい）
- ブラックボックス化（仕様や設計の資料が整っておらず、運用が特定の人に頼った状態）
📰 出典：経済産業省「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」（2025年5月28日）
同じレポートでは、アンケートに回答したユーザー企業の61%がレガシーシステムを保有しているとされています。入れ替えの検討は特別なことではなく、多くの企業が向き合っているテーマです。
背景2：きっかけは「止まってから」が多い
同じレポートによると、モダン化（＝古いシステムを今の技術や業務に合わせて新しくすること）を決断するきっかけは、大規模なシステム障害や、保守を担当していた人の離脱といった、受け身の理由が上位を占めています。トップが先を見て自分から決める企業はまだ少ない、とも述べられています。
つまり、「提案が来た今」は、慌てずに選べるうちに検討を始められるタイミングともいえます。
背景3：開発会社にとっても、古いシステムは負担が読みにくい
開発会社の側から見ると、古い技術に詳しい技術者は限られ、仕様の資料が無いシステムは作業量の見当がつきにくいものです。入れ替えの提案は、売上のためだけでなく、「このまま保守を続けるのが難しくなってきた」という事情から出ていることも少なくありません。提案の理由を、率直に聞いてみてください。
3つの選択肢の違いを整理する
呼び方は会社によって違いますが、大きくは次の3つに分けて考えると整理しやすくなります。
| 選択肢 | 中身 | 向いている状況 | 注意点 |
|---|---|---|---|
| 改修（今のシステムを直して使う） | 部品の更新や不具合・機能の修正で延命する | 業務が大きく変わらず、仕様の資料や詳しい人が残っている | 古い技術のままなので、保守できる人が減るリスクは残る |
| 乗り換え（既製のパッケージやSaaSに移る） | 市販・クラウドの製品に業務を合わせる | 業務が一般的で、製品の標準機能で足りる | 業務のやり方を製品に合わせる調整と、データ移行が必要 |
| 作り直し（新しく開発する） | 今の業務に合わせて新しく作る | 自社独自の業務が競争力の源で、既製品では合わない | 費用・期間が大きく、要件（＝作るものの条件）を決める手間もかかる |
SaaS（＝インターネット経由で使うソフトウェアのサービス）への乗り換えは、サーバーの管理を任せられる反面、機能の自由度や契約条件の確認が必要です。どれが一番良いと決まるものではなく、状況との相性で選びます。
自社に合う方法を決める5つの判断軸
ここからは、開発会社に確認する5つの軸です。
軸1：何に一番困っているのか
「古い」ことそのものは、入れ替えの理由になりません。困りごとを次のように言葉にしてみてください。
- 動かなくなるのが怖い（サポート終了・保守できる人がいない）→ 改修か乗り換え、急ぐなら乗り換え
- 業務の変化に合わせて直せない → 乗り換えか作り直し
- 使いにくい・二重入力が多い → 業務の見直しを含めて検討
困りごとが定まらないまま見積もりを取ると、金額の比較ができません。
軸2：仕様や中身が分かる資料が残っているか
ブラックボックス化したシステムは、どの方法を選んでも調査に手間がかかります。前述のレポートは、仕様を復元してドキュメント（＝仕様や設計を書いた資料）にすることで、担当者が代わっても保守を引き継げるようになると述べています。
資料が無い場合は、入れ替えの前に「今の仕様を整理する作業」が必要になる可能性があります。その作業が見積もりに入っているかを確認してください。
軸3：業務はこの先も今のままか
業務が今後数年変わらないなら、改修や標準的な製品への乗り換えで足りることがあります。事業の拡大や制度の変更が見込まれるなら、後から直しやすい作りが必要です。経営側と現場の両方に、将来の予定を聞いておくと判断しやすくなります。
軸4：止められる時間と、移行の体制
入れ替えには、データの移行（＝古いシステムの情報を新しいシステムに移すこと）と、並行運用や切り替えの作業が必要です。月末の締め処理など、止められない時期を伝えたうえで、次を確認します。
- 切り替えは一括か、段階的か
- 問題が起きたときに、元に戻せるか（ロールバック）
- 現場の確認作業に、社内で何人・何日が必要か
軸5：将来の保守を誰が担えるか
入れ替えたあとも、保守は続きます。その技術に対応できる人が市場に十分いるか、開発会社が保守を続けられるか、契約が終わったときに別の会社へ引き継げるかを確認します。ソースコードや設計資料を受け取れる条件も、契約前に決めておきましょう。
やりがちな失敗
- 困りごとを整理せず、提案された方法をそのまま選んでしまう
- 「今の機能をそのまま再現する」ことを条件にして、不要な機能まで作り直す費用を払う
- 現場の担当者を入れずに決め、切り替え後に「使えない」と言われる
- 移行の費用を見積もりに入れず、後から追加費用になる
- 1社の提案だけで決める（他社の見立てを聞く機会を作らない）
発注者がやること チェックリスト
- ☐ 今のシステムで一番困っていることを、1〜3行で書き出した
- ☐ 仕様書・設計書・操作手順が残っているか確認した
- ☐ 今後3年ほどの業務の変化の見込みを、経営側と現場に聞いた
- ☐ 止められない時期と、現場で確認に出せる人数を整理した
- ☐ 改修・乗り換え・作り直しの3案で、費用・期間・リスクの説明を求めた
- ☐ 入れ替え後の保守を誰が担うか、確認した
- ☐ 必要に応じて、第三者の意見も聞くことにした
開発会社への質問例
- 「改修・乗り換え・作り直しの3案で、それぞれの費用・期間・リスクを教えてください」
- 「今のシステムの仕様が分かる資料はありますか。無い場合、整理の作業はどの案に含まれますか」
- 「データの移行は、どこまで見積もりに入っていますか。移行できないデータはありますか」
- 「切り替えで業務が止まる時間は、どのくらいですか。問題が出たときに元に戻せますか」
- 「入れ替えたあとの保守は誰が行い、別の会社に引き継ぐときに受け取れるものは何ですか」
なお、契約の形や責任の範囲など個別の判断が必要な場合は、弁護士や専門家、公式窓口に相談してください。この記事は一般的な考え方の紹介です。
まとめ：方法を選ぶ前に、困りごとと現状を言葉にする
古い業務システムの入れ替えは、次の流れで考えられます。
- まず「何に困っているのか」を言葉にする
- 仕様の資料が残っているか、業務が変わるかを確かめる
- 止められる時間と移行の体制、将来の保守を含めて3案を比べる
- 迷うときは、小さく調べてから決める
最終判断は発注者の役割ですが、材料をそろえるのは開発会社の仕事です。5つの質問を最初の打ち合わせで使うだけでも、提案の中身が見えやすくなります。
あわせて読みたい関連記事
