古くなった業務システムやWebシステムを新しくしたいものの、何から始めればよいか分からない。社内で提案したくても、具体的に計画を提案できない。この記事は、そうした悩みを持つIT担当者の方に向けたものです。
システムリプレース（今のシステムを新しいシステムに置き換えること）を開発会社に依頼する前の準備、提案から移行までの流れ、良い提案の見分け方、社内で稟議を通すときのポイントを、国の公開資料をもとに整理します。仕様書が残っていない場合の進め方も扱います。
先に結論をお伝えすると、システムリプレースの提案を開発会社に依頼するときは、「現状の整理 → 開発会社への相談と現状調査 → 作り直す範囲と移行方法の検討 → 概算見積りと提案内容の比較」の順で進めるのが基本です。案件によって順序が前後することもあります。社内で稟議を通すときも、この現状調査と概算が説明の材料になります。
システムリプレースとは
システムリプレースとは、今使っているシステムを新しいシステムに置き換えることです。「リプレイス」と書かれることもあります。
マイグレーションとの違い
似た言葉に、マイグレーションがあります。マイグレーションはシステムやデータを別の環境や構成へ移すこと、リプレースは今のシステムを新しいシステムに置き換えることです。マイグレーションでも、クラウドへの移行に合わせてOSやデータの形式を変えるなど、中身に手を入れることがあります。
実際の案件では両方を組み合わせることも多くあります。言葉の違いよりも、「何をどこまで変えるか」を決めることが大切です。
検討を始めるタイミング
経済産業省が2025年にまとめた報告では、企業がシステムの刷新を決めるきっかけとして、大規模なシステム障害や保守担当者の離脱など「受動的」なものが上位でした。困ってから動き出す企業が多いということです。
出典：経済産業省「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」
次のような状況があれば、検討を始める目安になります。
- OSや使っている部品（ソフトウェア）のサポート終了が近い
- 仕組みを分かる担当者が、社内にも委託先にも少ない
- 小さな修正にも時間と費用がかかるようになった
なお、法人税法上、販売用の原本や研究開発用を除くソフトウェア（自社で使う業務システムなど）の耐用年数は5年です。ただし、これは減価償却に使う税務上の年数で、システムの寿命や入れ替えの時期を示すものではありません。実際の時期は、サポートの状況、保守のしやすさ、セキュリティ、業務上の必要性から判断します。
出典：国税庁「No.5461 ソフトウエアの取得価額と耐用年数」
開発会社に提案を依頼する前に整理しておくこと
この節では、依頼前に社内でまとめておくべきことを紹介します。これらを整理することは開発会社からの提案の精度にも影響します。すべて揃っていなくても相談はできますが、分かる範囲で整理しておくと話が早く進みます。
| 項目 | 整理する内容の例 |
|---|---|
| 目的 | 保守を続けられるようにしたい、機能を追加したい、運用の手間を減らしたい |
| 困っていること | 動作が遅い、修正できる人がいない、手作業で補っている部分が多い |
| 資料と資産 | 仕様書、ソースコード、データ、サーバーやドメインの管理者 |
| 期限 | サポート終了日、今の保守契約の更新日、事業上の予定 |
| 関係者 | 実際に使う部署、最終的に承認する人 |
特に確認したいのが、ソースコード（システムを動かすプログラムの元になる文章）の扱いです。ソースコードの著作権が誰にあるかは契約によって異なります。IPA（情報処理推進機構）が公開しているモデル契約書でも、著作権の帰属について、同ページで公開している契約書の第45条に複数の案が示されています。また、著作権の帰属とは別に、ソースコードの引き渡しを受けられるか、改修やほかの会社への保守委託が認められているかも確認しておきましょう。今の契約書を手元に用意しておくと、相談がスムーズです。
整理した内容を開発会社に伝える資料の作り方は、提案依頼書（RFP）の書き方で詳しく解説しています。
仕様書がない・作った会社と連絡が取れない場合
この節では、資料が残っていないシステムをどう進めるかを説明します。
長く使ってきたシステムほど、仕様書が古いまま更新されていなかったり、作った担当者がいなくなっていたりします。再構築がうまくいかない原因として、時間がたって分からなくなった今のシステムの仕様があいまいなまま、開発に着手してしまうことがあります。
まずは現状調査から始める
そのため、いきなり作り直すのではなく、まず今のシステムを調べる工程を置きます。IPAの講演資料でも、要件定義（何を作るかを決める工程）の前の企画段階で今のシステムを調べ、必要に応じて開発会社に委託する流れが示されています。
出典：IPA「システム開発の健全化に向けて〜「情報システム・モデル取引・契約書」から読み解く〜」
調べる内容の例は次のとおりです。
- 画面・帳票・機能の一覧
- データの種類と量
- ほかのシステムとのつながり
- 実際の業務での使われ方（手作業で補っている部分を含む）
表面だけの調査にしない
普段目にしている画面だけを調べて、裏側の仕組みやつながりを見落とすことに注意が必要です。実際に使っている部署の方にも、早い段階から参加してもらうことが大切です。
オプスインでは、仕様書が残っていないシステムの現状調査や、他社が作ったシステムの引き継ぎについてもご相談を承っています。
提案の依頼から移行までの流れ
この節では、相談してから新しいシステムに切り替わるまでの一般的な流れを示します。
- 1. ヒアリング：リプレースの目的と困りごとを共有する
- 2. 現状調査：前の節の内容を調べる
- 3. 方式の提案：パッケージ・SaaS・個別開発などを比べ、作り直す範囲と移行方法の候補を整理する（詳細は要件定義で具体化する）
- 4. 概算見積り：調査の結果と前提条件をもとに、費用の目安を出す
- 5. 要件定義と見積りの具体化：何を作るかを固め、見積りを更新する
- 6. 開発・テスト
- 7. データ移行・切り替え：移行のリハーサルや、問題が起きたときに元へ戻す手順も確認する
5の要件定義の進め方は、要件定義とはの記事もあわせてご覧ください。
移行の方法の比較
新しいシステムへの切り替え方には、主に次の4つの考え方があります。これらは一つだけを選ぶものではなく、一部の部署で先に試してから段階的に広げる、切り替えの期間だけ新旧を並行して動かす、といった組み合わせもできます。業務を止められる期間や、関わる部署の数を踏まえて検討します。
| 方法 | 内容 | 向いているケース | 注意点 |
|---|---|---|---|
| 一括移行 | 一度にすべて切り替える | 停止できる時間を確保でき、問題が起きたときの影響を管理できる | 不具合が出たときの影響が大きい |
| 段階移行 | 機能や部署ごとに切り替える | 対象の範囲が広い | 全体の期間が長くなる |
| 並行稼働 | 新旧を一定期間、同時に動かす | 停止時間をできるだけ短くしたい、新旧の結果を照らし合わせたい | データの同期や二重入力を防ぐ仕組みが必要で、二重の運用で現場の負担も増える |
| パイロット移行 | 一部の部署で先に試す | 拠点や部署が多い | 全体の完了まで時間がかかる |
見積りは段階ごとに見直す
最初の段階では分からないことが多いため、見積りの精度にも限りがあります。前述のIPAの講演資料では、内容がはっきりした段階で見積もり直す「多段階の見積り」が、発注する側と受注する側の双方のリスクを下げると説明しています。
まずはパッケージやSaaSで済むかを検討する
この節では、すべてを作り直す必要があるとは限らないことを説明します。
経済産業省が2018年に公表したDXレポートは、機能ごとに「作り直す」「追加する」「廃棄する」「そのまま使う」に仕分けることを提案しています。使われていない機能まで作り直す必要はありません。
出典：経済産業省「DXレポート〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜」
パッケージやSaaSは、スクラッチ開発に比べて初期の開発費用を抑えやすいのがメリットです。ただし、導入時の設定やデータ移行、ほかのシステムとの連携には別途費用がかかります。また、アカウント数や利用の規模によっては、ランニングコストが大きくなる場合もあります。利用人数や必要な機能、使い続ける期間によっては、オーダーメイドで開発した方が有利になるケースもあります。ただし、オーダーメイドでも保守・改修やサーバーなどの費用がかかるため、使い続ける間にかかる費用の総額で比べる必要があります。また、機能追加などカスタマイズの自由さがオーダーメイドのメリットです。それらを踏まえてどちらで構築するかを考えましょう。判断が難しい場合は、弊社でもご相談を承っておりますので、ご連絡ください。
良いリプレース提案を見分けるチェックポイント
この節では、開発会社からの提案を比べるときの確認項目を挙げます。
- 現状調査の進め方が具体的に書かれているか
- 「今と同じ」で済ませず、変えること・変えないことを分けているか
- データ移行の計画があるか
- 業務を止められない期間への配慮があるか
- 見積りの前提と、見直すタイミングが書かれているか
- 移行後の保守体制と、ソースコードや資料の受け渡しが明記されているか
データ移行や性能、セキュリティなど、機能以外の要件（非機能要件）の決め方は、「非機能要件とは」の記事で解説しています。
「今と同じ」という要件に注意する
IPAの資料は、新しいシステムの要件を「今と同じ」とだけ決めると、関係者ごとに認識がずれ、後から抜け漏れが見つかると指摘しています。
出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集〜注意すべき7つの落とし穴とその対策〜」、2018年
DXレポートでも、今の仕様が不明確なのに「現行機能保証」（今の機能をすべて保証すること）を求めることを、失敗の例に挙げています。「今と同じでお願いします」と依頼する前に、本当に残す機能はどれかを一緒に確認することが大切です。
社内でリプレースを提案（稟議）するときのポイント
この節では、経営層や上司に説明するときの考え方を紹介します。
DXレポートは、今は問題なく動いているため将来のリスクを説明しにくく、問題が先送りされやすいと指摘しています。だからこそ、感覚ではなく、材料をそろえて伝えることが大切です。
放置した場合のリスクを具体的に示す
「古いから危ない」ではなく、具体的な事実で示します。たとえば、サポート終了日、修正できる人の人数、障害が起きたときに止まる業務などです。
費用対効果を伝える
今の保守にかかっている費用や手間と、新しくした後に変わることを並べて示します。前述の2025年の報告では、刷新が順調な企業ほど、課題だけでなく計画や投資対効果、見積りの情報まで経営層と共有している割合が高い傾向がありました。
概算を出してもらうタイミング
金額の根拠がないと、判断は進みにくくなります。稟議の前に開発会社へ相談し、現状調査を踏まえた概算を出してもらうと、説明の裏付けになります。
「何も決まっていない段階で相談してよいのか」と迷う方もいますが、整理の段階から相談して構いません。弊社オプスインでも、社内で提案する前の段階から、今のシステムの課題や進め方の整理についてご相談に乗っています。
リプレース費用の決まり方
この節では、費用が何によって変わるかを整理します。リプレースの費用は条件によって大きく変わるため、一つの金額では示せません。主に次の要素で決まります。
- 作り直す機能の数と複雑さ
- 移行するデータの量と形式
- ほかのシステムとの連携の数
- 仕様書の有無など、現状調査にかかる手間
- 移行の方法（並行稼働の有無など）
- 移行後の保守の範囲
複数の会社から見積りを取る場合は、前提条件をそろえて比べることが大切です。前提が違えば、金額の差は単純に比べられません。
費用の考え方は、SFA・CRMを例にした「システム開発の費用相場」の記事でも整理しています。
よくある質問
Q. 仕様書がなくても相談できますか？
A. 相談できます。まず今のシステムを調べ、分かったことを資料にまとめるところから始めます。
Q. 今の開発会社と契約中でも相談できますか？
A. 相談できます。ただし、解約できる時期やソースコードの受け渡しの条件は、契約書によって異なります。先に今の契約内容を確認しておくと安心です。
Q. 一部の機能だけ作り直すことはできますか？
A. 選択肢の一つです。機能ごとに仕分けをした結果、作り直す範囲を絞るという判断もあります。
Q. 社内で提案する前の段階でも相談できますか？
A. 相談できます。今のシステムの課題や、進め方の整理からお手伝いします。
まとめ
システムリプレースは、いきなり作り直すのではなく、今のシステムを知るところから始めます。要点は次のとおりです。
- まず現状調査で、今のシステムの仕様や使われ方を把握する
- 機能を仕分けし、パッケージやSaaSで済むかを先に検討する
- 「今と同じ」で済ませず、変えること・変えないことを分ける
- 稟議では、具体的な事実と概算を材料にする
- 開発会社の提案は、調査の進め方と見積りの前提で比べる
リプレースのご相談について
パッケージやSaaSでは賄えない機能や要件がある場合は、スクラッチ開発が選択肢になります。株式会社オプスインでは、仕様書が残っていないシステムの現状調査や、他社が作ったシステムの引き継ぎについてご相談を承っています。社内で提案する前の整理の段階でも構いませんので、お問い合わせフォームからご連絡ください。
