運用管理の現場で気になる人口比較！COBOLとシェルスクリプトのどっちが現在も多くの人に使われているか

運用管理の現場で、ふと「いまどちらのスキルがより多く使われているのだろう」と気になることがあります。
それはCOBOLとシェルスクリプトです。
一方は1950年代に生まれたビジネス言語の老舗。
もう一方はUnix系OSと共に育った軽量な自動化ツール。
両者はまったく異なる出自と役割を持ちながら、現在進行形でシステム運用を支えています。
しかし、「使われている」という言葉の解釈が曖昧だと、比較は混乱します。
そこで本稿では、以下の3つの軸で定量的に考察します。

• アクティブな実務従事者数：日常的にコードを書くエンジニアの概算
• 既存コードベースの総量：稼働中のプログラム行数やジョブ数
• 新規プロジェクトでの採用頻度：ここ3年以内に書き起こされた案件の割合

まずアクティブ従事者数ですが、これは明確にシェルスクリプトが優勢です。
なぜなら、シェルスクリプトはクラウドネイティブな環境でもコンテナ起動前後の初期化やヘルスチェック、CI/CDパイプラインで日常的に使われており、DevOpsエンジニアのほぼ全員が何らかのシェルコードを書くからです。
日本国内だけでも数十万人単位の層が該当します。
対してCOBOLの現役プログラマーは、金融・保険・公共系のメインフレーム維持に従事するベテラン層が中心で、その総数は数万人規模と推定されます。
単純な人数比較ではシェルスクリプトに圧倒的な開きがあります。

しかし、既存コードベースの総量という観点では状況が逆転します。
日本の基幹系システムで稼働するCOBOLプログラムの総行数は、いまだに数十億行に達すると言われており、毎日のバッチ処理や決済システムの核として動作しています。
シェルスクリプトは軽量で分散しやすい反面、1つのスクリプトが数百行を超えることは稀で、トータルの行数ではCOBOLの足元にも及びません。
つまり、「書かれている量」ではCOBOLが依然として圧勝しています。

新規プロジェクトの採用頻度で見ると、シェルスクリプトはほぼ全ての新設システムで何らかの形で採用されるのに対し、COBOLは既存システムのリプレイスや改修に限られ、新規書き起こしは年間で数パーセント未満です。
この点だけを取ればシェルスクリプトの一人勝ちですが、運用管理の現場では「動いているものの重み」が重要です。

結論として、「多くの人に使われている」を人的リソースで解釈するならシェルスクリプトが明らかに多く、稼働資産で解釈するならCOBOLが依然として無視できない存在です。
運用管理の現場では、この2つのスキルセットは補完関係にあります。
たとえば、夜間バッチの監視スクリプトをシェルで書き、その起動条件や異常時の再実行制御をCOBOL側で受け持つ、といった連携が日常的に行われています。
どちらか一方だけを学べば十分という時代は終わり、両方の振る舞いを理解した上で、適材適所に使い分けることが真の運用管理力と言えるでしょう。

はじめに：COBOLとシェルスクリプト、運用管理の現場で今どちらが生きているか

運用管理の現場に携わっていると、必ず一度は耳にする議論があります。
それは「COBOLはもう古いのでは」「シェルスクリプトだけで十分ではないか」というものです。
しかし、実際にシステムの稼働を支える立場から言えば、この問いはそれほど単純ではありません。
なぜなら、両者はまったく異なるレイヤーで動作し、異なる目的を持っているからです。
それでもなお、人的リソースの配分や教育投資の優先順位を決めるうえで、どちらにより多くの現場の人間が関わっているのかという事実は、非常に実用的な知見となります。

まず、COBOLは1960年代から金融や保険、公共分野の基幹システムで使われ続けてきた言語です。
その特徴は、圧倒的なトランザクション処理能力とレコード指向のデータ構造にあります。
いまだに日本の銀行の勘定系システムや年金管理システムのコア部分はCOBOLで記述されており、1日のバッチ処理で数千万件の更新を捌くことも珍しくありません。
一方のシェルスクリプトは、Unix系オペレーティングシステムのシェル（bashやzshなど）で動作するスクリプト言語で、ファイル操作やプロセス制御、テキスト処理を得意とします。
クラウド時代になった現在では、コンテナの起動前後処理やヘルスチェック、CI/CDパイプラインの各ステージで頻繁に利用されています。

ここで重要なのは、両者は競合関係ではなく補完関係にあるという点です。
例えば、夜間に稼働する大規模バッチ処理の本体をCOBOLで書き、その起動タイミングや異常時の再実行制御をシェルスクリプトで行う、という構成は実際の現場でごく普通に見られます。
つまり、どちらか一方だけが「生きている」のではなく、異なる役割で並存しているのが実態です。

しかし、運用管理者として現場の人員計画を立てる際には、それぞれのスキル保有者の母数を知ることが欠かせません。
新人教育のカリキュラムを組むにしても、外部委託先を選定するにしても、市場にどの程度の人数が存在するかは重大な判断材料になります。
そこで本記事では、以下の3つの指標を用いて定量的に比較を試みます。

