【セミナーレポート 】富士通製オフコンのオープン化は、なぜ『資産棚卸』が成否を分けるのか──COBOL／CL放置による手戻りとコスト増を防ぐ考え方

2026年6月24日、「【富士通製オフコンユーザー向け】2030年度末にサービス終了が迫る、オープン化の成否を分ける資産棚卸 ～なぜCOBOL／CL放置、棚卸なしの移行で想定外の手戻りとコスト増が発生するのか～」というセミナーが開催されました。富士通製オフコンのサービス終了が見えてきた中、多くの企業で移行時期の集中も懸念されています。そのため、移行方式の検討に入る前に、まず現行資産の全体像を把握することが重要です。本記事では、なぜ資産棚卸が成否を分けるのか、その理由と進め方を整理します。

2026年6月24日にマジセミで配信したセミナーのセミナーレポートです。

セミナーアーカイブはこちら

登壇者

2030年度末が迫る中、富士通製オフコンユーザーはなぜ移行準備を急ぐべきなのか

まず、富士通製オフコンユーザーが直面している終息対応の全体像を整理します。期限が見えている今、単なる延命ではなく、移行に向けた現実的な検討が必要になっている背景を解説します。

富士通製オフコンを取り巻く環境は、すでに「いつか考える」段階を過ぎています。Cloud Service for オフコンは2026年3月末で新規販売を終了しており、サービス提供の終了時期も2031年3月末、すなわち2030年度末と明確になっています。残り4年9カ月という期間だけを見ると一見まだ時間があるようにも見えますが、方式検討、現行調査、設計、開発、テスト、本番切り替えまでを考えると、決して余裕があるとは言いにくい状況です。リホストであっても、プロジェクト期間として約2年が必要になるケースがあります。

さらに見落とせないのが、2030年度への移行集中リスクです。2030年度まで利用を想定する企業が多く、移行時期が後半に集まりやすい状況にあります。そのため、検討開始を遅らせるほど、希望する時期に十分な体制を確保しにくくなるおそれがあります。2030年度まで様子を見るのではなく、その前に判断材料をそろえ、計画を具体化していく必要があります。

重要なのは、「いつ移行するのか」だけではなく「どう移行するのか」です。リホスト、リライト、リビルド、あるいはパッケージ置き換えなど、選択肢はいくつかあります。ただし、どの方式を選ぶにしても、現行環境を正しく把握していなければ、比較の前提が定まりません。期限があるからこそ、方式選定より前に、判断材料を整える準備が必要になります。

COBOL／CL資産のブラックボックス化が、オープン化の難易度を上げる理由

次に、オープン化を難しくしている本当の要因を取り上げます。長年の運用で肥大化したCOBOL／CL資産がブラックボックス化し、依存関係や不要資産が見えにくくなっている状況を解説します。

富士通製オフコンの移行が難しくなりやすい背景には、長年にわたって積み重なったCOBOL／CL資産の複雑化があります。業務追加や改修を繰り返す中で、プログラム本数は増え、呼び出し関係も入り組み、どの処理がどこで使われているのかを正確に説明できる人が限られていきます。担当者の引退が近づき、ドキュメントも十分に残っていない状態では、業務に不可欠なロジックと、すでに使われていない資産の見分けがつきにくくなります。 

この状態が厄介なのは、単に古い技術だからではありません。見えない資産が多いほど、移行計画の前提が不安定になるからです。どの資産を残すのか、どこを改修するのか、何を捨てられるのかが曖昧なままでは、工数見積もりも移行範囲の確定もぶれやすくなります。結果として、着手後に想定外の依存関係や不足資産が見つかり、スケジュールや費用の再調整が発生しやすくなります。

しかも、COBOL技術者の確保は以前より難しくなっています。現行資産を理解している人材が少ないままブラックボックス化が進むと、現行踏襲で延命する判断も、抜本的にオープン化する判断も、どちらも難しくなります。「何から始めればよいのか分からない」という悩みが多いのは自然なことです。だからこそ、最初に必要なのは大きな構想より、現行資産の見える化です。

なぜ資産棚卸なしの移行は、手戻りとコスト増を招くのか

ここでは、資産棚卸の必要性を解説します。現行資産を整理しないまま移行を進めると、テストや運用の段階で問題が顕在化し、想定外の手戻りや追加コストにつながる理由を整理します。

資産棚卸を行わずに移行を進めると、最も起こりやすいのが「不要なものまで運ぶ」ことです。実際には使われていないプログラムや、使われているかどうか確信が持てず削除判断ができない資産まで移行対象に含めると、変換、設計、テスト、現新照合、運用準備のすべてが重くなります。移行対象が増えれば、その分だけ確認作業も増え、品質確保に必要な工数も膨らみます。

