COBOLの案件を見かけると、少し身構えてしまう。古い技術に戻るようで、この先どうなるのか分からない。そう感じてはいませんか。

ところが実際には、基幹システムの刷新はほとんど進んでいません。経済産業省の最新レポートでも、その停滞が数字で示されています。読み解ける人が減り続けているぶん、扱える人の立場は強くなります。この記事では、COBOL案件がなぜ残るのか、AI時代に残る役割はどこか、報酬をどう考えるかを、公的データとRemoguの独自調査で整理します。

1. COBOL案件が今も残っている理由

COBOLで書かれたシステムは、金融、保険、公共、製造の基幹業務を支えています。止められないうえに、作り直すには規模が大きすぎる。この二つが重なって、刷新は先送りされ続けてきました。

刷新が進んでいないことは、公的資料に書かれている

経済産業省が2025年5月に公表した「レガシーシステムモダン化委員会総括レポート」では、2018年のDXレポートで警鐘を鳴らした「2025年の崖」を迎える中、産業界のDXおよびレガシーシステム脱却の進捗は依然としてスピード感に欠けると指摘されています¹。

象徴的なのが、経営側の姿勢を示す数字です。同レポートによれば、中期経営計画に大規模システムの導入・刷新を記載している利用企業は12%にとどまります¹。つまり9割近くの企業では、基幹システムの刷新が経営計画の言葉になっていません。

出典：経済産業省「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」（2025年5月28日）をもとに作成

なぜ「作り直す」判断ができないのか

刷新が動かない理由は、技術の古さそのものではありません。実務では三つの壁が重なります。

一つ目は規模です。数十年ぶんの業務ルールが積み上がっており、機能の数も分岐の数も膨大になっています。作り直すとなれば、その全量を洗い出す作業から始まります。

二つ目は停止できないことです。入出金や在庫、契約管理といった業務は日々動いています。切り替えの失敗が事業に直結するため、判断そのものが慎重になります。

三つ目は仕様が失われていることです。設計書が更新されていない、あるいは残っていない場合、コードが唯一の仕様になります。読める人がいなければ、現状を把握する段階で止まってしまいます。

この三つを前にすると、「今年は見送る」判断が毎年続きます。結果として、動かし続ける仕事が残ります。

情報システム部門が動けない構造

同レポートは、利用企業の情報システム部門が自社システムの運用維持保守にかかりきりになっている点にも触れています¹。日々の維持で手一杯になると、刷新の検討まで進みません。

そこに人材の不足が重なります。IPAの調査では、日本企業の85.1%でDXを推進する人材が不足していると報告されています²。社内で手が回らない部分を、外部の専門人材で補う流れが生まれます。

新しい技術を追う人が増えるほど、古い基幹を読める人は希少になります。人が少ない場所に立つほうが、案件の選択肢は増えます。では実際の仕事はどのような内容でしょうか。

2. COBOL・基幹システム案件の類型と仕事内容

COBOLの案件は「古いコードを直すだけ」ではありません。維持する仕事と、次の仕組みへ橋渡しする仕事に分かれます。後者ほど関与の範囲が広く、評価もされやすくなります。

「守る仕事」と「橋を架ける仕事」

守る仕事は、稼働中システムの改修や障害対応、法制度改正への対応です。業務が止まらないことに価値があり、確実さが求められます。

橋を架ける仕事は、既存の仕様を読み解いて新しい環境へ移す仕事です。仕様書が残っていないシステムでは、コードが唯一の仕様になります。読める人がいなければ移行の計画すら立てられません。

単価を上げたいなら、守る側だけに留まらないほうが有利です。移行の判断材料を出せる人は、刷新計画そのものに関わることになります。

【表1】COBOL・基幹システム案件の類型比較

以下は、COBOLが関わる案件を5つの類型に整理したものです。リモート適性は、対象環境へのアクセス方法と関係者との調整量で変わります。金融や公共の領域では、セキュリティ要件により稼働形態が限られる場合があります。

