レガシーシステム刷新を外注する進め方【2026年版】4つのアプローチ・現状把握・段階移行・体制

「20年動いている基幹システムを作り替えたいが、仕様書もなければ分かる人もいない。この状態で外注できるのか」——レガシーシステムの刷新を検討している方から、こうした相談をよく受けます。動いているものを触るのは怖い、しかし保守期限も担当者の退職も待ってくれない。見積もりを取ろうにも、何を作りたいのか自社でも説明できない。まずここで足が止まります。

結論から言うと、外注できます。ただし順番があります。最初に決めるのは「どこに頼むか」ではなく、「どのアプローチで刷新するか」「どこまで自社で調べてから出すか」「どの順番で移行するか」の3つです。刷新のアプローチはリホスト、リライト、リビルド、リプレース(パッケージ・SaaSへの置き換え)の4つで、1つに統一せず機能ごとに組み合わせるのが実務です。そして最初に発注すべきは実装ではなく、ブラックボックス化した現行システムの現状把握です。

この順番を守れば、数千万円から数億円という投資を一度に賭ける必要がなくなります。現状把握で全体像が見えれば見積もりの精度が上がり、機能単位で移していけば失敗したときの影響も局所で止まります。逆に、現行の中身が分からないまま実装を発注すれば、見積もりは不確実性を織り込んで膨らみ、途中で想定外の依存関係が出てスコープが崩れる。これが失敗のもとです。

本記事では、刷新の4つのアプローチと選び方、ブラックボックス化した既存システムの現状把握、段階移行(ストラングラーパターン)と一括移行・データ移行・並行稼働、外注先と体制の作り方(既存ベンダーとの関係、要員確保、古い技術と新技術の橋渡し)、よくある質問の順に解説します。アプローチ比較と移行方式の対比は、そのまま社内の稟議資料に転記できる表にしました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。ERPのプライム案件を上流から下流まで担当した経験から言えるのは、既存システムの作り替えで本当に時間がかかるのは、コードを書く工程ではなく、画面と帳票と現場の記憶から仕様を組み立て直す工程だということです。この記事を読み終えるころには、自社がどのアプローチで、どこから外注すればよいかが判断できるはずです。

レガシーシステム刷新の4つのアプローチ——リホスト、リライト、リビルド、リプレースの違いと選び方

レガシーシステムの刷新と聞くと「一から作り直す」を思い浮かべる方が多いのですが、実際の選択肢は4つあります。リホスト(そのまま新しい基盤へ載せ替える)、リライト(同じ機能を新しい言語や構造で書き直す)、リビルド(業務ごと設計し直して作り直す)、リプレース(市販のパッケージやSaaSに置き換える)です。費用も期間もリスクも、そして刷新後に何が残るかも大きく異なります。外注先を探す前に、自社がどれを選ぶのかを決めてください。ここが決まっていないまま相談すると、その会社が得意な手法に寄った提案が返ってくるだけになります。

4つのアプローチの比較表(内容・費用と期間の目安・向くケース・残る課題)

費用の傾向は、当社が受けてきた刷新案件の相談内容に基づく整理です。手法別の金額・期間について、公的統計や業界団体の一次調査は確認できませんでした。実額は規模と現行システムの複雑さで大きく振れるため、現行調査を先に発注し、その結果をもとに見積もりを取ってください。要件定義と業務棚卸しの工数、および想定外の発覚に備えたバッファを、最初から予算に組み込んでおくことをおすすめします。

より細かい分類として、AWSが公開しているクラウド移行の「7 Rs」があります。Retire(廃止)、Retain(現状維持)、Rehost(リフト&シフト)、Relocate(プラットフォームごと移設)、Repurchase(製品ごと買い替え)、Replatform(一部最適化して移行)、Refactor / Re-architect(クラウドネイティブに作り替え)の7つです(出典: AWS Prescriptive Guidance「About the migration strategies」2026年9月21日確認)。ただし、社内の合意形成の場では7つは多すぎます。まず上の4つで方針を決め、必要に応じて細分化するほうが話が前に進みます。

選び方の軸は「業務価値」と「技術的負債の深さ」——1つに統一せず機能ごとに組み合わせる