• アクティブな実務従事者数：現在、日常的にコードを書いているエンジニアの概算
• 既存コードベースの総量：稼働中のプログラム行数やジョブ数で測る資産規模
• 新規プロジェクトでの採用頻度：直近3年以内に書き起こされた案件での採用割合

これらの指標はそれぞれ異なる「使われ方」を反映しており、1つの数字だけでは全体像を掴めません。
たとえば、新規案件での採用が少なくても、既存資産の維持運用には多くの人が必要とされるケースがあります。
逆に、日常的に書く人は多くても、1人あたりのコード量が少なければ総合的な影響度は限定的です。

また、技術のトレンドとして、クラウドネイティブな開発が主流になるにつれてシェルスクリプトの重要性は増しています。
一方で、レガシーシステムのモダナイゼーションプロジェクトにおいては、COBOLから他の言語への移行作業が活発化しており、その作業自体がCOBOLの知識を必要とするため、需要が完全に消えることはないでしょう。

本記事では、こうした複眼的な視点を持ちながら、現時点でどちらのスキルがより多くの現場人材に支えられているのかを論理的に解き明かしていきます。
最初に各言語の技術的特徴を整理し、その上で市場統計や業界の実態に基づいた比較を行います。
最終的には、運用管理の現場で実際にどのようなスキル構成が理想的なのか、実践的な示唆を得られることを目指します。

そもそもCOBOLとはどんな言語で、今どこで動いているのか

COBOL（Common Business Oriented Language）は、1959年にCODASYL委員会によって設計された、ビジネスデータ処理を主目的とする高水準プログラミング言語です。
当時のコンピュータリソースが極めて限られていた時代に、効率的なバッチ処理とレコード単位の入出力を最適化するよう設計されており、その構文は英語の自然言語に近い記述性を持っています。
ADDやSUBTRACT、MULTIPLYといった演算命令や、DATA DIVISIONによるデータ構造の厳格な定義が特徴的で、COBOLのコードは「自己文書化」されていると評されることもあります。

COBOLの最も顕著な特徴は、ファイルシステムと密接に連携したレコード指向のデータ処理にあります。
リレーショナルデータベースが主流になる以前から、VSAM（Virtual Storage Access Method）や順次ファイル、インデックス付きファイルを直接操作する能力を持ち、大量のトランザクションデータを高速にソート・集計・更新することが得意です。
また、固定小数点演算を標準でサポートしているため、金額計算や利率計算において誤差が発生しにくいという実務上の利点もあります。
このため、金融機関や保険会社、公共年金システムでは、COBOLが今なお第一級の実装言語として君臨しています。

では、実際に現在どのような環境でCOBOLが稼働しているのでしょうか。
もっとも代表的なのはIBMのメインフレーム（z/OS） 上での運用です。
大手上場銀行の勘定系システム、証券会社の決済システム、あるいは全国規模の公共料金請求システムなど、1日数千万件から数億件のトランザクションを処理するバッチジョブの多くが、メインフレーム上のCOBOLプログラムとして実装されています。
これらのシステムは24時間365日稼働を前提として設計されており、ダウンタイムは年間で数分単位に抑えられています。

また、メインフレームだけでなく、オープン系のUnix/Linuxサーバー上で動作するCOBOLも存在します。
Micro Focus社のCOBOLやGNU COBOLといった実装を使えば、x86サーバー上でもCOBOLプログラムをコンパイル・実行できます。
実際、地方銀行や信用金庫、生損保のバックオフィスシステムでは、比較的低コストなオープン系プラットフォームにCOBOLアプリケーションを移行した事例が増えています。

さらに、クラウド環境でCOBOLが動作するケースも出てきています。
AWSやAzure上でメインフレームエミュレーションを行い、その上でCOBOLバイナリを実行するというアーキテクチャです。
これは完全なリプレイスではなく、リフト＆シフトと呼ばれる移行パターンに該当し、クラウドのスケーラビリティを活かしつつ、既存のCOBOL資産をそのまま活用できるメリットがあります。

ここで押さえておきたいのは、COBOLが動いている現場は決して「過去の遺物」ではないという事実です。
むしろ、日本経済の基盤を支える最重要システムの核心部分で、今日も現役で稼働し続けています。
そして、それらのシステムを運用するためには、COBOLのコードを読み解き、障害時に修正し、性能チューニングできる人材が不可欠です。
実際の現場では、以下のような役割でCOBOL技術者が活躍しています。

• バッチジョブのスケジュール設計と実行監視
• 障害時のアボート原因調査とプログラム修正（デバッグ）
• 年度末や四半期末の大量決済処理における性能調整
• 既存プログラムのリファクタリングや、他言語との連携部分のインターフェース実装

このように、COBOLは単なる「古い言語」ではなく、現在進行形で日本の社会インフラを支える実戦言語です。
次のセクションでは、これと対比する形でシェルスクリプトの実態を詳しく見ていきます。

シェルスクリプトの実態：ただの自動化ツールではない多様性

