長年、生産管理や販売管理を支えてきたオフコン（オフィスコンピュータ）が、いよいよ限界を迎えつつある——。ハードの保守期限が迫り、開発言語を扱える技術者も社内に残っていない。それでも「止めると業務が回らない」ため、移行に踏み切れないまま毎年の保守費を払い続けている情シス担当者の方は少なくありません。

本記事では、オフコンの移行・リプレースを、失敗せず・後悔せず進めるための現実的な手順を、SIer目線で解説します。使い続けるリスクの整理から、リホスト・リライト・リビルド・パッケージ移行という4つの移行方式の比較、費用相場とその落とし穴、5年TCO（総保有コスト）での判断、そして外注先の選び方まで、順を追って答えていきます。

想定読者

本記事は、次のような方を想定しています。

• オフコンの老朽化・サポート終了が近づき、移行を検討し始めた製造業・卸売業の情シス担当者
• ベンダーから提示された移行見積が妥当かどうか判断したい経営者・管理部門の方
• リホストとリビルドなど、移行方式の違いと費用感を整理したい方
• 「オフコンを脱却したいが、何から手をつければいいのか」がわからない方
• 過去の基幹システム刷新で失敗した経験があり、次は慎重に進めたい方

オフコンを使い続ける3つのリスク

オフコンは堅牢で安定稼働しやすく、「動いているうちは触らない」という判断がされがちです。しかし、稼働し続けているという事実は、リスクが無いことを意味しません。むしろ、放置している間に静かにリスクが積み上がっていきます。代表的なものは次の3つです。

ハード保守終了とサポート終了

オフコン最大のリスクは、ハードウェアの保守期限とOS・ミドルウェアのサポート終了です。保守が切れた機器は、故障しても交換部品がなく、修理できないまま業務が止まる恐れがあります。中古部品でしのぐケースもありますが、それは時間を買っているだけで、根本的な解決にはなりません。

さらに、サポートが終了したOSはセキュリティパッチが提供されなくなります。オフコンは社内ネットワークに閉じているから安全、という認識は、ランサムウェアが取引先経由・保守回線経由で侵入する現在では通用しません。「壊れてから考える」では、代替システムの構築に半年〜1年かかる間、業務を止められないという最悪の状況に追い込まれます。

技術者の枯渇と属人化

オフコンで使われるRPGやCOBOL、独自の第4世代言語（4GL）を扱える技術者は、年々減少しています。開発を担ってきた社員やベンダー担当者が定年・引退を迎えると、「誰も中身を直せないシステム」が残ります。

新規に技術者を採用しようにも母数が少なく、採用できても習熟には時間がかかります。結果として、ちょっとした帳票の追加や税制改正への対応にも高額・長期の見積が返ってくるようになり、事業のスピードに情報システムがついていけなくなります。

業務のブラックボックス化

長年の改修を重ねたオフコンは、仕様書が現状と一致していないことがほとんどです。「なぜこの計算をしているのか」「この条件分岐は何のためか」を説明できる人がいなくなると、システムはブラックボックス化します。

ブラックボックス化したシステムは、移行しようとした瞬間に「そもそも今の仕様がわからない」という壁にぶつかります。移行の難易度は、放置期間が長いほど上がっていくのです。だからこそ、まだ仕様を知る人が社内に残っているうちに動き出すことが重要になります。

オフコン移行の4つの方式を比較する

オフコンの移行と一口に言っても、アプローチは大きく4つに分かれます。どれを選ぶかで費用も期間もリスクも大きく変わるため、まず全体像を押さえることが重要です。

リホスト（環境だけ載せ替える）

リホストは、既存のプログラム資産をできるだけ活かしたまま、稼働環境だけをオープン系サーバーやクラウドへ載せ替える方式です。専用のマイグレーションツールでRPGやCOBOLの資産を新環境向けに変換し、業務ロジックは基本的に維持します。

短期間・低リスクで「まず動く環境」を確保できるのが最大の利点です。一方で、古い業務ロジックや非効率な処理もそのまま持ち込むため、ブラックボックス構造は解消されません。「延命」に近い位置づけで、抜本的な業務改善は次のフェーズに委ねる考え方です。

リライト（ロジックを新言語へ書き換える）

リライトは、既存の業務ロジックを維持しつつ、プログラムをJavaやC#などのオープン系言語へ書き換える方式です。ロジックは踏襲するため業務への影響を抑えられ、かつ技術者が扱いやすいモダンな言語基盤へ移せます。

ただし、既存仕様の解読が前提になるため、ブラックボックス化が進んでいると工数が跳ね上がります。「仕様がわかっていること」がリライト成功の前提条件です。

リビルド（業務ごと作り直す）

リビルドは、現行仕様に縛られず、業務要件を再定義してシステムをゼロから作り直す方式です。長年の「使いにくさ」や「業務の歪み」を根本から改善でき、将来の拡張性も最も高くなります。