4つから1つを選ぼうとすると決まりません。判断は2つの軸で行います。1つ目は業務価値、つまりその機能が自社の競争力に直結しているかどうか。2つ目は技術的負債の深さ、つまり改修のたびに想定外の不具合が出るか、読める人がいるかどうかです。

業務価値が高く負債も深い領域はリビルドの対象です。ここは費用をかけて作り直す価値があります。業務価値が低く負債が深い領域は、リプレースで市販品に寄せるか、使われていないなら思い切って廃止します。業務価値が高いのに負債が浅い領域は、急いで触る必要はありません。そして負債は深いが業務価値が低く、かつ止められない領域は、リホストで基盤だけ延命し、後回しにします。

重要なのは、システム全体を1つのアプローチで塗りつぶさないことです。販売管理はリプレース、原価計算はリビルド、周辺の帳票出力はリホスト、使われていない機能は廃止、という組み合わせが実務では普通です。全社一括で作り直す前提に立つと、費用が跳ね上がり、合意も取れなくなります。

リプレース(パッケージ・SaaS移行)を選べるかは「自社固有の業務がどれだけあるか」で決まる

最も費用対効果が高いのはリプレースです。作らずに済むなら、それに越したことはありません。判断の基準は単純で、現行システムの機能のうち、他社と違うやり方をしている部分がどれだけあるかです。

私はERPのプライム案件を上流から下流まで担当したことがありますが、パッケージ導入がうまくいかない典型は、現行システムの画面と帳票をそのまま再現しようとするケースです。標準機能から外れた要求を積み上げると、カスタマイズ費用がスクラッチ開発を上回ることさえあります。逆に、業務のほうを製品の型に合わせられるなら、導入も運用も安定します。「業務を変えられるか」は技術ではなく経営の判断で、ここを曖昧にしたまま製品選定に入るのが失敗のもとです。

「2025年の崖」を根拠にしない——判断の期限は自社の保守期限・要員・法改正にある

刷新の必要性を説明するとき、多くの資料が「2025年の崖」を引用します。経済産業省が2018年に公表した「DXレポート」で、レガシーシステムの課題が解決されない場合、2025年以降に年間最大12兆円の経済損失が生じる可能性があると指摘したものです。あくまで当時の前提に基づく試算であり、断定された予測ではない点には注意してください。

2026年現在、この年を根拠に稟議を通すのは説得力を欠きます。代わりに使うべきなのは、自社に実在する期限です。ハードウェアやOSのサポート終了日、現行システムを理解している担当者の定年、法改正への対応可否、この3つはいずれも日付が特定でき、対応しなかった場合の損失も試算できます。経営層は「投資」より「損失回避」のほうが判断しやすいため、やらなかった場合に起きることを数字で示すほうが通ります。

アプローチの方針が決まったら、次は見積もりを取る番——ではありません。その前に、現行システムの中身を明らかにする工程が要ります。次章で詳しく説明します。

ブラックボックス化した既存システムの現状把握——外注の第一歩は「作る」ではなく「調べる」

「仕様書がないから外注できない」という相談をよく受けますが、これは順番が逆です。仕様書がないことは外注できない理由ではなく、最初に外注すべき対象です。現行システムの中身が分からないまま実装の見積もりを取れば、開発会社は不確実性を価格に上乗せせざるを得ず、金額は膨らみます。しかも着手後に想定外の依存関係が見つかれば、スコープも予算も崩れます。まず調べる、という工程を独立させることが、刷新の外注で最も効く準備です。

現状把握で洗い出す8項目(構成・連携・バッチ・データ・帳票・権限・非機能・運用)

現状把握では、次の8項目を漏れなく洗い出します。ここで作った資料が、そのまま提案依頼書(RFP)の現行システム情報の章になります。

この中で見落とされやすいのは4と5です。データの表記ゆれや重複は移行時に必ず問題になりますし、「使われていない画面」を洗い出せると、作り直す範囲そのものを減らせます。稼働しているからといって、すべてを移す必要はありません。

ドキュメントがない場合の進め方——コードリーディング、画面と帳票からの仕様の再構築、現場ヒアリング

