Service 11
システムリプレイス
AI駆動開発で、現行仕様の復元から段階移行まで
OUR APPROACH
システムリプレイスに対するARCHECOの考え方
システムリプレイス（いま動いている業務システムを新しい仕組みに置き換える取り組み）について、ARCHECOがどう考えているかは、基幹システムを段階的に作り直した開発記録の変更履歴にいちばんはっきり表れています。その記録はブログ記事「システムリプレイスの進め方」に書きました。このページでは要点だけをまとめ、さらに詳しく知りたい方はページ末尾のリンクから記事をご覧いただけます。
システムリプレイスの見積もりを膨らませているのは新機能ではなく、現行と同じ動きを調べ、移し、同じ結果になると保証する工数です。
システムリプレイスの見積もりを取ると、新しい機能を頼んだわけではないのに、想定より大きな金額が返ってくることがあります。費用の大半が、現行と同じ動きの再現に使われるからです。画面、権限、計算ロジック、通知、例外処理を作り直すため、利用者には変化が無くても内部では再実装が発生します。前提になる現行仕様が文書に残っていなければ、人が画面とコードを追って復元するしかなく、この調査の工数が刷新の費用と期間を動かします。さらに、画面と画面のあいだの書かれていない業務ルールは、丁寧な要件定義でも文書からは拾えません。
記事が例にするのは、中堅の物流会社が受注・料金計算の基幹システムを段階的に作り直した開発記録（複数の実経験をもとに再構成したもの）で、データベース構造の変更が数百回規模で残っています。料金表では1,152セルを作り、空港料金だけを独自テーブルに切り出しましたが、実データ約1,400セルを照合すると全て「地上料金＋固定額」で導出でき、例外は0件だったため、独自テーブルごと削除しました。注文完了通知では、2人が別々に実装して通知が2系統になり、1注文につき2回届く状態を一つに収束させました。いずれも新機能ではなく、期待される動きを一つに定め、既存状態との差分を解消した変更です。
物流会社の料金計算を、受注管理でも、請求でも、読者の現行システムに置き換えても起きることは同じです。リプレイスで費用が集まるのは、新しい何かを作る部分ではなく、「同じ結果になることを調べ、移し、保証する」部分です。そして再現実装そのものは、現行の画面と挙動という参照できる正解があればAIが得意な領域で、人手で数か月かかっていた画面の作り直しが、検証込みで週単位まで縮み始めています。ただし、AIが正解を決めるわけではありません。書かれていない業務ルールの言語化は縮まず、実装が安くなるほど、現行仕様の調査と受入確認の比重が上がります。
だから、ARCHECOは
そのため、ARCHECOのシステムリプレイスは、新機能の要件を並べることから始めません。最初に、既存コード・帳票・画面遷移・DBスキーマをAIに読ませて現行仕様と依存関係を復元し、文書に無い業務ルールは案件を1件選んで現場を歩いて拾います。そのうえで現行の画面と挙動を正解にしてAI駆動開発で再現実装し、新旧の結果を照合しながら、戻せる単位でしか進めない原則で切り替えます。見積もりの大半を占める「読み解き」の工数を下げることが、刷新の費用と期間を下げる道だからです。
システムリプレイスの見積もりが膨らむのは、新機能のせいではありません。現行と同じ動きを人手で読み解いて再現する工数が大半を占めるからです。ARCHECOはその「読み解き」にAIを入れ、刷新の費用と期間を下げます。
課題
「仕様書が現行と合っていない」「作った会社の担当者がもういない」「見積もりを取ったら桁が違って返ってきた」——システムリプレイスが止まる場所は、技術の新旧ではなく、いま動いているものが何なのかを誰も正確に言えないことにあります。見積もりの大半は、新機能ではなく現行と同じ動きの再現に消えます。画面、権限、計算ロジック、通知、例外処理を作り直すためで、その前提になる現行仕様が文書に無ければ、人が画面とコードを追って復元するしかありません。刷新の費用と期間を動かしているのは、この調査の工数です。加えて、画面と画面のあいだにある書かれていない業務ルールは、丁寧な要件定義でも文書からは拾えません。ここを見落としたまま切り替えると、稼働直後に後続業務が止まります。刷新ではなく新規に作る案件はアプリ開発の外注、刷新後に自社で直し続ける体制づくりは内製化支援が扱います。このページは、いま動いているシステムを置き換える工程だけを扱います。
ARCHECOのアプローチ
ARCHECOは、現行の画面と挙動を「参照できる正解」として扱います。既存コード・帳票・画面遷移をAIに読ませて現行仕様を復元し、依存関係と連携の一覧を先に作ってから、要件定義と移行方式の選択に入ります。AIが得意なのは正解が参照できる実装で、人手で数か月かかっていた画面の作り直しが、検証込みで週単位まで縮み始めています。開発手法そのものはVibe Coding（AI駆動開発）、継続改修と内製化への引き渡しはGlobal AI Lab（ラボ型体制）に書いています。このページは「既存システムの刷新案件」を主語に、移行方式・費用の構造・進め方・失敗の型を、依頼しない前提で読んでも使える粒度で整理しています。
提供価値
刷新は「戻せる単位でしか進めない」を原則に、段階移行か並行移行を基本にします。切替前に戻す対象と判定条件を決め、本番切替の14日前を告知の基準日として役割別の教材を渡し、稼働直後の問い合わせは一次受付・業務判断・技術調査で分業します。契約では、ソースコードの著作権の帰属、設計書と運用手順書の納品、移行協力義務の3か所を先に文字にし、次の刷新で同じ依存を繰り返さない形にします。作って納めて終わりではなく、社内の担当者が自分で直せる状態までを引き受けます。刷新が終わった5年後に、また同じ調査から始めない形にします。
"システムリプレイスの進め方｜4つの移行方式と失敗の型"記事を読む
"ベンダーロックインとは｜原因6つ・問題点と脱却の手順"記事を読む
"AI駆動開発とは｜3つのレベルとメリット・デメリット"記事を読む
Solution Flow
01
STEP 01
現状調査と現行仕様の復元
既存コード・帳票・画面遷移・DBスキーマをAIに読ませ、現行仕様と依存関係を復元します。文書に無い業務ルールは、案件を1件選んで見積から請求まで現場を歩いて拾います。
Method
AIによる既存コードの読み解き
帳票・画面からの仕様復元
連携・依存関係の棚卸し
現場観察（1案件を最初から最後まで追う）
Output
現行仕様書（復元版）
連携台帳・依存関係図
書かれていない業務ルールの一覧
要件定義と移行方式の決定
「変えない範囲」と「変える範囲」を先に合意し、標準機能に寄せる部分と作り込む部分を分けます。切替中に業務を止められるかを起点に、一括・段階・並行・パイロットから移行方式を選び、概算と工程表を出します。
Method
変えない範囲の合意（成功条件の文書化）
Fit/Gapの棚卸し
移行方式の比較
費用を動かす変数の確定
Output
要件定義書
移行方式の比較表と決定理由
概算・工程表・確認条件つきの計画
AI駆動の再現実装とテスト・リハーサル
現行の画面と挙動を正解にして、AI駆動開発で再現実装します。単体・結合・システム・受入の4層でテストし、同じ入力で新旧の結果を照合します。移行リハーサルで戻す手順まで通します。
Method
AI駆動開発（現行の挙動を正解にした再現）
テスト4層（単体・結合・システム・受入）
新旧の結果照合
移行リハーサル
Output
新システム（段階ごとの稼働単位）
テスト記録・照合結果
データ移行手順とリハーサル記録
本番移行・切戻し設計・内製化への引き渡し
戻せる単位でしか進めません。切替前に戻す対象と判定条件を決め、14日前から告知と役割別の教育を行い、稼働直後は問い合わせを分業で受けます。移行後評価を経て、社内の担当者が自分で直せる状態まで引き渡します。
Method
ロールバック設計（戻す対象と判定条件）
利用者教育（14日前告知・役割別教材）
稼働直後の問い合わせ分業
移行後評価と内製化の引き渡し
Output
切替タイムラインと切戻し手順
運用手順書・教材
移行後評価レポート
ソースコード・設計書の帰属と引き渡し
SERVICE MENU
システムリプレイスの3つの型
いま手元に何が残っているかで、頼むべき範囲が変わります。①は現行仕様が文書に無い段階から入る型、②は作り直しを段階的に進める型、③は刷新後も自社で直し続けられる体制に渡す型です。①だけで終えて他社に発注することもできます。
仕様書が無い・ブラックボックスの段階から
仕様復元型 システムリプレイス
既存コード・帳票・画面遷移・DBスキーマをAIに読ませ、現行仕様と依存関係を復元します。文書に無い「画面と画面のあいだの業務ルール」は、案件を1件選んで見積から請求まで現場を歩いて拾います。移行方式の比較と概算まで出すので、この型だけで終えて、実装は他社に相見積もりを取ることもできます。
- やること
- AIによる既存コードの読み解きと、帳票・画面からの現行仕様の復元
- 連携台帳・依存関係の棚卸しと、書かれていない業務ルールの現場観察
- 変えない範囲の合意、移行方式の比較、費用を動かす変数の確定と概算
- 成果物
- 現行仕様書（復元版）／連携台帳／要件定義書／移行方式の比較表と概算
- 契約
- 受託（準委任）
- 期間
- 数週間〜数か月
現行を止めずに、段階的に作り直す
AI駆動再構築型 システムリプレイス
現行の画面と挙動を「参照できる正解」にして、AI駆動開発で再現実装します。人手で数か月かかっていた画面の作り直しが、検証込みで週単位まで縮み始めています。戻せる単位でしか進めない原則で段階移行か並行移行を基本にし、同じ入力で新旧の結果を照合しながら切り替えます。
- やること
- AI駆動開発による再現実装と、テスト4層（単体・結合・システム・受入）
- 段階／並行移行の設計、データ移行手順、リハーサル、切戻し設計
- 14日前からの利用者教育と、稼働直後の問い合わせ分業、移行後評価
- 成果物
- 新システム（段階ごとの稼働単位）／移行済みデータ／テスト記録・照合結果／運用手順書
- 契約
- カスタマイズ開発受託（1年以内）
- 期間
- 数か月〜1年
刷新後も、自社で直し続けられる体制に
内製化移行型 システムリプレイス（ラボ型）
刷新して終わりにすると、次の刷新で同じ依存が再発します。ダッカのAI開発センターを使ったラボ型の体制で継続改修を回しながら、社内の担当者に判断と改修の型を渡します。ソースコードの著作権、設計書と運用手順書、移行協力義務の3か所を契約に入れ、乗り換えられる状態を保ちます。
- やること
- ラボ型体制による継続改修と、社内担当者への改修の型の引き渡し
- 著作権の帰属・ドキュメント納品・移行協力義務を含む契約設計
- 依存の棚卸しと、年1回の乗り換え演習を含む脱ロックインの運用
- 成果物
- 運用体制／改修の型と手順／ソースコード・設計書の帰属と引き渡し
- 契約
- 月額（ラボ型・準委任）
- 期間
- 6か月〜
PROOF
システムリプレイスの実測値
刷新で効くのは、新機能の量ではなく、現行の動きをどれだけ速く正確に再現し、戻せる単位で切り替えられるかです。ここに並べたのは、自分たちで作り、運用し、書き残した数字です。
CASE STUDIES
システムリプレイスの導入事例
CASE TYPES
システムリプレイスの実績（類型別）
システムリプレイスを固有名つきで公開している案件はまだありません。ここに並べるのは、大企業の既存サービスの再設計・運用と、自社プロダクトで「現行を崩さずに作り直す」工程を回してきた経験の類型です。守秘の範囲で、業種と類型だけを書いています。
ABOUT SYSTEM REPLACEMENT
システムリプレイスの選び方・費用・進め方
刷新を検討している段階の方に向けて、システムリプレイスという仕事の輪郭を一通り整理しました。検索上位9本の見出しを全部取り、どこも書いている合意点は言い直し、どこにも無い項目は名指しで足しています。ARCHECOに依頼しない前提で読んでも、見積もりと提案を比べる物差しになるように書いています。
システムリプレイスとは、何を置き換える仕事か
システムリプレイスとは、古くなったシステムの全部または一部を、新しい仕組みに置き換える取り組みです。検索上位9本すべてがこの定義から始めますが、置き換える対象の範囲と、似た言葉との違いは会社によって書き方が揺れています。まずそこを揃えます。
基盤だけでなく、画面・データ・業務手順まで置き換える
システムリプレイスは、サーバーやソフトウェアを新しくする作業だけを指しません。利用者が触る画面、蓄積されたデータ、そのシステムを前提に組まれている業務手順まで含めて、新しい仕組みへ引き継ぐ設計が要ります。上位9本のうち定義を置いているのは9本すべてですが、置き換える範囲を「業務手順まで」と明記しているのは少数です。実務で効くのは、契約前に「何を変えないか」を文書にしておくことです。刷新の相談は「新しくしたい部分」から始まりがちですが、見積もりと工程を決めるのは、変えずに再現しなければならない部分の量のほうです。
リプレイスとマイグレーション（と「リプレース」表記）の違い
上位9本中6本が扱う論点です。マイグレーションは、OSやデータベース、クラウドなどの動作環境を移すことで、アプリケーションの中身は原則そのままです。リプレイスは仕組みそのものを置き換えるので、業務全体の引き継ぎ設計が要ります。実務では両方が同時に起きます。保守期限を理由に環境を移す（マイグレーション）ついでに、古い画面や計算ロジックも作り直す（リプレイス）ケースです。見積もりを読むときは、どちらの範囲にいくら乗っているかを分けて確かめてください。なお「システムリプレース」と長音で書く会社もありますが、同じ意味で使われています。日立ソリューションズ西日本のコラムのようにリプレースを「部分的な置き換え」と区別して使う例もあるので、提案書に両方の表記が出てきたら定義を聞いてください。
目的とメリット：攻めの投資、守りの投資、統制と人材
目的を「攻め」と「守り」に分けるのは上位9本中8本の共通した書き方です。攻めは、新しい技術や販路に対応して事業を伸ばすための刷新。守りは、保守期限切れ、セキュリティ、動作の不安定さ、保守コストの増大に対処する刷新です。これに、インボイスや電子帳簿保存法などの法対応、内部統制、担当者の退職による属人化の解消が加わります。メリットとして挙げられるのは、セキュリティの維持、動作の安定、業務効率、DXの土台、保守コストの削減です。ARCHECOが付け足すのは一点で、目的は稟議の文言ではなく「切替後に何が測れていれば成功か」に落としてから始めてください。守りの刷新でも、保守費の削減額や障害対応の時間など、測れる形にできます。目的を測れる形にしていないと、要件定義で要求の優先順位が決まりません。
実施すべき時期：「導入から5年」の正体と、実際の兆候
上位9本中5本が「導入から約5年」を目安に挙げています。根拠は、国税庁の減価償却上「その他のソフトウエア」の法定耐用年数が5年とされていることです。会計上の数字であって、5年を迎えたら交換するという技術基準ではありません。実際に動く必要があるかは、3つで判断します。保守期限（OS・ミドルウェア・パッケージのサポート終了日）がいつ来るか、小さな改修に何週間かかるようになっているか、障害が起きたときに業務がどれだけ止まるか。この3つのどれかが先に来るなら5年未満でも動くべきで、どれも当面問題が無いなら延命で構いません。上位で「必要か」を延命と比べて書いているのは1本だけでした。延命を選ぶ場合も、現行仕様の復元と連携台帳だけは先に作っておくと、次に判断するときの調査費が消えます。
システムリプレイスの4つの移行方式と選び方
移行方式は、一括・段階・並行・パイロットの4つです。上位9本中5本が4方式を並べていますが、選び方まで独立した見出しで書いているのは1本だけでした。最初の問いは1つ、「切替中に業務を止められるか」です。
一括移行方式：一度で切り替える
全対象を同じ切替機会に移します。作業が一度で済むので手間と費用は最小で、新旧の整合を考えなくてよいのが利点です。反面、障害が出たときの影響範囲が最も広く、戻す判断も一度に全部になります。向くのは、数日程度システムを止めても業務に大きな支障が出ない場合と、対象どうしの関係が強くて分割できない場合です。実務で確かめておくのは、切替日に決算や月次締めが重ならないか、そして「戻す」と決める判定条件と最終判断者が誰かをタイムラインに書いてあるかです。一括で行くなら、リハーサルは本番と同じデータ量で通してください。
段階移行方式（順次移行）：機能や業務の単位で順に移す
機能や業務、拠点などの単位に分けて順に切り替えます。1回あたりの停止時間が短く、トラブルの影響も狭く済むため、大規模で一括が難しい場合によく使われます。注意点は、新旧が同時に動く期間にデータの整合をどう保つかで、ここを設計しないと二重入力や突合作業が現場に落ちます。上位の記事で「順次移行」を段階移行と別の方式として数えているものもありますが、分け方の粒度の違いで、実務上は同じ考え方です。ARCHECOはこの方式を基本にしています。理由は、戻せる単位でしか進めないという原則と噛み合うからです。移す単位ごとに、切替前に戻す対象と判定条件を決めます。
並行移行方式：新旧を同時に動かして照合する
現行と新環境を一定期間同時に動かし、同じ入力に対する結果を照合してから旧を止めます。停止を避けられ、戻す先が常にある状態を保てるので、金融や医療のように誤りが許されない領域や、稼働を一切止められない業務に向きます。代わりに、二重運用の負担と費用がかかります。上位が書いていないのは、照合で差分が出たときの扱いです。差分の原因は「新システムの不具合」だけではなく、「現行が実は仕様どおりに動いていなかった」場合と「書かれていない業務ルールで人が補正していた」場合があります。差分の原因を技術か業務ルールかで切り分ける手順を、並行期間の前に決めておいてください。
パイロット移行方式：限定した部門で先行する
特定の部門や拠点で先に新システムを使い、問題を潰してから全体に広げます。小さく検証できるので、利用者の反応や運用手順の不備を早く見つけられます。注意点は、先行した範囲が全体を代表するとは限らないことです。本社の1部門で通っても、拠点ごとの例外処理や取引先ごとの帳票の違いは出てきません。選ぶときは、先行部門を「最も標準的なところ」ではなく「例外が多いところ」にするほうが、後で広げたときの手戻りが減ります。段階移行と組み合わせて、パイロットで通した単位から順に移していく形が実務では多くなります。
選び方：最初の問いは「切替中に業務を止められるか」
4方式の比較は、リスクと費用の天秤として書かれることが多く、一括が最も安くて危険、並行が最も高くて安全、段階とパイロットがその中間、という整理です。これは正しいのですが、順番が逆です。先に決めるのは「切替中に業務を止められるか」で、止められないなら一括は選べません。次に「対象を分割できるか」で、分割できないなら段階は選べません。この2問で候補が絞れてから、残った方式の費用と期間を比べてください。もう一つ、上位が書いていない条件は、切替日が決算期・月次締め・繁忙期に制約されることです。基幹系なら、受注から出荷、請求、入金、仕訳までの一連業務で範囲を決めるため、単一画面ではなく業務全体の同期が要ります。切替可能な日は年に数回しかないことが珍しくありません。
| 方式 | 向く条件 | リスク | 実務で確かめること |
|---|---|---|---|
| 一括移行 | 数日止めても支障が出ない／対象が分割できない | 障害時の影響範囲が最も広く、戻す判断も一度に全部 | 切替日と決算・月次締めの重なり、戻す判定条件と最終判断者 |
| 段階移行 | 大規模で一括が難しい／対象を単位に分けられる | 新旧同時期間のデータ整合。二重入力や突合が現場に落ちる | 移す単位ごとに、切替前に戻す対象と判定条件を決める |
| 並行移行 | 誤りが許されない領域／稼働を一切止められない業務 | 二重運用の負担と費用 | 照合の差分を技術か業務ルールかで切り分ける手順を先に決める |
| パイロット移行 | 利用者の反応や運用手順の不備を早く見つけたい場合 | 先行部門が全体を代表しない（拠点の例外、取引先別の帳票） | 先行部門を「例外が多いところ」にし、通した単位から段階移行 |
システムリプレイスの費用は、何で決まるか
費用を独立した見出しで扱っている上位ページは9本中1本で、実額の相場を書いているページはありません。書けないのが正直なところで、金額そのものより、金額を動かしている構造と変数を見たほうが比較できます。
見積もりの大半は、新機能ではなく「同じ動きの再現」
システムリプレイスでは、新機能だけに費用がかかるわけではありません。大きな部分を占めるのは、現行と同じ動きの再現です。画面、権限、計算ロジック、通知、例外処理を作り直すためで、利用者から見れば「今と同じ」でしかない部分に、見積もりの大半が乗ります。ここが理解されていないと、経営層には「何も変わらないのに、なぜこの金額か」に見え、予算が削られて再現の品質が落ちます。上位9本のうち、この構造を書いているページはありませんでした。見積もりを受け取ったら、まず「新しくする部分」と「同じ動きを再現する部分」に分けて金額を出してもらってください。分けられない見積もりは、範囲が決まっていないということです。
金額を動かす5つの変数
金額を動かす変数は、対象範囲と不確実性です。画面数だけでなく、画面間の分岐が工数に影響します。データ量より、変換ルールの複雑さが効く場合もあります。外部連携、権限の細かさ、停止可能時間も変数です。整理すると、①対象範囲（画面数と画面間の分岐）、②現行仕様の不確実性（文書がどれだけ現行と合っているか）、③外部連携の数と複雑さ、④データ変換ルールの複雑さ、⑤停止可能時間（並行運用や夜間作業がどれだけ要るか）の5つです。このうち②だけは、発注側が先に下げられます。現行仕様を復元しておけば、ベンダーは不確実性分のバッファを積まずに見積もれます。①③④は調査で確定でき、⑤は経営判断です。
見積もりを比べる前に、5つの条件を自社側で揃える
複数のベンダーから見積もりを取るのは上位の多くが勧めることで、正しい手順です。ただし条件が揃っていない見積もりを金額だけで比べると、安く見えたほうが後で高くつきます。上の5つの変数を自社側で書いて、同じ条件で出してもらってください。あわせて、含まれる範囲（データ移行は含むか、教育は含むか、切替後の修正は何か月までか）、費用の内訳（固定費と変動費）、支払い条件、検収条件、保守条件を揃えます。GRANDITのコラムが勧める「実測して選ぶ」は費用でも同じで、机上の比較で決めるより、代表的な画面を1つ試作させて工数を測るほうが、見積もりの妥当性が分かります。
AIに既存コードと帳票を読ませて現行仕様を復元し、調査工数を下げる
上位9本のどこにも無い項目で、ARCHECOが刷新の費用を下げるために最初に手を付ける工程です。見積もりの大半は同じ動きの再現で、その前提になる現行仕様が文書に無ければ、人が画面とコードを追って復元するしかありません。この読み解きにAIを入れます。既存コードの読み解き、依存関係の洗い出し、移行の下書きはAIに任せられ、帳票と画面遷移からは計算と例外処理の候補が出せます。AIが得意なのは、参照できる正解がある実装です。現行の画面と挙動が残っていれば、それが再現条件になります。人手で数か月かかっていた画面の作り直しが、検証込みで週単位まで縮み始めています。ただしAIが復元するのはコードと帳票に書かれていることまでで、画面のあいだの書かれていない業務ルールは拾えません。そこは人がやります。
| 対象 | AIで復元できるか | 読ませる材料 | 人がやること |
|---|---|---|---|
| 既存コードの読み解き・依存関係の洗い出し | できる | ソースコード、DBスキーマ | コードの著作権と現物の所在を先に確かめる |
| 計算と例外処理 | 候補まで出せる | 帳票の出力サンプル、画面遷移のキャプチャ | 現行の画面と挙動を再現条件として検証する |
| 移行の下書き | できる | バッチのスケジュール、連携先のインターフェース定義 | AIが読める場所に材料を置く |
| ソースコードが手元に無い部分 | 精度が下がる | 画面、帳票、出力データ | 挙動から再現する前提で見積もりに織り込む |
| 書かれていない業務ルール（人が接着剤の部分） | できない | 文書にもコードにも無い | 案件1件を見積から請求まで追って観察する |
AIに読ませるもの
ソースコード、DBスキーマ、帳票の出力サンプル、画面遷移のキャプチャ、バッチのスケジュール、連携先とのインターフェース定義。これらをAIが読める場所に置くところから始めます。ソースコードが手元に無い場合は、画面と帳票と出力データから挙動を再現する形になり、精度は下がります。先にコードの著作権と現物の所在を確かめてください。
AIが復元できないもの
文書にもコードにも無い判断です。営業が口頭で受けた条件を事務が電話で確認している、締め日の判定を担当者が手で補正している、といった「人が接着剤になっている」部分は、案件を1件選んで見積から請求まで実際の書類とデータの動きを追わないと出てきません。AIは調査の量を減らしますが、この観察を省く理由にはなりません。
費用を抑えるときに、削ってはいけないもの
削って良いのは、新機能の量と、切替後すぐには要らない画面の作り込みです。標準機能に寄せて作り込みを最小にする（Fit to Standard）のも、正しい削り方です。削ってはいけないのは、現場観察、受入テストの参加時間、移行リハーサル、そして切戻しの設計です。ここを削ると、費用は下がりますが、切替後に後続業務が止まって、停止分の損失が削った額を上回ります。上位で失敗事例を書いている2本が挙げるのも、新旧データの照合観点の不足と、ピーク時の性能を実測しなかったことで、いずれも「削ると後で高くつく」工程です。予算が限られているなら、対象範囲を狭めて段階数を増やすほうが、範囲を保って検証を減らすより結果が出ます。
ARCHECOでは、対象範囲と現行仕様の不確実性によって変わるため、定額での提示はしていません。無料のシステムリプレイス診断で、仕様の復元にどれだけの調査が要るかと、向く移行方式を見立ててから概算をお出ししています。
システムリプレイスの進め方
進め方は上位9本すべてが書いており、順番も概ね同じです。チームを立ち上げ、要件を洗い出し、ベンダーを選び、計画と予算を固め、データを準備し、リハーサルをして本番移行する。重要なのは各段階の名前ではなく、次に進んでよいかを何で判断しているかです。日付だけの計画では、未確認事項が本番へ持ち越されます。
現状分析と目的設定：成功条件と「変えない範囲」を文書にする
最初にやるのは、いま何が動いていて、何に困っていて、切替後に何が測れていれば成功かを文書にすることです。テレワークス社のコラムが挙げる「運用コストの30%削減」のように、誰が聞いても分かる目標に落とします。ARCHECOが加えるのは「変えない範囲」の合意です。刷新は変える話から始まるので、変えない部分が曖昧なまま要件定義に入ると、現場から「今できていることができなくなる」が後から出続けます。成功条件と変えない範囲の2つを、この段階で関係者の署名つきの1枚にしておくと、後の要求の優先順位が揺れません。あわせて、概算投資とロードマップと主要リスクを同じ1枚にまとめて合意します。
体制：プロジェクトチームと、決裁の道筋
チームは情報システム部門だけで組まない、というのが上位の共通した助言です。実際に使う部門の担当者、予算を持つ人、決裁者を最初から入れます。ARCHECOが加えるのは、決裁の道筋を先に引くことです。誰が、何を見て、いつ判断するか。変更・仕様・受入の承認を、誰がいつまでにどの基準でするか。これが決まっていないと、要件定義の途中で出てくる判断が全部止まり、日程だけが後ろへ動きます。経営層には、リプレイスの難しさとリスクを最初に認識してもらってください。上位9本中2本が指摘するとおり、経営層の理解が無いと十分な予算と期間が確保できず、途中で削られます。
要件定義：標準に寄せる部分と、書かれていない業務ルール
要件定義を軽視しないことは、上位9本中8本が失敗しないポイントとして挙げています。実務で効くのは2つです。1つ目は、GRANDITのコラムが勧める「Fit to Standard（標準優先）」で、現行の課題を業務シナリオ単位に分解し、標準機能で足りる部分と作り込む部分を分けます。作り込みは最小にします。2つ目は、丁寧な要件定義でも拾えないものが一つあるということです。画面と画面のあいだにある、書かれていない業務ルールです。営業が口頭で受けた支払条件の変更が受注データに入らず、事務が毎回営業に電話で確認している、といった部分は、機能一覧を百行積んでも出てきません。案件を1件選び、見積から請求まで書類とデータの動きを追いかけてください。今のシステムの外で行われている手作業も、同じ表に載せます。
機能一覧に足す3列
機能一覧の各行に「この機能の前後で人が何をしているか」「例外はどこで誰が判断しているか」「他システムとの受け渡しは何か」を足します。この3列が空欄の行が、切替後に業務が止まる場所です。
ベンダー選定と契約：実測して選び、3か所を文字にする
信頼できるベンダーを選ぶ、というのは上位9本中5本が書く助言ですが、「信頼できる」の中身が書かれていません。実務で使える基準は2つです。1つ目は実測で、机上の比較ではなく、代表的な画面を1つ試作させて工数と品質を見ます。ピーク時のデータ量で性能を再現するテストも、選定の段階で要求します。2つ目は契約で、ソースコードの著作権の帰属、設計書と運用手順書の納品と更新、移行協力義務の3か所を先に文字にします。この3か所が無いと、次の刷新でいまと同じ「仕様書が無い・コードが手元に無い・他社が見積もれない」状態が再発します。ベンダーロックインの原因は6つに整理できますが、契約で塞げるのはこの3つです。上位9本のうち、契約の中身をここまで書いているページはありませんでした。
移行計画・予算確保・データ移行
移行計画では、何を移すか、いつ・どの順で進めるか、どう確認するか、問題が出たらどう戻すか、誰に知らせるかの5点を決めます。データ移行を独立した見出しで扱う上位ページは9本中4本で、失敗事例を書く2本はどちらもデータ移行の照合不足を原因に挙げています。照合の観点は、件数、金額、計算ロジック、締め処理の4つを最低限にします。名寄せとクレンジングは移行の直前にやると間に合わないので、現状分析の段階から始めます。予算は、社内の年度計画に合わせて確保しつつ、不確実性分の余裕を持たせます。ARCHECOが加えるのは、この余裕を「不明」ではなく「現行仕様の復元が終わるまでの暫定」と明記し、復元が終わった時点で見積もりを確定させる二段階にすることです。
テスト4層とリハーサル：同じ入力で新旧を照合する
テストは4層で考えます。単体テストで機能が仕様どおりか、結合テストで部品間の受け渡しが正確か、システムテストで全体の性能・権限・障害対応が成り立つか、受入テストで業務の結果が満たされているかです。上位が「テスト」と一語で書く工程を分けるのは、どの層で見つけた不具合かで直す場所が変わるからです。移行リハーサルは本番と同じデータ量・同じ手順で通し、戻す手順まで含めて計測します。ARCHECOが加えるのは、リハーサルと並行稼働で「同じ入力に対する結果を照合する」ことです。差分が出たら、原因が技術（新システムの不具合）か業務ルール（現行で人が補正していた）かを切り分けます。後者は不具合ではなく、要件定義で拾えなかったルールが見つかったということなので、仕様に書き足します。
本番移行・切戻し設計・教育・移行後評価
切替当日は、開始→確認→周知→必要時の切戻しまでの流れと最終判断者をタイムラインに書きます。ロールバックの原則は「戻せる単位でしか進めない」です。切替前に、戻す対象と判定条件を定めます。教育は、本番切替の14日前を告知の基準日とし、対象者と変更点を知らせ、遅くとも3営業日前までに役割別の教材を渡す流れで設計します。実データに近い操作会を1回はやってください。稼働直後は問い合わせが集中するので、一次受付・業務判断・技術調査を分業し、重大度別に応答目標を置きます。移行後評価を独立した工程にしている上位は9本中2本で、目的設定で決めた成功条件（保守費、処理時間、障害件数など）を稼働後に測って初めて、刷新が終わります。教育と切戻しを独立した見出しにしている上位はそれぞれ1本ずつでした。
システムリプレイスで失敗するケースと、防ぎ方
失敗しないためのポイントは上位9本中8本が書いていますが、具体的な失敗事例まで書いているのは2本です。ここでは失敗を型に分け、どれも切替後に「後続の業務が止まる」形で表面化することと、防ぐ側の手を書きます。
目的が曖昧なまま進み、要求の優先順位が揺れる
「老朽化したから」だけで始まると、要件定義で出てくる要求に優先順位が付けられません。全部が要件になり、予算と期間に収まらず、削る段になって現場と衝突します。上位が最も多く挙げる失敗で、テレワークス社のコラムでも失敗例の1つ目です。防ぐには、成功条件と変えない範囲を先に文書で合意します。要求が出てきたときに「それは成功条件のどれに効くか」で判定できるようにしておくと、削る議論が感情ではなく基準で済みます。要件のベースラインを決めて、それ以降の変更は変更管理に乗せる運用も効きます。
現場の声と、書かれていない業務ルールを見落とす
現場部門を上流から参加させる、というのは上位9本中3本が書く助言です。参加させるだけでは足りません。現場の人も、自分が毎日やっている補正作業を「業務ルール」だと認識していないことが多く、聞かれても出てきません。画面と画面のあいだの判断、例外処理、他部門への電話確認は、機能一覧の行にはなりません。防ぐには、観察です。実際の案件を1件、見積から請求まで書類とデータの動きで追いかけ、人が接着剤になっている箇所を見つけます。受入確認にも利用者を入れ、「今までできていたこと」ができるかを利用者自身に判定させます。
既存システム間のデータ連携を見落とす
刷新対象のシステムが、どのシステムからデータを受け取り、どこへ渡しているかが把握されていないと、切替後にデータが届かず、後続の業務が止まります。既存システムとの連携確認は上位9本中3本が挙げています。防ぐには、連携台帳を作ることです。連携先、方向、頻度、形式、失敗時の扱いを1行ずつ書き、疎通テストと異常系（相手が止まっている、形式が違う）のテストを移行前に通します。連携台帳はAIで既存コードとバッチ定義を読ませると、下書きまでは出せます。台帳に無い連携が現場の手作業（CSVを手で落として別システムに入れる）で行われていることがあるので、観察と組み合わせます。
データ移行の照合観点と、非機能の見積もりが甘い
GRANDITのコラムが挙げる失敗事例は2つです。1つは、カットオーバー直後に受発注や在庫の不整合が連鎖し、出荷・製造が長期停止に至ったケースで、新旧データの照合観点（件数・金額・計算ロジック・締め処理）が抜けていました。もう1つは、大容量データや連携バッチの性能見積もりが甘く、工期の延伸と予算超過を招いたケースで、机上比較に偏って実機検証とピーク時の再現テストが無かったことが原因です。共通するのは、実測に基づかない選定と、短すぎる並行期間、あいまいな切戻し基準です。防ぐには、選定の段階でピーク時のデータ量で性能を実測させ、照合観点を4つ以上決めて並行稼働で確かめ、切戻しの判定条件を数値で置きます。
次の刷新で、同じベンダー依存が再発する
上位9本のどこにも無い項目です。刷新が終わった時点で、ソースコードの著作権が受注側に残り、設計書が納品されず、更新もされない状態になっていると、5年後にいまと同じ「他社が見積もれない」状態に戻ります。ベンダーロックインの原因は、ドキュメントの不備、独自技術への依存、著作権の帰属、契約の縛り、社内に判断できる人がいないこと、業務プロセスの個別作り込みの6つに整理できます。刷新は、この6つを一度に減らせる数少ない機会です。防ぐには、契約で著作権の帰属・ドキュメントの納品・移行協力義務を文字にし、社内に担当を置き、年1回は乗り換えの演習をします。ARCHECOが内製化への引き渡しを型にしているのは、刷新して終わりにすると、この再発を止められないからです。
システムリプレイスの依頼先の選び方
「システムリプレイス」で検索して出てくる会社は、性質の違う4種類が混ざっています。上位9本はすべてERPベンダーかSIer、ニアショア仲介のコラムで、依頼先の種類を分けて書いているページはありませんでした。どこに頼むかで、返ってくるものが変わります。
依頼先の4つの型：パッケージ／SIer／開発会社／ニアショア・オフショア
パッケージ・ERPベンダーは、標準機能に業務を寄せる刷新が得意で、会計・人事・販売など制度対応が絡む基幹系に向きます。作り込みが多い業務には合いません。SIerは、大規模で複数システムにまたがる刷新を一括で受けられ、体制の厚さが強みです。反面、単価が高く、小さく段階的に進める動きとは相性が良くありません。開発会社は、業務に固有の仕組みを作り直す刷新に向き、AI駆動開発を使う会社なら再現実装の速度が出ます。ARCHECOはここに属します。ニアショア・オフショアは、要件が固まった後の実装を費用を抑えて進める形で、現行仕様の復元や要件定義を自社かコンサルで持てる場合に噛み合います。刷新の対象が「標準に寄せられる業務」か「固有の業務」かで、最初の絞り込みができます。
| 型 | 得意な刷新 | 向く案件 | 注意点 |
|---|---|---|---|
| パッケージ・ERPベンダー | 標準機能に業務を寄せる刷新 | 会計・人事・販売など制度対応が絡む基幹系 | 作り込みが多い業務には合わない |
| SIer | 複数システムにまたがる大規模刷新の一括請負 | 体制の厚さが要る案件 | 単価が高く、小さく段階的に進める動きと相性が悪い |
| 開発会社（ARCHECOはここ） | 業務に固有の仕組みを作り直す刷新 | 固有の業務が対象の案件 | AI駆動開発を使うかで再現実装の速度が変わる |
| ニアショア・オフショア | 要件が固まった後の実装を費用を抑えて進める | 仕様復元と要件定義を自社かコンサルで持てる案件 | 現行仕様の復元は発注側で持つ |
現行仕様が無い状態を、どう扱う会社か
提案の場で「仕様書が現行と合っていない」「ソースコードの一部が手元に無い」と伝えたときの反応で、その会社の刷新の型が分かります。「まず要件定義から」と返す会社は、現行仕様の復元を発注側の仕事にしています。復元されていない仕様の上に要件定義を積むと、要件定義の途中で現行の挙動を確かめる作業が発生し、そこで日程が動きます。「現行の調査をどう進めるか」を具体的に答える会社は、この工程の重さを知っています。ARCHECOはAIによる読み解きと現場観察を組み合わせた仕様復元型を最初の型にしており、この型だけで終えて実装は他社に相見積もりを取ることもできます。復元された仕様と連携台帳があれば、どの会社の見積もりも比べられるようになります。
刷新後に、自社で直し続けられる形で渡す会社か
契約の終わりが「稼働」なのか「社内の担当者が自分で直せる状態」なのかを見ます。前者が悪いわけではなく、保守を同じ会社に任せ続ける前提なら正しい選択です。ただし次の刷新で同じ依存に戻ることは織り込んでください。後者を求めるなら、契約中に社内の誰がどの改修を引き取るかを決めて、実際にやらせておく必要があります。「引き継ぎ資料をもらう」では回りません。ARCHECOはラボ型の体制（Global AI Lab）で継続改修を回しながら改修の型を渡す形を用意しており、ソースコードと設計書の帰属を契約に入れています。上位9本のうち、内製化を扱っているページはありませんでした。刷新が終わった5年後に、また同じ検索をしないための項目です。
NEWS & BLOG
システムリプレイスの関連記事
SOLUTIONS
システムリプレイスで使う開発手法・契約モデル
このサービスで使う開発手法・契約モデル・技術方式です。
Vibe Coding
「AIに書かせる」ではなく「判定はエンジニアが握ったまま任せる」。これがバイブコーディングの本体で、MVP構築を通常の数分の一の期間で実現します
Global AI Lab
ラボ型開発のコスト効率を活かしながら、コンサル会社がオフショアを「使う」のではなく、自己資金で現地法人を設立した当事者意識のある3拠点体制でAI開発を提供します
FAQ
システムリプレイスのよくある質問
ご相談の前によくいただく質問です。解決しない点はお気軽にお問い合わせください。
01
QUESTION
IT用語でリプレイスとは何ですか？
英語のreplace（置き換える）が語源で、古くなったシステムの全部または一部を新しいものに置き換えることです。基盤だけでなく、画面・データ・業務手順まで含めて引き継ぎを設計するのがシステムリプレイスで、OSやプラットフォームなど動作環境を移すマイグレーションとは範囲が違います。「リプレース」と書く会社もありますが、同じ意味で使われています。
02
QUESTION
システムリプレイスで失敗するケースは？
型は3つに集約されます。目的が曖昧なまま進んで要求の優先順位が揺れる、画面と画面のあいだにある書かれていない業務ルールを見落とす、既存システム間のデータ連携を見落とす、の3つです。いずれも切替後に「後続の業務が止まる」形で表面化します。防ぐ側の手は、成功条件と変えない範囲を先に文書で合意すること、文書確認に現場観察を組み合わせること、連携台帳を作って疎通と異常系のテストをすることです。
03
QUESTION
システムリプレイスは必要ですか？
「導入から5年」という目安はソフトウェアの法定耐用年数から来た会計上の数字で、5年で必ず交換する技術基準ではありません。判断材料は、保守期限（OS・ミドルウェア・製品のサポート終了）、改修に要する速度、障害が業務に与える影響の3つです。どれも当面問題が無いなら延命で構いませんし、逆に保守期限が先に来るなら5年未満でも動く必要があります。延命を選ぶ場合も、現行仕様の復元と連携台帳だけは先に作っておくと、次に判断するときの調査費が消えます。
04
QUESTION
システムリプレイスの費用はいくらですか？
一律の相場はありません。見積もりの大半は新機能ではなく、現行と同じ動きの再現（画面・権限・計算・通知・例外処理の作り直し）に使われます。金額を動かすのは、対象範囲、現行仕様の不確実性、外部連携の数と複雑さ、データ変換ルール、停止可能時間の5つです。ARCHECOは現行仕様の復元にAIを入れて不確実性を先に潰し、そのうえで概算を出します。見積もりを比べるときは、この5つの条件を自社側で揃えて各社に渡してください。
05
QUESTION
仕様書が無い、作った会社が無くなったシステムでも刷新できますか？
できます。むしろその状態から入る型（仕様復元型）を用意しています。既存コード・帳票・画面遷移・DBスキーマをAIに読ませて現行仕様と依存関係を復元し、文書に無い業務ルールは案件を1件選んで現場を歩いて拾います。ソースコードが手元に無い場合は、画面と帳票と出力データから挙動を再現する形になるため、先にコードの著作権と現物の所在を確かめてください。
06
QUESTION
切替中に業務を止められない場合はどうしますか？
並行移行か段階移行を選びます。並行移行は現行と新環境を同時に動かして同じ入力の結果を照合し、差分の原因を技術か業務ルールかで切り分けてから旧を止めます。二重運用の負担は増えますが、戻す先が常にある状態を保てます。段階移行は機能や業務の単位で順に移し、新旧のあいだのデータ整合を設計します。どちらも「戻せる単位でしか進めない」を原則にし、切替前に戻す対象と判定条件を決めておきます。
07
QUESTION
Vibe Coding や Global AI Lab のページとは、何が違うのですか？
このページは「既存システムの刷新案件」を主語にしています。Vibe Codingは開発手法（AI駆動開発）そのもの、Global AI Labはラボ型の開発体制の説明で、システムリプレイスではその手法と体制を、現行仕様の復元・移行方式の選択・切戻し設計という刷新固有の工程に当てはめています。刷新の相談は、このページの診断から入ってください。
Plans
ARCHECOの契約モデル
受託開発（1年以内のカスタム開発）、代理出産型プロフィットシェア（ARCHECOが事業運営を主導、無償保証・サービス譲渡確約付き、2〜3年計画）、ジョイントベンチャー（双方が資本出資し事業体を共同設立、2〜3年計画）、スウェットエクイティ（労働力を株式として投下）。事業フェーズとリスク許容度に合わせて、最適な契約形態を設計します。どの契約を選んでも、事業を当てることへのこだわりは変わりません。
Plan 01
Customize Development
カスタマイズ開発受託
お好みのスタイルを何なりと
ARCHECOのソリューションライブラリと自律型AI開発エージェントを活用し、1年以内でカスタムシステムを構築・納品します。AI戦略策定からAgentic RAG構築、業務特化型プライベートSaaS開発、UX/UIデザインまで、事業に必要な全工程を一気通貫で実行します。
Plan 02
Surrogacy
代理出産
産みの苦しみ、請け負います
ARCHECOが事業の企画・開発・運営を主導し、2〜3年計画で事業を立ち上げます。無償保証、サービス譲渡確約、採用代行を含むリスク軽減策をセットで提示。事業が黒字化して初めてARCHECOの収益が発生するプロフィットシェア構造により、全員が事業の成功だけに集中します。
Plan 03
Joint Venture
ジョイントベンチャー
新たなお仕事ご一緒に
クライアント様とARCHECOが資本を出し合い、新たな事業体を共同設立します。双方からの人材出向・採用により、独立した組織として事業を推進。既存事業のルールや予算制度に縛られない「出島」として機能し、スタートアップと同等のスピードと柔軟性で意思決定を行います。
無料のシステムリプレイス診断
いまの現行システムについて、仕様の復元にどれだけの調査が要るか、どの移行方式が向くかを無料で見立てます。製品の提案ではなく、「次に確かめるべきこと」と費用を動かす変数を具体的にお返しします。
※弊社のリソース状況によってはお受け出来ないことがございます。