反面、費用と期間は4方式の中で最大で、要件定義の巧拙が成否を左右します。現場を巻き込んだ体制づくりが不可欠で、「作り直すこと」自体が一大プロジェクトになります。

パッケージ移行（ERP等へ乗せ換える）

パッケージ移行は、自社開発をやめ、市販の生産管理・販売管理パッケージやERPへ業務を寄せる方式です。標準機能に業務を合わせられれば、保守負担を大きく減らせます。

課題は、パッケージの標準に合わない独自業務をどう扱うかです。過度なカスタマイズは「第二のオフコン」を生むため、業務側を標準に合わせる意思決定とセットで進める必要があります。

4方式の特徴を整理すると、次のようになります。

どれが正解かは一律には決まりません。「保守終了まで時間がないならリホストで延命 → 数年かけてリビルド」といった二段構えも実務ではよく採られます。まずは自社の制約（期限・予算・業務改善の必要度）を整理することが出発点です。

オフコン移行・リプレースの費用相場

費用は移行方式と規模、そして既存資産の量によって大きく変わるため、一律の相場を示すことはできません。移行支援を手がける各社が公開している目安を総合すると、方式別の初期構築費はおおむね次のようなレンジで語られています（企業規模・資産量・連携の複雑さによって数倍変動します）。

数字はいずれも「規模による」ものであり、自社の見積は必ず現物（資産本数・データ量・連携数）を棚卸ししたうえで確認してください。金額の幅が大きいのは、既存資産の本数・データ移行の複雑さ・周辺システムとの連携数・現場の巻き込み度合いによって工数が数倍変わるためです。

「見えない費用」で当初見積を上回りやすい

見積を受け取るときに最も注意すべきは、提示額は最初のスタートラインに過ぎないという点です。オフコン移行では、次のような「見積に含まれにくい費用」が後から積み上がります。

• 現状仕様の調査・解析（ブラックボックス解読）の追加工数
• データ移行時に判明する不整合データのクレンジング
• 周辺システム・帳票・EDIとの連携改修
• 並行稼働期間の二重運用コスト（旧環境の保守費が重なる）
• 現場教育・マニュアル整備・移行後の初期サポート

こうした「見えない費用」を含めると、最終的な実質コストは当初のベンダー提示額を上回りやすい傾向があります。移行事業者の中には、実質コストは提示額の1.4〜1.7倍程度に着地することが多いと指摘する例もあります。金額の大小だけでなく「どこまで見積に含んでいるか」を必ず突き合わせ、相見積もりでは含む範囲をそろえて比較してください。

初期費用でなく5年TCOで判断する

移行の意思決定を初期費用だけで行うと、判断を誤ります。正しくは、現行維持と移行後を「5年間の総保有コスト（TCO）」で比較することです。

TCOに含めるべき主な項目は次のとおりです。

• ハードウェア・OS・ミドルウェアの保守費（年額）
• 開発言語・技術者確保のためのベンダー費（改修単価が高止まりする点に注意）
• 障害・トラブル対応の実費と機会損失
• 法改正・制度対応（インボイス・電子帳簿保存等）の都度発生コスト
• 電力・設置スペース等の運用コスト

現行オフコンを維持する場合、これらは年々上昇していく傾向にあります。特に「改修が必要になるたびに割高な見積が返ってくる」構造は、5年で見ると初期の移行費用を上回ることが多々あります。

考え方をごく簡単な例で示すと、次のようになります（数値は説明用の一例です）。

このケースでは、初期費用2,000万円を投じても、5年トータルでは移行後のほうが安くなります。さらに、移行後は障害リスクの低減・技術者確保のしやすさ・業務改善の余地といった「金額に表れない価値」も得られます。判断の土俵を初期費用からTCOへ移すことが、オフコン移行を正しく決断する第一歩です。判断基準をさらに詳しく知りたい方は、基幹システムの移行・リプレイスを決断する5つの判断基準も参考になります。

移行方式の選定やTCO試算は、自社だけで精緻に行うのが難しい領域です。「まず自社のオフコンでどのくらいコストが下げられるのか試算したい」という段階から、専門家に相談するのが近道です。

---

移行プロジェクトの進め方と失敗回避

方式と費用感が見えたら、次はプロジェクトの進め方です。オフコン移行は、大きく次の5ステップで進めます。

1. 現状の棚卸し（プログラム資産・データ・帳票・連携・業務フローの可視化）
2. 移行方式の選定と要件定義（残す機能・捨てる機能の仕分け）
3. 設計・構築（新環境の構築、プログラム変換・開発、データ移行設計）
4. データ移行と並行稼働（旧環境と新環境を一定期間並走させ整合を検証）
5. 本番切替と運用定着（現場教育・初期サポート・旧環境の廃止）

このうち、成否を分けるのは最初の「棚卸し」と、後半の「並行稼働」です。棚卸しを省くと、移行の途中で未知の仕様が次々に出てきて、費用も期間も膨らみます。並行稼働を省いて一気に切り替えると、データ不整合や処理漏れが本番で発覚し、業務停止に直結します。

