製造業のレガシーシステム刷新 では、システムを新しくするだけでなく、生産ラインへの影響を抑えながら移行する計画が欠かせません。「ラインは止められない」「中身が分かる担当者がいない」といった理由で、刷新に踏み切れない企業も少なくありません。
ポイントは、一度にすべてを入れ替えないこと です。範囲を分けて段階的に移行し、新旧の結果を照合したうえで、長期休暇や計画停止日に切り替えます。あわせて、問題が起きたときに旧システムへ戻す手順も用意しておきます。
本記事では、基幹システム・生産管理システム・MESなどの情報システム（IT）を中心に、刷新の進め方を解説します。
本記事で分かること：
- 工場を止めずに刷新するための5つの原則
- 刷新対象の優先順位と、刷新手法の選び方
- 段階移行・並行稼働を使った切替計画の立て方
- データ移行・本番切替のチェックリストとよくある失敗
工場を止めずにレガシーシステムを刷新する5つの原則
最初に、本記事全体の要点を5つの原則として整理します。それぞれの詳細は、後半の各章で解説します。
- 現状を見える化してから刷新範囲を決める プログラム、データ、外部連携、帳票、そして現場のExcel運用までを棚卸しし、何をどこまで刷新するかを決めます。
- 目的に合った刷新手法を、機能ごとに選ぶ すべてを作り直す必要はありません。機能ごとに「環境だけ移す」「作り直す」「パッケージに置き換える」などを使い分けます。
- 一括移行を避け、段階的に移行する 機能、工場、ラインなどの単位に分け、影響の小さい範囲から順に切り替えます。
- 新旧を並行稼働させ、生産計画に合わせて切り替える 新旧システムの結果を照合して問題がないことを確認し、長期休暇や計画停止日に本番切替を行います。
- 切り戻し手順を用意し、リハーサルで検証する 問題が起きた場合に旧システムへ戻す基準と手順を決め、本番前に必ずリハーサルします。
製造業のレガシーシステムとは？刷新が必要な理由
レガシーシステムとは
レガシーシステムとは、一般に、古い技術や仕組みで構築され、長年の改修によって複雑化・ブラックボックス化し、保守や改修が難しくなったシステムを指します。経済産業省の「DXレポート」（2018年）では、こうした既存システムがデジタルトランスフォーメーション（DX）の足かせになると指摘されています。
重要なのは、「古いこと」そのものが問題なのではないという点です。古いシステムでも、仕様が文書化され、保守できる人材がいて、技術的なサポートが続いていれば、すぐに刷新する必要はありません。問題になるのは、中身が分からない、直せない、つなげられない 状態になっていることです。
＞＞＞関連記事：
製造業に多いレガシーシステムの例
製造業では、次のようなシステムがレガシー化しているケースが多く見られます。
- メインフレームやオフィスコンピュータ（オフコン）上で、COBOLやRPGで構築された基幹システム
- Visual Basic、Accessなどで自社開発されたクライアント・サーバー型の生産管理システム
- 長年の改修で複雑になったExcelマクロによる計画・集計業務
- サポートが終了したOS上で動き続けている、設備と接続された現場のPC
- 大規模なカスタマイズを重ね、バージョンアップが難しくなったERP
製造業ならではの刷新の難しさ
製造業のレガシーシステム刷新は、他の業種と比べて次のような難しさがあります。
| 難しさ | 内容 |
|---|---|
| 停止できない | 24時間・365日稼働の工場では、システムが止まると生産も止まり、出荷遅延や取引先への影響につながる |
| 設備との連携 | MES、PLC、計測器などと接続しているため、システムの変更が生産ラインの動作に影響する |
| 現場独自の運用 | 工場ごとのルールやExcelでの補完作業が、システムの外側に存在する |
| 属人化 | システムを構築した担当者が退職し、設計書も残っていない |
| データを失えない | ロット管理や品質記録などのトレーサビリティ情報は、長期間の保存が求められる |
一般社団法人日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」（2025年度調査、東証上場企業とそれに準じる企業が対象）には、システム開発の品質が予定どおりにならなかった要因を尋ねた設問があります。この設問の回答企業（n=172）のうち48.8%が、要因の一つとして「想定以上の現行業務・システムの複雑さ」を挙げています。
これは日本企業全体の割合ではなく、品質面の課題について回答した企業の中での割合です。それでも、現行システムの複雑さを事前に把握できるかどうかが、システム開発や刷新の成否に影響することを示すデータといえます。
レガシーシステムを放置するリスク
1. 保守・サポートの終了 OSやミドルウェア、パッケージの保守期限が切れると、不具合やセキュリティの問題に対応できなくなります。例えば、Windows 10のサポートは2025年10月14日に終了しました。また、SAP ERP 6.0（SAP ECC 6.0）の保守期限は、利用しているバージョンや拡張パッケージによって異なります。自社が利用しているバージョンの保守期限と、延長保守の適用条件を確認しておく必要があります。ハードウェアの部品が調達できなくなることも、製造業では現実的なリスクです。
2. セキュリティとシステム障害のリスク サポートが終了したOSやソフトウェアは、新たに見つかった脆弱性が修正されず、サイバー攻撃を受けやすくなります。また、システム障害が生産に与える影響は、自社のシステムだけにとどまりません。2022年3月には、取引先のシステム障害により、トヨタ自動車が国内14工場28ラインの稼働を一時停止しました。この事例は、自社システムだけでなく、サプライチェーン全体のシステム障害が生産に影響することを示しています。
3. 人材と技術の継承 COBOLやオフコンを扱える技術者の高齢化が進んでいます。JUASの同調査では、内製化を進めるうえでの課題を尋ねた設問で、回答企業（n=953）の25.9%が「現行システムの仕様がわからない」を挙げています。
4. DXやデータ活用の足かせ データがシステムごとに分断されていると、生産実績の可視化やAIによる需要予測、設備の予知保全といった取り組みを進められません。
経済産業省の「DXレポート」は、既存システムの問題を解決できない場合、2025年以降に最大で年間12兆円の経済損失が生じる可能性があるとして、これを「2025年の崖」と呼びました。2025年はすでに過ぎましたが、これは2018年時点の試算であり、指摘された課題そのものは多くの企業で現在も続いています。
刷新対象となるシステムと優先順位の決め方
対象システム別の特徴
製造業の主なシステムと、刷新時に注意すべき点は次のとおりです。
| システム | 主な機能 | 停止時の影響 | 刷新時の注意 |
|---|---|---|---|
| 基幹システム（ERP・販売・購買・会計） | 受注、購買、在庫、会計 | 大きい（取引先との取引に影響） | 標準業務が多く、パッケージへの置き換えを検討しやすい |
| 生産管理システム | 生産計画、MRP（資材所要量計画）、工程管理 | 非常に大きい | 自社独自のロジックが多く、要件の洗い出しに時間がかかる |
| MES（製造実行システム） | 製造指示、実績収集、作業記録 | 生産ラインに直結 | 設備との連携仕様の確認が必要 |
| 品質管理・トレーサビリティ | 検査記録、ロット追跡 | 顧客対応・コンプライアンスに影響 | 過去の履歴データを確実に引き継ぐ |
| 周辺システム（Excel・Access・帳票） | 集計、帳票出力、現場の補助業務 | 個々の影響は小さいが数が多い | 棚卸しで漏れやすい |
優先順位の決め方
すべてのシステムを同時に刷新するのは現実的ではありません。優先順位は、リスクの高さ と 業務への影響度 の2つの軸で整理すると判断しやすくなります。
- リスクの高さ：保守期限、属人化の程度、セキュリティ上の問題、ハードウェアの老朽化
- 業務への影響度：停止した場合の生産・出荷・取引先への影響
リスクが高く、業務への影響が比較的小さいシステムから着手すると、刷新のノウハウを社内に蓄積しながら進められます。一方、リスクも業務影響も大きいシステムは、優先度は高いものの、十分な準備期間を確保して計画的に進めます。
情報系（IT）と制御系（OT）の境界に注意する
PLCやSCADAなどの制御システムは、設備メーカーや設備のインテグレーターと連携して扱う領域です。情報系システムを刷新する際は、制御系との接続点（データの受け渡し方法、通信方式、タイミング）を事前に洗い出し、設備側の担当者を早い段階から巻き込みましょう。
また、制御系のネットワークを情報系やクラウドと接続する場合は、セキュリティ対策の見直しが必要です。産業用制御システムのセキュリティについては、国際規格IEC 62443などが参考になります。
レガシーシステム刷新の手法と選び方
ここでは、「何を、どのように新しくするか」という 刷新手法 を紹介します。「旧システムから新システムへ、どのように切り替えるか」という 移行方式 は、手法とは別に設計する必要があります。移行方式については、後述の「工場を止めない移行方式と切替計画」で解説します。
主な5つの刷新手法
| 手法 | 内容 | 向いているケース | コスト・期間（相対） | 注意点 |
|---|---|---|---|---|
| リホスト／リプラットフォーム | プログラムをほぼそのまま、新しい基盤（サーバー、クラウドなど）へ移す | 機能は安定しているが、基盤の保守期限が迫っている | 小 | 複雑なプログラム構造（技術的負債）はそのまま残る |
| リファクタリング | 機能を変えずに、コードの構造を改善する | 構造は使えるが、保守しにくい | 小〜中 | 業務上の効果が見えにくい |
| リアーキテクト | システムの構造を再設計し、API化やクラウド対応を行う | 他システムとの連携を増やしたい | 中〜大 | 設計力が求められる |
| リビルド | 最新の技術でシステムを作り直す | 独自のロジックが競争力の源泉になっている | 大 | 現行機能の洗い出し漏れが起きやすい |
| リプレース | パッケージやSaaSに置き換える | 業界標準の業務で対応できる | 中〜大 | 業務プロセスをパッケージに合わせる必要がある |
※コスト・期間は手法同士の相対的な目安です。実際の規模や費用は、システムの規模や要件によって大きく異なります。
＞＞＞関連記事：レガシーシステム刷新ではRehost・Replatform・Rebuildのどれを選ぶべき？違い・メリット・選び方を比較
製造業での手法の選び方
製造業では、1つのシステムの中でも、機能ごとに最適な手法が異なることがよくあります。
- 生産計画や工程管理など、自社独自のノウハウが詰まった機能：競争力の源泉になっている場合は、リビルドやリアーキテクトで自社に合った仕組みを維持します。
- 会計や購買など、標準化しやすい業務：パッケージやSaaSへのリプレースで、保守負担を減らします。
- 機能は安定しているが、基盤の保守期限が迫っているシステム：まずリホストで基盤のリスクを解消し、その後、段階的に機能の刷新を進めます。
レリパ（Relipa）のレガシーシステム刷新・モダナイゼーション支援では、現状診断の結果をもとに、これらの手法を機能ごとに組み合わせた刷新方針をご提案しています。
「旧システムの再現」にこだわらない
レガシーシステムの刷新でよくあるのが、旧システムの機能や画面をそのまま再現しようとして、費用と期間が膨らむケースです。パッケージを導入する場合は、業務をパッケージの標準機能に合わせる「Fit to Standard」の考え方が基本になります。
すべてを標準に合わせる必要はありませんが、「この機能は本当に必要か」「現在の業務のやり方は今後も続けるべきか」を見直すことが、刷新後の保守性を高めることにつながります。
レガシーシステム刷新の進め方【6ステップ】
刷新プロジェクトの全体像を、6つのステップで紹介します。ステップ4〜6の移行と切替の詳細は、次の章で解説します。
| ステップ | 主な作業 | 成果物 | 製造業でのポイント |
|---|---|---|---|
| 1. 現状調査・資産の棚卸し | プログラム、データ、外部連携、バッチ処理、帳票を洗い出す。設計書がない場合はソースコードから仕様を分析する | 資産一覧、課題一覧 | 現場へのヒアリングで、Excelでの補完作業や暗黙のルールも洗い出す |
| 2. 目的・刷新方針の策定 | 刷新の目的、KPI、予算、対象範囲を決める | 刷新方針書 | 「古いから替える」ではなく、生産性や品質など事業上の目的と結び付ける |
| 3. 手法・移行方式・アーキテクチャの設計 | 機能ごとの刷新手法、移行方式、新システムの構成を決める | 移行計画書、アーキテクチャ図 | 設備や他システムとのインターフェースを設計する |
| 4. 段階的な開発・移行 | 範囲を分け、パイロットから順に開発・移行する | 稼働可能なシステム（一部） | 影響の小さい範囲から始める |
| 5. テスト・検証 | 新旧の結果を比較するテスト、性能テスト、設備との接続テスト、受け入れテスト | テスト結果、本番切替の判定資料 | 繁忙期の処理量を想定した性能テスト、現場担当者による受け入れテスト |
| 6. 本番切替・定着化 | 本番切替、利用者教育、切替直後の集中サポート、継続的な改善 | 運用マニュアル、改善計画 | 切替直後はサポート体制を厚くする |
特に重要なのが、ステップ1の現状調査です。前述のとおり、現行システムの複雑さを把握できないまま進めると、後の工程で想定外の機能や連携が見つかり、手戻りが発生します。現状調査には、全体の工程の中で十分な期間を確保しましょう。
＞＞＞関連記事：
工場を止めない移行方式と切替計画
ここからが、製造業のレガシーシステム刷新で最も重要なポイントです。新しいシステムをどれだけ丁寧に作っても、切替の方法を誤れば、生産が止まるリスクがあります。
3つの移行方式を比較する
| 方式 | 進め方 | 業務停止の時間 | リスク | 向いているケース |
|---|---|---|---|---|
| 一括移行（ビッグバン） | すべての機能を一度に新システムへ切り替える | 短いが、切替日に集中する | 高い（問題が起きると影響範囲が大きい） | 小規模で、他システムとの依存が少ない |
| 段階移行 | 機能、工場、ラインなどの単位で順に切り替える | 分散される | 中程度 | 製造業の多くのケース |
| 並行稼働 | 新旧システムを同時に動かし、結果を照合してから切り替える | 切替方法やデータ同期の仕組みによって異なる | 新旧の結果を照合できる一方、二重運用やデータ不整合への対策が必要 | 処理結果の正確性を事前に確かめたい重要なシステム |
実際のプロジェクトでは、これらを組み合わせるのが一般的です。例えば、「機能単位で段階移行し、各段階で一定期間の並行稼働を行う」といった進め方です。
一括移行は、関係するシステムの依存関係が少ない場合や、新旧のデータ構造が大きく異なり並行稼働が難しい場合に選ばれることがあります。ただし、その場合でも、移行リハーサルと切り戻し手順の準備は欠かせません。
分割の単位とパイロット導入
段階移行では、どの単位で分割するかを最初に決めます。
- 機能単位：在庫照会、受注、生産計画など、機能ごとに切り替える
- 工場単位：複数の工場がある場合、1つの工場をパイロットとして先行導入する
- ライン・製品単位：特定のラインや製品群から切り替える
パイロットには、業務への影響が比較的小さいこと、現場に協力的なキーパーソンがいること、効果を測定しやすいこと の3つの条件を満たす範囲を選ぶと、スムーズに進みやすくなります。パイロットで得られた課題や運用ノウハウを、次の段階の計画に反映させましょう。
ストラングラーパターンで少しずつ置き換える
段階移行を実現する代表的な設計の考え方が、「ストラングラー（ストラングラーフィグ）パターン」です。旧システムの周りに新しい仕組みを少しずつ作り、機能を段階的に移していくことで、最終的に旧システムを置き換えます。
- 旧システムと利用者・他システムの間に、APIなどの中継の仕組みを設ける
- 1つの機能を新システムで作り、中継の仕組みでその機能へのアクセスを新システムに振り向ける
- 問題がないことを確認したら、次の機能を移す
- すべての機能を移し終えたら、旧システムを停止する
例えば、「在庫照会 → 受注 → 生産計画」のように、参照系の機能や影響の小さい機能から移していく進め方が考えられます（あくまで一例です）。この方法であれば、一度に切り替える範囲を小さくでき、問題が起きた場合も、その機能だけを旧システムに戻すことができます。
並行稼働の進め方と終了の判断
並行稼働では、同じ業務データを新旧両方のシステムで処理し、結果を照合します。
- 照合する項目を決める：在庫数、所要量計算の結果、生産計画、帳票の出力内容など
- 差異が出た場合のルールを決める：差異の原因を調べ、新システムの不具合か、旧システムの仕様（または不具合）かを判断する
- 二重入力の負荷を減らす：新旧両方への入力は現場の負担になります。データ連携で自動的に同期する、並行稼働の期間をあらかじめ決めるなどの工夫が必要です
- 終了条件を決める：例えば「月次の締め処理を含む一定期間、重要項目の差異がないこと」など、並行稼働を終える条件を事前に合意します
並行稼働は、新旧の結果を照合して問題を事前に見つけられる反面、期間が長引くと現場の負担とコストが増えます。また、並行稼働をしていても、正式な処理を新システムへ切り替える時点では、データの最終同期や他システムとの接続切替のために、短時間の停止が必要になる場合があります。終了条件と最終切替の手順を明確にし、ずるずると続けないことが大切です。
生産計画に合わせた切替タイミング
本番切替の日程は、生産計画と業務カレンダーに合わせて決めます。
- 切替に適した時期：年末年始、ゴールデンウィーク、夏季休暇などの長期休暇、計画停止日
- 避けるべき時期：繁忙期、月末・期末の締め処理、棚卸しの時期、新製品の立ち上げ時期
切替日が決まったら、そこから逆算して、移行リハーサル、受け入れテスト、利用者教育などのスケジュールを組み立てます。長期休暇は年に数回しかないため、切替日を逃すと次の機会まで数か月待つことになる点にも注意が必要です。
切り戻し（ロールバック）の設計
どれだけ準備をしても、本番切替で想定外の問題が起きる可能性はあります。そのため、問題が起きたときに旧システムへ戻す手順 を、切替計画の一部として設計しておきます。
- Go/No-Go判定の基準：切替を進めるか、中止して戻すかを判断する基準（例：データ件数・金額の一致、主要な処理の正常終了、設備との通信確認）
- 判断する人と期限：誰が、いつまでに判断するかを決めておく。判断が遅れると、戻すための時間がなくなります
- 旧システムの保持：切替後も一定期間、旧システムをすぐに再稼働できる状態で残しておく
- 代替運用：システムが使えない時間帯に、紙やExcelで業務を続ける手順を用意する
切り戻し手順は、作るだけでなく、移行リハーサルの中で実際に試しておくことが重要です。具体的な確認項目は、次の章のチェックリストにまとめています。
データ移行・本番切替のチェックリストとよくある失敗
データ移行チェックリスト
- 品目、部品表（BOM）、工程、取引先などのマスタデータを整備した（重複、表記ゆれ、使われていないコードの整理）
- 履歴データ・トレーサビリティデータの移行範囲と保存期間を決めた
- 移行しない古いデータを、刷新後にどのように参照するかを決めた
- 文字コードや外字（独自に作成した文字）の変換方法を確認した
- 切替時点の仕掛品や、処理途中の受注・発注の扱いを決めた
- 移行リハーサルを複数回実施し、実際にかかる時間を計測した
- 移行後のデータ件数・金額・数量を、旧システムと照合する方法を決めた
本番切替チェックリスト
- 時間単位の切替スケジュールを作成した
- Go/No-Go判定会議の基準、参加者、判定時刻を決めた
- 切り戻し手順書を作成し、リハーサルで検証した
- 緊急時の連絡体制（社内、開発会社、設備メーカー）を整えた
- 取引先や顧客へ、必要に応じて事前に通知した
- システムが使えない時間帯の代替運用（紙・Excel）を準備した
- 切替直後の問い合わせ窓口と、集中サポートの体制を決めた
- 利用者向けの操作教育とマニュアルを用意した
よくある失敗と対策
| 失敗 | 主な原因 | 早期に気づくためのサイン | 対策 |
|---|---|---|---|
| 切替日に障害が起き、生産が止まる | 一括移行、リハーサル不足 | 本番と同じ手順での移行リハーサルを一度も行っていない | 段階移行と並行稼働、複数回のリハーサル |
| 隠れた機能やExcel運用が漏れる | 現状調査の不足 | 現場担当者へのヒアリングが行われていない | 資産の棚卸しと現場ヒアリング |
| 刷新したシステムが現場で使われない | 現場が計画に参加していない | 受け入れテストを情報システム部門だけで行っている | 現場のキーパーソンを初期から参画させる |
| 費用と期間が膨らむ | 旧システムをそのまま再現しようとする | 「今と同じにしてほしい」という要望が多い | Fit to Standardの考え方で要件を見直す |
| 新システムが再びブラックボックスになる | 設計書やソースコードが引き継がれていない | 契約に成果物や権利の範囲が明記されていない | 成果物（設計書・ソースコード）と権利の帰属を契約で明確にする |
レガシーシステム刷新の費用・期間の考え方
費用を左右する要因
レガシーシステム刷新の費用は、システムの規模や手法によって大きく異なるため、一律の相場で判断することは困難です。見積もりを比較する際は、次の要因を確認しましょう。
- システムの規模：プログラム数、画面数、帳票数、外部連携の数
- 刷新手法：リホストは比較的小さく、リビルドは大きくなる傾向
- 設計書の整備状況：設計書がない場合、現状調査の工数が増える
- データ量とデータの品質：マスタの整備が必要な場合、移行の工数が増える
- 対象の工場・拠点の数：段階移行の回数が増えると、移行とテストの工数が増える
- テストの範囲：設備との接続テストや性能テストの範囲
- 並行稼働の期間：新旧2つのシステムを運用する期間の費用と、現場の負担
＞＞＞関連記事：
期間の目安
刷新の期間も、対象範囲によって大きく変わります。参考として、Relipaのレガシーシステム刷新サービスでは、一般的なプロジェクト期間の目安を3〜9か月程度としています。ただし、これは対象範囲や前提条件によって変わる目安です。複数の工場にまたがる基幹システムを刷新する場合、設計書がなく現状調査に時間がかかる場合、並行稼働の期間を長く取る場合などは、さらに長くなります。製造業では、切替のタイミングが長期休暇に限られることも多いため、全体のスケジュールは切替可能な日から逆算して計画しましょう。
費用を抑えるための工夫
- 刷新範囲の優先順位を付ける：すべてを一度に刷新せず、リスクの高い部分から着手する
- 再利用できる資産を活かす：業務ロジックやデータ構造のうち、使えるものは引き継ぐ
- 標準業務にはパッケージやSaaSを使う：独自開発は競争力につながる領域に絞る
- 開発体制を工夫する：継続的に段階移行を進める場合は、専属チームで開発を続けるラボ型開発も選択肢になります。
＞＞＞関連記事：
レガシーシステム刷新パートナーの選び方
レガシーシステムの刷新は、新規開発とは異なる知識と経験が求められます。パートナーを選ぶ際は、次の観点で確認しましょう。
| 確認項目 | なぜ重要か | 質問の例 |
|---|---|---|
| 旧技術と新技術の両方の経験 | 現行システムを正しく理解できなければ、要件が漏れる | 当社のシステムで使っている言語や基盤（COBOL、VB、Oracle Formsなど）の経験はありますか？ |
| 現状調査の進め方 | 設計書がないことは珍しくない | 設計書がない場合、どのように仕様を分析しますか？ |
| 停止を最小限にする移行の経験 | 製造業の刷新で最も大きなリスク | 段階移行や並行稼働、切り戻しを計画・実施した経験はありますか？ |
| 製造業の業務への理解 | 業務を理解していないと、要件の確認に時間がかかる | 生産管理やMESに関わる開発の経験はありますか？ |
| 日本語でのコミュニケーション | 現場の要望を正確に伝える必要がある | 窓口となる担当者は誰で、どのような体制ですか？ |
| セキュリティと成果物の引き継ぎ | 再びブラックボックス化することを防ぐ | 取得している認証は何ですか？設計書やソースコードの権利はどうなりますか？ |
| 切替後のサポート | 切替直後は問い合わせや不具合が集中する | 本番切替後、どのくらいの期間、どのような体制でサポートしますか？ |
よくある質問
Q1. 工場を一切止めずに、レガシーシステムを刷新することはできますか？
システムの構成や設備との連携の状況によって異なります。段階移行や並行稼働を組み合わせることで、生産への影響を最小限に抑えることは可能です。一方で、データの最終的な移行や設備との接続の切替など、短時間の停止が必要になる場面もあります。現実的な目標は「停止をゼロにすること」ではなく、「停止を計画された時間内に収めること」です。
Q2. 設計書が残っていなくても刷新できますか？
可能です。ソースコードやデータベースの構造、画面や帳票、現場担当者へのヒアリングから現行の仕様を分析します。ただし、その分だけ現状調査に時間がかかるため、計画の段階で十分な期間を見込んでおく必要があります。
Q3. COBOLやオフコンの資産は、どのように扱えばよいですか？
選択肢は、基盤だけを移すリホスト、別の言語への変換、作り直し（リビルド）、パッケージへの置き換え（リプレース）などがあります。業務ロジックの複雑さ、保守できる人材の有無、将来の拡張性を踏まえて選びます。機能ごとに異なる手法を組み合わせることもできます。
Q4. 刷新にはどのくらいの期間がかかりますか？
対象の範囲や手法によって大きく異なります。一部の機能の刷新であれば数か月、複数の工場にまたがる基幹システムの刷新であれば1年以上かかることもあります。製造業では、切替のタイミングが長期休暇などに限られるため、切替可能な日程から逆算して計画することが大切です。
Q5. パッケージ（ERP）とスクラッチ開発は、どちらを選ぶべきですか？
標準化しやすい業務（会計、購買など）はパッケージ、自社独自のノウハウが競争力になっている業務（生産計画、工程管理など）はスクラッチ開発、と使い分けるのが一般的な考え方です。パッケージを選ぶ場合は、過度なカスタマイズを避けることが、将来の保守性を高めるポイントです。
Q6. 生産設備（PLC・制御系）も刷新の対象になりますか？
情報システムの刷新と、制御システムの更新は、別の計画として扱うのが一般的です。ただし、両者の接続部分（データの受け渡しや通信方式）は、情報システムの刷新に合わせて見直しが必要になることがあります。設備メーカーや設備のインテグレーターと早い段階から連携しましょう。
Q7. 古い品質記録やロット履歴は、どのように扱えばよいですか？
すべてを新システムへ移行する方法のほか、一定期間分だけを移行し、それより古いデータは参照専用の仕組みで保管する方法もあります。顧客との契約や業界のルールで求められる保存期間を確認したうえで、移行範囲と参照方法を決めましょう。
まとめ
製造業のレガシーシステム刷新で最も避けたいのは、切替の失敗で生産が止まることです。現場のExcel運用まで含めて現状を棚卸しし、機能ごとに適した手法を選んだうえで、影響の小さい範囲から段階的に切り替えましょう。切替は長期休暇や計画停止日に合わせ、切り戻し手順をリハーサルで確かめておくことが大切です。設計書とソースコードを確実に引き継ぎ、新しいシステムを再びブラックボックスにしないことも忘れないようにしましょう。
レリパ（Relipa）では、レガシーシステムの現状診断から、刷新の方針と手法の選定、段階的な移行計画、開発、テスト、本番切替後の運用支援までを一貫してご支援しています。
「どこから手を付ければよいか分からない」「設計書が残っていないシステムを刷新したい」「工場を止めずに切り替える方法を相談したい」といった段階からのご相談も歓迎しています。現在のシステム構成、課題、切替が可能な時期をお伺いしたうえで、刷新の進め方をご提案します。
レリパ（Relipa）は東京とハノイに拠点を持ち、日本語に対応したブリッジSEが窓口となって、ご要望を開発チームに正確にお伝えします。また、品質マネジメントシステム（ISO 9001）と情報セキュリティマネジメントシステム（ISO/IEC 27001）の認証を取得しており、現行システムの情報やソースコードをお預かりする刷新プロジェクトでも、定められた管理体制のもとで作業を進めます。
