なぜ今、IT基盤全体の中でオフコンを見直す必要があるのか
大きな理由の一つが、サービス終了と保守リスクです。エフサステクノロジーズは、DX推進の一環としてオフコンのモダナイゼーションを2031年3月末までに完了するよう推進しており、「Cloud Service for オフコン」は2026年3月31日に販売中止、2031年3月31日にサービス提供中止と案内されています。
2031年と聞くと、まだ時間があるように感じるかもしれません。しかし、基幹システムの刷新には、現行調査、方針決定、設計、開発、data移行、テスト、現場教育、並行稼働が必要です。移行には長い期間と多くの準備が必要であり、早めにプロジェクトを立ち上げることで、不測のトラブルや停止リスクを抑えやすくなります。
IT基盤の中でオフコンが引き起こす5つの構造的リスク
1. 基盤全体の硬直化──周辺システムとの連携断絶
オフコンはメーカー独自のOSとネットワークプロトコルで動作するため、TCP/IPベースのオープンシステムやcloudサービスとのdata連携が困難です。その結果、ERP・CRM・BIツールといった現代の業務アプリケーションとの統合が進まず、IT基盤全体が硬直化します。
経済産業省が指摘した「2025年の崖」──すなわち、レガシーシステムの維持にIT予算の約8割が費やされ、新規投資に回せなくなるリスク──は、オフコンを抱える企業にとって現実の課題です。
2. TCO (総保有コスト) のブラックボックス化
オフコンの運用コストは、保守契約費・専用部品の調達費・専任技術者の人件費など、複数の費目に分散しています。これらを合算したTCOを正確に把握している企業は少なく、「動いているから問題ない」という判断の裏で、年間数百万円〜数千万円規模のコストが見えにくくなっているケースがあります。
3. 技術者の枯渇と属人化リスク
COBOL・RPG・メーカー独自言語を扱える技術者の平均年齢は50代後半から60代に達しており、10年後にはほぼ確保できなくなると予想されています。社内のkey personが退職した瞬間、システムは「誰も触れないブラックボックス」に変わります。
4. 法制度・セキュリティ対応の限界
電子帳簿保存法、インボイス制度、改正個人情報保護法、さらにはサイバーセキュリティに関する各種ガイドラインへの対応は年々厳格化しています。オフコンの独自OS環境では、これらの法制度改正に追従するためのシステム改修コストが、オープン環境への刷新コストに匹敵するケースが増えています。
5. 取引先からのdigital化要求への対応不能
大手取引先から求められるEDI対応強化、トレーサビリティ要件、API連携への対応がオフコン環境では困難です。中堅企業 (年商50億円規模) では、これにより年間1,000万〜2,000万円規模の機会損失が発生しうるとの試算もあります。
「動いているから大丈夫」は本当か？──よくある3つの誤解
|
誤解
|
実態
|
|
「独自OSだからセキュリティは万全」
|
外部攻撃のリスクは低いものの、内部統制・監査ログの不備や、周辺システム経由の侵入経路が盲点になりやすい
|
|
「保守契約があるから安心」
|
主要メーカーの撤退により延長保守費は年々高騰。部品在庫の枯渇で、障害発生時の復旧が保証されないリスクがある
|
|
「全面刷新は高額すぎて無理」
|
リホスト方式なら既存のCOBOL/RPG資産を生かし、比較的短期間 (8〜12カ月) ・低コストで移行可能。段階的なアプローチも選択肢に入る
|
IT基盤刷新の3つのアプローチ──自社に合った手法を選ぶ
オフコンからの移行には、主に以下の3つの手法があります。重要なのは、IT基盤全体の将来像から逆算して手法を選ぶことです。
|
手法
|
概要
|
期間目安
|
コスト感
|
業務改革効果
|
|
リホスト
|
既存プログラムのロジックをほぼ維持したまま、オープン環境 (Linux / Windows) やcloudに基盤を移す
|
8〜12カ月
|
低〜中
|
限定的
|
|
リライト
|
業務要件を見直しながらJava / .NET等で再構築
|
18〜24カ月
|
中〜高
|
大きい
|
|
パッケージ移行
|
業界特化型ERP / SaaSへの置き換え
|
12〜18カ月
|
中〜高
|
大きい
|
段階移行という第4の選択肢
「一括移行か、現状維持か」の二択ではなく、段階的に移行する方法も有効です。たとえば、まずリホストでオープン基盤に載せ替えたうえで、業務改革が必要な領域だけをリライトまたはパッケージに置き換えるハイブリッド型アプローチです。
この方法は、業務停止リスクを最小限に抑えながらIT基盤を段階的にモダナイズできるため、特にレンタル・リースを活用したIT資産の入れ替えと相性が良く、初期投資を平準化しやすいメリットがあります。
2025年〜2031年──オフコン移行のtimelineとアクションプラン
例として、富士通 Cloud Service for オフコンの終了 (2031年3月末) を起点に、逆算した行動計画を示します。
|
時期
|
アクション
|
ポイント
|
|
2025年〜2026年
|
現状把握・資産棚卸し
|
オフコン上の全資産 (プログラム本数・data量・周辺連携) を可視化。TCOを算出
|
|
2026年〜2027年
|
移行方針の決定・PoC
|
リホスト / リライト / パッケージの比較検証。サンプル変換で実現性を確認
|
|
2027年〜2029年
|
移行プロジェクト実行
|
段階的な切り替え。並行稼働期間を設けて品質を担保
|
|
2029年〜2031年
|
安定運用・最適化
|
新環境での運用定着。旧環境の完全廃止。cloud / AI活用への布石
|
移行判断のためのセルフチェックリスト
以下の項目に3つ以上該当する場合、早期の移行検討を推奨します。
☐ オフコンの保守契約費が年々増加している
☐ オフコンを扱える社内技術者が2名以下、または60歳以上
☐ 基幹dataをBIツールやcloudサービスで活用できていない
☐ 法制度改正 (電子帳簿保存法・インボイス制度等) への対応に苦慮している
☐ 取引先からEDI / API連携を求められているが対応できていない
☐ システム障害時の復旧に24時間以上かかるリスクがある
☐ IT予算の大半が現行システムの維持に費やされている
まとめ──IT基盤全体を見渡し、経営判断としてオフコンに向き合う
オフコンは日本企業の基幹業務を数十年にわたり支えてきた信頼性の高いシステムです。しかし、メーカーの撤退・技術者の高齢化・法制度の厳格化という3つの潮流が重なる今、「動いているから問題ない」という判断は経営リスクに直結します。
重要なのは、オフコン単体ではなくIT基盤全体を俯瞰し、事業継続性・コスト・成長戦略の観点から最適な判断を下すことです。リホスト・リライト・パッケージ移行、そして段階移行というアプローチの中から、自社の業務特性と経営計画に合った手法を選択しましょう。
横河レンタ・リース株式会社は、日本ヒューレット・パッカード社のPlatinumパートナーとして、ITインフラの構築・運用支援に関する知見を基に、お客さまの状況に合わせた最適な環境づくりを支援します。
オフコンを含むレガシーシステムの見直しや、安定稼働を重視したインフラ刷新をご検討の際は、ぜひお気軽にご相談ください。