つまずきやすい失敗と回避策

オフコン移行で繰り返される失敗には、パターンがあります。代表的なものと回避策を整理します。

これらの失敗の多くは、「時間がない」「予算がない」を理由に工程を省いた結果として起きます。逆に言えば、棚卸し・データ移行・並行稼働の3工程を丁寧に踏めば、オフコン移行の失敗リスクは大きく下げられます。

自社対応か外注か、外注先の選び方

オフコン移行を自社リソースだけで完遂するのは、現実には困難です。旧環境の言語知識と新環境の技術、その両方を持つ人材が社内に揃っていることは稀だからです。多くの場合、外部パートナーの活用が現実解になります。

外注先を選ぶときは、次の観点で見極めてください。

• 旧環境（オフコン・RPG・COBOL・4GL）と新環境の両方を理解しているか：どちらか片方だけだと、仕様の橋渡しで齟齬が生じます
• 移行方式をゼロベースで提案してくれるか：自社の得意な方式に誘導せず、TCOで最適解を示してくれるか
• 棚卸し・データ移行・並行稼働まで一貫して支援できるか：構築だけで手離れするベンダーは、最も難しい後半で頼れません
• 製造業・自社業種の業務理解があるか：生産管理・原価計算・EDIなど、業種特有の勘所を押さえているか
• 見積の内訳が透明か：「含まれていない費用」を事前に説明してくれるか

安さだけで選ぶと、後から追加費用が積み上がり、結局は割高になります。「どこまで含むか」「後半まで伴走できるか」を軸に選ぶことが、TCOを本当に下げる近道です。マイグレーション全体の流れや注意点は、マイグレーションとは？実施する流れや注意点を解説でも整理しています。

よくある質問

Q. オフコンはまだ問題なく動いています。それでも今すぐ移行を検討すべきですか？

A. 「動いている」ことと「リスクが無い」ことは別です。ハード保守終了・技術者の引退・仕様のブラックボックス化は、放置期間が長いほど移行難易度と費用を押し上げます。仕様を知る人が社内に残っているうちに、まず棚卸しと方式検討だけでも始めることを強くおすすめします。

Q. なるべく安く済ませたいのですが、どの方式が最もコストを抑えられますか？

A. 初期費用だけならリホスト（環境の載せ替え）が最も安価です。ただしブラックボックス構造は残るため、5年TCOで見るとリライトやパッケージ移行のほうが有利になるケースもあります。初期費用ではなくTCOで比較することをおすすめします。

Q. AS/400（IBM i）やCOBOL資産の移行も相談できますか？

A. 可能です。AS/400固有のモダナイズの進め方はこちらの記事、COBOL言語資産の移行はCOBOL基幹システムの移行ガイドで詳しく解説しています。本記事はオフコン全般の移行実務としてご覧ください。

Q. 移行にはどのくらいの期間がかかりますか？

A. 方式と規模によります。移行支援各社の公開情報では、環境を載せ替えるリホストでおおむね半年〜1年程度、業務を作り直すリビルドやパッケージ移行では1年半〜2年程度を見込む例が多いとされています。並行稼働期間を確保する分、余裕を持った計画が失敗を防ぎます。

Q. 移行中に業務を止めずに進められますか？

A. はい。旧環境と新環境を一定期間並走させる「並行稼働」を設計に組み込むことで、業務を止めずに切り替えられます。一発切替はリスクが高いため、並行稼働での結果突合を推奨しています。

まとめ

オフコンの移行・リプレースについて、要点を整理します。

• オフコンを使い続けるリスクは、ハード保守終了・技術者の枯渇・業務のブラックボックス化。放置するほど移行難易度と費用が上がる
• 移行方式はリホスト・リライト・リビルド・パッケージ移行の4つ。費用・期間・業務改善効果が異なり、二段構えの併用も現実的
• 費用は方式・規模・資産量で大きく変わり、一律の相場はない。データ移行・並行運用・教育などの「見えない費用」で当初見積を上回りやすいため、「どこまで含むか」を必ず確認する
• 判断は初期費用でなく5年TCOで行う。改修・制度対応・障害コストまで含めると、移行後が有利になるケースが多い
• 成否を分けるのは棚卸し・データ移行・並行稼働の3工程。ここを省くと失敗する
• 外注先は「旧環境と新環境の両方を理解し、後半まで伴走できるか」で選ぶ

オフコン移行は、先送りするほど不利になる案件です。仕様を知る人が社内にいるうちに、まず現状の棚卸しと方式検討から動き出すことが、コストとリスクを最小化する最善策になります。

---

c3index に相談する

c3index は、製造業の基幹システム・レガシー移行・クラウド移行を専門とするシステム会社です。オフコンからの移行を、現行資産の棚卸しから移行方式の選定・TCO試算・設計構築・並行稼働の検証・運用定着まで一貫してご支援します。「まず自社のオフコンでどのくらいコストが下げられるのか試算したい」という段階からのご相談も歓迎です。まずはお気軽にお問い合わせください。