「うちはまだオフコンで動いている」——中堅製造業・卸売業の経営者から、いまだに聞こえる言葉です。30 年以上稼働してきたオフコンは業務にぴったり合っていて、動いてさえいれば不便はない。しかし、サポート終了、技術者の枯渇、取引先からのデジタル化要求が同時に押し寄せ、『動いている』こと自体が経営リスク になりつつあります。本記事では、オフコン移行を中堅企業の経営者向けに 完全ガイド として整理。現状認識、移行の必要性、3 つの手法、費用・期間、事例、失敗パターン、判断チェックリストまで、25 年の現場経験に基づいて解説します。
『うちのオフコン、いつ移行すべき？』とお悩みではありませんか？ 25 年の経験で判断軸を一緒に整理します。 無料相談 ＞オフコンの現状認識：消えゆく『隠れた基幹』
オフィスコンピューター（オフコン）は、1980～90 年代に中堅・中小企業の基幹システムとして広く導入された専用機です。汎用機（メインフレーム）より小型・低コストでありながら、PC より高性能・高信頼性で、製造業の生産管理・原価計算、卸売業の販売管理、建設業の工事管理など、業務にぴったり合った独自仕様で 30 年以上稼働してきました。
主要メーカーと機種
| メーカー | 代表機種 | 主な言語 |
|---|---|---|
| 富士通 | K シリーズ／PRIMERGY 6000 | COBOL・RPG |
| NEC | EXPRESS5800／A-VX（旧 System 100/3100） | COBOL・RPG・SMART |
| IBM | IBM i（旧 AS/400・iSeries・System i） | RPG・COBOL |
| 日立 | HITAC（旧）／HA8000 系 | COBOL・RPG |
| 東芝・三菱・ユニシス | 各社専用機 | 独自言語含む |
国内導入企業数の推計
近年の調査によれば、現役で稼働しているオフコンは 数万台規模 と推計されています。特に IBM i（AS/400 後継機）は今も製造・卸売・建設の中堅企業で広く使われており、その数は中堅企業の数百～千社単位とも言われます。
なぜここまで残ったのか
オフコンが長く残った理由は、3 つあります。
- 業務に完全フィット：30 年かけて積み上げられた独自仕様が、自社業務にぴったり合っている
- 安定稼働：ハードウェアの信頼性が高く、障害が極めて少ない
- 移行リスクへの恐れ：「動いているのに、わざわざリスクを取って移行する理由がない」という経営判断
しかし、これらの『残った理由』が今、『移行できない理由』 に変わりつつあります。
なぜ今、オフコン移行をやるべきか
オフコン移行は、もはや『いつかやればいい』ではなく、『いつ着手するか』 の問題になっています。5 つの圧力が同時に押し寄せているからです。
圧力 1：ハードウェア・OS のサポート終了
主要メーカーは段階的にオフコンの保守を縮小・終了しています。富士通の K シリーズはすでに保守終了済み。NEC の A-VX、日立の旧機種も同様。延長保守はあっても、年々保守費が高騰し、いずれは完全終了 します。IBM i は比較的長期サポートですが、それでも世代ごとの保守ライフサイクルがあります。
圧力 2：技術者の枯渇
COBOL、RPG、メーカー独自言語を扱える技術者の平均年齢は 50 代後半～60 代。新卒で COBOL を学ぶ機会は皆無に近く、10 年後には技術者がほぼいない 状態が予想されます。社内のキー技術者が退職した瞬間、システムは『誰も触れない箱』に。
圧力 3：業務変化への追従不能
中堅企業の業務は、事業拡大、海外取引、新規業態、M&A など、絶えず変化しています。オフコンの独自仕様での改修は、改修費の高騰と納期長期化を招き、業務変化のスピードに追いつけなく なります。
圧力 4：法制度対応の重圧
電子帳簿保存法、インボイス制度、改正電子取引保存法、サイバーセキュリティ対策——次々と新しい法制度・規制が導入されています。古いオフコンでの対応は技術的に困難、または対応費用が刷新費に近づく ケースが頻発。
圧力 5：取引先からのデジタル化要求
大手取引先からの EDI 対応強化、トレーサビリティ要求、API 連携要求が増加。オフコンではこれらに対応しきれず、取引縮小・新規取引機会の喪失 につながります。中堅企業（年商 50 億円規模）では、年 1,000～2,000 万円規模の機会損失が見込まれます。
オフコン移行の『3 つの手法』
オフコン移行には、主に 3 つのアプローチがあります。自社の状況・予算・業務独自性に応じて選択します。
手法 1：リホスト（基盤のみ移行・機能はそのまま）
オフコンの COBOL/RPG プログラムを、ロジックはほぼそのままにオープン系サーバ（Linux/Windows）またはクラウドへ移行する手法。業務インパクトが最小、短期間（8～12 ヶ月）で稼働 可能ですが、業務改革効果は限定的です。
手法 2：リライト（再構築・業務改革を伴う）
既存の業務要件を見直しながら、新しいプラットフォーム（Java / .NET など）で再構築。業務プロセスを刷新できる ため改革効果は大きいが、期間 18～24 ヶ月、費用も高めになります。
手法 3：パッケージ移行（業界特化 ERP への置き換え）
オフコンを業界特化型のパッケージ ERP（製造業向け／卸売業向け／建設業向け 等）に置き換える手法。業務をパッケージ標準に合わせる Fit to Standard が前提。中堅企業で最も成功率が高いアプローチです。
3 手法の比較
| 項目 | リホスト | リライト | パッケージ移行 |
|---|---|---|---|
| 業務改革効果 | 低 | 大 | 中～大（Fit to Standard 次第） |
| 期間 | 8～12 ヶ月 | 18～24 ヶ月 | 10～14 ヶ月 |
| 費用レンジ | 2,000 万～5,000 万円 | 8,000 万～2 億円 | 3,000 万～8,000 万円 |
| 業務独自性の維持 | 高（既存ロジック維持） | 中（再設計） | 低（パッケージ標準へ） |
| 稼働後の柔軟性 | 中 | 高 | 中（パッケージ仕様の範囲内） |
| 失敗リスク | 低 | 中～高 | 中（スコープ管理次第） |
オフコン移行の費用・期間
規模別の費用目安（中堅企業）
| 企業規模 | リホスト | パッケージ移行 | リライト |
|---|---|---|---|
| 従業員 50～150 名 | 1,500～3,000 万円 | 2,500～5,000 万円 | 5,000 万～1.2 億円 |
| 従業員 150～300 名 | 3,000～5,000 万円 | 5,000 万～1 億円 | 1～1.8 億円 |
| 従業員 300～500 名 | 5,000 万～8,000 万円 | 8,000 万～1.5 億円 | 1.5～2.5 億円 |
隠れコスト（ベンダー見積もり以外）
オフコン移行は、ベンダー支払額以外に 隠れコスト が発生します。
- 周辺機器の更新：オフコン専用の帳票プリンタ・MICR リーダー・専用端末などの置き換え（数百万～数千万円）
- 業務部門の工数：要件定義・UAT・移行リハーサルに業務時間の 20～30% を 1～2 年
- 並行運用コスト：旧システムと新システムの並行稼働期間の重複費用
- データ移行：過去 20～30 年の蓄積データの整備・移行
- 教育・定着支援：稼働後 90 日の現場教育（200～500 万円規模）
実コストはベンダー支払額の 1.3～1.5 倍を見込んでおくのが現実的です。
期間
方式により異なりますが、検討フェーズ（経営判断～RFP～ベンダー選定）に 3～6 ヶ月、要件定義～稼働に 8～24 ヶ月、稼働後 90 日の定着化を含めると、経営判断開始から成果獲得まで 15～33 ヶ月 が現実的なスケジュールです。
オフコン移行の事例（中堅企業モデル）
業種別の典型ケースを示します（業界一般のモデルケース）。
ケース 1：製造業 A 社（富士通 K → クラウド ERP）
| 規模 | 年商 80 億円／従業員 200 名（自動車部品） |
|---|---|
| 移行前 | 30 年使用の富士通 K シリーズ／COBOL 自社開発／月次決算 10 営業日 |
| 方式 | 業界特化クラウド ERP へのパッケージ移行（Fit to Standard 7 割） |
| 期間／投資額 | 18 ヶ月／8,000 万円 |
| 主な成果 | 月次決算 10 日 → 3 日／月次原価リアルタイム化／IT 保守費 年 1,200 万 → 600 万円 |
ケース 2：卸売業 B 社（IBM i → AWS リホスト）
| 規模 | 年商 150 億円／従業員 280 名（食品・酒類卸） |
|---|---|
| 移行前 | 25 年使用の IBM i（AS/400）／RPG／受発注処理が属人化 |
| 方式 | RPG プログラムを AWS（IBM Power Virtual Server）へリホスト＋段階的にリライト |
| 期間／投資額 | 14 ヶ月／6,500 万円 |
| 主な成果 | 業務継続性確保／ハード保守費 半減／3 年計画でリライトへ移行中 |
ケース 3：食品製造業 C 社（NEC A-VX → 業界特化パッケージ）
| 規模 | 年商 40 億円／従業員 100 名（食品加工） |
|---|---|
| 移行前 | 20 年使用の NEC A-VX／賞味期限管理が独自開発／取引先要求のトレーサビリティ未対応 |
| 方式 | 食品業界特化パッケージへの全面移行 |
| 期間／投資額 | 12 ヶ月／4,000 万円 |
| 主な成果 | トレーサビリティ対応／大手取引先との新規取引獲得／出荷ミス 1/5 削減 |
オフコン移行の失敗パターン
失敗パターン 1：移行先での『オフコン互換』にこだわる
「現行業務をそのままオープン系で動かしたい」という要件にすると、独自仕様の山を新環境で再現することになり、開発費が膨張。オフコン時代の業務独自性のうち、本当に競争力に直結する部分はわずか 1～2 割。残りはパッケージ標準で吸収すべきです。
失敗パターン 2：周辺機器を後回し
オフコン専用の帳票プリンタ、MICR リーダー、専用端末などの周辺機器は、新システムでそのまま使えないことが大半。後から気付いて追加予算が必要 になるパターン。要件定義段階で周辺機器のリストアップと代替手段の検討が必須です。
失敗パターン 3：業務独自仕様を全て再現しようとする
30 年蓄積された業務独自仕様（帳票フォーマット、特殊計算ロジック、例外処理など）を全て新システムで再現しようとすると、開発費が 2～3 倍に膨らみ、テストが終わらず炎上。Fit to Standard で 7 割を標準化、残り 3 割は本当に必要なものに絞る 経営判断が必要です。
失敗パターン 4：自社で技術者を確保しようとする
「COBOL/RPG が分かる技術者を採用して、自社で保守を続ける」という発想。求人を出しても応募がない、来てもすぐ離職、というケースが大半。『自社で抱える』のではなく『早期に脱却する』方向で経営判断 すべきです。
オフコン移行の『判断チェックリスト』
経営者が押さえるべき判断項目を整理します。3 つ以上当てはまったら、本格的な移行検討の時期です。
- ☐ ハードウェア・OS・パッケージのサポート終了が予告されている
- ☐ COBOL/RPG を保守できる技術者が社内に 1～2 名しかいない
- ☐ その技術者が 55 歳以上、または退職の可能性が見えている
- ☐ 年間改修費が増加傾向（直近 3 年で 1.5 倍以上）
- ☐ 大手取引先から EDI・トレーサビリティ等の要求が来ている
- ☐ 業務変化（新規業態・海外取引等）にシステムが追従できない
- ☐ 電子帳簿保存法・インボイス制度等への対応が困難
- ☐ 経営層から『いつまで使うのか』の問題提起が出ている
- ☐ 中期経営計画の策定タイミング（新計画への組み込み）
- ☐ 業績好調で投資余力がある（業績悪化前に動くべき）
3 つ以上該当したら、まずは 現状把握と移行方針の検討 から始めるタイミング。本格的な要件定義に進む前に、3 手法（リホスト／リライト／パッケージ移行）のうちどれが自社に向いているかを見極めることが重要です。
まとめ｜オフコン移行は『経営判断』の重要事項
オフコン移行は、ハードウェアやプログラミング言語の問題ではなく、『この先 10 年、自社の基幹業務をどう支えるか』 という経営判断です。技術判断は専門家に任せられますが、『いつ』『いくらで』『どの手法で』『誰と組むか』の経営判断は経営層自身が下す必要があります。
動いているうちに動く、判断材料が完璧に揃う前に決断する、本業が好調なうちに投資する——これらの姿勢が、オフコン移行の成否を分けます。サポート終了通知が来てから動き出すのでは間に合いません。
株式会社クオンツでは、汎用機・オフコンから Java／オープン系・クラウド基盤への移行プロジェクトに 25 年 携わってきた経験から、富士通・NEC・日立・IBM i（AS/400）など、主要メーカーのオフコン移行を含む基幹システム刷新プロジェクトに携わってきました。『うちのオフコン、どこから手をつければ』『リホストとパッケージ移行、どちらが向いているか』『移行までの逆算スケジュールを設計したい』 といったご相談を、無料で受け付けています。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
