COBOLエンジニアのフリーランスの将来性とキャリアの広げ方

COBOLエンジニアの仕事は、メインフレームで動き続けるシステムの保守と、別の基盤や言語へ移す移行の両方で、形を変えながら続くと考えられます。提供元の公式の発表を見ると、新しい版を出し続けている製品がある一方で、販売と保守の終了の時期を示した製品もあり、現場によって進む方向が分かれています。

選択肢を広げるには、COBOLの読解に加えて、移行の現行分析と検証、業務知識、移行先の技術のどれかの軸を持つことが近道です。この記事では、公式に示されている動きを土台に、COBOLの仕事の変わり方と経験に応じた広げ方を整理します。

公式の発表から見えるCOBOLの現在地

COBOLが動く環境については、提供元ごとに方向が違います。2026年10月時点で公式のページで確かめられる主な動きは次のとおりです。

富士通の発表は、ハイブリッドITのロードマップの中で、メインフレームやUNIXサーバーのシステムをクラウドへ移す時間軸として示されたものです。一方、IBMは、OSとCOBOLのコンパイラの新しい版を出し続けています。

つまり、メインフレームを使い続ける現場と、期限に向けて移す現場の両方があるというのが現在地です。どちらの現場でも、現行のCOBOLを読める人が必要になる点は共通しています。銀行・保険・公共の基幹系の状況は、銀行業界のIT案件、保険業界のIT案件、公共・官公庁のIT案件で整理しています。

COBOLの仕事はどう変わっていくか

保守は続き、移行の比重が増える

メインフレームを使い続ける現場では、制度対応や商品の改定、OSやコンパイラの版の更新に伴う保守が続きます。一方、販売や保守の終了が示された製品を使う現場では、期限に向けて移行のプロジェクトが進みます。

移行の仕事では、現行のプログラムが何をしているかを調べる現行分析と、移行の前後で結果が同じことを確かめる検証が欠かせません。どちらも、現行のCOBOLと環境、業務を知っている人でないと担いにくい作業です。移行が進むほど、現行を読める人の役割は「作る」から「調べて、確かめる」へ重心が移ると考えられます。

AIを使った移行の道具が出てきている

提供元からは、生成AIを使ってメインフレームのアプリケーションの理解や移行を支援する道具が出ています。

• IBM watsonx Code Assistant for Z：IBMの公式ページでは、メインフレームのアプリケーションの依存関係の分析、コードの説明文の作成、COBOLやPL/Iのアプリケーションの業務サービス単位への切り出し、COBOLからJavaへの変換と、変換後の動作を元のCOBOLと比べる単体テストの生成を支援すると説明されています
• AWS Transform for mainframe：AWSの公式ページでは、コード全体の依存関係の分析、業務ルールの抽出と要件への変換、コードの生成、元のアプリケーションと同じ動きをするかの自動テスト、配置のための成果物の生成を、AIのエージェントで進めると説明されています

こうした道具で、コードの説明や変換の下書き、依存関係の洗い出しは速くなっていく可能性があります。一方で、次のような判断は、道具が変わっても人の責任で残る部分が大きいと考えられます。

• 抽出された業務ルールが、実際の業務と合っているか
• 移行の前後で、金額の計算や帳票の出力が変わっていないか
• 変換しきれない部分や、設計書と実装が違う部分をどう扱うか

業務システムの案件では、ソースコードを外部の道具に渡せるかどうかが発注元の方針で決まっていることがあります。生成AIの利用と仕事の変化の全体像は、生成AIで仕事はどう変わるかで扱っています。

選択肢を広げる4つの方向

COBOLの経験を軸にしたまま、選べる案件を広げる方向は大きく4つあります。

全部を同時に追う必要はありません。今の経験に近い方向を一つ選び、そこで一段深い経験を積むほうが、面談で説明しやすくなります。

移行先の技術へ広げる場合

COBOLからJavaへのリライトや、クラウドへの移行に関わる場合は、移行先の技術の知識が役に立ちます。Javaの動きはJavaエンジニアの将来性、クラウドへの移行の動きはAWSエンジニアの将来性が参考になります。ただ、移行先の技術を一から極めるより、現行と移行先の両方を見比べられることのほうが、移行の案件では評価されやすいと考えられます。

経験の段階ごとの広げ方

製造・テストが中心の段階

まずは、影響調査や障害の原因の調査を自分で担える範囲を広げることが、選べる案件の幅に直結します。手元で移行先の環境に触れておくと、移行の案件の面談で話せる材料になります。

影響調査・設計を任されている段階

影響調査や設計を担っている人は、移行の現行分析に入りやすい段階です。調査の手順や観点を文書にして残す習慣をつけると、移行の案件で「現行の仕様を文書に起こせる人」として説明できます。

リード・上流の段階

チームをまとめる立場では、移行の方式の検討や、移行の計画と検証の設計に関わる道があります。業務部門と話ができ、現行の仕組みを踏まえて移行の進め方を説明できる人は、上流の案件に入りやすくなります。上流への入り方は上流工程の記事、経験の長い方の働き方は50代のフリーランスの記事で扱っています。

将来に備えて今からできること

1. 今の現場の方向を確かめる：使い続けるのか、移すのか、その時期はいつ頃か
2. 経歴に環境と版を書く：OS、コンパイラ、オンライン、DBの系統と版を書き分けます。書き方はCOBOLのスキルシートの記事で解説しています
3. 一つの調査を深く言葉にする：影響調査、障害の原因の特定、現新比較の差分の切り分けのどれかで、手順と判断を説明できるようにします
4. 広げる方向を一つ決める：上の4つの方向から、今の経験に近いものを選びます

求められるスキルの全体像はCOBOLの案件で求められるスキル、報酬の決まり方はCOBOLエンジニアの報酬の記事にまとめています。

よくある質問

COBOLはこの先も案件がありますか？

先の案件の量を言い切ることはできません。ただ、メインフレームを使い続ける現場では保守と版の更新が続き、販売や保守の終了が示された製品を使う現場では移行が進みます。どちらでも現行のCOBOLを読める人が必要になるため、保守と移行の両方で語れる経験を持っておくと、状況が変わっても選択肢を保ちやすくなります。

AIの道具でCOBOLの仕事はなくなりますか？

提供元からはコードの説明や変換を支援する道具が出ており、作業の一部は速くなっていく可能性があります。ただ、抽出された業務ルールが正しいか、移行の前後で結果が変わっていないかを確かめる判断は、人の責任で残る部分が大きいと考えられます。道具を使えるかどうかは発注元の方針によるため、案件ごとに確かめてください。

COBOLからJavaに移るべきですか？

一律に移る必要はありません。移行の案件では、COBOLとJavaの両方を読める人が現新の比較や変換後のレビューで求められることがあり、COBOLの経験を残したままJavaを足すほうが強みになる場合があります。今の現場の方向と、ご自身が進みたい方向を踏まえて、どちらを深めるか決めることをおすすめします。