設計書が存在しない、あるいは最終更新が10年以上前という状況は珍しくありません。その場合は3つの手がかりを組み合わせます。

1つ目はコードリーディングです。ソースコードの静的解析ツールを使えば、モジュール間の呼び出し関係、デッドコード、循環参照といった構造を機械的に可視化できます。近年は生成AIによる解析で、この工程の工数が下がってきました。ただし、コードから分かるのは「何をしているか」であって、「なぜそうしているか」ではありません。

2つ目は、画面と帳票からの仕様の再構築です。実際に動いているシステムの画面を1つずつ操作し、入力項目、バリデーション、遷移、出力される帳票を記録していきます。地味な作業ですが、利用者の視点で見た仕様がここで揃います。

3つ目は現場ヒアリングです。「この項目は空欄でも登録できるが、空欄にすると月次で弾かれる」といった暗黙のルールは、コードにも帳票にも表れず、担当者の頭の中にしかありません。私はERPのプライム案件を上流から下流まで担当しましたが、既存システムの作り替えで本当に時間がかかるのは、コードを書く工程ではなく、この3つを突き合わせて仕様を組み立て直す工程です。当社が日本人PMによる設計レビューを標準の工程に入れているのも、ここで拾い漏らした前提が後工程で表面化するからです。

現状把握そのものを1フェーズとして発注する——準委任で調査だけを切り出す発注設計

現状把握は、成果物を先に定義できない仕事です。何が出てくるか分からないものに完成責任を負わせる契約は成立しないため、準委任契約で期間と体制を決めて発注します。請負で一括発注しようとすると、開発会社はリスクを織り込んで高い見積もりを出すか、調査範囲を限定してくるかのどちらかになります。契約形態の違いは「準委任 請負 違い」の記事で整理しています。

調査フェーズの成果物は、現行システム構成図、業務フロー図、機能一覧と利用状況、データ定義とデータ品質の所見、移行時のリスク一覧、そして刷新アプローチの推奨と概算費用です。ここまで揃えば、複数の会社に同じ条件で見積もりを依頼でき、提案の比較が成り立ちます。調査に費用をかけることを「まだ何も作っていないのに」と言われがちですが、実際には最も回収率の高い投資です。現状把握を飛ばして本体を発注し、途中で作り直しになった案件のほうが、はるかに高くつきます。

段階移行(ストラングラーパターン)と一括移行——データ移行、テスト、並行稼働の設計

アプローチと現状把握が固まったら、次は「どう移すか」です。ここで選ぶのは、ある日を境に新システムへ一斉に切り替える一括移行(ビッグバン)か、機能単位で少しずつ置き換える段階移行かの2択になります。基幹システムの刷新で大きな事故が起きるのは、ほぼこの選択を誤ったときです。工数だけを見れば一括移行のほうが小さく見えますが、比べるべきは工数ではなく、失敗したときに何が起きるかです。

一括移行(ビッグバン)と段階移行の対比表——止められない基幹システムは段階移行が原則

止められない基幹系では、全面一括ではなく機能単位で新旧を並行稼働させる段階的置き換えがリスクを最小化する定石です。Martin Fowlerが提唱したストラングラーフィグ・パターンも、「小さな追加から始めて、段階的に古いコードベースから新しいコードベースへ挙動を移す」ことで、全面置換に比べてリスクと投資を段階的に可視化できると説明しています(出典: martinfowler.com「Strangler Fig Application」2026年9月21日確認)。当社が相談を受ける案件でも、店舗系や生産系のように業務を止められない領域は、例外なく段階移行を前提に計画しています。

ストラングラーパターンの進め方——外周の機能から新システムに寄せ、コアを最後に残す

段階移行の代表的な設計が、ストラングラーパターン(Strangler Fig Application)です。Martin Fowlerが提唱した考え方で、既存システムの前に新旧を振り分ける層を置き、移行済みの機能へのアクセスは新システムへ、未移行の機能は既存システムへ流します。移行が進むにつれて既存システムの役割が細っていき、最後に残ったコアを置き換えて終わります。