シェルスクリプトと聞いて、多くのエンジニアがまず思い浮かべるのは「軽量な自動化のためのお手軽スクリプト」というイメージではないでしょうか。
確かにその側面は間違いありませんが、実際の運用現場におけるシェルスクリプトの役割は、単なるバッチ代替にとどまらず、システム全体の制御層としての機能を担っています。
シェルスクリプトはUnix系OSの標準インターフェースであり、ほぼすべてのLinuxディストリビューションでbashやPOSIX準拠のshが利用可能です。
このユビキタス性が、シェルスクリプトをインフラストラクチャの「接着剤」として機能させる最大の強みです。

シェルスクリプトの本質は、ファイルシステム、プロセス、パイプ、シグナルといったOSプリミティブを直接操作できることにあります。
たとえば、grepやsed、awkといったフィルタコマンドをパイプで連結することで、数十GBのログファイルから特定のパターンを抽出し、集計してメールで通知するといった処理を、わずか数行のコードで実装できます。
このような処理をPythonやJavaで書こうとすると、ファイルI/Oや正規表現エンジン、メール送信ライブラリなどを明示的にインポートし、ビルドや依存関係の管理も必要になりますが、シェルスクリプトなら標準コマンドの組み合わせだけで完結します。

また、シェルスクリプトはプロセス制御に非常に長けています。
バックグラウンド実行やジョブ制御、シグナルハンドリングをシンプルな文法で記述でき、trapコマンドを使えばスクリプト終了時のクリーンアップ処理を確実に実行することが可能です。
さらに、cronやsystemdタイマーと連携することで、定時実行のバッチ処理を容易に構築できます。
このため、システム監視やヘルスチェック、ログローテーション、バックアップの自動化といった運用タスクの多くがシェルスクリプトで記述されています。

現代のクラウドネイティブな環境では、シェルスクリプトの役割はさらに拡張しています。
Dockerコンテナのエントリポイントスクリプトとして、コンテナ起動時に環境変数のチェックや設定ファイルの動的生成を行ったり、KubernetesのinitコンテナやpostStartフックとしてメインコンテナの事前準備を担当したりします。
また、CI/CDパイプラインでは、ビルドステップの前後処理やデプロイメントスクリプトとしてシェルが多用され、GitHub ActionsやGitLab CIでもシェルコマンドを直接記述するケースが圧倒的に多いです。

ここで注目すべきは、シェルスクリプトが「書く人」の範囲を広げているという点です。
バックエンドエンジニアだけでなく、インフラエンジニア、SRE、データエンジニア、さらにはQAエンジニアまでもが、日々の作業効率化のためにシェルスクリプトを書きます。
つまり、シェルスクリプトのユーザー層はCOBOLよりも桁違いに広く、かつ多様です。
以下に、現場で見られる具体的なユースケースを挙げてみます。

• 複数サーバーへの一括コマンド実行やファイル配布（sshとループ処理の組み合わせ）
• アプリケーションログからエラー発生率を集計し、閾値を超えたらSlack通知する監視スクリプト
• データベースのバックアップを取得し、圧縮してS3にアップロードする夜間バッチ
• 新規インスタンス起動時の初期設定（ホスト名変更、パッケージインストール、ファイアウォール設定）を自動化するセットアップスクリプト
• 複数のマイクロサービスのビルドとデプロイを直列・並列で制御するデプロイメントオーケストレーション

このように、シェルスクリプトはスコープが極めて広く、短納期で変更に強いという特性を持っています。
もちろん、複雑なビジネスロジックや大規模なデータ構造の操作には向きませんが、運用管理の文脈では「制御」と「連携」という本質的な役割を担っており、その重要性はむしろ増す一方です。
次のセクションでは、このようなシェルスクリプトの多様性を踏まえたうえで、COBOLとの従事者数の比較に入るための指標を整理します。

従事者数を比較する前に押さえるべき3つの指標

「COBOLとシェルスクリプト、どちらがより多くの人に使われているか」という問いに答える際、まず注意しなければならないのは 「使われている」という表現の多義性 です。
単に「コードを書いたことがある人数」で測るのか、「現在日常的に業務で使用している人数」で測るのか、あるいは「そのスキルを求める求人数」で測るのかによって、答えは大きく変わります。
そこで本記事では、比較のための指標として以下の3つを定義します。
これらは相互に排他的ではなく、むしろ補完関係にあるため、全てを総合的に評価することが肝要です。

1つ目の指標は「アクティブな実務従事者数」 です。
これは、現在の業務において週に1回以上、該当言語でコードを記述または修正しているエンジニアの人数を指します。
この指標は 人的リソースの流動性 を反映しており、採用市場や教育投資の判断材料として最も実用的です。
ただし、同じ「従事者」でも、フルタイムで専従するケースと、週に数時間だけ関与するケースがあり、その質も考慮する必要があります。

2つ目の指標は「既存コードベースの総量」 です。
これは、稼働中のシステム全体に含まれる該当言語のプログラム行数や、ジョブ数、モジュール数などの資産規模を示します。
この指標は 過去の投資の累積 を表しており、保守運用に必要な工数の見積もりに直結します。
たとえば、従事者数が少なくてもコードベースが膨大であれば、その言語のエコシステムは依然として経済的影響力を持ちます。

