「そろそろ基幹システムを刷新したほうがいい」と経営層から言われたものの、何から手をつければいいか分からず戸惑っていませんか。保守費は年々増え、システムを作ったベンダーのサポートも終わりが見え、当時の担当者はもう社内にいない。「2025年の崖」という言葉も耳にして、自社が手遅れにならないか不安を感じている方も多いはずです。
レガシーシステムの刷新が難しいのは、技術の問題というより「用語と選択肢が多すぎて、発注する側が全体像をつかめない」ことにあります。刷新・更改・マイグレーション・モダナイゼーション、リホスト・リライト・リビルド。専門用語が次々に出てくるうえ、ベンダーごとに言うことが微妙に違い、提案を受けても良し悪しを判断できる自信が持てません。結果として「とりあえずベンダーに丸投げ」になり、想定外の費用と納期、使いにくいシステムが残る——これがレガシーシステム刷新で最も多い失敗のかたちです。
この不安を解消する鍵は、発注者自身が「最低限の地図」を持つことです。すべてを理解する必要はありません。用語の関係、手法の大枠、進め方の流れ、そして発注者が主体的に準備すべきことさえ押さえておけば、ベンダーと対等に話し、提案を評価できるようになります。
本記事では、IT専任ではない発注者の方に向けて、レガシーシステム刷新とは何かを基礎から整理します。紛らわしい用語の違い、なぜ今刷新が必要なのか、刷新手法の3系統、発注者が刷新前にやるべき準備、進め方と費用・期間の目安、そして失敗しないパートナーの選び方まで、「丸投げで失敗しないための地図」を一通り解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
レガシーシステム刷新とは
まず「レガシーシステム刷新とは何か」を、発注者にわかる言葉で整理します。ここがあいまいなまま手法や費用の話に進むと、ベンダーの提案を正しく受け取れなくなります。最初の土台として、レガシーシステムの定義と、刷新まわりの紛らわしい用語の関係を押さえておきましょう。
レガシーシステムとは（老朽化・属人化・ブラックボックス化）
レガシーシステムとは、古い技術や設計のまま長く使われ続け、現在の業務要件や環境に適合しにくくなった既存システムを指します。単に「古いシステム」というだけでなく、次の3つの状態が組み合わさっているのが特徴です。
- 老朽化: ハードウェアやOS、プログラミング言語、ミドルウェアが古く、メーカーのサポート終了が近い、または既に終了している。セキュリティ更新が受けられず、トラブル時の対応も難しくなる
- 属人化: システムを理解している人が特定の担当者やベンダーに偏っている。その人が退職・引退すると、誰もシステムの中身を説明できなくなる
- ブラックボックス化: 長年の改修が積み重なり、仕様書が実態と合っていない、あるいは存在しない。どこを変えると何に影響するのかが分からず、改修も移行も怖くてできない状態
この3つは互いに悪循環を起こします。古くて触れる人が少なくなり（属人化）、ドキュメントも更新されず（ブラックボックス化）、結果として「動いているから触らない」まま老朽化が進む——多くの企業のレガシーシステムはこの状態に陥っています。
そして「刷新」とは、こうしたレガシーシステムを新しい技術基盤や設計に作り替え、保守性・拡張性・安全性を回復させる取り組み全体を指します。後ほど解説するように、刷新の中身は「インフラだけ載せ替える」軽いものから「業務ごと作り直す」大規模なものまで幅があります。まずは「刷新＝古くなったシステムを今の要件に合うかたちに作り替えること」と大づかみに理解しておけば十分です。
「刷新」と「更改・リプレース・マイグレーション・モダナイゼーション」の関係
刷新を調べると、似た言葉が次々に出てきて混乱しがちです。ここで一度、関係を整理しておきましょう。これらは厳密な定義が業界で統一されているわけではなく、文脈によって重なり合って使われます。発注者としては「だいたいどの範囲を指す言葉か」をつかんでおけば十分です。
用語 | 大まかに指す範囲 |
|---|---|
刷新 | 古くなったシステムを今の要件に合うかたちに作り替える取り組み全体を指す広い言葉。以下の手法をまとめて含むことが多い |
更改（こうかい） | 老朽化したシステムを新しいものに入れ替えること。機能はおおむね維持しつつ、基盤を新しくするニュアンスで使われることが多い |
リプレース | 既存システムを別のシステム（パッケージ製品や新規開発）に置き換えること。更改とほぼ同義で使われる場面も多い |
マイグレーション | システムやデータを別の環境へ移行すること。サーバーからクラウドへ、古い言語から新しい言語へ、といった「移し替え」に焦点がある |
モダナイゼーション | レガシーシステムを最新技術で近代化する取り組み全体の総称。刷新とほぼ同じ意味で使われることが多い |
ポイントは、これらの言葉に厳密にこだわる必要はないということです。ベンダーや記事によって「更改」と「リプレース」を同じ意味で使ったり、「モダナイゼーション」を「刷新」の言い換えとして使ったりします。大切なのは、提案を受けたときに「この提案は、既存の機能をそのまま新基盤に載せ替える話なのか、それとも業務の見直しを含めて作り直す話なのか」という中身（スコープ）を確認することです。言葉の定義論争ではなく、何をどこまで変えるのかをベンダーに具体的に聞くことが、認識のズレを防ぎます。
なぜ今レガシーシステムの刷新が必要なのか
刷新は決して小さくない投資です。社内や経営層に「なぜ今やるのか」を説明するには、根拠を持っておく必要があります。ここでは、放置することで膨らむリスクと、国が示している経営インパクト（「2025年の崖」）を、社内説明にそのまま使えるかたちで整理します。
放置で膨らむ4つのリスク
レガシーシステムを「動いているから」と放置すると、次の4つのリスクが時間とともに膨らんでいきます。
- 保守費の増大: 古い技術を維持できる人材が減るほど、保守単価は上がります。部品やライセンスの調達も難しくなり、「使い続けるためのコスト」が新規構築に匹敵するほど膨らむケースもあります
- ベンダー・製品のサポート終了: OSやデータベース、ミドルウェアのサポートが終了すると、セキュリティ更新が止まります。脆弱性が放置され、サイバー攻撃や情報漏洩のリスクが一気に高まります
- 属人化・人材不足による運用停止リスク: システムを理解している担当者の退職・引退で、トラブル対応ができなくなる恐れがあります。古い技術を扱える人材の採用も年々難しくなっています
- DX・データ活用の障壁: レガシーシステムはデータが取り出しにくく、他システムとの連携も困難です。新しい業務の仕組みやデータ分析、AI活用を進めようとしても、足元のシステムがボトルネックになります
重要なのは、これらが「いつか」ではなく「年を追うごとに確実に悪化する」性質を持つことです。先送りするほど、保守費は積み上がり、対応できる人材は減り、刷新そのものの難易度も上がります。つまり「今は動いているから大丈夫」という判断は、将来のリスクとコストを先送りしているに過ぎません。
「2025年の崖」が示す経営インパクト
レガシーシステムの放置リスクを国レベルで警告したのが、経済産業省が2018年9月に公表した「DXレポート」です。このレポートが提示した「2025年の崖」という概念は、社内説明の有力な根拠になります。
DXレポートは、多くの企業で基幹システムの老朽化・複雑化・ブラックボックス化が進んでおり、これを放置したまま2025年を迎えると、最大で年間12兆円（2018年時点の約3倍）の経済損失が生じる可能性があると警告しました。背景には、レガシーシステムを保守する技術者の引退・不足があり、IT人材の不足は2025年には約43万人規模に拡大すると試算されています（出典: 経済産業省「DXレポート ～ITシステム『2025年の崖』克服とDXの本格的な展開～」2018年）。
「2025年の崖」というネーミングから「2025年を過ぎたから関係ない」と捉えてしまいがちですが、これは誤解です。崖は2025年に一斉に訪れる断崖ではなく、レガシーシステムを放置するほど落ちていく傾斜だと考えてください。サポート終了や人材引退は2025年以降も続いており、警告された構造的な問題は今も解消していません。「2025年を過ぎた今だからこそ、先送りしてきた刷新に向き合うべき」というのが、このレポートの本質的なメッセージです。
社内説明では、この一次情報を「不安を煽る材料」ではなく「経営判断の根拠」として使うことをおすすめします。「国がここまで踏み込んで警告している経営課題であり、当社の基幹システムも放置すれば同じリスクを抱える」という位置づけにすれば、刷新を客観的な経営アジェンダとして提示できます。
レガシーシステム刷新の主な手法
ここからは具体的な刷新手法を見ていきます。刷新手法は調べると「7R」など細かい分類が出てきますが、発注者がまず押さえるべきは大枠の3系統です。「軽く速く動かす」「構造を整え直す」「業務ごと作り直す」——この3つの違いと、自社がどれに当てはまりそうかの当たりをつけることが目的です。細かい手法選定はベンダーと詰めればよく、ここでは判断の入口となる地図を提示します。
リホスト系（早く・安く・まず動かす）
リホスト系は、既存のプログラムやアプリケーションをできるだけそのまま、新しいインフラ（多くはクラウド）へ載せ替える手法です。「動いているものを、新しい器に移す」イメージです。
- 目的: 老朽化したハードウェアやOSのサポート終了リスクをまず回避する。インフラの維持コストを下げる
- メリット: 業務ロジックに手を入れないため、3系統の中で最も期間が短く、費用も抑えやすい。リスクも比較的小さい
- 向くケース: とにかくサポート終了が迫っていて時間がない、まずは延命して足元のリスクを下げたい、業務の中身は当面変えなくてよい場合
- 注意点: 古い設計やブラックボックス化はそのまま残るため、保守のしにくさや属人化といった根本問題は解決しません。あくまで「時間を稼ぐ」手法と位置づけるのが現実的です
リライト系（構造を整え保守性を回復する）
リライト系は、業務の機能は維持しつつ、古いプログラミング言語や設計を新しいものに書き換える手法です。中身を整え直すことで、保守性・拡張性を回復させます。
- 目的: ブラックボックス化・属人化を解消し、今後改修・拡張しやすいシステムにする
- メリット: インフラだけでなくソフトウェアの中身が新しくなるため、保守のしやすさが大きく改善する。リホストより根本的な改善が見込める
- 向くケース: 業務の流れ自体は大きく変えたくないが、古い言語のせいで改修できない・人材を確保できないといった構造的な問題を抱えている場合
- 注意点: 既存の仕様を正確に把握できていないと、書き換え時に機能の抜け漏れが起きます。ブラックボックス化が進んだシステムでは、現状把握（仕様の掘り起こし）に相応の労力がかかります
リビルド／リプレース系（業務ごと作り直す）
リビルド／リプレース系は、既存システムにとらわれず、業務そのものを見直したうえでシステムを新規に作り直す（または市販のパッケージ製品に置き換える）手法です。3系統の中で最も大がかりですが、得られる効果も最も大きい手法です。
- 目的: 古い業務のやり方ごと刷新し、DXやデータ活用に対応できる新しい仕組みを手に入れる
- メリット: 現在の業務要件に最適化された、拡張性の高いシステムを構築できる。長年の「とりあえずの改修」で複雑化した業務を整理する好機にもなる
- 向くケース: 業務プロセス自体に課題があり見直したい、既存システムの延命では将来の事業に対応できない、本格的にDXを進めたい場合
- 注意点: 費用・期間・社内負荷が最も大きくなります。要件定義や業務の見直しに発注者側が深く関わる必要があり、丸投げが最も失敗につながりやすい手法でもあります
3系統の比較と選び方の目安
3系統を一覧で比較すると、次のように整理できます。費用・期間はあくまで傾向であり、実際には規模やデータ量で大きく変わる点に注意してください。
系統 | 何をするか | 費用・期間の傾向 | 根本解決の度合い | 主な狙い |
|---|---|---|---|---|
リホスト系 | インフラ（基盤）を新しくする | 小〜中・短期 | 低（延命） | サポート終了回避・時間稼ぎ |
リライト系 | 言語・構造を書き換える | 中・中期 | 中〜高 | 保守性・拡張性の回復 |
リビルド／リプレース系 | 業務ごと作り直す | 大・長期 | 高（抜本） | 業務刷新・DX対応 |
選び方の目安は、「急いで延命したいのか／構造を直したいのか／業務ごと変えたいのか」という目的から逆算することです。多くの企業では、いきなり全面リビルドではなく「まずリホストで時間を稼ぎ、その間に本命の刷新を計画する」「優先度の高い領域からリライト・リビルドを段階的に進める」といった組み合わせが現実的な選択になります。
なお、どの手法を選ぶか（延命・リプレイス・段階移行のどれにするか）は、刷新プロジェクトの成否を分ける重要な意思決定です。自社の状況に当てはめた具体的な判断軸については、より踏み込んだ意思決定フレームを基幹システム刷新の判断フレームワークで詳しく解説しています。
発注者が刷新前にやるべき準備
ここが本記事で最もお伝えしたいパートです。「丸投げして大失敗するのが怖い」という不安の正体は、ベンダーに渡す前の準備が発注者側でできていないことにあります。手法選定やシステム構築はベンダーの仕事ですが、「何を・なぜ・どこから刷新するのか」を決めるのは発注者の役割です。ここを固めずに発注すると、ベンダーは判断材料がないまま進めるしかなく、結果として認識のズレと手戻りが生まれます。刷新を始める前に、発注者側で固めておくべき4つの準備を順に見ていきましょう。
現状の棚卸し（何があり・誰が使い・何に依存しているか）
最初にやるべきは、今あるシステムの「棚卸し」です。ブラックボックス化したシステムでも、発注者が分かる範囲で次の情報を整理しておくだけで、ベンダーとの会話の質が大きく変わります。
- 機能: どんな業務を、どの画面・帳票で処理しているか。よく使う機能と、ほとんど使われていない機能の区別
- データ: どんなデータを保持しているか。過去何年分のデータを引き継ぐ必要があるか
- 依存関係: 他のどのシステムや外部サービスと連携しているか。連携が切れると何が止まるか
- 利用実態: 誰が・いつ・どれくらい使っているか。実は使われていない機能や、逆に業務上欠かせない機能はどれか
完璧な仕様書を作る必要はありません。むしろ「自社では現状をここまでしか把握できていない」という事実を可視化することが目的です。把握できていない部分は、刷新プロジェクトの初期にベンダーと一緒に現状調査として明らかにしていく領域になります。棚卸しは、ベンダーに「丸投げ」ではなく「協働」で進めるための第一歩です。
刷新の目的とゴールを言語化する
次に、「何のために刷新するのか」を言葉にします。これが曖昧だと、ベンダーは何を最適化すればいいか分からず、発注者も提案の良し悪しを判断できません。
たとえば同じ刷新でも、目的が「サポート終了のリスクをとにかく早く回避したい」のか、「将来のデータ活用に備えて拡張しやすい基盤にしたい」のか、「複雑化した業務をこの機会に整理したい」のかで、選ぶべき手法も予算配分もまったく変わります。先ほど紹介した3系統のどれが自社の目的に近いかを考えながら、ゴールを言語化してみてください。
ゴールは「保守費を年間〇割下げる」「サポート終了までに基盤を移行する」「新サービスのデータ連携を可能にする」のように、できるだけ具体的・測定可能なかたちにするのが理想です。完璧でなくてかまいません。「優先したいことの順番」が言語化できていれば、ベンダーとの議論の軸になります。
一度に全部やらない（優先順位と段階化）
レガシーシステム刷新でよくある失敗が、「この機会にすべてを一気に作り直そう」として、費用・期間・社内負荷が膨れ上がり、プロジェクトが頓挫することです。特に中小企業では、一度にすべてを刷新するのではなく、優先度の高い部分から段階的に進める方式が、リスクが低く現実的とされています。
優先順位づけの考え方はシンプルです。「リスクが大きい（サポート終了が迫る・止まると影響が大きい）」かつ「効果が大きい（業務改善やコスト削減につながる）」領域から着手します。逆に、まだ余裕があり影響も小さい領域は後回しにしてかまいません。
段階化のメリットは、一度の投資額を抑えられるだけでなく、最初の段階で得た学びを次の段階に活かせること、そして途中で方針を見直せる柔軟性が残ることです。「全部を完璧に一度で」ではなく「重要なところから着実に」が、刷新を成功させる現実的な進め方です。
社内体制・キーパーソンを確保する
最後に、刷新を社内で推進する体制を用意します。これがないまま発注すると、ベンダーからの質問に誰も答えられず、意思決定が滞り、プロジェクトが停滞します。
- 意思決定者: 予算や方針を決められる責任者を明確にする。現場任せにすると、要件がまとまらず手戻りが増える
- 業務を理解しているキーパーソン: 各業務の「実態」を説明できる現場担当者を巻き込む。仕様書にない暗黙のルールを知っているのは現場です
- 窓口担当: ベンダーとの日常的なやり取りを担う担当者。質問への回答や社内調整のハブになる
刷新は「ベンダーに任せる仕事」ではなく「ベンダーと一緒に進める仕事」です。発注者側に主体的に関わる人がいてはじめて、現場で本当に使えるシステムが生まれます。逆に言えば、この体制づくりこそが「丸投げによる失敗」を防ぐ最大の防波堤になります。
レガシーシステム刷新の進め方と費用・期間の目安
準備が整ったら、実際の刷新プロジェクトはどう進むのでしょうか。ここでは、プロジェクトの基本的な流れを発注者目線で俯瞰し、各段階で発注者が関与すべきポイントを示します。あわせて、最も気になる費用・期間の目安と、その金額を左右する要因を整理します。
刷新プロジェクトの基本的な流れ
刷新プロジェクトは、手法によって細部は変わりますが、おおむね次の流れで進みます。発注者が特に深く関わるべき段階を意識しながら読んでみてください。
- 構想・現状調査: 刷新の目的を確認し、現状システムを調査する。発注者は棚卸し結果を共有し、業務の実態を伝える役割を担う（関与度: 高）
- 要件定義: 新システムに求める機能・性能・移行範囲を決める。刷新の成否を最も左右する段階で、発注者の意思決定が不可欠（関与度: 最も高い）
- 方式選定・設計: リホスト・リライト・リビルドなどの手法と、具体的なシステム構成を決める。発注者は提案を評価し、判断する（関与度: 中〜高）
- 開発・データ移行準備: ベンダーが構築を進める。発注者は進捗確認と、随時の確認事項への回答を担う（関与度: 中）
- テスト: 新システムが要件どおり動くかを検証する。発注者は実際の業務目線での受け入れテストに関わる（関与度: 高）
- 本番移行（カットオーバー）: 新システムへ切り替える。データ移行や旧システムとの並行稼働の判断など、慎重な計画が必要（関与度: 高）
この流れの中で発注者が最も力を入れるべきは、上流の要件定義です。ここでの決定が後工程すべてに影響し、要件があいまいなまま進むと、手戻りや追加費用の最大の原因になります。本番移行（カットオーバー）を含む刷新プロジェクトの具体的な手順については、レガシーシステムの改善方法を実践的に解説で詳しく解説しています。
費用・期間の目安と変動要因
費用と期間は、手法と規模によって大きく変わります。一律の相場を示すのは難しいですが、目安のレンジを知っておくと、ベンダー提案の妥当性を判断する手がかりになります。
公開されている各社の情報を総合すると、刷新の費用は手法・規模により数百万円から数億円規模まで幅があります。単一の業務システムであれば数千万円規模、基幹システム全体の刷新となると1億円を超える規模になることも珍しくありません。期間も、中小企業の比較的小規模な刷新で半年〜1年程度、大企業の大規模な刷新では2〜3年に及ぶケースがあります（出典: 各社公開情報の総合）。
これらの金額・期間を大きく左右するのは、次の要因です。
- システムの規模・複雑さ: 機能数や画面数、連携先の多さに比例して費用・期間が増えます
- 移行するデータの量と質: 過去データの引き継ぎ範囲が広く、データの整理が必要なほど、移行の負荷が上がります
- 並行稼働の要否: 旧システムを止められず、新旧を一定期間並行稼働させる場合、その分のコストと管理工数がかかります
- 業務見直しの範囲: リビルド系のように業務プロセスから見直す場合、要件定義の負荷が大きくなります
重要なのは、金額の数字だけで提案を比較しないことです。安い提案が「延命だけのリホスト」で、高い提案が「業務見直しを含むリビルド」なら、そもそも比べる対象が違います。先に自社の目的とゴールを固めておけば（前述の準備）、「この金額は何に対する対価か」を正しく評価できるようになります。
補助金・公的支援の活用も検討する
刷新は大きな投資ですが、中小企業向けには公的な支援制度を活用できる可能性があります。代表的なものに、業務効率化やDXに資するITツール導入を支援する「デジタル化・AI導入補助金（旧IT導入補助金）」などがあります。制度の対象範囲・補助率・公募時期は年度ごとに変わるため、刷新を計画する際は最新の公募要領を確認し、自社の刷新内容が対象になるかをベンダーや専門家に相談するとよいでしょう。
補助金はあくまで費用の一部を軽減する手段であり、補助金ありきで刷新内容を決めるのは本末転倒です。「自社にとって必要な刷新」を先に固めたうえで、活用できる支援制度がないかを確認する、という順番をおすすめします。
刷新を成功させる開発パートナーの選び方
最後は、丸投げ回避の最後のピース——開発パートナー（ベンダー）の選び方です。ここまで準備を固めても、伴走してくれるパートナーを見極められなければ刷新は成功しません。逆に、良いパートナーと出会えれば、発注者の不足を補いながら一緒にプロジェクトを前に進められます。技術力だけで選ばない視点と、提案を評価するチェック観点を押さえておきましょう。
技術力だけで選ばない（業務理解・移行実績・伴走姿勢）
ベンダー選びというと「技術力が高いか」に目が行きがちですが、レガシーシステム刷新では技術力と同じくらい、次の観点が重要です。
- 業務理解: こちらの業務を理解しようとする姿勢があるか。技術の話ばかりで、業務の実態をヒアリングしようとしないベンダーは、現場で使えないシステムを作りがちです
- 移行・刷新の実績: 新規開発と刷新は別物です。レガシーシステムからの移行や、ブラックボックス化したシステムの現状調査に慣れているかは、大きな差になります
- 伴走姿勢: 発注者の知識不足を前提に、分からないことを噛み砕いて説明し、一緒に決めていく姿勢があるか。専門用語で煙に巻くベンダーは、後々の認識のズレを生みます
刷新は数か月から数年に及ぶ長い取り組みです。短期間の発注先というより、長く付き合うパートナーを選ぶつもりで評価することをおすすめします。
提案を評価するチェック観点
複数のベンダーから提案を受けたとき、発注者として次の観点をチェックすると、提案の質を見極めやすくなります。
- 目的・ゴールを正しく踏まえているか: こちらが伝えた目的に沿った提案になっているか。自社の得意な手法に無理やり寄せていないか
- 手法とその理由が説明されているか: なぜリホスト／リライト／リビルドを選んだのか、理由が腹落ちするかたちで説明されているか
- 現状把握・リスクへの言及があるか: ブラックボックス化や移行リスクに触れ、どう対処するかが示されているか。リスクに一切触れない提案はむしろ要注意です
- 費用の内訳が示されているか: 総額だけでなく、何にいくらかかるのかが分解されているか。追加費用が発生する条件が明示されているか
- 要件変更への柔軟性があるか: 進めながら要件が変わることを前提に、変更にどう対応するかの考え方が示されているか
- コミュニケーションの取りやすさ: 質問への回答が分かりやすく、レスポンスが誠実か。提案段階の対応は、プロジェクト中の対応の予兆です
これらの観点でチェックすれば、「金額の安さ」や「技術用語の華やかさ」だけに惑わされず、自社の刷新を本当に成功に導けるパートナーを選べます。提案を評価する目を持つこと自体が、「丸投げによる失敗」を遠ざける最後の備えになります。
よくある質問
レガシーシステム刷新について、発注者からよく寄せられる疑問をまとめました。
Q. 刷新と更改・リプレースの違いは何ですか？
A. 厳密な定義は業界で統一されておらず、重なり合って使われます。「刷新」は古いシステムを作り替える取り組み全体を指す広い言葉で、「更改」「リプレース」はその中で「老朽化したものを新しいものに入れ替える」ニュアンスで使われることが多い言葉です。言葉の定義にこだわるより、「既存機能をそのまま載せ替えるのか、業務見直しを含めて作り直すのか」という中身をベンダーに確認するのが実務上は重要です。
Q. リホスト・リライト・リビルドの違いは何ですか？
A. リホストは「インフラ（基盤）だけを新しくする」延命寄りの手法、リライトは「言語・構造を書き換えて保守性を回復する」手法、リビルドは「業務ごと作り直す」抜本的な手法です。費用・期間・効果はリホスト＜リライト＜リビルドの順に大きくなります。詳しくは本記事の「レガシーシステム刷新の主な手法」をご覧ください。
Q. 費用はどれくらいかかりますか？
A. 手法と規模で大きく変わり、単一業務システムで数千万円規模、基幹システム全体で1億円を超える規模になることもあります。金額の数字だけで比較せず、「その金額が何に対する対価か（延命なのか抜本刷新なのか）」を見極めることが大切です。
Q. 全面刷新せずにDXやAI活用を進めることはできますか？
A. できる場合があります。レガシーシステムを全面的に作り直さなくても、既存システムとデータ連携する仕組みを足すことで、データ活用やAI活用を段階的に進めるアプローチも選択肢になります。自社の状況によって最適解は変わるため、全面刷新と部分的な連携の両面から検討することをおすすめします（レガシーシステムを全面刷新せずにAIと連携する具体的な手法については、レガシーシステムのAI連携完全ガイドをご参照ください）。
Q. 何から始めればよいですか？
A. まずは「現状の棚卸し」と「刷新の目的の言語化」から始めてください。ベンダーに相談する前に、今あるシステムで何ができているか・誰が使っているか、そして何のために刷新したいのかを発注者側で整理しておくと、その後のベンダー選定や提案評価がぐっとスムーズになります。詳しくは本記事の「発注者が刷新前にやるべき準備」をご覧ください。
レガシーシステムの刷新は、用語と選択肢の多さに圧倒されがちですが、発注者が持つべき地図はシンプルです。レガシー化の正体を理解し、なぜ今やるのかを根拠を持って説明できるようにし、手法を3系統で大づかみにし、発注前に棚卸しと目的の言語化を済ませる。あとは進め方の流れと費用の見方を知り、伴走してくれるパートナーを選ぶ目を持つ——この順番で進めれば、「丸投げによる失敗」は十分に避けられます。まずは自社システムの棚卸しという、今日からできる一歩から始めてみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