進める順番は、外周から中心へです。第1弾は、他機能への影響が小さく、効果が見えやすい領域を選びます。帳票出力、参照系の画面、周辺業務のワークフローなどが該当します。ここで移行の手順、テストの型、切替の判断基準を確立し、チームに経験を溜めます。第2弾以降で受発注や在庫といった中核業務に入り、最も依存関係が多い会計や原価の領域を最後に残します。

順番を決めるときの判断材料は、現状把握で作った機能一覧と利用状況です。「使われていない機能は移さず廃止する」という判断も、この段階で効いてきます。

データ移行とテスト——クレンジング、本番相当データでの検証、差分の自動チェック

移行で最も工数が読みにくいのがデータです。長年運用されたシステムには、表記ゆれ、重複、廃止された区分値、想定外の桁あふれが必ず残っています。これを新システムの構造に合わせて整えるクレンジングは、現状把握の段階で件数を掴んでおかないと、後から一気に工数が膨らみます。

テストでは、個人情報をマスキングした本番相当のデータを使います。テスト用に作った綺麗なデータでは、現実に存在する異常値を検出できません。加えて、新旧システムに同じ入力を流し、出力の差分を自動で突き合わせる仕組みを移行の早い段階で用意します。手作業で目視照合すると、並行稼働の期間中ずっと人手を取られます。当社ではGitのプルリクエストによるコードレビューとリリース前のダブルチェックを標準の工程にしていますが、移行案件ではこれに加えて差分チェックの自動化を最初のスプリントで作るようにしています。

並行稼働の期間と切替の客観基準——感覚ではなく整合率と差分件数で決める

並行稼働は、新旧のシステムを一定期間同時に動かし、同じ入力に対して同じ結果が出ることを確認しながら業務を新システムへ寄せていく方法です。期間は、対象業務の重要度と、締めサイクルをどこまで確認する必要があるかで決まります。ただし並行稼働中は現場の入力作業が二重になるため、繁忙期を外して計画することが前提になります。

切替の可否は、感覚ではなく数値で決めてください。見るべき指標は2つです。新旧システムで突き合わせた件数と金額の整合率、そして差分件数がゼロである連続営業日数。この2つをどの水準で何日分満たせば切り替えるのかを、並行稼働を始める前に発注側と開発会社で合意しておきます。日数は、対象業務の締めサイクル(日次・週次・月次)を最低1周できる長さを起点に決めてください。基準に達しなければ延長する、という取り決めも同時に置いておきます。ここまで決めておけば、責任者の勘や関係者の空気に左右されずに判断できます。

ここまでが移行計画の骨格です。では、この計画を誰と、どんな契約で進めるのか。移行期には新旧2系統を同時に面倒を見る要員が要りますが、その要員を数年にわたって確保できる体制を、あなたの会社は用意できているでしょうか。

外注先と体制の作り方——既存ベンダーとの関係、要員確保、古い技術と新技術の橋渡し

レガシー刷新の外注が新規開発の外注と決定的に違うのは、現行システムを保守している会社が必ず存在することと、移行期に新旧2系統を同時に見る必要があることの2点です。この2つが、会社選びと契約形態、そして要員の確保の仕方を規定します。数年にわたって続く取り組みなので、単発の請負で切り取るより、長く続けられる体制をどう組むかが実際の課題になります。

既存ベンダーを続けるか、乗り換えるか——判断の4つの分かれ目と、乗り換え時に発注側へ残る手間

まず決めるのは、現行を保守している会社に刷新も任せるかどうかです。判断は4つの点で分かれます。

第1に、現行システムの調査を提案書に明示できるかどうか。「現状分析にこれだけの工数をかける」と書ける会社は、分からないことを分からないと言える会社です。安さだけを訴えて現行調査に触れない提案は要注意です。第2に、刷新の実績を移行の中身まで説明できるかどうか。実績の社数ではなく、どの方式で移し、並行稼働をどう設計したかを聞きます。第3に、刷新後の保守体制と費用。刷新は作って終わりではなく、稼働後も毎年の保守費が発生します。初期の開発費だけで比べず、保守を含めた数年分の総額で比較してください。第4に、同じ状態に戻さない仕組み。設計書とテストコードを納品物に含める、コードレビューの記録を残す、といった条項を契約に入れられるかです。

