LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

COBOL技術者不足とは — 高齢化・退職・育成断絶の三重苦

COBOL技術者不足の補完策とは、COBOL（Common Business Oriented Language：事務処理用の歴史ある高水準言語）を扱える技術者を自社だけでは確保できなくなった状況において、ニアショア（地方拠点の技術者を活用した外部委託）や受託外注を通じてレガシーシステムの保守・運用を継続するための取り組みを指します。

COBOLは1960年代から金融機関・官公庁・大企業の基幹システムで使われてきた言語です。膨大な業務ロジックを抱えたシステムが今も現役で稼働しており、その保守・運用を担ってきた技術者の高齢化が進んでいます。

新規育成の担い手が限られる一方で、基幹システムの維持ニーズは続きます。この需給ギャップを埋める現実的な選択肢として、ニアショアや受託外注によるCOBOL保守の補完が注目されています。

「2025年の崖」とCOBOL保守リスク — 経産省DXレポートが示す警告

経済産業省は2018年に公表したDXレポート（「DXレポート〜ITシステム『2025年の崖』克服とDXの本格的な展開に向けて〜」）において、老朽化・複雑化・ブラックボックス化した既存システムを刷新しない場合、2025年以降に大規模なシステム障害や競争力低下のリスクが高まると指摘しました^*1。

同レポートでは、こうした状況が続いた場合に生じうる経済的損失の試算が示されています。DXが進まない場合の損失見込みとして年間12兆円規模という数値が示されています（レポートの試算値であり確定値ではありません）^*1。

COBOLを含むレガシーシステムはこの「既存システムのブラックボックス化」の典型例です。システム仕様が現役技術者の記憶の中にしか残っていないケースも多く、退職による知識断絶が保守の継続を直接脅かすリスクになります。

保守が止まるとどうなるか — 金融・公共・基幹システムへの影響

COBOL技術者が不足し保守が滞ると、具体的にどのようなリスクが生じるかを整理しておく必要があります。影響が深刻になりやすいのは、金融機関の勘定系システム・官公庁の行政処理システム・製造業の在庫・原価管理システムなど、業務の根幹を担う基幹系です。

障害発生時に対応できる技術者がいなければ、サービス停止が長期化するリスクがあります。金融機関であれば入出金・振込処理の停止、官公庁であれば給付業務・税務処理の遅延が直接的な被害として現れます。また、法改正・税率変更・制度改定にともなうシステム改修が遅延した場合、コンプライアンス上の問題が生じることもあります。

内製でCOBOL技術者を確保しようとする場合、現状の採用市場では経験者が極めて少なく、人材を補充できないまま既存技術者への依存が続きやすい状況です。この属人性リスクこそが、外部委託・ニアショア活用を検討すべき出発点になります。

ニアショア・受託外注でCOBOL保守を補完する打ち手

COBOL保守を外部で補完する主な選択肢は、受託保守（成果物責任型の保守委託）とニアショアSES（地方拠点のCOBOL技術者が遠隔で常駐参加する形態）の2系統です。プロジェクトの特性に応じた使い分けが重要になります。

受託保守は、保守範囲（対象システム・対象機能・対応時間帯）を契約書に明記し、委託先が責任を持って対応する形です。社内にCOBOL技術者がいない場合でも業務継続性を確保しやすく、障害対応・定期メンテナンス・法改正対応といった保守業務を一括して委ねられます。

ニアショアSES（地方拠点のCOBOL技術者が遠隔で保守業務に参加する形態）は、長期継続的な保守に適しています。社内エンジニアと協働する過程でシステムの業務ロジックが徐々に共有され、知識の社内蓄積が進みやすい利点があります。

ドキュメント化・知識移転 — 委託前に整えるべき準備

COBOL保守を外部に委託する際、準備不足のまま移行すると委託先が業務ロジックを把握できず、障害対応や改修に長時間を要するリスクが生じます。委託前にドキュメント化と知識移転の基盤を整えることが、スムーズな移行の前提条件です。