3つ目の指標は「新規プロジェクトでの採用頻度」 です。
これは、直近3年以内に開始された新規開発または大規模リプレイス案件において、該当言語が主要な実装言語として選定された割合を指します。
この指標は 将来性とトレンド を映し出すもので、エンジニアのキャリア選択やベンダーの技術戦略に大きな影響を与えます。
新規案件での採用が少ない言語は、いずれ人材の新規流入が途絶えるリスクをはらんでいます。

これら3つの指標は、それぞれ異なる時間軸と視点を持っています。
アクティブ従事者数は「現在の現場の生きた力」、コードベース総量は「過去から積み上がった重み」、新規採用頻度は「未来への投資意欲」を表していると言えるでしょう。
したがって、ある言語が「多く使われている」と主張するには、少なくともこのうち2つ以上で優位性を示す必要があります。

また、これらの指標は業界や企業規模によっても偏りが生じます。
金融・保険業界ではCOBOLのコードベースが圧倒的に大きい一方、Web系スタートアップではシェルスクリプトの従事者数がほとんど全てのエンジニアをカバーします。
そのため、本記事では日本国内の運用管理現場に焦点を絞り、特に基幹システムとクラウドネイティブシステムの両方を扱う中規模から大規模の企業を対象とします。

以上の前提を踏まえたうえで、次のセクションからは各指標ごとにCOBOLとシェルスクリプトを詳細に比較していきます。
単なる総合順位をつけるのではなく、どの指標においてどちらが優位に立ち、その理由は何かを論理的に掘り下げることが目的です。
そうすることで、運用管理の現場で実際にどのスキルに優先的に投資すべきか、あるいは両方をバランスよく育成すべきかという実践的な判断材料を提供できると考えています。

アクティブな実務従事者数ではシェルスクリプトが圧倒的である理由

最初の指標である「アクティブな実務従事者数」において、シェルスクリプトはCOBOLに対して桁違いの優位性を持っています。
この差は単なる推測ではなく、開発環境の変化、エンジニアの役割の多様化、そして学習のハードルの低さという3つの要因によって構造的に生まれています。
まずはそれぞれの要因を分解しながら、なぜこのような差が生じているのかを論理的に見ていきましょう。

第一の要因は、シェルスクリプトがほぼ全てのUnix/Linux環境で標準的に利用可能であるというユビキタス性です。
クラウド上の仮想マシン、オンプレミスのサーバー、コンテナイメージ、さらにはmacOSやWindows（WSL経由）に至るまで、シェルはどこにでも存在します。
そのため、インフラエンジニア、SRE、バックエンド開発者、データエンジニア、さらにはQAやセキュリティエンジニアに至るまで、幅広い職種のエンジニアが日常的にシェルを操作し、必要に応じてスクリプトを書く習慣を持っています。
ある調査では、DevOps関連のエンジニアの約9割が月に1回以上シェルスクリプトを編集しているというデータもあり、その裾野の広さは他のスクリプト言語と比較しても群を抜いています。

第二の要因は、学習コストの極端な低さにあります。
シェルスクリプトは、対話的に実行するコマンドをそのままファイルに記述するだけで動作するため、プログラミング初心者でも比較的容易に書き始められます。
変数宣言や条件分岐、ループの文法も簡潔で、たとえば以下のような数行のスクリプトであれば、経験の浅いエンジニアでも30分もあれば作成できます。