乗り換える場合、発注側に残る手間は正直に見積もってください。現行ベンダーからの情報提供は契約上の義務ではないことが多く、協力が得られないまま調査を進める前提で計画を立てる必要があります。既存ベンダーとの関係整理の具体的な進め方は「開発会社 乗り換え」の記事で扱っています。

外注範囲と契約形態の対応表——フェーズごとに請負と準委任を使い分ける

レガシー刷新では、全工程を1つの契約で括らず、フェーズごとに契約形態を変えるのが実務上の定石です。

請負と準委任を取り違えると、リスクが一方に偏ります。要件が流動的な工程に請負を当てれば見積もりに不確実性が上乗せされ、逆に要件が固まった工程に準委任を当てれば品質の担保が発注側の責任になります。

要員確保とCOBOLなど古い技術の橋渡し——読める人と作れる人を同じチームに置く

刷新プロジェクトの体制で最も詰まるのが要員です。COBOLやメインフレームのアセンブラを読める技術者は年々減り、新しい技術で書ける若手はレガシーを読みたがりません。この断絶を「橋渡しできる人を探す」で解こうとすると、まず見つかりません。

現実的な解は、読める人と作れる人を同じチームに置き、仕様の受け渡しを日々の作業にすることです。現行の担当者(社内でもベンダーでも)が仕様を言語化し、新システムの開発者がその場で質問して詰める。週次のまとめて確認ではなく、日々のやり取りにできるかどうかで、仕様の取りこぼしが変わります。そのためには、開発チームが発注側と同じリズムで動く継続的な体制が要ります。丸投げしてまとめて納品を受ける形では、この橋渡しは成立しません。

当社の位置づけ: ラボ型(準委任)で長期・段階的に進める

当社TALENTBASE VIETNAMは、ホーチミンを拠点にベトナムオフショア開発の体制を提供しています。レガシー刷新の文脈での位置づけは、上流の全工程を代行するコンサルティング会社ではなく、方針が決まった後の実装・移行・保守を長く担う体制の提供です。

提供の形はラボ型(準委任)で、専属チームを月額固定で確保し、優先順位を見直しながら継続的に開発を進めます。段階移行のように数年かけて少しずつ置き換えていく取り組みとは相性がよく、実績としても、新規開発から週次の保守へ移行した決済アプリや、介護記録SaaS「CareViewer」のように要件が動き続ける開発を週次の優先順位判断で回している案件があります。CareViewerでは日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、従来の半分以下のコストで継続開発を進めています。システムの改修・保守の受け皿としての使い方は「システム改修・保守 外注」の記事でも詳しく扱っています。

体制の特徴は3点です。1つ目は日本人PMをフロントに置くパターンAを推奨していること。仕様の言語化と設計レビューを日本語で巻き取れるため、前述の「橋渡し」が日々のやり取りとして成立します。2つ目は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインすること。協力会社を挟まないため仲介マージンがかからず、必要な技術の人財を指名して集められます。3つ目は単価を公開していることです。実務3年目安で1,500USD(約22.5万円)、5年で2,000USD(約30万円)、10年相当・ブリッジSEで3,000USD(約45万円)、1USD=150円換算の目安です。最小構成は日本人PMフロント+2〜3人月で月額約80万円からで、1名から契約でき、増員は約1週間、縮小と交代は1か月単位で調整できます。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

向く案件と向かない案件も書いておきます。向くのは、方針が決まったオープン系の実装、段階移行の第2弾以降の継続開発、移行後の改修・保守、そして予算を平準化しながら数年かけて進めたい案件です。向かないのは、メインフレームの一括マイグレーションのように専用ツールと重厚な体制が要る領域、現行ベンダーとの交渉や社内合意形成まで含めた上流の全面代行、そして半年で全社一括切替を完了させたい案件です。これらは国内の大手システムインテグレーターやマイグレーション専業のベンダーのほうが適しており、当社に相談いただいてもその旨をお伝えしています。

レガシーシステム刷新の外注でよくある質問

レガシー刷新の外注について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内での検討や稟議の説明にもお使いください。

Q1. 刷新には何年かかりますか?

