IBM i（AS/400）の移行は 『継続も含めた 4 つの選択肢』 があり、どの方式を選ぶかが経営判断の核心です。本記事では、中堅企業の IBM i 移行事例を 4 つの方式別に整理。クラウドリホスト／業界特化パッケージ／オープン系リライト／IBM i 継続＋Web 化 の各ケースで、業種・規模・期間・投資額・成果を業界一般のモデルケースとして解説します。

※ 本記事のケース 1～4 は、クオンツが過去 25 年で関わってきたプロジェクトおよび業界一般の傾向から作成した モデルケース です。特定企業の個別事例ではなく、中堅企業の典型例として読んでください。

自社に近いケースを見つけたいですか？ 業種・規模・課題を伺い、最適な事例の進め方を整理します。 無料相談 ＞

結論：IBM i 移行事例から見える『3 つの傾向』

4 つのケースを並べて見えてくる傾向は、次の 3 つです。

  • 『移行ありき』ではなく『継続も含めた経営判断』：4 ケース中 1 ケースは『継続＋Web 化』を選択。他オフコンと違い IBM i は継続が有力な選択肢
  • 業務独自性のレベルが方式を決める：独自性高 → リライト or 継続／標準化可 → パッケージ移行／変化緩やか → リホスト
  • 稼働後 90 日の定着支援が成功の鍵：4 ケースすべて、稼働後の運用サポートを予算化した点が共通

事例の読み方｜IBM i 移行の評価軸

他社事例を自社に当てはめて読むには、次の 5 軸で整理すると分かりやすくなります。

評価軸確認ポイント
方式リホスト／パッケージ移行／リライト／継続＋Web 化
業務独自性のレベルパッケージ標準で吸収可か、独自開発が必要か
RPG 資産の扱い活かす（継続・リホスト）／清算する（リライト・パッケージ）
5250 依存度現場が 5250 グリーン画面に強く依存しているか
稼働後の成果 KPI業務指標で改善効果を数値化

ケース 1：製造業 A 社｜IBM i → クラウドリホスト

業種・規模自動車部品製造業／年商 60 億円／従業員 180 名
移行前20 年使用の IBM i（旧 AS/400）／RPG II/III 自社開発／ハード保守費の上昇
方式IBM Power Virtual Server へのクラウドリホスト
期間／投資額10 ヶ月／3,500 万円
主な成果ハード保守費 年 800 万 → 月額クラウド料金 50 万／ハード調達リードタイム解消／DR 対応強化

このケースの肝は、『業務改革は急がない、まずハード保守の負担を解消する』 という割り切り。RPG プログラムも 5250 画面もそのまま維持し、基盤だけクラウドへ移行。投資抑制と短期稼働を優先した経営判断が成功要因です。

ただし、これは『時間稼ぎ』の選択肢でもあります。社内の RPG 技術者の高齢化が進行中で、5 年後にはリライトかパッケージ移行への二段階移行を計画中、というのが現実的なロードマップです。

ケース 2：卸売業 B 社｜IBM i → 業界特化パッケージ

業種・規模食品・酒類卸売業／年商 120 億円／従業員 220 名
移行前25 年使用の IBM i／RPG＋自社カスタマイズ／受発注処理が属人化
方式食品卸売業界特化パッケージへの全面移行（Fit to Standard 7 割）
期間／投資額14 ヶ月／6,500 万円
主な成果受注処理工数 35% 削減／在庫精度 95% → 99.5%／属人化解消／取引先 EDI 対応

RPG 資産を 『負債として清算する』 判断をしたケース。25 年蓄積された独自仕様のうち、本当に競争力に直結する 3 割だけパッケージにカスタマイズで残し、残り 7 割は業界標準プロセスに合わせる Fit to Standard を徹底。経営層が要件定義の入口で『何をやらないか』を明示したことが、開発費の抑制と稼働後の定着成功につながりました。

ケース 3：建設業 C 社｜IBM i → オープン系リライト

業種・規模中堅ゼネコン／年商 80 億円／従業員 150 名
移行前30 年使用の IBM i／RPG IV／工事案件別原価管理が業界特殊／パッケージで吸収不可
方式Java / Spring Framework / PostgreSQL へのオープン系リライト
期間／投資額22 ヶ月／1.2 億円
主な成果工事原価リアルタイム把握／利益率 +2 ポイント改善／業界トップクラスの原価管理基盤を実現

建設業特有の 工事案件別原価集計・出来高による進捗管理 は、業界特化パッケージでも完全に吸収できないケース。RPG 資産の業務ロジックを引き継ぎつつ、Java で書き直す道を選択。投資額は大きいが、業界差別化要因として原価管理機能を磨き上げる経営戦略との整合性が成功要因。

自社に近いケースはどれ？ 業種・規模・業務独自性を伺い、最適な事例の進め方を整理します。
無料相談はこちら ＞

ケース 4：食品製造業 D 社｜IBM i 継続＋Web 化

業種・規模食品加工業／年商 40 億円／従業員 100 名
移行前15 年使用の IBM i／業務にぴったり合致／RPG 技術者 2 名在籍
方式IBM i 継続＋5250 画面の Web 化／モバイル対応
期間／投資額8 ヶ月／2,000 万円
主な成果RPG 資産を全面活用／5250 端末廃止／タブレットでの現場入力／投資抑制で他経営課題に予算配分

他のオフコン（富士通 K・NEC A-VX 等）の移行記事では出てこない、『継続』が経営判断として正解だったケース。理由は ①業務がパッケージ標準に合いにくい食品加工の独自性、②社内 RPG 技術者の継続在籍見通し、③IBM の長期サポート方針、④他経営課題（人材・営業力）への投資優先度。5～7 年後の二段階移行を計画 しつつ、いまは『継続』を選ぶ経営合理性が成立しています。