類型	主な作業内容	求められる経験	リモート適性
基幹システムの保守・改修	稼働中システムの機能追加・不具合対応	COBOLの読解と改修、業務知識	中〜高い
制度改正への対応	税制・法令改正に伴う仕様変更の実装	業務仕様の理解、テスト設計	高い
仕様の可視化・棚卸し	コードから業務仕様を復元し文書化する	コード読解力、業務の言語化	高い
マイグレーション設計	新環境への移行方式の検討・移行設計	移行の段取り、新旧両環境の知識	中〜高い
移行後の並行稼働・検証	新旧システムの結果比較、差異の調査	データ検証、原因追跡の経験	中程度

業種によって求められるものが変わる

同じCOBOLでも、業種によって重視される点は違います。金融では計算の正確さと監査への対応、保険では商品ごとの複雑な条件分岐、公共では制度改正への漏れのない追随、製造では生産計画や在庫との連動が中心になります。

ここで効いてくるのが業務知識です。コードを読めるだけでなく、その業務が何を守るために作られているかを理解している人は、改修の判断が速くなります。経験のある業種を軸に案件を探すと、条件の交渉もしやすくなります。

言語の経験年数を並べるより、どの業種のどの業務を支えてきたかを語るほうが伝わります。基幹システムの案件では、業務の理解が技術と同じ重さで見られます。

3. AI時代に残る役割はどこにあるのか

生成AIはコードを読む作業を助けます。だからCOBOLの仕事は消えるのか。結論は逆で、AIが読めるようになるほど、判断する人の重みが増します。

AIが得意な部分と、人が引き受ける部分

生成AIの利用は急速に広がっています。個人で利用した経験がある人は、2023年度の9.1%から2024年度は26.7%へと伸びました³。コードの要約や変換の下書きは、道具で速くなる領域です。

一方で、基幹システムの改修は「間違えたときの影響」が極端に大きい仕事です。入出金や在庫の計算を1件でも取り違えれば、業務が止まります。出力を検証し、責任を持って採否を決める役割は人に残ります。

道具を使える人が有利になる

AIを避ける必要はありません。読解の下書きを任せて、検証と判断に時間を使うほうが成果は出ます。経産省のレポートでも、モダン化には情報システム部門の自律性や事業部門との連携が有効だと整理されています¹。技術と業務の両方を橋渡しできる人が必要とされる構図です。

古い技術を守る人ではなく、古い資産を次へ渡せる人。この立ち位置に寄せると、案件の質は変わります。

【表3】COBOL技術者のスキルの積み上げ方

役割を広げるには、順番があります。上のレイヤーほど刷新計画に近づきますが、いきなり全部を揃える必要はありません。今の位置から一つ上を狙う進め方が現実的です。

レイヤー	具体スキル	学習・実践の手がかり
基礎（読める・直せる）	COBOLの読解、改修、テスト、JCLやバッチ運用の理解	担当システムの処理フローを自分の言葉で書き出す
応用（業務が分かる）	対象業務の仕様理解、制度改正への対応、データ検証	業務部門との確認記録を残す、IPAの試験区分で体系化する
発展（移行を設計できる）	移行方式の比較、移行先環境の知識、並行稼働の設計	クラウドや現行言語の基礎を押さえ、差異検証の手順を作る

基礎から応用へ進む鍵は、コードの説明ではなく業務の説明ができるかどうかです。「この処理は何のためにあるのか」を業務の言葉で語れる人は、移行の議論に呼ばれます。

4. 報酬水準の基準線と交渉の材料

希少だから高い、とは限りません。報酬は担当する工程と責任範囲で決まります。ここではRemogu独自の調査で基準線を確認します。

Remoguは、実案件2,450件（2023年1月〜2024年2月・支払上限金額から算出）を分析した調査を公表しています。フリーランスエンジニアの平均月額報酬は約76.5万円で⁴、職種別ではCTO/VPoE/テックリードが約98.9万円で1位です⁴。

出典：Remogu「職種別・言語別の月額報酬ランキング」調査（2024年／実案件2,450件・支払上限金額から算出）をもとに作成

【表2】交渉のときに使える材料

なお、COBOLに特化した報酬データは、今回参照した調査には含まれていません。言語ではなく担当範囲を材料にするほうが実際的です。以下はその整理です。