アプローチと範囲で変わります。基盤だけを移すリホストと、業務ごと作り直すリビルドとでは期間の桁が変わりますが、手法別の標準期間を示した一次調査は確認できていないため、本稿では具体的な月数を示しません。現行調査の結果をもとに、外注先に自社の規模での期間を出してもらってください。段階移行を選ぶ場合は、第1弾の効果を半年以内に出せる計画にすることをおすすめします。期間の長さより、最初の成果をいつ出せるかで計画を組んでください。

Q2. 仕様書がなくても外注できますか?

できます。むしろ、仕様書がない状態で最初に発注すべきなのが現状把握です。ソースコードの静的解析、画面と帳票からの仕様の再構築、現場ヒアリングの3つを組み合わせ、現行構成図・機能一覧・データ定義・リスク一覧を作ります。これは準委任契約で期間と体制を決めて発注する工程で、その成果物をもとに実装の見積もりを取り直すのが順番です。

Q3. 既存ベンダーに知られずに検討を進められますか?

検討と現状把握の初期段階までは可能です。ただし、本番環境の情報やソースコードの提供が必要になる段階で、現行ベンダーの協力の有無が計画を左右します。協力が得られない前提で調査工数を多めに見積もり、契約上どこまでの情報を自社が受け取れるかを先に確認しておくと、後戻りが減ります。

Q4. オフショア開発で基幹システムの刷新はできますか?

範囲を分けて考えてください。現状把握、方式の決定、現場との合意形成といった上流は、日本側で日本語を使って進めるほうが確実です。一方、方針が固まった後の実装、移行ツールの作成、テスト、移行後の保守は、継続的な体制を組めるオフショアが適しています。当社の場合は日本人PMをフロントに置き、日本語N1〜N2相当を含む2,000名以上の人財データベースから直接アサインすることで、この分担を成立させています。

Q5. 費用を抑えるなら、どの順番で進めるのがよいですか?

作らずに済む部分を先に切り分けることです。順番としては、使われていない機能の廃止、市販のパッケージやSaaSに置き換えられる領域のリプレース、基盤だけ移して延命する領域のリホスト、そして最後に自社の競争力に直結する領域だけをリビルドする、という並びになります。全社を一度に作り直す前提を外し、機能ごとにアプローチを組み合わせて投資を平準化すること。

まとめ: アプローチを選び、現状把握から発注し、段階的に移す——外注先は現行調査を提案に書ける会社を

レガシーシステムの刷新を外注するときの順番は、アプローチの決定、現状把握、移行方式の設計、体制づくりの4つです。アプローチはリホスト、リライト、リビルド、リプレース(パッケージ・SaaS移行)の4つで、業務価値と技術的負債の深さの2軸で判断し、1つに統一せず機能ごとに組み合わせます。全社を一度に作り直す前提を外すだけで、費用も合意形成の難しさも下がります。

最初に発注すべきは実装ではなく、ブラックボックス化した現行システムの現状把握です。構成・連携・バッチ・データ・帳票・権限・非機能・運用の8項目を洗い出し、設計書がなければコードリーディング、画面と帳票からの仕様の再構築、現場ヒアリングの3つを組み合わせます。この工程は成果物を先に定義できないため、準委任で切り出して発注します。移行は、止められない基幹システムなら段階移行(ストラングラーパターン)が原則で、外周の機能から寄せてコアを最後に残し、並行稼働の切替は、整合率と差分件数を何日連続で満たすかという数値の基準を事前に合意したうえで判断します。

外注先は、現行調査に工数をかけると提案書に明示できる会社を選んでください。フェーズごとに請負と準委任を使い分け、読める人と作れる人を同じチームに置けるかどうかが、古い技術と新技術の橋渡しを成立させます。当社は方針が決まった後の実装・移行・保守を、ラボ型(準委任)の継続的な体制で担う立場です。日本人PMをフロントに置き、2,000名以上のIT人財データベースから直接アサインし、1名から・増員約1週間・縮小と交代は1か月単位で調整できます。一方で、メインフレームの一括マイグレーションや上流の全面代行は当社の守備範囲ではありません。移行後の改修・保守の進め方はシステム改修・開発保守の外注、既存ベンダーとの関係整理は開発会社の乗り換えと引き継ぎもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、どのアプローチが合うかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。