4 ケースから見える成功要因と失敗要因

共通する成功要因

  • 経営層が方式選定に深く関与：技術者・ベンダー任せにせず、経営判断として方式を決め切った
  • 業務独自性のレベルと方式の整合：独自性低 → パッケージ、独自性高 → リライトor継続、変化緩やか → リホスト
  • 稼働後 90 日の定着支援を予算化：4 ケースすべて、稼働後の運用サポートをプロジェクト範囲に含めた
  • RPG 資産の客観評価：「資産か負債か」を経営判断のフレームで整理
  • 業務責任者を専任化：本業との兼任ではなく、プロジェクト期間中フルコミット

逆に失敗パターンに陥るケース

  • 『継続』を消極的に選ぶ：RPG 技術者の年齢・退職リスクを織り込まず、5 年後に慌てる
  • リホストを過大評価：『基盤を移すだけ』なのに、業務改革効果まで期待してしまう
  • RPG 資産を過大評価：客観評価せずに継続を選び、結果として業務改革の機会を逃す
  • 5250 グリーン画面への愛着：UI 刷新を後回しにし、若手社員の定着・採用に支障
『自社の RPG 資産、活かすべきか清算すべきか』とお悩みの方へ
4 ケースを参考に、貴社の業務独自性・人材・経営戦略で最適な方式を整理します。
無料相談 ＞

IBM i 移行は『継続も含めた 4 択』が他オフコンとの違い

IBM i 移行の意思決定で最も重要なのは、『継続も含めた 4 択』を経営判断のテーブルに乗せる ことです。他のオフコン（富士通 K・NEC A-VX 等）と違い、IBM の長期サポートが続く IBM i は、継続を選ぶ経営合理性が成立するケースがあります。

ただし、継続を選ぶ場合も 5～7 年後の二段階移行を視野に入れる べき。RPG 技術者の年齢、業務変化の度合い、経営戦略の転換期を見極めながら、『次の刷新』を計画的に進めることが、長期的な経営判断として正しい姿勢です。

株式会社クオンツでは、『IBM i 継続 vs 脱却の経済合理性比較』『RPG 資産の客観評価』『業種・規模に応じた方式選定』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社の業務・人材・経営戦略に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。

FAQ｜

よくあるご質問

IBM i の移行事例にはどんな共通点がありますか？
3 つの傾向が見えます。①『移行ありき』ではなく『継続も含めた経営判断』が選ばれる（他オフコンと違い継続が有力選択肢）、②業務独自性のレベルが方式を決める（独自性高 → リライトor継続／標準化可 → パッケージ／変化緩やか → リホスト）、③稼働後 90 日の定着支援を予算化したプロジェクトが共通して成功。技術判断より経営判断の質が成否を分けます。
クラウドリホストとパッケージ移行、どちらの事例が多いですか？
中堅企業ではパッケージ移行が最も多いです。理由は、Fit to Standard で開発リスクを抑えつつ、業務改革効果も得られるバランスの良さ。一方、業務変化が緩やかで RPG 資産を活かしたい場合はクラウドリホストが選ばれます。最近は、まずクラウドリホストで時間を稼ぎ、5 年後にパッケージ移行を計画する『二段階移行』も増えています。
IBM i 継続を選ぶケースは本当にありますか？
あります。本記事のケース 4（食品製造業 D 社）が典型例。①業務がパッケージ標準に合いにくい独自性、②社内 RPG 技術者の継続在籍見通し、③IBM の長期サポート方針、④他経営課題への投資優先度——これらが揃うと、継続が経営合理的な選択になります。ただし、5～7 年後の二段階移行を視野に入れて『継続』を選ぶのが鉄則。永続的に IBM i のままで良い、という判断ではありません。
業務独自性が高い場合はどの方式が良いですか？
2 つの選択肢があります。①リライト（業務ロジックを Java 等で書き直し）：本記事ケース 3（建設業 C 社）が該当。投資額は大きいが、業界差別化要因として業務独自性を磨き上げられる。②IBM i 継続＋Web 化：本記事ケース 4（食品製造業 D 社）が該当。RPG 資産を活かしつつ、UI だけ刷新。経営戦略との整合性で選択します。
事例の費用感の目安は？
本記事 4 ケースでは、クラウドリホスト 3,500 万円（A 社）、業界特化パッケージ 6,500 万円（B 社）、オープン系リライト 1.2 億円（C 社）、IBM i 継続＋Web 化 2,000 万円（D 社）。方式により大きく異なります。中堅企業の標準レンジは 2,000 万～1.5 億円で、投資/売上比率では 0.5～2% の範囲に収まることが多い。
事例の期間はどれくらいですか？
本記事 4 ケースでは、最短 8 ヶ月（D 社：IBM i 継続＋Web 化）、最長 22 ヶ月（C 社：オープン系リライト）。中堅企業の標準は、リホスト 8～12 ヶ月、パッケージ移行 10～14 ヶ月、リライト 18～24 ヶ月、継続＋Web 化 6～10 ヶ月。これに検討フェーズ 3～6 ヶ月、定着化 3 ヶ月を加えるのが現実的な総期間です。
RPG 資産は活かすべきですか、清算すべきですか？
客観評価が必要です。社内では『価値ある資産』と思っていても、実は大半がパッケージ標準で代替可能というケースが多々あります。判断軸は、①業務独自性が業界差別化に直結するか、②技術者の年齢・退職可能性、③RPG プログラムの保守性（属人化・ブラックボックス化の度合い）、④パッケージ標準での代替可能性。これらを第三者の目で評価することをおすすめします。