さらに深刻なのは、後工程で問題が表面化することです。仕様が不明なロジック、呼び出し関係が整理されていない処理、抜け落ちていた関連資産などがテスト段階で見つかると、再設計や追加調査が必要になります。これが手戻りです。しかも、手戻りは前工程より後工程で起こるほど高くつきます。移行の途中で前提が崩れると、コストだけでなく、納期や体制にも影響が広がります。 

資産棚卸の価値は、単なる台帳整備にとどまりません。現行資産を解析し、依存関係を可視化し、不要資産を見極めることで、移行対象そのものを絞り込めます。実例として、COBOL 3,000本が2,200本まで整理されたケースもあります。20～30％程度の削減につながる例がある一方で、削減幅は企業ごとに異なります。だからこそ、まずは自社資産を定量的に把握することが重要です。不要資産を早い段階で外せれば、その後の移行やテストにかかる負荷も抑えやすくなります。

株式会社シーイーシーは、こうした上流整理を含むマイグレーション支援をワンストップで提供しています。資産棚卸による可視化、移行方式の見極め、変換ツールの活用、移行作業、運用保守までを一気通貫で支援できる点は、ブラックボックス化した環境を抱える企業にとって現実的な強みです。現行踏襲を前提に動くのではなく、まず整理してから移る。その順番を守れるかどうかが、手戻りとコスト増を防ぐ分かれ目になります。

最後に――オープン化成功の第一歩は、現行資産を正しく把握すること

まとめとして、富士通製オフコンの終息対応では、移行方式の検討だけでなく、まず現行資産を可視化し、何を残し、何を移行対象とするのかを見極めることが重要です。オープン化の成否を分ける実務として、資産棚卸を最初の一歩に据える必要があります。

富士通製オフコンの終息対応で問われているのは、単に期限までに移ることではありません。残り期間が限られる上に、2030年度には案件集中も見込まれるため、無駄な資産を抱えたまま高コストな移行に踏み込まないこと、そしてその前に判断に必要な情報をそろえることが重要です。開始が遅れるほど、選べる方式も体制も狭まりやすくなります。

その意味で、資産棚卸は準備作業ではなく、移行全体の精度を決める基盤です。現行資産の見える化によって、残すべき資産、整理すべき資産、見直すべき業務が明確になれば、リホストなのか、リライトなのか、再構築なのかという判断も現実的になります。逆に、この土台が曖昧なまま方式だけを先に決めると、後から想定外の負荷が噴き出しやすくなります。

富士通株式会社が終了スケジュールや全体の選択肢を提示し、株式会社シーイーシーが資産棚卸から移行方式の提案、実際のマイグレーション、運用保守までを支えるサービスをご利用いただくことも、こうした難しさに対する現実的な進め方の一つです。何から着手すべきか迷っている場合でも、最初にやるべきことは明確です。まず現行資産を把握すること。その一歩が、2030年度末を見据えたオープン化の成功確率を大きく左右します。

よくある質問

なぜ富士通製オフコンの移行準備を早めに始める必要があるのでしょうか。

2030年度末という期限が明確であるうえ、移行案件が後半に集中しやすいからです。着手が遅れるほど、開発体制の確保が難しくなり、方式選定やテストにも余裕が持ちにくくなります。準備を早めることで、選択肢を広く持ったまま進めやすくなります。

なぜCOBOL／CL資産のブラックボックス化が問題になるのでしょうか。

依存関係や不要資産が見えないままだと、移行範囲や工数の見積もり精度が下がるからです。どの処理が業務上重要なのか、どこを整理できるのかが曖昧な状態では、着手後の手戻りが起こりやすくなります。

資産棚卸を行わずに移行すると、どのような問題が起こりやすいのでしょうか。

不要プログラムまで移行対象に含めてしまい、変換やテストの負荷が増えやすくなります。また、後工程で不足資産や仕様不明の処理が見つかると、再設計や追加対応が発生し、コスト増や納期への影響につながりやすくなります。

資産棚卸は、マイグレーションにおいてどのような役割を持つのでしょうか。

資産棚卸は、現行資産を可視化し、何を残し、何を整理し、どの方式で移行するのかを判断するための土台です。移行対象の見極めとコスト抑制の起点になり、現実的なマイグレーション計画を立てやすくします。

動画視聴のお申込みはこちらから

オフコン関連のその他記事はこちらから