#!/bin/bash
LOG_DIR="/var/log/myapp"
ERROR_COUNT=$(grep -c "ERROR" $LOG_DIR/*.log)
if [ $ERROR_COUNT -gt 100 ]; then
    echo "Alert: High error rate detected" | mail -s "Error Alert" admin@example.com
fi

このように、実用的な自動化が極めて少ない記述量で実現できるため、多くのエンジニアが「とりあえずシェルで書いてみる」という選択をします。
結果として、シェルスクリプトを書けるエンジニアの母数は、PythonやJavaScriptと並ぶほどにまで拡大しています。

第三の要因は、現代のアーキテクチャがシェルスクリプトの需要を増幅させていることです。
マイクロサービス化が進み、各サービスが個別にデプロイメントパイプラインを持つようになると、ビルドトリガーや環境変数設定、ヘルスチェックのエンドポイント検証など、サービスごとにカスタマイズされた制御スクリプトが必要になります。
Kubernetes環境では、InitコンテナやPostStartフックとしてシェルスクリプトが埋め込まれるケースが頻繁に見られ、これらは全て運用エンジニアの手によって日々メンテナンスされています。

これに対してCOBOLのアクティブ従事者数は、日本国内で推定数万人程度とされています。
そのほとんどは金融・保険・公共系のメインフレーム運用に携わるシニアエンジニアであり、その年齢層は50代以上が中心です。
新卒でCOBOLを学ぶ機会はほぼ皆無に等しく、既存のスキル保有者が定年退職を迎えるたびに、その人数は確実に減少傾向にあります。
また、COBOLの実務はメインフレームという特殊なオペレーティング環境やJCL（Job Control Language）といった周辺知識も要求されるため、たとえ言語仕様だけを学んでも即戦力にはなりません。

加えて、シェルスクリプトの従事者は単一の業界に依存しないという点も重要です。
Web系、ゲーム系、組込み系、学術計算系、あらゆる分野でシェルは使われており、業界を超えた人材の流動性が高いことも母数を押し上げています。
COBOLが金融・公共という特定ドメインにほぼ限定されているのとは対照的です。

以上の理由から、アクティブな実務従事者数においてはシェルスクリプトが圧倒的かつ拡大傾向にあると結論づけられます。
ただし、この数値は「書く人数」であって「書かれる量」ではない点に注意が必要です。
次節では、コードベース総量という別の指標で両者を比較し、まったく異なる構図が浮かび上がることを見ていきます。

既存コードベースの総量ではCOBOLが依然として君臨する現実

アクティブ従事者数ではシェルスクリプトが圧勝したものの、既存コードベースの総量という指標ではCOBOLが圧倒的な優位性を見せます。
この逆転現象こそが、両言語の比較を単純化できない最大の理由です。
コードベースの総量とは、現在稼働中のシステム全体に含まれる該当言語のプログラム行数、モジュール数、あるいはジョブ数などの総和を指します。
この指標は、過去数十年にわたって積み上げられた資産の大きさを直接反映しており、COBOLが日本の基幹システムにおいてどれほど深く根付いているかを如実に物語っています。

まず、具体的な数字を挙げましょう。
日本の主要銀行の勘定系システムには、数千万行から数億行規模のCOBOLコードが組み込まれていると言われています。
これは単一の企業システムとして世界最大級の規模であり、そのすべてが日々の預金取引、振込処理、為替決済、ローン管理といった中核業務を支えています。
また、全国の生命保険会社や損害保険会社の契約管理システム、さらには公的年金の記録管理システムにおいても、同様に巨大量のCOBOLプログラムが稼働中です。
これらのコードベースは50年以上にわたって継続的に改修・拡張されてきたものであり、一度にすべてを置き換えることは事実上不可能です。

これに対し、シェルスクリプトのコードベース総量はどうでしょうか。
シェルスクリプトは軽量で分散型の性質を持つため、1つのスクリプトはせいぜい数十行から数百行程度であることがほとんどです。
仮に1万台のサーバーそれぞれにデプロイメント用のシェルスクリプトが配置されていたとしても、その総行数はせいぜい数百万行から数千万行にとどまります。
さらに、シェルスクリプトは使い捨てられるケースも多く、一時的な運用タスクのために書かれたスクリプトは、役目を終えると削除されるか放置されるため、正確な総量を把握すること自体が困難です。

ここで重要なのは、コードベースの総量が単なる「過去の遺物」ではないという点です。
大量のコードベースは、それを保守し続けるための継続的な人的リソースを要求します。
COBOLのコードベースは一度書かれたら終わりではなく、法規制の変更、新商品の追加、システム統合や合併に伴うデータ項目の追加など、常に改変が発生します。
そのたびに、COBOLのコードを読み解き、影響範囲を調査し、修正を加え、テストを実施するという一連の工程が必要です。
この作業を支えるために、たとえ新規のCOBOL開発案件が減少しても、既存コードベースの維持だけで一定以上の従事者数が確保されるという構造があります。

また、コードベースの規模は ビジネス上のクリティカル度 とも直結します。
COBOLで書かれたプログラムは、ほとんどの場合、決済や契約といった金銭的・法的な拘束力を持つ処理を担当しています。
そのため、障害が発生すれば即座に経営リスクに直結し、修正の際には徹底した品質保証が求められます。
このようなシステムでは、コードの総量が多いほどテスト範囲も広がり、運用コストが増大するという負の側面も持ち合わせています。

さらに、COBOLのコードベースには ベンダーロックイン という現実も付きまといます。
多くのメインフレームCOBOLプログラムは、IBMの独自拡張や特定のミドルウェア（CICS、IMS、DB2など）に強く依存しており、オープン系への移行には膨大な労力がかかります。
そのため、多くの企業はリプレイスを先送りにし、現状のCOBOL資産を動かし続けるという選択をしています。
この結果、コードベースの総量は減少することなく、むしろ年々わずかながら増加し続けているケースも珍しくありません。

このように、コードベース総量の観点ではCOBOLが圧倒的かつ不動の地位を築いています。
しかし、この膨大な資産を維持するための人材が次第に減少している点は、業界全体にとって深刻な課題です。
次のセクションでは、新規プロジェクトでの採用頻度という未来志向の指標をもとに、両言語のトレンドをさらに掘り下げます。

新規プロジェクトでの採用頻度から見る将来性の差異

3つ目の指標である「新規プロジェクトでの採用頻度」は、未来への投資意欲を測るバロメーターとして極めて重要です。
この指標においては、シェルスクリプトが引き続き優位に立ち、COBOLは極めて限定的な採用にとどまるという明確な差異が現れます。
この差は単なるトレンドではなく、技術要件の変化、開発手法の進化、そして人材獲得の現実を反映した構造的な要因に基づいています。

まず、シェルスクリプトの新規採用頻度が高い理由は、現代のソフトウェア開発ライフサイクルにシェルが深く組み込まれているからです。
クラウドネイティブなアーキテクチャでは、インフラストラクチャのコード化（IaC）が標準となり、TerraformやAnsibleといったツールと併用してシェルスクリプトがプロビジョニングの前後処理を担います。
また、GitOpsスタイルのデプロイメントでは、ArgoCDやFluxCDのフックとしてシェルスクリプトが実行されることが一般的です。
さらに、GitHub ActionsやGitLab CIのようなモダンなCI/CDプラットフォームでは、ワークフローの各ステップをシェルコマンドで記述するケースが圧倒的多数を占めており、新規プロジェクトの立ち上げ時にシェルスクリプトがまったく登場しないというシナリオはほぼ考えられません。

加えて、マイクロサービスやサーバーレスアーキテクチャの普及により、サービス単位で独立したデプロイメントパイプラインが構築されるようになりました。
これにより、各サービスに固有の初期化スクリプトやヘルスチェックスクリプトが大量に新規作成される需要が生まれています。
これらのスクリプトはプロジェクトごとにカスタマイズされるため、新規案件が増えるほどシェルスクリプトの新規コードも比例して増加します。

一方、COBOLが新規プロジェクトで採用されるケースは、以下のような極めて限定的なシナリオにほぼ絞られます。
まず、既存のメインフレームシステムに新たな業務機能を追加する場合です。
この場合、既存のCOBOLプログラム群と整合性を保つために、やむを得ずCOBOLで新規モジュールを書くことがあります。
ただし、これは「新規プロジェクト」というよりは「既存資産の延長上の改修」であり、ゼロベースでCOBOLを選定するケースは事実上存在しません。

次に、大規模なレガシーシステムのリプレイスプロジェクトにおける中間段階として、一時的にCOBOLが使われることがあります。
たとえば、メインフレームからオープン系への移行期間中、既存のCOBOLバッチを一旦クラウド上のエミュレーション環境で動作させつつ、段階的にJavaやPythonなどに置き換えるというアプローチです。
しかし、この場合もCOBOLは「移行対象」であって「新規採用」ではありません。

最後に、極めて特殊なドメイン、例えば航空機の予約システムや鉄道の座席管理システムなど、COBOLで書かれた超長期運用が前提のシステムでは、新規にCOBOLを採用する判断がなされることが稀にあります。
しかし、これらは世界全体で見てもごくわずかな事例にすぎません。

ここで重要なのは、新規採用頻度が低いことは即座にCOBOLの終焉を意味しないという点です。
既存コードベースの膨大さが、改修需要として持続的にCOBOL技術者の雇用を創出し続けています。
しかし、新規流入がほぼない状態が続けば、10年後、20年後には確実に人材不足が深刻化します。
多くの金融機関では、この問題に先手を打ち、社内の若手エンジニアにCOBOL研修を実施したり、メインフレームからオープン系への段階的移行ロードマップを策定したりしています。

結局のところ、将来性という観点では、シェルスクリプトは今後も新規プロジェクトで必須のスキルであり続ける一方で、COBOLは既存資産の管理というニッチでありながら決してなくならない領域に収斂していくでしょう。
運用管理の現場では、この二つの異なる将来性を理解した上で、短期的な改修需要と長期的な人材育成計画をバランスよく設計することが求められます。

運用管理で実際に求められるのは二者択一ではなく補完理解

ここまでの3つの指標を総合すると、シェルスクリプトは「人的リソース」と「将来性」で優位に立ち、COBOLは「既存資産の規模」で圧倒的であるという構図が明確になりました。
この結果だけを見ると、あたかもシェルスクリプトに統一すべきとかCOBOLを早急に廃止すべきといった極端な結論に誘導されがちですが、運用管理の現場における現実はもっと複雑です。
実際には、両者は対立関係ではなく補完関係にあり、それぞれの強みを活かしたハイブリッドな運用体制こそが、堅牢で効率的なシステム運用を実現する鍵となります。

まず、運用管理の基本的な責務を思い出してみましょう。
運用管理とは、システムを安定稼働させ、障害時に迅速に復旧し、性能を最適化し、変更を安全に実施することです。
この一連のタスクを考えると、バッチ処理の核となるビジネスロジックとそれを取り巻く制御や監視のレイヤーが明確に分離されていることに気づきます。
COBOLは前者の「核」に最適化されており、シェルスクリプトは後者の「制御レイヤー」に最適化されています。
両者はまったく異なる抽象度で動作するため、どちらか一方で全てを賄うことは設計として非効率です。

具体的なユースケースを想定してみましょう。
例えば、金融機関の夜間バッチ処理では、COBOLで書かれた複数のプログラムが順次実行され、預金残高の更新や利息計算、取引明細の作成などを行います。
この一連のバッチジョブの実行順序はJCL（Job Control Language）で制御されることが多いですが、JCLだけでは柔軟な条件分岐や異常時の再実行制御が難しいため、シェルスクリプトがその上位制御層として導入されるケースが増えています。
シェルスクリプトは、COBOLプログラムの終了コードを判定し、成功すれば次のプログラムを起動し、失敗すればリトライまたは代替処理を実行し、その結果をメールやSlackで通知するといったオーケストレーションを担当します。

また、監視の観点でも補完関係が顕著です。
COBOLプログラム自体は処理結果をログファイルやテーブルに出力しますが、そのログをリアルタイムに解析し、エラー発生率や処理時間の閾値を超えた場合にアラートを発報するのは、シェルスクリプトの得意とする領域です。
tail -fでログを追跡しながらgrepでエラーパターンを検出し、awkで集計してcurlでWebHookを呼び出すという一連の処理は、数行のシェルスクリプトで実現できます。

さらに、システム変更やリリース作業においても、両者は補完し合います。
新しいCOBOLプログラムを本番環境にデプロイする際、まずシェルスクリプトで既存のプログラムをバックアップし、新しいモジュールを所定のライブラリにコピーし、依存するファイルの整合性をチェックし、必要に応じてDBマイグレーションを実行し、最後にバッチジョブのスケジュールを更新する──こうした一連のデプロイメント手順は、シェルスクリプトなしでは自動化が困難です。

このように、COBOLは「何を処理するか」に集中し、シェルスクリプトは「いつ・どのように・どの順序で」を制御するという役割分担が自然と成立しています。
運用管理者はこの補完構造を理解した上で、それぞれの技術に適切な投資を行うべきです。
COBOLの人材が不足すればバッチの改修や障害解析が遅延し、シェルスクリプトのスキルが不足すれば自動化の質が低下し、手作業が増えてヒューマンエラーが誘発されます。
両者は車の両輪であり、どちらかが欠けても運用の効率性と信頼性は大きく損なわれるという認識が現場では求められます。

スキルセットの市場価値とキャリアパスをどう考えるか

ここまでの議論を踏まえると、運用管理に携わるエンジニアとして、COBOLとシェルスクリプトのどちらを優先的に習得すべきかという問いは、単純な二者択一では答えが出ないことがお分かりいただけるでしょう。
むしろ、それぞれのスキルが持つ市場価値の特性を理解し、自身のキャリアフェーズや志向に合わせて戦略的に投資することが重要です。
このセクションでは、両スキルの市場価値の特徴と、それに基づく実践的なキャリアパスについて考察します。

まず、シェルスクリプトのスキルは汎用性が極めて高く、ほぼ全てのエンジニアにとって基礎教養と言えます。
クラウドエンジニア、SRE、バックエンド開発者、DevOpsエンジニア、データエンジニアなど、職種を問わず日常的にシェルを操作する機会があります。
そのため、シェルスクリプトを習得しておくことは転職市場におけるアドバンテージというよりは、エンジニアとしての最低限の前提条件に近い位置づけです。
実際、多くの求人票では「Linuxコマンドに精通していること」や「シェルスクリプトによる自動化経験」が必須要件として明記されており、これらを満たせない場合、応募書類の通過自体が難しくなります。

一方、シェルスクリプトのスキルだけでは希少性による高単価を期待しにくいという側面もあります。
習得者が非常に多いため、スペシャリストとしての差別化ポイントにはなりにくく、むしろ他のスキル（クラウド運用やコンテナオーケストレーション、監視ツールの深い知見など）との組み合わせで価値が発揮されます。
シェルスクリプトは「道具」であり、それをどう使うかの設計力や運用知見こそが市場価値を決めるという認識が適切です。

これに対し、COBOLのスキルは希少性が非常に高く、特定の業界ではプレミアムがつくという特徴を持ちます。
新規にCOBOLを学ぶ人が極端に少ないため、既存のCOBOLエンジニアは需要に対して供給が追いつかず、年収ベースで見ると同世代の汎用エンジニアよりも高い水準で推移することが多いです。
特にメインフレームの運用経験とCOBOLのデバッグ能力を併せ持つ人材は、金融・保険業界から引く手あまたの状態が続いています。
また、COBOLエンジニアはプロジェクト単位の契約や保守サポート契約といった形でフリーランスとして活動するケースも多く、単価交渉力が比較的高い市場です。

しかし、COBOLスキルには明確なリスクも存在します。
それは市場の縮小傾向です。
金融機関は中長期的にメインフレームからの脱却を進めており、10年後、20年後にはCOBOLの需要は確実に減少していくでしょう。
現在30代のエンジニアが定年を迎える頃には、COBOLの仕事は現在の数分の一にまで縮小している可能性が高いです。
そのため、COBOL一本でキャリアを構築することは、短期的な高収入と長期的なリスキリングリスクのトレードオフと捉えるべきです。

では、現実的なキャリア戦略として何が推奨されるのでしょうか。
私の見解は、シェルスクリプトを基礎として確実に身につけた上で、COBOLはオプショナルな追加スキルとして習得するという段階的アプローチです。
具体的には、以下のようなキャリアフェーズを想定します。

• 若手エンジニア（入社〜5年目）：シェルスクリプトを含むLinux運用スキルを徹底的に習得します。この時期はCOBOLよりも、クラウドやコンテナ、CI/CDといったモダンな技術スタックに投資する方がリターンが大きいでしょう
• 中堅エンジニア（5〜15年目）：自身の所属する業界や企業戦略を見極めながら、COBOLを学ぶかどうかを判断します。金融・公共系に長く居る予定であれば、COBOLの習得は強力な武器になります。一方、Web系やスタートアップ志向ならCOBOLではなく、GoやPythonなどの別の言語に投資した方が賢明です
• シニアエンジニア（15年目以降）：COBOLの深い知見を持つ場合は、その希少性を最大限に活かしたスペシャリスト路線か、あるいはマネジメントやアーキテクトとしてシステム全体の移行戦略をリードする路線を選びます。後者の場合、COBOLだけでなくモダンな技術とのブリッジ役としての知識が求められます

最後に、両方のスキルをバランスよく持つことのアドバンテージも強調しておきます。
COBOLのコードを読めるエンジニアがシェルスクリプトで監視・デプロイ自動化を設計できると、障害時の調査範囲が格段に広がり、単一のエンジニアでレイヤーを越えた問題解決が可能になります。
このような「T字型」ならぬ「π字型」のスキルセットは、運用管理の現場で非常に重宝され、結果として長期的なキャリアの安定性にもつながります。
市場価値はその時々の需給で変動しますが、幅広いレイヤーを俯瞰できる視野はどの時代でも評価される資質であると確信しています。

まとめ：数字が示す真実と現場のリアルバランス

ここまで、COBOLとシェルスクリプトを3つの指標（アクティブ従事者数、既存コードベース総量、新規案件採用頻度）に基づいて比較し、さらに運用管理での補完関係やキャリア戦略までを論じてきました。
最終的なまとめとして、数字が示す客観的な真実と現場で実際に体感されるリアルなバランスを整理し、運用管理に携わる皆さんが今後の方針を立てる際の指針を提示したいと思います。

まず、数字が示す真実を簡潔に要約します。
アクティブな実務従事者数ではシェルスクリプトが数十万人規模で圧倒し、COBOLは数万人程度に留まります。
既存コードベースの総量ではCOBOLが数十億行と桁違いに大きく、シェルスクリプトはその数分の一です。
新規プロジェクトでの採用頻度ではシェルスクリプトがほぼ全ての案件で採用されるのに対し、COBOLは新規書き起こしが1％未満という極端な差がついています。
これらの数字だけを並べれば、シェルスクリプトが現代の主流であり、COBOLは縮退するレガシーという単純な図式が浮かび上がります。

しかし、現場のリアルバランスはこの図式よりもずっと微妙です。
確かにシェルスクリプトを書くエンジニアは多いですが、その多くはシェルスクリプトを「主戦場」としていません。
彼らはあくまで本業の開発や運用の一部としてシェルを使っているに過ぎず、シェルスクリプトだけで生計を立てている専門家はごくわずかです。
一方、COBOLエンジニアはCOBOLが主戦場であり、そのスキルセットだけで高度な専門性を提供しています。
つまり、「使っている人数」と「そのスキルに依存している人数」は異なるという点が重要です。

また、障害対応の現場では、COBOLの知識が生死を分けるケースが少なくありません。
バッチ処理が異常終了した際、COBOLのコードを読めなければ原因を特定できず、ベンダーに高額なサポート料を支払って待つしかなくなります。
しかし、シェルスクリプトの不具合であれば、多くのエンジニアが自力で修正可能です。
このクリティカル度の差が、COBOLスキルの希少価値を支えているのです。

さらに、企業の投資判断も数字だけでは測れません。
多くの金融機関はCOBOL資産の完全撤去に数十年単位の期間と数千億円規模のコストを見積もっており、その間はCOBOLエンジニアの確保が経営課題であり続けます。
したがって、COBOLの需要は今後10年間は急減しないという現実的な予測が成り立ちます。
一方で、シェルスクリプトは今後も新規技術と融合しながら進化し続けるため、エンジニアとしての基礎教養としての価値は不変です。

最後に、運用管理の現場で実際に求められるバランス感覚を、以下の3つの指針としてまとめます。

• シェルスクリプトは必修科目として、すべての運用エンジニアが読み書きできる水準を目指すこと。これが自動化の質とトラブルシューティングの速度を決めます
• COBOLは選択科目として、所属する業界や企業のシステム戦略に応じて習得を判断すること。金融・公共系に長く携わるなら積極的な投資価値がありますが、そうでなければ無理に学ぶ必要はありません
• 両方のスキルを持つ人材は、組織内での価値が非常に高いことを認識すること。COBOLのコードを読み解きながら、その運用をシェルスクリプトで高度に自動化できるエンジニアは、どの現場でも重宝されます

結局のところ、「どちらが多く使われているか」という問いの答えは、指標によって異なるというのが最も正確な結論です。
そして、その多面性を理解したうえで、自社のシステム構成や人材プール、中長期計画に照らして最適なバランスを取ることが、運用管理のプロフェッショナルに求められる力量だと言えるでしょう。
数字はあくまで指標であり、現場のリアルは常にそれよりも複雑で、かつ創造的な判断を必要とします。
皆さんの現場で、今日からでもこの視点を活かしていただければ幸いです。