材料となる要素	提示のしかた
担当する工程	移行方式の設計や技術判断まで担うなら、上位職種の水準（約98.9万円）4が判断材料になります
仕様の可視化の実績	コードから業務仕様を復元し、文書として残した経験を具体的に示します
止めなかった実績	制度改正対応や障害対応で、業務を止めずに完了させた件数と規模を挙げます
引き継ぎ可能性	属人化を減らすドキュメントやレビューの体制づくりに貢献できると示します

「希少だから高い」が成立しにくい理由

扱える人が少ないのに、条件が思ったほど上がらない場面があります。理由は、依頼側が「維持のための人手」として枠を組んでいる場合が多いからです。維持は予算が固定されやすく、交渉の余地が狭くなります。

逆に、刷新や移行の検討は投資の枠で語られます。同じシステムを相手にしていても、どちらの枠に入るかで条件は変わります。移行の判断材料を出せる立場に寄せると、この枠が動きます。

経産省のレポートでも、モダン化には情報システム部門の自律性や事業部門との連携が有効だと整理されています¹。外部から入る人が、その連携を進める役を担える場面は少なくありません。

希少さを主張するより、任せられる範囲を示すほうが交渉は進みます。まずは全体平均の76.5万円を基準線に置いて考えてみましょう。

5. COBOL案件に参画する3つのステップ

1. スキルの棚卸し：関わった業種（金融・保険・公共・製造など）、扱った環境、担当した工程を書き出します。業務知識は言語スキルと同じくらい評価されます。
2. 実績の言語化：制度改正対応を何件完了させたか、障害をどのくらいの時間で収束させたか、仕様書のない機能をどこまで文書化したかを具体的に示します。
3. 案件参画：マッチングサービスに登録し、経験に合う案件をクライアントと協議しながら決めます。稼働形態やセキュリティ要件は契約前に確認しておくと安心です。

Remoguが扱う案件は90%以上がフルリモート可能で⁵、ハイブリッド型も含めて幅広く公開されています。仕様の可視化や移行設計はリモートでも進めやすく、地方在住であることは妨げになりません。

6. まとめ

古いから価値がない、ではありません。動かし続けてきた経験を、次へ渡す力に言い換えてみませんか。

7. よくある質問

Q1．COBOLの経験が古くても案件に参画できますか。

読解と業務知識が評価されるため、経験年数が過去のものでも活かせる場面があります。まずは保守・改修や仕様の可視化といった類型から入り、移行設計へ広げる進め方が現実的です。

Q2．COBOL案件はリモートで参画できますか。

仕様の可視化や移行設計はリモート中心で進めやすい類型です。ただし金融や公共の領域では、セキュリティ要件により稼働形態が限られる場合があります。Remoguが扱う案件は90%以上がフルリモート可能です⁵。

Q3．生成AIがコードを読めるなら、需要は減りませんか。

読解の下書きは道具で速くなります。一方で基幹システムは誤りの影響が大きく、出力を検証して採否を決める役割が必要です。DX推進人材の不足も続いています²。

Q4．COBOLだけでなく、何を足すとよいですか。

移行先の環境の知識（クラウドや現行の言語）と、データ検証の手法が有効です。新旧を比べて差異を説明できると、移行設計に関わりやすくなります。表3の応用から発展のレイヤーが、そのまま次の一手になります。

Q5．基幹システムの案件は稼働時間が読みにくいのでは。

制度改正やリリースの前後は負荷が高まりやすい領域です。だからこそ、稼働時間の上限や対応時間帯、障害時の連絡体制を契約前にクライアントと協議しておくことが重要になります。条件を明確にしてから参画すれば、長く続けやすくなります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 経済産業省「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」（2025年5月28日）
＊2 IPA「DX動向2025（AI時代のデジタル人材育成）」ディスカッション・ペーパー（2025年10月）
＊3 総務省「令和7年版情報通信白書」（2025年）生成AIの個人利用経験
＊4 Remogu「職種別・言語別の月額報酬ランキング」調査（2024年）
＊5 Remoguサイト公開情報（フルリモート可能案件の割合）