業務仕様書とソース解析資料の整備

最初に取り組むべきは、業務仕様書とソース解析資料の作成です。COBOLプログラムの各モジュール（プログラムIDと処理概要）、画面・帳票・バッチとの対応関係、データ項目の定義（WORKING-STORAGE・FD節の主要変数の意味）を文書化します。

長年の改修で積み上げられたロジックが「現役技術者の頭の中」にしか残っていないケースでは、退職前に口頭ヒアリングを実施して記録することが急務になります。この段階を省略すると、委託先が保守を担えないだけでなく、自社内でも引き継げる人がいなくなるリスクが高まります。

並走期間の設計と知識移転セッション

現役のCOBOL技術者と委託先が一定期間並走する移行フェーズを設けることが大切です。並走期間中に、実際の障害対応や定期メンテナンス作業を委託先が担当し、社内技術者が確認・補足する役割を担う形にすると、実務ベースでの知識移転が進みます。

週次または隔週の技術レビューセッションを契約に組み込み、変更履歴・対応記録を双方が参照できる共有ドキュメントで管理する仕組みを整えると、委託先への依存度を段階的にコントロールしやすくなります。

当面の保守補完と並行モダナイゼーションへの橋渡し

COBOL保守の外部補完は「当面の業務継続」という短期的な解ですが、中長期的にはレガシーシステムそのものの近代化（モダナイゼーション）を並行して検討する必要があります。保守補完とモダナイゼーションは対立する選択肢ではなく、段階的に移行するための橋渡しとして組み合わせることが実務上は現実的です。

段階的移行：サブシステム単位でのAPI化・モジュール分離

一気にすべてのCOBOLシステムを刷新するのは費用・期間・リスクの面で現実的でないケースが多いです。影響範囲が小さく独立性の高いサブシステムから段階的に移行する手法が取られることがあります。

具体的には、COBOLのバッチ処理の一部をAPIとして外部公開し、新しいフロントエンドやサービスから呼び出せる形にするアプローチです。COBOLコアを動かし続けながら周辺から新技術で包んでいく「ストラングラーフィグパターン（既存システムを徐々に置き換える設計手法）」が有効なケースがあります。

保守委託先をモダナイゼーションの協力者として活用する

COBOL保守を受託する委託先の中には、移行支援（COBOL資産の分析・移行先言語の提案・段階移行の設計）までカバーできる先もあります。保守委託の段階から移行計画を共同で策定できる委託先を選ぶと、業務継続と近代化を一貫した体制で進めやすくなります。

ただし、移行には相応のコストと期間が必要であり、保守費用とは別の予算計画が求められます。移行後のランニングコストと移行前の保守コストを比較した上で、段階的な移行計画を立てることをお勧めします。

費用・単価の目安（市場参考値）

COBOL保守委託の費用は、対象システムの規模・複雑度・対応時間帯・委託先の体制によって大きく変わります。以下に示すレンジはあくまで市場参考値であり一次資料ではないため、実際の費用は複数社への個別見積もりで確認してください。

受託保守（月次保守契約）の場合

COBOL技術者は市場での希少性が高いため、一般的なITエンジニアよりも単価が高めになる傾向があります。月次の保守契約では、対象システムの規模・対応範囲（障害対応・定期メンテナンス・法改正対応など）・担当人数によって月額費用が変わります。

スポット対応（緊急障害・臨時改修）が発生した場合は別途費用が加算されるケースが多く、年間の保守予算を立てる際は定常保守費用とスポット対応費用の両方を見込んでおくことが大切です。

ニアショアSESの場合

ニアショアSES（地方拠点のCOBOL技術者がリモートで保守参加する形態）では、担当技術者のスキルレベル・経験年数に応じた月額単価が発生します。COBOL実務経験者は希少なため、スキルレベルによる単価差が大きいです。

