「自社のオフコンを移行したいが、製造業特有の論点があるのか分からない」「RPG／COBOL の技術者が引退間際で、移行のタイミングを逃しそう」「BOM・工程管理・原価管理を新システムでどう再現するか」——中堅製造業の経営層・情シス責任者から、こうした問いが届きます。製造業のオフコン環境は IBM i／AS400 が多数を占めますが、富士通・NEC・日立オフコンも残存 しており、言語も RPG／COBOL／専用言語 と幅広く存在します。本記事では、製造業のオフコン移行で共通する 3 つの固有難所、移行戦略の判断軸、費用・期間の目安、成功 4 条件、よくある失敗を整理します。
『製造業のオフコン移行、自社環境（IBM i／富士通／NEC／日立）で何から進めるべきか整理したい』 25 年の経験で、現状システムと業務要件から最適な進め方を一緒に整理します。 無料相談 ＞結論：製造業のオフコン移行は『3 つの固有難所 × 移行戦略』で進める
製造業のオフコン移行は、他業種と比べて 3 つの固有難所（レガシー言語資産・生産管理ロジック・並行稼働の長期化）があります。一方で オフコンの種類（IBM i／富士通／NEC／日立）や言語（RPG／COBOL／専用言語）に関わらず、論点は共通している のが実態です。
| 観点 | 整理ポイント | 判断軸 |
|---|---|---|
| ① 3 つの固有難所 | レガシー言語資産の移植／生産管理ロジック／並行稼働の長期化 | オフコン種別を問わず共通 |
| ② 移行戦略 | 段階移行 or 一括移行／パッケージ vs リライト | 業務独自性・人材在籍状況・予算で判断 |
| ③ 費用・期間 | 中堅製造業の典型：5,000 万～2 億円／15～30 ヶ月 | 規模・対象範囲で大きく変動 |
意思決定で重要なのは、『RPG／COBOL／専用言語の技術者がまだ在籍しているうちに動き始める』 ことです。技術者退職後の移行は、業務知識の継承が困難になり、費用・期間が想定の 2～3 倍 に膨らむケースがあります。
製造業のオフコン環境の現状｜各社オフコンとレガシー言語
中堅製造業のオフコン環境は、メーカー・言語の組み合わせが複数存在します。それぞれ生産終了・保守期限の状況が異なるため、自社の置かれた状況を把握しておくことが移行計画の起点になります。
| メーカー | 典型的な機種・言語 | 市場での位置づけ | 移行のきっかけ |
|---|---|---|---|
| IBM i（旧 AS/400） | IBM i／RPG・COBOL | 製造業オフコンの多数派 | RPG 技術者の引退・クラウド移行ニーズ |
| 富士通オフコン | K シリーズ／PRIMERGY 6000／ASP・COBOL | 「2031 年問題」（Cloud Service for オフコンの提供終了が予告されている問題）に直面 | サービス終了予告・サポート切れ |
| NEC オフコン | EXPRESS5800/100 シリーズ／COBOL | 標準保守終了・延長保守縮小 | 延長保守の打ち切りタイミング |
| 日立オフコン | 各種オフコン／COBOL | ユーザー減少・保守縮小の二重圧力 | 保守体制縮小・市場縮小 |
メーカー・言語が異なっても、製造業のオフコンユーザーが直面する 共通の経営課題 は次のとおりです。
- RPG／COBOL／専用言語の技術者の高齢化と退職
- 業務独自仕様の塊化（生産管理ロジックがオフコンに集中）
- BOM・工程・原価データのブラックボックス化
- ハードウェア／OS／サービスの保守期限
- 後継パッケージとの業務適合度の見極め
製造業のオフコン移行で注意すべき 3 つの固有難所
難所 1：RPG／COBOL などのレガシー言語資産の移植
製造業のオフコンには、RPG・COBOL・専用言語で書かれた数百～数千本のプログラム資産 が蓄積されています。これらの言語は技術者市場が大きく縮小しており、ベンダー側でも対応できる人材が限られます。自動変換ツール でオープン系言語（Java／C#／.NET 等）へ移植する手法もありますが、変換後のコードは保守しやすい設計になるとは限らず、追加リファクタリングが必要なケースが多くなります。
製造業特有の論点として、RPG／COBOL コードの中に『生産管理ロジック』『原価計算ロジック』『工程進捗管理ロジック』が深く埋め込まれている ことが多く、ロジックの可視化・仕様書化に数ヶ月かかることがあります。自社・ベンダーの技術者がまだ在籍しているうちに、業務知識の文書化を始めることが重要です。
難所 2：生産管理ロジック（BOM・工程・原価）の移植複雑さ
製造業の基幹システムには、BOM（部品表）・工程（製造工程）・原価（標準原価・実際原価） という 3 大データ構造があり、これらは業務独自仕様の塊です。
| 領域 | 移植の複雑さ | 典型的な落とし穴 |
|---|---|---|
| BOM（部品表） | 多階層・配賦ルール・代替部品・有効期限が業務独自 | パッケージ標準で表現できないルールが後発で発覚 |
| 工程（製造工程） | 工程順序・並行工程・外注工程・歩留まりが業務独自 | 「現状の工程をそのまま再現」しようとして開発費が膨張 |
| 原価（標準・実際） | 配賦基準・差異分析・期末締めロジックが業務独自 | 会計連携の整合性が崩れて経営数字が出せなくなる |
これらは パッケージの標準機能だけでは再現できない ことが多く、カスタマイズか、リライト（コード書き直し）が必要になります。業務独自仕様のうち「業界差別化に直結する 1～2 割」だけ独自実装し、残りは Fit to Standard で標準機能に合わせる のがコスト最適化の鉄則です。
難所 3：並行稼働期間の長期化（業務サイクル基準）
製造業の業務サイクルは 月次（締め）・四半期（棚卸し）・年次（決算・原価集計） と長く、新システムの動作検証には少なくとも 主要な締め処理を 1 回以上確認できる期間 が必要です。単純なサブシステムなら数週間で足りることもありますが、生産管理・原価管理では 3～12 ヶ月 の並行稼働が必要になる場合があります。
並行稼働期間中は、旧オフコンと新システムの両方に業務データを入力する『二重入力』 が現場負荷になります。期間が長すぎると現場の疲弊・運用負荷増加、短すぎると本番切替後にトラブル多発という二律背反があるため、業務サイクルに応じた期間設計が重要です。
段階移行 vs 一括移行｜判断フロー
製造業のオフコン移行では、段階移行（業務領域単位で順次移行）と一括移行（全業務領域を一度に切替） のどちらを選ぶかが重要な意思決定です。
段階移行が向くケース
| 条件 | 業務領域を切り分けられる（例：販売管理 → 在庫管理 → 生産管理 → 会計） |
|---|---|
| メリット | リスク分散／各フェーズで学習しながら次に活かせる／投資の平準化 |
| デメリット | 総期間が長期化（旧オフコンと新システムの並行稼働期間が長い）／旧環境の維持コストが追加発生 |
| 典型ケース | サブシステム間の依存が比較的疎な中堅製造業／投資余力が限定的 |
一括移行が向くケース
| 条件 | サブシステム間の依存が密で分割困難／BOM・工程・原価データが密接に連動 |
|---|---|
| メリット | 総期間が短い／並行稼働コストが少ない／業務改革と一体で進められる |
| デメリット | 失敗時の影響範囲が大／要件定義のスコープが膨大／本番切替リスク高 |
| 典型ケース | 業務領域間の連携が密で分割困難な大規模製造業／業務改革を伴う抜本的刷新 |
中堅製造業では、業務領域ごとに切り分けられる場合は 段階移行の方がリスクを抑えやすいケース があります。一方で、システム間依存が強い場合は一括移行の方が適することもあるため、並行稼働期間とデータ整合性を含めて判断してください。
製造業のオフコン移行の費用・期間（当社想定の概算）
中堅製造業（150～300 名規模・主要サブシステム対象）のオフコン移行の典型的な目安を整理します。
| 規模 | 典型的な対象 | 費用目安（当社想定） | 期間 |
|---|---|---|---|
| 小規模（50～150 名） | 販売管理＋在庫管理 | 3,000 万～8,000 万円 | 12～18 ヶ月 |
| 中規模（150～300 名） | 生産管理＋販売管理＋会計 | 5,000 万～1.5 億円 | 15～24 ヶ月 |
| 大規模（300 名以上） | 基幹システム全体＋周辺系 | 1 億～3 億円 | 20～30 ヶ月 |
前提条件：上記は当社想定の概算です。実際の費用・期間は、対象範囲・BOM 階層の複雑さ・工程数・原価集計の独自性・データ移行量・テスト範囲・パッケージのカスタマイズ量によって大きく変動します。一般相場ではなく自社想定の概算としてご覧ください。
製造業で見落としやすいのが 『実質総費用』 です。ベンダー支払額に加えて、社内工数（要件定義参加・テスト参加・現場研修参加）・並行稼働期間の重複コスト・教育研修費を含めると、ベンダー支払額の 1.3～1.5 倍 が実質総費用になるケースが多くなります。
製造業のオフコン移行を成功させる 4 条件
過去のプロジェクトを振り返ると、製造業のオフコン移行の成否は次の 4 条件で大きく分かれます。
| 条件 | 具体的なアクション |
|---|---|
| ① 技術者在籍中に動く | RPG／COBOL／専用言語の技術者がまだ社内・ベンダーに在籍しているうちに業務知識の文書化を完了させる |
| ② BOM・工程・原価の独自仕様を仕分け | 業界差別化に直結する 1～2 割と、それ以外を仕分け。差別化以外は Fit to Standard でパッケージに合わせる |
| ③ 現場巻き込み（生産現場・経理） | 要件定義に生産現場（工程責任者）と経理（原価責任者）を必ず参加させる。情シスだけでは要件が拾えない |
| ④ 並行稼働は業務サイクルに合わせる | 月次締め・四半期棚卸し・年次決算を含む業務サイクルを 1 回以上確認できる期間を設計 |
製造業のオフコン移行でよくある失敗パターン
失敗 1：「現状の生産管理をそのままシステム化」しようとした
オフコン上で長年運用してきた業務独自仕様（BOM 多階層・工程順序・原価配賦ルール）を そのままパッケージで再現 しようとして、カスタマイズ費用が当初予算の 2～3 倍に膨張するパターン。業界差別化に直結する 1～2 割のみ独自実装、残りは Fit to Standard が成功の鉄則です。
失敗 2：RPG／COBOL 技術者の退職後に着手
社内・ベンダーの技術者の退職を待ってから動き始めた結果、業務知識の継承ができず、要件定義に半年以上かかる パターン。技術者在籍中こそが移行プロジェクトの最後のチャンスです。
失敗 3：生産管理ロジックを「後でカスタマイズすれば」と思ってパッケージを選んだ
ベンダーの「カスタマイズで対応可能」という言葉を鵜呑みにして契約後、実際にはパッケージのコア機能に手を入れる必要があり、追加開発費が当初予算の 2～3 倍 になるパターン。契約前の Fit & Gap 分析（パッケージとの適合度評価）に十分な時間をかけることが必要です。
失敗 4：並行稼働を短縮しすぎる
「コストを下げたい」「早く本番にしたい」という理由で並行稼働を 1 ヶ月以下に短縮した結果、本番切替後に月次締めや原価計算でデータ整合性問題が発覚 して業務が止まるパターン。製造業の業務サイクルでは 少なくとも月次締めを 1 回以上確認できる期間 が安全側の判断です。
失敗 5：BOM の棚卸しを後回し
BOM（部品表）の整理を移行後に回した結果、新システム稼働後に「同じ部品が複数の品番で登録されている」「廃番品が残っている」などのマスタ不整合 が多発し、在庫差異や原価計算ミスが頻発するパターン。BOM の棚卸しは移行プロジェクトの前段で完了させてください。
まとめ｜製造業のオフコン移行は『技術者在籍中×業界差別化を見極めて』進める
製造業のオフコン移行は、メーカー（IBM i／富士通／NEC／日立）や言語（RPG／COBOL／専用言語）が異なっても、3 つの固有難所（レガシー言語資産の移植・生産管理ロジックの移植複雑さ・並行稼働の長期化）が共通します。成否は 『RPG／COBOL 技術者が在籍しているうちに動き始められるか』『BOM・工程・原価のうち、業界差別化に直結する 1～2 割を仕分けできるか』 でほぼ決まります。
- 製造業のオフコン環境は IBM i 多数派／富士通・NEC・日立も残存。論点は共通
- 3 つの固有難所：レガシー言語資産の移植／生産管理ロジック／並行稼働の長期化
- BOM・工程・原価：業界差別化に直結する 1～2 割のみ独自実装、残りは Fit to Standard
- 移行戦略：段階移行 or 一括移行（業務領域の依存度・投資余力で判断）
- 費用相場（当社想定）：中規模で 5,000 万～1.5 億円／15～24 ヶ月。実質総費用はベンダー支払額の 1.3～1.5 倍
- 並行稼働期間：業務サイクル（月次・四半期・年次）に応じて設計
- 成功条件：技術者在籍中／独自仕様の仕分け／現場巻き込み／業務サイクル基準の並行稼働
株式会社クオンツでは、『製造業のオフコン現状アセスメント』『BOM・工程・原価の独自仕様棚卸し』『RPG／COBOL 資産の評価』『段階移行設計』『5 年 TCO 試算』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社のオフコン環境（IBM i／富士通／NEC／日立）と業務要件に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