東京・大阪などの大都市圏と比べて地方拠点では人件費が抑えられるケースがあり、ニアショア特性がCOBOL領域でもコスト面で機能する場合があります。ただし、対象システムに合った業務知識・メインフレーム運用経験があるかどうかは、単価以上に重要な確認項目です。

委託先の選び方 — メインフレーム実績・COBOL対応・体制の3軸

COBOL保守を外部に委託する際に失敗しないためには、委託先の選定が極めて重要です。COBOL固有の技術実績・対象業種・システム種別の実績・保守継続体制の3軸で評価することをお勧めします。

技術軸：COBOL実務経験とメインフレーム運用知識

COBOL保守には言語知識だけでなく、メインフレーム（IBM System z等の汎用機）やオフコンの運用知識、JCL（Job Control Language：バッチジョブ制御言語）・VSAM（仮想記憶アクセス方式のファイル管理）・CICS（トランザクション処理ミドルウェア）といった周辺技術への理解も必要です。

委託先に「COBOL保守の実務経験年数」「メインフレーム保守実績の有無」「担当できる技術者の人数・スキルレベル」を確認することが大切です。Web系・オープン系に強い開発会社でも、メインフレーム保守は経験がないケースがあるため、確認を省略しないことが重要です。

領域軸：業種・システム種別に合った保守実績

金融機関の勘定系・官公庁の行政処理・製造業の原価管理では、業務ロジックの複雑度や法的要件が異なります。自社の業種・システム種別に近い保守実績を持つ委託先を選ぶと、業務の特性を踏まえた対応が期待しやすくなります。

提案依頼（RFP）には「対象業種での保守実績の概要」「過去の障害対応事例（匿名可）」を記載するよう求め、回答の具体性から判断することが有効です。

体制軸：元請として一貫して対応できるかどうか

COBOL保守を複数の下請けベンダーを経由する体制で委託すると、障害発生時の一次対応・エスカレーション・業務オーナーとの調整に時間がかかるリスクがあります。元請（プライムベンダー）として責任を一手に担い、保守・緊急対応・改修・ドキュメント更新まで一貫して対応できる委託先を選ぶことで、窓口コストを削減できます。

また、将来のモダナイゼーション移行を見据えている場合は、COBOL資産の分析・移行先技術の提案まで対応できる委託先かどうかも確認しておくと、保守から移行への連続性が確保しやすくなります。

LASSICのIT事業部では、元請（プライムベンダー）としての受託実績をもとに、保守継続から段階的なモダナイゼーション支援まで対応しています。ご相談はIT開発支援サービスページからどうぞ。

まとめ：COBOL技術者不足への対応で押さえる3つの判断軸

本稿では、COBOL技術者不足の背景と「2025年の崖」が示すレガシーシステムリスク、ニアショア・受託外注による保守補完の選択肢・委託前の準備・費用感・委託先の選び方、そして並行モダナイゼーションへの橋渡しを整理しました。要点を3つにまとめます。

第一に、COBOL技術者の高齢化・退職進行と新規育成の断絶により、内製での技術者確保が難しくなっています。ニアショアや受託外注による外部補完が、業務継続性を確保するための現実的な打ち手です。

第二に、保守委託を進める前に業務仕様書・ソース解析資料の整備と並走期間の設計が欠かせません。ドキュメント化なしに委託を開始すると、委託先が保守対応できない状態が続くリスクがあります。準備段階への投資が長期的なコストを抑えます。

第三に、当面の保守補完と並行してモダナイゼーションの計画を立てることが中長期のリスク低減につながります。段階的なサブシステム移行や委託先との共同移行計画など、保守と移行を連続した取り組みとして設計することをお勧めします。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：経済産業省「DXレポート〜ITシステム『2025年の崖』克服とDXの本格的な展開に向けて〜」（2018年）— https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html

Tweet